Most storefronts are not slow where the report says they are. The work starts with the Chrome UX Report for your origin, because that is what Google grades and what your customers actually sat through, with a lab run beside it to show the cause. Sometimes the honest answer is that speed is not your bottleneck, and you will hear that before you spend anything on it. When it is the bottleneck, the fix belongs at the layer the time is going to: server response on Adobe Commerce, apps and theme on Shopify, the image pipeline, and the scripts nobody owns.
Where the time usually is
Server response, before anything on the front end
Time to First Byte sets the floor for every metric after it. On Adobe Commerce that means full page cache behaviour, Varnish, and the queries behind a category page. No amount of front-end work recovers a slow origin, and a Lighthouse score will not tell you that is where the time went.
LCP: the first screen and the image pipeline
Priority hints on the hero image, fonts that do not block the render, and critical CSS inline. The target is the 75th percentile of your real mobile visitors, which is the number Search Console grades, rather than a score from one run on one machine.
INP: the scripts you did not write
Tag managers, chat widgets, review apps and pixels. They arrive through marketing, they run on the main thread, and on Shopify they are usually the largest single cause. Facades and deferred loading where the script earns its place, and a case for removing it where it does not.
CLS, which is not the small one
Reserved space for anything that loads late, and dimensions on every image. In the best-designed commercial experiment in my evidence register, CLS moved 92.72% while LCP did not move at all, and revenue per visitor rose 53.37%. That does not prove CLS caused it. It does mean layout stability is not the metric to leave until last.
Verified on your users, not on my machine
web-vitals in the page reporting real sessions, read back against the Chrome UX Report and the Core Web Vitals report in Search Console. Field data is the only evidence that a deploy helped, and the 28 day window is what decides whether it counted.
How an engagement runs
- 1
Diagnose - field data for the origin, a lab run for the cause, and which layer the time is in
- 2
Price it - what closing the gap is worth on your own traffic, from randomised experiments rather than the number the market quotes
- 3
Fix the part that pays, in order, with each change measurable on its own
- 4
Verify in the field - real-user monitoring, and the 28 day window that decides whether it counted
What I measure with and work on
What you have when it is done
Deliverables, not projections. Each one is something you can check on the day it is handed over.
- Your own field data from the Chrome UX Report, read at the 75th percentile Google grades you on.
- The gap priced from published experiments, with every source named and the uncertainty stated.
- A list of what is costing the time, ordered by what it would take to fix, including the items not worth fixing.
Related Resources
Use this content path to evaluate implementation depth before we start your project.