Core Web Vitals for e-commerce: fix templates, not pages

An online store can have fifty thousand URLs but only a handful of templates: home, category, product, search, cart and checkout. When product pages fail Core Web Vitals, it’s almost never one product’s fault. Fix the template and every page built on it improves; fix pages one at a time and you’ll never finish.

Why templates matter

Every product page runs the same code, image pipeline and third-party scripts, and the same is true of category, home and cart pages. A slow gallery component or a late review widget affects every product at once. Search Console works the same way: its Core Web Vitals report groups URLs into pages with a similar user experience, and a group takes the status of its worst metric on that device type. A failing group of product URLs is a template problem, and the fix is a template fix.

Core Web Vitals are used by Google’s ranking systems, but Google says it always seeks to show the most relevant content, even if the page experience is sub-par. The stronger case is your shoppers, who feel every slow image and every jumpy layout.

Measure by template

Start by mapping URL patterns to templates, such as /p/ for products and /c/ for categories. Then measure each template separately:

• Field data first. Search Console’s groups, and CrUX data in PageSpeed Insights, show how real Chrome users experience your pages at the 75th percentile over the last 28 days.
• Real-user monitoring by template. Collect LCP, INP and CLS from your own visitors, for example with Google’s open-source web-vitals library, and tag each measurement with the page template. That shows which template fails, and on which devices.
• Lab tests to debug. Run Lighthouse on a few representative URLs per template to find the cause, then confirm the fix in field data.

p75 LCP by template, mobile

Home2.2 s

Category3.1 s

Product4.4 s

Search results3.4 s

Cart2.4 s

A breakdown like this replaces a site-wide average with one template to fix first.

LCP: the main product image

On product pages the largest element is usually the main product image; on category pages it’s often the first row of product images or a banner. LCP breaks down into four parts: time to first byte, the delay before the image starts loading, the time it takes to load, and the delay before it renders. Product templates tend to lose time in all four.

Core Web Vitals thresholds

LCP Largest Contentful Paint · loading

Good≤ 2.5 sNeeds improvement2.5–4 sPoor> 4 s

INP Interaction to Next Paint · responsiveness

Good≤ 200 msNeeds improvement200–500 msPoor> 500 ms

CLS Cumulative Layout Shift · visual stability

Good≤ 0.1Needs improvement0.1–0.25Poor> 0.25

• Put the image in the HTML. If a gallery script injects the main image, the browser can’t find it until the script has run. Render the first image on the server, and preload it if it’s only referenced from CSS or JavaScript.
• Prioritise it. Add fetchpriority="high" to the main image, and to no more than one or two images in total; prioritising everything prioritises nothing.
• Never lazy-load it. loading="lazy" on the LCP image always delays it. Lazy-load the rest of the gallery and the products further down the grid instead.
• Size it properly. Use a responsive srcset with sizes, serve AVIF or WebP, and let an image CDN resize and cache images close to shoppers.
• Fix the server response. A slow first byte can make a 2.5-second LCP hard or impossible. Cache category and product pages at the edge for anonymous visitors, keep redirects out of the path, and load personalised parts afterwards.

<img src="/img/sofa-800.avif"
  srcset="/img/sofa-480.avif 480w, /img/sofa-800.avif 800w, /img/sofa-1200.avif 1200w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  width="800" height="800" fetchpriority="high" alt="Three-seater sofa in green velvet">

INP: filters, add to basket and third parties

Interaction to Next Paint measures how quickly the page responds to clicks, taps and key presses. E-commerce templates are full of them, and the slow ones are predictable:

• Filters that re-render the whole product grid before showing any feedback. Show the selection straight away, then update the results.
• Add to basket handlers that wait for the network, recalculate the basket and fire analytics before anything is painted. Update the button first and do the rest afterwards.
• Variant pickers where choosing a size or colour re-renders the entire page instead of just the price, image and stock message.
• Third parties: review widgets, chat, personalisation, A/B testing and tag managers all add work to the main thread. Audit them per template, remove what nobody uses, and load the rest later or only when needed.

Long tasks, those over 50 ms, are the usual culprit: break them up so the browser can respond in between. Our guide to finding and fixing slow interactions goes deeper. Filters also have SEO consequences of their own, covered in our post on faceted navigation, and heavy client-side rendering can hurt both responsiveness and what search engines see, as we explain in what Googlebot actually sees.

CLS: keep the layout still

• Image dimensions: set width and height (or an aspect ratio) on every product and banner image so the browser reserves the space.
• Injected promo banners: free-delivery strips and countdowns that appear after load push everything down. Reserve their space or render them on the server.
• Cookie banners: an overlay on top of the page doesn’t shift anything; a banner inserted above the content does.
• Web fonts: a late font swap reflows product names and prices. Preload the key fonts and use fallback fonts with matching metrics.
• Review widgets: star ratings and review blocks that load late move the “Add to basket” button. Reserve a fixed height for them.

Prioritise by traffic and revenue

Not every template deserves the same effort. List the templates with their share of organic traffic and revenue from your own analytics, mark which metric fails on each, and start where the two overlap, which is usually product and category pages. Then sort the fixes by impact and effort.

Template fixes by impact and effort

Impact →

Do this sprintPlan as projectsBatch with other workPark for nowNo lazy-load on herofetchpriority on imageSpace for reviewsDelay chat widgetEdge cachingRebuild variant pickerReplace A/B toolTrim icon fonts

Effort →

Then protect the gains. Set a performance budget per template, such as a maximum JavaScript size, a cap on third-party tags and a weight limit for the main image, and check it in your build pipeline so a release can’t quietly break it. Keep real-user monitoring running and alert on regressions after each release. Field data covers a rolling 28 days, so give a fix about four weeks before you judge it in Search Console.

Our e-commerce SEO and web design and development teams work through this together, and the e-commerce organic revenue playbook shows where it fits in a wider plan.

---

Want to know which template is holding your store back? Request a free SEO audit: it covers real-user LCP, INP and CLS, with the likely causes of any failures.