Three questions a visitor asks
When someone opens a page, they are silently asking three things. Has the main content appeared yet? Does the page respond when I tap or click? Is anything going to jump around while I read? Core Web Vitals are a set of measurements that try to turn those three questions into numbers. They are published by search-related browser teams and are commonly treated as a way to describe real-world page experience.
The set has been updated over time, so check current documentation for the exact metrics and thresholds. At the time of writing, the three are usually described as Largest Contentful Paint (loading), Interaction to Next Paint (interaction) and Cumulative Layout Shift (visual stability).
Largest Contentful Paint: how fast the main content appears
Largest Contentful Paint, or LCP, measures how long it takes for the largest visible element in the first screen to render. That element is often a hero image, a large heading or a big block of text. It is a stand-in for the moment the visitor feels the page has “mostly loaded.”
A commonly cited guideline is that 2.5 seconds or less is good, and over 4 seconds is poor, with a band in between that needs improvement. Treat these as published guidelines that can change, not guarantees.
Typical causes of a slow LCP include:
- A large hero image that has not been compressed or is loaded late.
- A slow server response, so everything starts late.
- Files that delay the first view of the page, which the article on render blocking describes.
- Fonts that hold up text until they download.
Because LCP depends on one element, it is worth finding out which element it is on your key pages. Fixing something unrelated will not help.
Interaction to Next Paint: how quickly the page responds
Interaction to Next Paint, or INP, looks at how long the page takes to visually respond after a user interacts: a tap, a click or a key press. It considers interactions across the visit and reports a value that reflects the slower ones, rather than only the first.
Commonly cited guidance treats about 200 milliseconds or less as good and above 500 milliseconds as poor. Again, these figures are guidelines.
INP is mostly about JavaScript. If the browser is busy running a long task, it cannot update the screen when you tap a menu button, so the page feels frozen even though it has finished loading. Common causes include:
- Heavy third-party scripts such as chat widgets, advertising and tracking tags.
- Large amounts of code run on page load.
- Complex page elements that take a long time to redraw.
An earlier measure called First Input Delay looked only at the delay before the first interaction was handled. INP replaced it because it covers the whole visit. If you see older articles that mention FID, that is why.
Cumulative Layout Shift: how stable the page is
Cumulative Layout Shift, or CLS, adds up unexpected movements of visible content while the page loads and while it is used. Everyone knows the annoyance: you go to tap a link and an advertisement loads above it, pushing the link down so you hit something else.
The score is a unitless number, not a time. A commonly cited guideline is 0.1 or lower for good and above 0.25 for poor.
Common causes include:
- Images, videos or embeds without set dimensions, so the browser does not know how much room to leave.
- Ads or banners injected above existing content.
- Fonts that swap in with different sizing, which the article on font loading explains.
- Content inserted at the top of the page after it has started to render, such as cookie notices.
How the numbers are collected
The scores you see can come from two different kinds of sources. Real-visitor measurements, collected from actual browsers over a period of weeks, show what people experienced. Test-tool results are produced by loading a page once in a controlled environment. The two often disagree, and the difference is the subject of the article on field data. For Core Web Vitals, real-visitor data is generally treated as the more meaningful, while test tools are more useful for diagnosing causes.
Real-visitor data is also usually reported at a percentile (commonly the 75th). In other words, a page counts as good when most visitors, not just the fastest, had a good experience.
What to do with the scores
A few sensible habits:
- Check your important pages, not just the home page. Templates differ. A product page with large images may behave differently from a plain article.
- Look at mobile first. Phones are often slower and have less memory, and results are frequently worse there.
- Find the cause before fixing. A poor LCP might be an image, a server or a script. The fix depends on which one.
- Change one thing at a time. Then re-measure. Field data takes a few weeks to reflect changes because it averages over time.
- Keep it in proportion. Search engines use many signals. Page experience is generally described as one of them, and relevant, useful content is still central. Improving these measures is likely to help visitors, but nobody can promise a particular ranking effect.
For a broader look at causes of slow pages and ways to reduce load time, the article on page speed goes through them. Server response time and caching also come up often as underlying causes.
Common misunderstandings
- “A perfect score is the target.” A page that is comfortably in the good range does not need endless tuning. Spending days chasing the last few points rarely pays off.
- “The metrics measure total load time.” They do not. A page can finish loading late and still feel fast if the main content appears early and the page is responsive.
- “One test tells the truth.” A single test is a single sample, affected by network conditions and device power.
- “These are the only things that matter.” They cover three aspects of experience. Accessibility, readability and clear navigation are not covered at all.
Used sensibly, Core Web Vitals give a shared vocabulary for talking about speed and stability. They are best treated as diagnostic prompts that tell you where to look, not as a grade.