Core Web Vitals optimization, one failing metric at a time.

Core Web Vitals optimization starts in the Core Web Vitals report in Search Console, not with a speed score. The report groups similar URLs and judges each group on the 75th percentile of real visits over the last 28 days. A group is good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. We list every failing group, the metric it fails and the template behind it, usually product, collection or the home page.

For largest contentful paint, we find the element first. On most store templates it is the hero banner or the first product image. Google’s guide to optimizing LCP splits the time into four parts: time to first byte, resource load delay, resource load duration and element render delay. We measure each one, because the fix differs: a slow server needs caching, a late image needs to be in the HTML with fetchpriority="high", and a heavy image needs the right size for a phone.

For interaction to next paint, we record real taps on the parts shoppers use: the variant picker, size buttons, filters, the cart drawer and add to cart. Google’s guide to optimizing INP breaks each interaction into input delay, processing time and presentation delay. On stores the usual cause is app scripts running long tasks on the main thread. We delay or remove the scripts, split long tasks, and load each app only on the templates where it is used.

For layout shift, we find every element that moves and why. Google’s guide to optimizing CLS names the usual causes: images without dimensions, ads and embeds, content injected late, and web fonts. We give images and embeds a reserved box, keep banners in space set aside for them, and load fonts so text doesn’t re-flow.

We have fixed these problems on this site. On inner pages a decorative background moved when the web font swapped in, giving a CLS of 0.23; after the fix it measured 0. PageSpeed Insights later showed a mobile CLS of 0.132, all from our cookie banner. The banner was fixed to the bottom of the screen, but its text re-wrapped when the font loaded and its top edge moved. We now open it only after the fonts are ready, and Lighthouse mobile scores 95 to 100 on our main templates.

We also read the raw HTML of 36 store homepages on 18 October 2026 to see how common these causes are. 30 of the 36 had images without width and height, 975 of 4,092 image tags in total. 17 marked 3 or more elements as high priority, which defeats the point of the hint. 18 carried 100 or more script tags. None of that needs a new theme; each one is a fix in the code you already have.

Every change is made on a copy of the theme, checked with Lighthouse and on real phones, and compared with the old version before it goes live. Then we check that tracking events still fire and apps still work. Speed work that breaks a purchase pixel or a review widget isn’t a win.

Last, we start validation. In Search Console, Start Tracking opens a 28-day monitoring session; if no URL in the group shows the issue in that window, the issue is marked fixed. We report lab results at once and field data when validation ends. Since March 2024, INP has replaced First Input Delay as the responsiveness metric, as web.dev announced, so older advice about FID no longer applies.