Core Web Vitals Without the Jargon

Someone has probably sent you a screenshot of a PageSpeed test with a red circle on it and a number like 34. Then someone else sold you a caching plugin, the number went to 78, and nothing else changed. This piece is about what those numbers are made of, so you can tell the difference between a real problem and a scoreboard.

Core Web Vitals are three measurements Google publishes about how a page behaves for a real person using it. They are not a grade for your website. They are three specific, narrow questions: how long until the main thing appears, how long until the page answers a tap, and does anything move under your finger. That is genuinely all they cover.

What the three numbers actually measure

LCP — Largest Contentful Paint

Plain translation: how long before the biggest visible thing on the screen has finished drawing. Usually that is your hero image, a banner, or a big block of headline text. The clock starts when the person taps your link and stops when that largest element is painted.

Note what it does not measure. It does not care whether the rest of the page has loaded, whether your fonts have settled, or whether your tracking scripts are still chattering away in the background. If your hero image is a four-megabyte photo straight off a phone, LCP will be bad even if the whole rest of the site is featherweight.

INP — Interaction to Next Paint

Plain translation: when someone taps something, how long before the screen visibly changes in response. A menu tapped, an accordion opened, a quantity increased, a form field focused. INP looks at the interactions across the whole visit and reports roughly the worst one, not the average.

INP replaced an older measure called First Input Delay in March 2024. FID only measured the delay before the browser started handling your tap. You could pass FID comfortably while the user waited two seconds for anything to appear on screen. INP closed that gap, which is why some sites that were green in 2023 quietly went amber in 2024 without anybody touching the code.

CLS — Cumulative Layout Shift

Plain translation: how much the page jumps around while it is loading. You go to tap "Call now", an advert or a late-loading image pushes in above it, and your thumb lands on something else. CLS is a score, not a time — it multiplies how much of the screen moved by how far it moved, and adds up the unexpected shifts.

Shifts you cause yourself by tapping something are excluded. It is only the ones the page does to you.

The thresholds, and the detail everyone skips

Google publishes the boundaries. They are fixed numbers, not a curve you are graded against:

Metric	Good	Needs improvement	Poor
LCP	2.5 seconds or less	2.5 – 4.0 seconds	over 4.0 seconds
INP	200 milliseconds or less	200 – 500 ms	over 500 ms
CLS	0.1 or less	0.1 – 0.25	over 0.25

Here is the detail that changes how you read every report you will ever be shown. A page is assessed at the 75th percentile of real visits. Meaning: three quarters of your visitors must be inside the "good" boundary. The slowest quarter — the person on a two-year-old Android in a lift in Laxmi Nagar with patchy signal — is allowed to be slow, and you are still passing.

That cuts both ways. If your site is fast on your iPhone on office Wi-Fi and that is your only evidence, you know almost nothing. Your customers are not you.

Why your lab score and Google's data disagree

Every speed tool gives you two kinds of number, and they are answering different questions.

Lab data is a simulation. A tool such as Lighthouse (the engine inside PageSpeed Insights) loads your page once, on a machine in a data centre, deliberately throttled to imitate a mid-range phone on a slow connection. No cookies, no logged-in state, nothing cached, no ad blocker, no real network weather. It is a laboratory. It is repeatable and it is fictional.

Field data is what actually happened. Google collects it from Chrome users who have opted into reporting, and publishes it as the Chrome User Experience Report — CrUX. It is a rolling 28-day window of real visits from real devices on real networks. This is the data used for Core Web Vitals assessment. When PageSpeed Insights shows you a section headed "Discover what your real users are experiencing", that is the field data. The big coloured 0–100 score underneath is the lab simulation, and it is not a Core Web Vitals measurement at all.

So the two numbers routinely disagree, for reasons that are all mundane:

• Caching. A returning visitor's browser already has your fonts and logo. The lab test never does.
• The 28-day lag. You fixed your images on Tuesday. Field data will still be averaging in the old, broken version for weeks. Do not panic, and do not "fix" it twice.
• Real interaction. INP can only be measured when somebody actually taps something. A lab test taps nothing, so it cannot report INP at all — it substitutes a rough proxy.
• Who your visitors are. If most of your traffic comes from cheap Android handsets on mobile data, your field numbers will be worse than a simulation, and that is the truth, not an error.
• Not enough traffic. Low-traffic pages have no field data of their own and get grouped at the origin level, or show nothing.

The working rule: field data tells you whether you have a problem. Lab data tells you where it is. Diagnose in the lab, judge by the field. Never the other way round.

What to actually do about each one

LCP is slow

In practice it is nearly always one of four things, in this order of likelihood:

1. The hero image is enormous. Photos uploaded straight from a phone or a camera are frequently three to five megabytes. That image needs resizing to the dimensions it is actually shown at, and saving in a modern format such as WebP or AVIF. This single change fixes more LCP failures than everything else combined.
2. The hero image is lazy-loaded. Lazy loading — only fetching images as the user scrolls to them — is good, except for the one image at the top. Someone has usually applied it site-wide, which tells the browser to delay the exact thing LCP is timing. Turn it off for the top image.
3. Slow server response. If the server takes 1.5 seconds to send the first byte of HTML, nothing downstream can save you. Cheap oversubscribed shared hosting is the usual culprit. Moving to decent hosting is a boring fix and often the biggest one.
4. Render-blocking fonts and stylesheets. A stack of Google Fonts weights loaded before anything can paint. Cut to one or two weights and let text display in a fallback font while the real one arrives.

INP is slow

INP is a JavaScript problem almost by definition. The browser can only do one thing at a time on its main thread; if a script is busy, your tap waits in the queue.

• Count your tags. Analytics, a pixel, a heatmap, a chat widget, a reviews widget, an exit-intent popup, a cookie banner and a third-party font loader is a normal state of affairs on an Indian small-business site, and it is far too much. Every one of those was added by someone with a reason. Ask which ones anybody has looked at in the last six months.
• Chat widgets and popups are the repeat offenders. They load early, they are heavy, and they run on every page. If you get two chats a month, a visible phone number and a WhatsApp link do the job for free.
• Plugin sprawl on WordPress. Fourteen plugins each adding a script to every page, when three of them are only used on the contact form.

CLS is bad

This is usually the cheapest of the three to fix, because it is not about speed at all — it is about the page reserving space in advance.

• Images without width and height set. The browser does not know how tall the gap should be, so it collapses, then jolts open when the image lands. Setting the dimensions in the markup fixes it.
• Ads, embeds and iframes — same problem, same fix: give the slot a fixed height.
• Late-injected banners. Cookie notices and offer bars that appear a second in and shove everything down. Either render them from the start or overlay them rather than pushing content.
• Custom fonts that swap. Text renders in a fallback, then reflows when the real font arrives at a different size. Matching the fallback's metrics reduces the jump.

What not to buy

Three things get sold in this category that we would not spend your money on.

"We will get you 100 out of 100 on PageSpeed." That number is the lab score, and it is not what Core Web Vitals assessment uses. It is achievable by stripping a page back to almost nothing, and it can be achieved on a page that is still a poor experience for real users. Buy an improvement in field data, or buy nothing.

An all-in-one optimisation plugin as the whole answer. Caching plugins are genuinely useful and we use them. But they compress and defer what is already there; they do not resize your four-megabyte hero image, they do not remove the chat widget nobody uses, and "defer all JavaScript" applied blindly can make INP worse while making the lab score prettier. A plugin is a tool, not a strategy.

A CDN sold as a speed cure. A content delivery network — servers around the world that keep copies of your files close to visitors — helps if you have international traffic or heavy media. If ninety per cent of your visitors are in India and your problem is a slow database query on cheap hosting, a CDN changes very little and you have added a monthly bill and a layer of complexity to debug.

How much does this actually matter for rankings?

Google has publicly said page experience signals are used in ranking and has been equally clear that relevance and quality of content matter more. Nobody outside Google can tell you the weighting, and anyone who quotes you a percentage is guessing. Our honest read: Core Web Vitals rarely make a page rank when the content does not deserve to, but they are a tiebreaker between similar pages, and — more concretely — a page that takes six seconds to show anything on a mobile connection loses customers before Google is even part of the conversation. Fix it for the conversion rate. Treat any ranking benefit as a bonus.

What to do next

Do this yourself, this week, before you commission anything:

1. Open PageSpeed Insights, enter your homepage and your most important service page, and look only at the field data section on the mobile tab. Note whether each of the three is green, amber or red.
2. If there is no field data, your traffic is too low for Google to have collected any. Use the lab score as a rough guide and prioritise the obvious: image sizes and script count.
3. Check the size of your hero image. If it is over 300 KB, you have found your first job.
4. List every third-party widget on the site and ask who uses each one.

If the field data is red and you would rather someone diagnosed it properly, that is technical support and site performance work, and it usually overlaps with the wider SEO picture. If the site is old enough that fixing it piecemeal costs more than replacing it, that is a web development conversation instead. Either way, tell us your URL and what your field data says and we will tell you which of the two it is.

Questions we get asked