Shopify speed and Core Web Vitals
A Lighthouse score is a lab measurement of one page on one simulated device. Core Web Vitals are what your actual visitors experienced over the last 28 days, on the phones they actually own. The two disagree often enough that optimising for the first can leave the second untouched, which is how a store ends up with a green score and the same bounce rate it started with.
Measured on your real traffic
Chrome UX Report data and real-user monitoring, segmented by device and template. Lab tools are used for diagnosis, never as the definition of success.
A finding, not a score
Each regression is traced to a specific asset, script or app. "Reduce JavaScript" is not a finding; "this app injects 180KB on every page and is used on two" is.
Budgets, not one-off wins
Performance decays as apps and sections accumulate. The handover includes budgets and a monitoring setup so the next regression is caught rather than rediscovered a year later.
LCP: usually the hero, usually preventable
On most Shopify themes the largest contentful paint is a hero image or an H1 sitting behind a web font. The pattern that causes the damage is consistent: the hero is lazy-loaded along with everything else, so the browser only discovers it after layout, and the one image that needed to arrive first arrives last.
The fixes are unglamorous and they work. Serve the true LCP image eagerly with fetchpriority, never lazily. Size it for the device with a correct srcset rather than shipping a 2400px asset to a phone. Preload one critical asset, not six: a preload list is a priority list, and everything on it competes.
Fonts are the other half. Self-host the weights actually in use, set font-display so text renders immediately in a fallback, and delete the second family nobody remembers adding.
INP: the metric apps break
Interaction to Next Paint measures how long the page takes to respond when someone taps. It is dominated by long main-thread tasks, and on Shopify those overwhelmingly come from apps, each one loading its own JavaScript on every page regardless of whether that page uses it.
So the audit is inventory before optimisation: every third-party script, what it costs, and where it actually runs. Reviews on product pages, upsells at cart, a chat widget everywhere. Several will turn out to be from apps uninstalled months ago whose script tags were never removed.
What survives gets deferred, scoped to the templates that need it, or replaced. What does not survive gets deleted, which is the fastest optimisation available and the one nobody wants to make the decision on.
CLS: reserve the space
Layout shift is caused by content arriving after layout without space held for it. Images without dimensions, embeds sized by their own script, announcement bars injected above the fold, and cookie banners that push the page down half a second after it settles.
The remedy is to reserve dimensions for everything that will arrive, width and height or aspect-ratio on images and embeds, a fixed slot for anything injected, and to stop inserting content above what is already rendered.
What you get at the end
A report with before and after field data, each change and what it moved, an inventory of every third-party script with a keep-or-remove recommendation and the reasoning, performance budgets to hold new work against, and a monitoring setup so the next regression shows up in a dashboard rather than in a quarterly review.
On numbers: I do not quote a percentage improvement before measuring your store. Anyone who does is quoting someone else's result.
Is this the right engagement?
A good fit
- Shopify and Plus stores failing Core Web Vitals on mobile field data
- Stores whose speed degraded as apps and sections accumulated
- Teams who fixed the Lighthouse score and saw nothing change in the field
- Businesses where mobile conversion visibly trails desktop
Not a fit
- Chasing a Lighthouse number as the goal in itself
- Stores wanting speed work without removing any app
- Full theme rebuilds, which is a different engagement
Common questions
Why not just optimise the Lighthouse score?
Because it is a simulation of one page load on one throttled device, and Google ranks on field data from real visitors. They can move independently. I use Lighthouse to diagnose and field data to decide whether the diagnosis was right.
Will I have to remove apps?
Probably some. Every app that injects script on every page is a permanent tax, and a few will be from apps you no longer use. You make the call, I provide the cost per app so it is an informed one.
How long before the numbers move?
Lab measurements move immediately. Field data is a 28-day rolling window, so Core Web Vitals take roughly a month to reflect the work fully, worth knowing before anyone checks Search Console the following morning.
Start with the diagnosis
Send me your store and I will record a 20-minute walkthrough of what I would change and why. No call required, and nothing to unsubscribe from afterwards.