Core Web Vitals for e-commerce: which pages matter most
The three speed measurements search engines use, what they mean on a store, and which page types to fix first.
The short answer
Core Web Vitals are three measurements search engines take from real visitors: how quickly the largest visible element appears, how fast the page responds when someone taps, and how much the layout jumps around while loading. On a store they matter twice, for ranking and for conversion, and they matter most on the pages with the most visits and revenue: the homepage, the top collections and the top products, on mobile. The culprits are the same on nearly every store: an oversized hero image, apps injecting scripts on every page, banners and late elements shifting the layout, and too much JavaScript making taps hesitate. Measure with real-user data by page type, fix the worst templates first, and re-measure after every app change.
The three measurements on a store
| Measurement | What it captures | Typical store cause | Typical fix |
|---|---|---|---|
| Largest element timing | When the hero or main product image appears | Oversized image; not prioritised; slow theme render; scripts ahead of it | Right-sized image with priority; defer scripts; lighter theme |
| Interaction responsiveness | Delay between a tap and the page reacting | Apps and theme JavaScript busy on the main thread; heavy variant and cart scripts | Remove or defer apps; lighter interactions; less JavaScript |
| Layout shift | Content moving as things load | Banners injected late; images without dimensions; fonts swapping; app widgets | Reserve space; set dimensions; preload fonts; load widgets without shifting |
Which pages to fix first
- Rank templates by traffic and revenue: homepage, top collections, top products, cart, then the rest.
- Read field data per template on mobile: which of the three fails, by how much.
- Fix the homepage hero first if it is the largest-element problem; it usually is.
- Audit apps on the collection and product templates: which inject scripts, what each costs, which can go or load later.
- Reserve space for every image, banner and widget on those templates.
- Re-measure after each change; field data takes a few weeks to reflect it.
- Gate future app installs with a before-and-after measurement.
Measuring properly
Use the real-user reports by page group in the search console and the platform’s speed reports as the judgement, and lab tools as the diagnosis. Look at mobile, because that is where most visits are and where scores fail. Track the top templates monthly and after every app or theme change. A single screenshot of a lab score on a desktop tells you almost nothing about what customers experience.
What this means for you
Treat Core Web Vitals as a store metric, not a technical one: measured from real visitors, by template, on mobile, with the homepage, top collections and top products first. Fix the hero image, audit the apps, reserve space, reduce JavaScript, and re-measure after every change. The pages that pass are the pages that convert, and the fixes are the same ones that make the store feel fast to the people spending money on it.
Frequently asked questions
Which of the three matters most for a store?
Interaction responsiveness is where stores most often fail and where customers feel it: a tap on a variant, a filter or add-to-cart that hesitates because scripts are busy. The largest-element timing is next, usually driven by the hero or product image. Layout shift is the one that makes people tap the wrong thing. Fix whichever is worst on your top templates.
Do we need to pass on every page?
Search engines assess by page groups and real-user data, so what matters is that the templates carrying most traffic pass on mobile. A rarely visited policy page failing is unimportant; the collection template failing is not. Fix by template, in order of traffic and revenue.
Why did our scores drop when we did not change anything?
Almost always an app: installed, updated or reconfigured, injecting a script on every page. Sometimes a new banner or a third-party pixel. Compare the list of scripts on the page with last month's and check the app timeline. Re-measure after every app change as routine.
Sources
- web.dev: Core Web Vitals (accessed 2026-09-12)