Core Web Vitals are three metrics Google uses to measure visitors' real experience of a page: how quickly the main content appears (LCP), how quickly the page responds to actions (INP) and how stable the layout stays while it loads (CLS). Good values are an LCP of no more than 2.5 seconds, an INP of no more than 200 milliseconds and a CLS of no more than 0.1, measured at the 75th percentile of visits.
In short, they are a standard way of answering the question “is my website fast and pleasant to use for real people?”. Below we explain each metric without jargon, how to check them for free and what usually drags them down.
In short
LCP measures loading, INP the response to a click or tap, CLS visual stability. Good thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1, for at least 75% of visits. What counts is real visitor data (from Search Console and PageSpeed Insights), not just the score of a one-off test.
What Core Web Vitals are and why website speed matters
Google defined Core Web Vitals as a small set of shared metrics for page experience. Each one captures a specific moment when a visitor forms an opinion about the site: “is it loading?”, “is it responding?”, “can I read without the text jumping around?”.
They matter for two reasons. The first is about people: a slow or unstable website is frustrating, and visitors leave more easily before they reach the form or the basket. The second is about search: Google uses page experience among its ranking signals, but the relevance and quality of the content remain more important. A fast site with weak content will not climb on speed alone; good content on a slow site, however, can lose visitors.
LCP: how quickly the main content appears
LCP (Largest Contentful Paint) measures the time until the largest visible element on the first screen is displayed. It is usually the main image, a banner or a large block of text. It is the metric closest to the impression that “the page has loaded”.
- Good: no more than 2.5 seconds.
- Needs improvement: between 2.5 and 4 seconds.
- Poor: over 4 seconds.
Common causes: large, unoptimised images, a server that responds slowly, fonts and scripts that block rendering, and the main image being “lazy-loaded” (only when it scrolls into view) even though it is visible straight away.
INP: how quickly the page responds
INP (Interaction to Next Paint) measures how long it takes for the page to show a visible response after a visitor clicks, taps the screen or presses a key. It looks at interactions throughout the whole visit and reports one of the slowest. Since March 2024, INP has replaced the old FID (First Input Delay) metric, which only measured the delay of the first interaction.
- Good: no more than 200 milliseconds.
- Needs improvement: between 200 and 500 milliseconds.
- Poor: over 500 milliseconds.
Common causes: too much JavaScript running at the same time, third-party scripts (chat, ads, analytics, widgets) keeping the browser busy, and menus or filters that recalculate the whole page on every click. On more modest phones the problem shows up far more clearly than on a high-end laptop.
CLS: how much the content “jumps”
CLS (Cumulative Layout Shift) measures how much elements on the page move unexpectedly. The typical situation: you are about to tap a button, an image or banner loads above it, the button moves down and you tap something else. CLS is not measured in seconds; it is a unitless score.
- Good: no more than 0.1.
- Needs improvement: between 0.1 and 0.25.
- Poor: over 0.25.
Common causes: images and videos without reserved dimensions, cookie banners or ads inserted over the content, fonts that visibly change after loading, and elements added dynamically above text that is already displayed.
Practical tip
The thresholds apply at the 75th percentile. This means a page only passes if at least three quarters of visits have a good experience. It is not enough for the site to be fast on your own computer, at the office, on a good connection.
Field data vs lab tests: why the score differs
There are two kinds of measurement, and confusing them is the most common source of misunderstanding.
- Field data: comes from real visitors, on their own devices and connections, aggregated over a period of several weeks. This is what Google uses to assess Core Web Vitals.
- Lab data: a simulated test, run once, on a standard device and connection. It is useful for finding causes and quickly checking a change, but it does not exactly reflect your audience's experience.
That is why you can have a high lab score and still have problems in the real data, or the other way round. For websites with few visitors, field data may be missing entirely, and then you rely on lab tests and checks on real phones.
How to check Core Web Vitals: PageSpeed Insights and Search Console
PageSpeed Insights
PageSpeed Insights is a free tool from Google. You enter a page's address and get, at the top, real visitor data (if there is enough of it) and, further down, a lab test with a score and recommendations. Check the mobile and desktop results separately and test the pages that matter: service pages, categories, products, not just the home page.
Google Search Console
The Core Web Vitals report in Search Console groups the site's pages by status (good, needs improvement, poor) and by the main issue. It is the best place to see the overall picture and to track whether a fix has worked. Results update gradually as new data comes in, so improvements do not show up the next day.
How to improve website speed: the usual fixes
- Optimise images: modern formats, sizes that suit the screen, compression, and the main image loaded with priority.
- Reserve space for images, videos, ads and banners so they do not push the content around.
- Cut back third-party scripts: keep only what you use and load them after the main content or after consent, where relevant.
- Break up large JavaScript tasks so the page stays responsive to clicks.
- Use hosting that suits your traffic, caching and, if your audience is wide, a content delivery network (CDN).
- Load fonts efficiently and limit the number of variants you use.
- Drop themes and plugins loaded with features you do not use.
Order matters. Start with the pages that bring in the most visits or enquiries and with the metric furthest from its threshold. Simple fixes, such as optimising images or reserving space for banners, are usually quick. INP problems caused by too much JavaScript or an overloaded theme may need deeper changes to the way the site is built.
The platform matters too, but it does not decide the result on its own. A site on WordPress, on Shopify or custom-built, for example with Next.js, can be fast or slow depending on the theme, the plugins, the images and the scripts added over time. That is why checking is not a one-off: every new widget, every marketing script and every plugin installed can change the metrics.
Quick website speed checklist
- I have checked the important pages in PageSpeed Insights, on mobile and on desktop.
- I have opened the Core Web Vitals report in Search Console and I know which groups of pages have problems.
- The main image on the first screen loads with priority and is the right size.
- Images, videos and banners have reserved space.
- Unused third-party scripts have been removed.
- I have tested the site on an ordinary phone, not just the latest model.
- I have noted the values before making changes, so I can compare after a few weeks.
Important limitation
A score of 100 in the lab test is not a goal in itself. Prioritise the pages that bring in enquiries or sales and the problems that affect real visitors. Sometimes a useful element (a map, a configurator) is worth keeping even if it lowers the score slightly, provided it is loaded intelligently.
How WEB-AZ helps with Core Web Vitals
At WEB-AZ we check Core Web Vitals on the important pages, in both field data and lab tests, and propose fixes in order of impact: images, scripts, fonts, hosting or, where needed, a rebuild of the template. If you want to know why your website loads slowly, send us its address and a few pages that matter to you.
Next steps