Core Web Vitals in Plain Language: What to Ask Your Developer For

Core Web Vitals are three measurements Google takes of how your site feels to real visitors: how fast the main content appears, how quickly the page reacts when someone taps something, and how much the layout jumps around while loading.

They feed Google's page experience signals, and they are measured from actual Chrome users rather than from a test you run yourself. That second point causes most of the confusion, so it is worth dealing with first. For remote production teams, a related reference is more details, which looks at how activity signals should be interpreted.

The thresholds

To pass, a page needs LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 — each measured at the 75th percentile of real visits. In other words, at least 75 percent of your visitors must have a good experience for the page to count as passing.

Poor territory begins at LCP over 4 seconds, INP over 500 milliseconds, and CLS over 0.25. Between the two bands is "needs improvement."

Why your perfect Lighthouse score means nothing

Google grades you on field data — the Chrome User Experience Report, collected from real users over a rolling 28-day window. For a broader technical reference, the W3C accessibility guidance is a useful starting point.

A lab test run on your laptop over office fibre tells you how the page performs for you. It says nothing about the visitor on a three-year-old Android phone on a congested mobile network, and that visitor counts equally toward your 75th percentile.

Two practical consequences:

Lab tools are diagnostic, not evaluative. Lighthouse and PageSpeed Insights are excellent for finding what is slow and why. They are not the score Google uses.

Fixes take weeks to show up. Because the window is 28 days and rolling, a deployment today will not fully reflect in your field data for about a month. Do not judge a fix after three days and conclude it failed.

Where to look at the real numbers: the Core Web Vitals report in Google Search Console, and the field data section at the top of PageSpeed Insights.

LCP — how fast the main content appears

Largest Contentful Paint measures when the biggest visible element in the viewport finishes rendering. Usually a hero image, a heading, or a video poster.

What to ask for:

Preload the hero image so the browser starts fetching it immediately rather than discovering it after parsing CSS
Inline the critical CSS needed for the first screen; defer the rest
Preload fonts and set font-display: swap so text is visible while fonts load
Serve images in WebP or AVIF, sized appropriately, with srcset for different screen sizes
Server-side render the initial content rather than assembling it in the browser
Check the server response time — if the server takes 800ms to start responding, no front-end work will save you

LCP tends to have the clearest commercial impact of the three, because it is the metric closest to "did the page appear before the visitor gave up."

INP — how quickly the page responds

Interaction to Next Paint measures the delay between a visitor tapping, clicking, or typing and the browser painting the result. It replaced First Input Delay in March 2024, and it is stricter: FID measured only the first interaction, INP looks at all of them and reports close to the worst.

This is the metric most sites fail, and it is the hardest to fix, because it is not a resource problem. It is a JavaScript architecture problem.

The mechanism: any JavaScript task running longer than about 50 milliseconds blocks the main thread. While it runs, the browser cannot respond to input. Several long tasks stacked together are why a button feels dead.

What to ask for:

Break long JavaScript tasks into smaller chunks that yield to the main thread
Defer non-critical work until after the page is interactive
Audit third-party scripts — chat widgets, analytics, tag managers, ad code — and remove or defer what is not essential
Reduce the amount of JavaScript shipped at all
Avoid heavy work in event handlers; acknowledge the interaction visually first, then compute

There is no plugin that fixes INP. If a developer suggests one, that is a signal.

CLS — how much the layout jumps

Cumulative Layout Shift measures unexpected movement of visible elements while the page loads. The everyday version: you go to tap a link, an image finishes loading above it, everything shifts down, and you tap an advert instead.

This is the easiest of the three to fix, and the fixes are mechanical:

Explicit width and height attributes on every image, video, and iframe
Reserved space for ad slots, embeds, and anything injected after load
font-display: swap with a fallback font metrically matched to the real one, so the text does not reflow when the webfont arrives
Never insert content above existing content unless the user triggered it
Use CSS transforms for animation rather than properties that change layout

If your site is failing CLS, it is usually failing on the first item alone.

Where to start

Fix whichever metric is in the poor band first — it does the most damage. After that, the practical order is INP, then LCP, then CLS, on the grounds of difficulty and payoff. Do not spend time optimising something already green.

Set alerts below the thresholds so you catch regressions before they cost you: INP over 160ms, LCP over 2.0s, CLS over 0.08. A single deployment can undo months of work, and without monitoring you find out from your rankings.

What to put in a brief

If you are commissioning a site or a rebuild, write the targets in:

The delivered site must achieve, on mobile field data, LCP under 2.5s, INP under 200ms, and CLS under 0.1 at the 75th percentile, verified in Search Console within 60 days of launch.

Sixty days because of the rolling window. Mobile specifically because mobile is substantially harder to pass than desktop, and a desktop-only commitment is close to meaningless.

Also ask for the third-party script inventory before launch. Marketing tools accumulate, and each one is main-thread time you did not budget for.

The perspective worth keeping

Core Web Vitals are one signal among many, and passing them will not outrank a competitor with better content and stronger authority. They matter at the margin — between two comparable pages, the faster one wins.

But the commercial argument is stronger than the SEO one. A form that lags on submission, a hero image that shifts as it loads, a page that takes four seconds on a phone — these lose customers regardless of what Google does with the data.

Строим статические и серверно-рендерящиеся сайты с расчётом на CWV с первого дня. Услуги веб-дизайна. .