probeo

What are Core Web Vitals and how do they affect site performance?

core-web-vitals-risk page

The issue

A page whose content jumps as it loads, that answers taps late, or that shows its main content late is a worse page to use, and Core Web Vitals are how Google measures those three things for its page experience signals. A reader who taps the wrong link because the layout moved, or waits on a blank hero, doesn’t see a metric. They see a broken page.

The cause is usually structural and repeats across a template: images without dimensions, scripts that run as the page builds, a large share of JavaScript, a heavy hero image. These patterns can pass a single lab test on a fast machine and still fail for visitors on slower phones and networks.

Scope

Core Web Vitals are assessed per page. Google uses field data at the URL level and groups similar pages when one URL has too little data. A pattern in a template, such as a product page’s image gallery, affects every page built from it, and fixing the template fixes them all.

How to check you have it

  • In probeo: each page carries a CLS risk and an INP risk, each low, moderate, high or critical. The CLS risk lists its reasons, such as missing-image-dimensions:3/12, late-layout-js, google-fonts-no-display-swap or css-hero-background-no-height. Probeo also estimates FCP and LCP for four network profiles: Broadband (40 Mbps, 30 ms round trip), 5G (75 Mbps, 40 ms), 4G Fast (20 Mbps, 60 ms) and 4G/3G Slow (5 Mbps, 150 ms), and grades each LCP from Exceptional to Bad.
  • By hand: in Chrome DevTools, the Performance panel shows LCP, CLS and INP for the page as you load it and interact with it.
  • With a tool: PageSpeed Insights shows field data from the Chrome User Experience Report at the 75th percentile when the page has enough traffic, and a Lighthouse lab run either way.

The fix

Remove the structural causes behind each metric, starting in the templates.

For CLS, give every image width and height attributes, reserve space for anything inserted after load, add async or defer to scripts in the body that change the layout, and load web fonts with font-display: swap and a fallback font sized close to the web font. For INP, ship less JavaScript, defer what isn’t needed at first, and keep work in event handlers short. For LCP, make the largest image smaller and serve it in a modern format, don’t lazy-load it, and take render-blocking resources off the critical path.

Done when: probeo’s CLS and INP risks read low, the LCP estimate is Good or better on the profiles your visitors use, field data where it exists is within the good thresholds at the 75th percentile, and the check above comes back clean.

Do not

  • Do not optimize for a lab score while ignoring field data.
  • Do not treat Core Web Vitals as the only thing that decides ranking.
  • Do not fix one page when the pattern lives in a template.
  • Do not take a single Lighthouse run as proof.

The three metrics

CLS, Cumulative Layout Shift, measures how much visible content moves unexpectedly. It is the largest burst of layout shifts during the visit, each shift scored by how much of the viewport moved and how far. Good is 0.1 or less; poor is above 0.25.

INP, Interaction to Next Paint, measures the delay between an interaction and the next visual update. It replaced First Input Delay in March 2024, and unlike FID it covers every interaction in the visit, reporting the slowest with outliers ignored on pages with many interactions. Good is 200 ms or less; poor is above 500 ms.

LCP, Largest Contentful Paint, measures when the largest visible element, usually a hero image or a block of text, finishes rendering. Good is 2.5 s or less; poor is above 4 s.

Google classifies a page by the 75th percentile of its field data. It passes when all three metrics are good at that percentile.

How probeo’s numbers differ from lab and field data

Probeo doesn’t run Lighthouse or collect data from real visitors. It reads the page’s HTML and the resources it loads, and estimates from them. The FCP and LCP estimates come from the CSS, JavaScript and fonts that block the first paint, the largest image, the server’s response time, the HTTP version and the hosts involved, worked out for each network profile. The CLS risk is a weighted score from images without dimensions, body scripts that run synchronously, hero backgrounds set in CSS without a height, and Google Fonts loaded without display=swap. The INP risk is an estimate from JavaScript’s share of the page’s bytes and requests; probeo doesn’t measure INP itself.

Lab tools measure one load under controlled conditions. Field data from the Chrome User Experience Report is what real visitors experienced, over the last 28 days. Probeo’s estimates point at causes; lab and field data confirm the effects.

FAQ

What is the difference between lab data and field data for Core Web Vitals?

Lab data comes from synthetic tests like Lighthouse running a single page load under controlled conditions. Field data comes from real users via the Chrome User Experience Report, aggregated over 28 days. Google uses field data for ranking decisions. Lab data is useful for debugging but does not reflect the variance of real user conditions: device capability, network speed, and interaction patterns.

Do Core Web Vitals thresholds differ between mobile and desktop?

The threshold values are the same for both mobile and desktop. However, Google evaluates mobile and desktop separately using distinct field data sets. A page may pass CWV on desktop but fail on mobile due to differences in rendering performance, network conditions, and interaction patterns.

How much do Core Web Vitals actually affect search rankings?

Core Web Vitals are part of Google’s page experience signals, which are one input among many. Google’s own guidance says it aims to show the most relevant content even when its page experience is poor. Treat them as something that matters when pages are otherwise close, and as a measure of what visitors go through, not as a ranking lever on their own.

Why might a page pass Lighthouse but fail in field data?

Lighthouse tests a single load on a controlled environment with consistent CPU and network settings. Field data captures the full distribution of real user experiences across varied devices, connections, and interaction timing. A page that scores well under lab conditions can still perform poorly for visitors on slower phones and mobile networks.

Why did Google replace FID with INP?

First Input Delay only measured the delay of the first user interaction, ignoring all subsequent interactions. A page could report excellent FID while remaining unresponsive throughout the rest of the session. INP covers every interaction in the visit and reports the slowest, ignoring outliers on pages with many interactions, so it reflects how the page responds throughout.

Does probeo replace Lighthouse or PageSpeed Insights?

No. Probeo identifies structural risk factors in page composition that tend to produce poor CWV outcomes. It operates before measurement tools run. Lighthouse and PageSpeed Insights confirm whether those outcomes materialize. Probeo surfaces causes. Measurement tools confirm effects. They serve different purposes in the same workflow.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.