Measure the change, then keep it or revert it
A theme performance log is only useful if it has as many reverts in it as wins. Half the value is writing down what didn't work and why.
Store performance doesn’t decay because developers can’t optimise. It decays because every individual change is defensible in isolation and nobody keeps a running measurement.
On the Informatica theme I keep a small harness: a script that runs Lighthouse five times per page and reports the median FCP, LCP, TBT and CLS, plus a markdown log of every hypothesis I tested and what happened to it.
The log is the deliverable
Here’s a real stretch of it:
- Kept:
fetchpriority="high"on the first two collection-card images. Free, and it lets the browser find the LCP image sooner. - Reverted: deferring the cart-drawer CSS. No FCP gain, and CLS went from 0.02 to 0.5.
- Reverted: preloading the hero image. Load delay dropped, render delay rose by the same amount because the image is CSS-gated. Net zero.
- Reverted: turning animations off. No change — Dawn’s opacity-0.01 trick already avoids the LCP penalty.
- Skipped: minifying assets. Shopify’s CDN already does it.
Four of those five are non-results. Writing them down is what stops me, or the next person, from trying them again in six months.
Measure on the thing you’re shipping
Local dev server scores run about 20 points low because there’s no compression and the proxy adds TTFB. The theme preview URL has noisy uncached TTFB. Only the live storefront number means anything in absolute terms — the other two are for big relative deltas, and you have to say which one you’re quoting.
Know when you’re done with theme code
After a round of this, the Informatica theme’s remaining cost is third-party: a reviews widget worth about 700ms of main thread, and Shopify’s own analytics stack worth another second and not removable. That’s a useful conclusion. It means the next work is app configuration, not Liquid, and I can stop poking at the template.