Core Web Vitals stopped being a per-URL signal in March 2026. The Core Update that ran from March 27 to April 8 reweighted them as a site-wide factor, which means a few slow tool pages, a heavy blog template, or one chronically broken category page can now drag down the ranking of your whole domain.
For ecommerce, that ends a common shortcut. You can no longer defend performance on the homepage and let the product detail pages slide. Every page that ships has to clear the bar, because the slowest pages are the ones that now define the site-wide signal. Here is what changed, what the thresholds actually require, and where the levers are.
What are the 2026 Core Web Vitals thresholds?
| Metric | Google "good" | 2026 competitive bar | Sites failing "good" in May 2026 |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | < 2.0s | ~28% |
| INP (Interaction to Next Paint) | ≤ 200ms | < 100ms | ~43% |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | = 0 | ~12% |
| TTFB (Time to First Byte) | ≤ 0.8s | < 0.4s | ~22% |
| FCP (First Contentful Paint) | ≤ 1.8s | < 1.2s | ~25% |
The "Sites failing 'good'" column comes from the Q2 2026 Chrome UX Report aggregates. Three things stand out.
INP is the worst-performing metric on the modern web. Roughly 43% of sites fail the 200ms "good" threshold, while the top quartile sits at 60-80ms. INP is the metric that breaks fastest under JavaScript pressure — every framework hydration, every analytics script, every chat widget that runs on the main thread costs you here.
LCP is improving, but slowly. Image CDNs, AVIF and WebP adoption, and priority hints moved the median from 3.2s in 2022 to 2.4s in 2026. The next 0.4 seconds is harder than the last 0.8, because the bottleneck shifts from "we are loading a 2MB JPEG" to "we are loading 80KB of JavaScript that delays the LCP image."
CLS is the most fixable but least-fixed. About 12% of sites still fail it, and the cause is almost always a one-day fix: image dimensions, widget layout slots, font loading. Most CLS failures are workflow problems, not technical ones.
Why does the site-wide change matter?
Before March 2026, a slow blog page did not affect your product pages. Each URL was scored on its own, so most ecommerce teams optimised the homepage and product pages and quietly accepted slower blog and tool pages because "they are informational, not transactional."
That no longer holds. Search Console now shows a domain score derived from the 75th-percentile field data across the URLs in your sitemap, and that score feeds into ranking. Underperforming pages drag the domain score, and the domain score affects the ranking of every URL on the site.
The fix is not simply "make every page fast." It is "make every page fast, or take the slow pages out of the index." Most teams discover 20-30 zombie pages — old landing pages, deprecated categories, never-updated tool pages — that have no business being indexed and are dragging the domain score for no commercial reason.
What are the biggest LCP levers?
LCP is usually the metric most directly tied to revenue: slower LCP means higher bounce and lower conversion, and the relationship holds across verticals. Five levers, in the order worth doing them.
1. Priority hints on the hero image. Add fetchpriority="high" to the LCP element. Cuts LCP by 100-300ms on most sites for the cost of one HTML attribute. Do this first.
2. AVIF or WebP for hero images. AVIF saves 30-50% over JPEG; WebP saves 25-35%. Most image CDNs (Cloudinary, imgix, Shopify) negotiate the format automatically. Pages still serving JPEG-only in 2026 are leaving 200-500ms on the table.
3. Preconnect to your image CDN. A <link rel="preconnect"> to the CDN saves 100-200ms on the first image request by getting DNS, TCP, and TLS out of the way early.
4. Remove render-blocking JavaScript above the fold. Any script in <head> without async or defer blocks the parser. Defer everything below the fold; for the few scripts that must run before the LCP event, use async.
5. Server-render the above-the-fold content. Server-rendered HTML paints fast; client components have to hydrate first. Render the hero, navigation, and first product grid on the server, and reserve client components for browser-only state like the chat widget.
Sites that do all five typically move from 2.4s LCP to 1.6-1.8s — into the competitive zone.
Why does INP break first under JavaScript?
INP is the most-failed metric for a reason. Every hydration, every event handler, every third-party tag adds main-thread work, and the visitor's tap cannot be processed until the main thread is free. Three structural causes show up on ecommerce sites.
Heavy hydration
Server-rendered HTML displays fast (good LCP). Then client-side JavaScript hydrates — attaching listeners, restoring state, re-rendering — and the main thread is busy for 300-800ms. Any tap during that window registers a high INP. The fix is to server-render the parts of the page that do not need client state, shrinking the hydration boundary and the main-thread work that comes with it.
Third-party scripts
Analytics, ad pixels, heatmaps, marketing tags — each adds 30-150ms of main-thread work on first run, and many re-run on every navigation in a single-page app. On a typical site with 8-12 tags, that is 200-600ms. The fix is to run them off the main thread (a Web Worker via Partytown is the 2026 pattern) or load them at idle priority after the LCP event. Either move drops INP by 100-300ms.
Chat widgets that wake up on page load
Some chat widgets run their full initialisation on every page load, costing 80-200ms of main-thread work, often right on the LCP path. A well-built widget — Yokaify included — defers its initialisation until after the LCP event; many older widgets require you to configure that by hand.
How do you get CLS to zero?
CLS is the easiest metric to drive to zero, with a little discipline.
Give every image explicit width and height. Even in a responsive layout, the attributes tell the browser the aspect ratio so it can reserve the slot before the image loads. CSS still scales the rendered size.
Reserve a slot for every embedded widget. Chat widgets, video embeds, ads — anything that loads asynchronously — needs a correctly sized placeholder in the DOM before it mounts.
Match font metrics on swap. When a custom font loads in, line height and character widths can shift the layout. The CSS Font Loading API and the size-adjust descriptor keep that shift near zero.
Use skeletons with real dimensions. If a section loads async, render a skeleton at the right size — not "loading…" text that grows to fill the space.
What bundle budgets should you set?
JavaScript weight is the single largest input to both LCP and INP. These reference budgets are calibrated to the competitive bar:
| Page type | Initial JS (gzip) | Total page weight | Notes |
|---|---|---|---|
| Homepage | < 80 KB | < 600 KB | Tightest budget |
| Product detail page | < 120 KB | < 1.2 MB | Includes recommendations widget |
| Cart / checkout | < 90 KB | < 700 KB | Wallet pay buttons add weight; budget includes them |
| Blog / content | < 60 KB | < 500 KB | No commerce widgets above the fold |
| Tool pages (with React widget) | < 100 KB | < 800 KB | Includes the tool client component |
| /vs/ comparison pages | < 70 KB | < 600 KB | Tables and FAQ are RSC |
Treat these as budgets, not aspirations — a number you check on every page, not once a quarter. The stack that hits them without giving up features in 2026: Next.js 15 App Router, React 19 Server Components, Tailwind CSS, and a small set of client components for the interactive bits. Hydrogen and Astro can hit the same budgets; older stacks (Vue 2, Angular, jQuery-heavy WordPress themes) usually cannot without a serious refactor.
Which rendering approach should you use?
- Static Site Generation (SSG). Pages built at deploy time. Best for content — guides, blog, comparison, glossary. LCP under 1.5s is achievable.
- Streaming SSR. Rendered on the server with
<Suspense>boundaries that stream in. Best for product pages with a dynamic catalogue. LCP under 2.0s is achievable. - Edge SSR. Streaming SSR run at the edge (Vercel Edge, Cloudflare Workers). Buys roughly 50ms of TTFB on a global audience.
- Client-side rendering (CSR / SPA). Almost never the right call for ecommerce in 2026; LCP regularly lands above 3.0s.
A reliable high-performance pattern is SSG for content plus streaming SSR for any user-specific page, which keeps LCP comfortably under the competitive bar across the site.
Why field data beats lab scores
Lab tools (Lighthouse, PageSpeed Insights) are useful during development, but they do not predict field performance. Real visitors have slower devices, worse networks, and more competing tabs than your build server.
The 2026 standard for field measurement is the web-vitals library — a small script that captures LCP, INP, CLS, FCP, and TTFB on real visitors and sends them to your analytics or a dedicated endpoint. It answers the questions lab data cannot: which devices are slow on your site, which pages, which traffic sources. The answers usually surprise teams that have only ever looked at lab numbers.
How do you stop regressions reaching production?
Performance is not a one-time cleanup; it decays as features ship. The durable fix is an automated gate in CI that runs on every pull request and blocks a merge when a page slips past its budget. Reasonable thresholds to enforce:
- LCP under 2.0s
- INP under 100ms
- Performance score at least 90
- Accessibility score at least 95
- SEO score at least 95
The point is to catch a regression in review, while it is one small diff, rather than in the field after it has already dragged your domain score.
Further reading
- GuideHow Rive fits ecommerceHow an animated mascot stays under the CWV budget.
- GuideHow onsite conversion agents workWhy a good on-site agent loads without slowing the page.
- GuideAI website mascot strategy and ROIKeeping a character lightweight enough to ship.
- GuideThe 2026 CRO playbookWhere page speed sits among the conversion levers.
Frequently asked questions
Roughly 43% of sites fail the 200ms threshold (Chrome UX Report aggregates, 2026). The cause is JavaScript: framework hydration, third-party tags, and event handlers all run on the main thread.
Last updated May 31, 2026.