DefinitionGoogle's three page-experience metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability).
Core Web Vitals are Google’s three user-experience metrics for loading, interactivity and visual stability: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Together they describe how a page feels to a real visitor: how fast content appears, how fast the page reacts to a tap, and whether elements jump around. Google measures them on real Chrome users and publishes the results in the Chrome User Experience Report (CrUX), which is why you will also hear them called web vitals or page experience metrics.
The most common misunderstanding is that a PageSpeed score of 90 means your Core Web Vitals are fine. It does not. The score comes from a lab test on one simulated device; the vitals that count for Google come from field data, measured at the 75th percentile of actual visitors over the past 28 days. A page passes only when all three metrics are “good” at that percentile: LCP within 2.5 seconds, INP within 200 milliseconds and CLS at or below 0.1. Many shop owners also still talk about First Input Delay (FID), but INP replaced FID as the interactivity metric in March 2024, and it is a far stricter test.
Why Core Web Vitals matter
As a ranking signal, Core Web Vitals are minor. In my own audits I rarely see a shop lose rankings purely because of a poor CLS score. If two pages are otherwise equal, good vitals can be a tiebreaker but nobody should expect to outrank a stronger competitor just by shaving half a second off LCP.
For a webshop the real argument is conversion, not ranking. A product page where the main image takes four seconds to appear on a 4G connection loses a share of its visitors before they see a price. A category page where the filter bar responds half a second after the tap feels broken. And the classic CLS failure, an “add to cart” button that shifts down just as the customer taps it, sends people to a different product or back to the category. How much revenue this costs varies by study, but whenever I compare conversion rate by page-load bucket in GA4, the slow bucket converts worse. That makes Core Web Vitals one of the few technical topics the finance side listens to.
How to measure Core Web Vitals
Start with field data, because that is what Google scores. The Core Web Vitals report in Google Search Console groups your URLs into good, needs improvement and poor for mobile and desktop, and it groups similar pages together (all product pages on one template, for instance), so you fix one template rather than one URL. PageSpeed Insights shows the CrUX field data for a single URL and for the whole origin at the top, with the lab diagnostics underneath. Smaller Dutch shops often have too little traffic for CrUX data and fall back on lab data. For clients with enough traffic I build a CrUX dashboard in Looker Studio to watch the monthly trend.
Lab data is for diagnosis. Chrome DevTools shows exactly which element is the LCP element, which script blocks the main thread during an interaction, and which image or banner causes the layout shift. For a quick first check of a product, category or homepage URL I use my own Core Web Vitals checker, which pulls both the field and lab numbers for a URL in one view. The important discipline is to read field and lab together: lab tells you what to fix, field tells you whether it worked.
Common Core Web Vitals mistakes
Oversized hero and product images. A 3,000-pixel-wide slider image served to a phone is the single most common LCP problem I find in WooCommerce and PrestaShop shops. Resize to the rendered size, serve WebP or AVIF, preload the LCP image and never lazy-load it.
Theme and plugin bloat. Multipurpose themes load sliders, icon fonts and page-builder CSS on every page, and each extra plugin adds its own scripts. The result is a heavy main thread, which hurts both LCP and INP. Deactivate what the shop does not use and load the rest only where it is needed.
Third-party scripts without limits. Chat widgets, review carousels, cookie banners and an overloaded Google Tag Manager container are the usual INP culprits. Every tag competes for the same main thread the customer is trying to interact with. Audit the container, delay non-essential scripts and ask whether the shop really needs three tracking pixels.
No caching, no font strategy and no reserved space. A shop without page caching regenerates every page on the server, so the browser waits before it can even start. Web fonts loaded without font-display swap delay text and cause layout shifts when they finally arrive, and banners, ads or reviews inserted above the fold without a fixed height produce the CLS jumps. Set explicit dimensions on images and embeds and keep injected content below the fold.
How I handle Core Web Vitals for clients
I start from the Search Console groups, not from a single PageSpeed run, and pick the template that touches revenue most: usually the product page, then the category page, then the homepage. For each template I take the field numbers for LCP, INP and CLS, trace the cause in DevTools and write up a fix list ordered by expected impact and effort. The deliverable is a short document the developer or the theme agency can work from, naming the exact image, script or stylesheet per item, plus a baseline to prove the change after 28 days of fresh CrUX data.
On smaller shops I implement the fixes myself: image compression and preloading, caching configuration, tag-manager clean-up and font loading. On larger platforms I coordinate with the development team and verify each release in the field data. This work is part of my Core Web Vitals service and it rarely stands alone; it is usually bundled with a technical SEO audit, because a faster shop converts the organic traffic the rest of the SEO work brings in.
Frequently asked questions
Are Core Web Vitals a ranking factor?
Yes, but a light one. Google uses Core Web Vitals as one of many ranking considerations, and content relevance weighs far more. Treat the vitals as a conversion and user-experience project that also removes a small ranking handicap, rather than as a direct lever for positions.
What are good Core Web Vitals scores?
A page is good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less, measured at the 75th percentile of real Chrome visitors. Between those limits and 4 seconds, 500 milliseconds and 0.25 the page “needs improvement”; above that it is “poor”. A page passes only when all three metrics are good on the same device type.
Why does Search Console show no Core Web Vitals data for my shop?
CrUX only publishes data for origins and URLs with enough Chrome traffic in the last 28 days. Newer or smaller shops often fall under that threshold, especially on desktop. In that case use lab data from PageSpeed Insights and DevTools to fix the obvious problems, and consider adding your own real-user measurement in GA4 so you still see what customers experience.
How long does it take before improvements show up?
Lab tools show the effect immediately after a change is live. Field data lags, because CrUX is a rolling 28-day window, so Search Console typically needs three to four weeks to move a URL group from poor to good.