Core Web Vitals are a set of metrics Google introduced in 2020 that became an official ranking factor in 2021 with the Page Experience Update. They measure three fundamental dimensions of user experience: how quickly the page's main content loads, how quickly it responds to interactions and how stable the layout stays while loading. If your site scores poorly on these metrics, Google penalises it in the SERPs compared with sites that have similar content but better performance. In this guide you'll find everything you need to understand, measure and optimise Core Web Vitals — with precise target values, free tools and concrete techniques you can apply even without a developer.
Sources: Google, web.dev/vitals
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | ≤ 2.5 s | 2.5–4 s | > 4 s |
| INP (responsiveness) | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (visual stability) | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Values at the 75th percentile of real visits. Source: Google, web.dev/vitals
What Core Web Vitals are and why Google uses them for ranking
Core Web Vitals are one part of page experience: Google does not use a single "page experience signal", but its ranking systems take several aspects of experience into account, including HTTPS, the absence of intrusive interstitials and mobile-friendliness. However, the three core metrics — LCP, INP and CLS — carry the most weight in rankings. Google collects them from real Chrome user data (the Chrome User Experience Report, CrUX for short) and compares them with lab data from PageSpeed tests. This means a good lab PageSpeed score is not enough: what counts is the experience of your real visitors, with their connections, their devices and their conditions of use. A site that loads in 1.2 seconds in a lab test but serves unoptimised images over mobile networks can easily have a 4–5 second LCP in the field. To access CrUX data for your site, your domain needs enough traffic to be included in the dataset — if the site is new or gets very few visits, Google Search Console will show an "insufficient data" message and you'll have to rely solely on lab data until traffic grows.
The way Core Web Vitals influence rankings isn't as simple as a numerical score. Google applies a threshold system: each metric has three zones — Good (green), Needs improvement (orange) and Poor (red). A page passes the Core Web Vitals assessment (the one shown in Search Console and PageSpeed Insights) when the 75th percentile of real sessions falls within the green zone for all three metrics. The 75th percentile means 75% of sessions must be below the green threshold — not the average, not the median. This matters because the average can be skewed by a small number of very fast sessions, while the 75th percentile ensures that users in worse conditions also get an acceptable experience. If even one of the three metrics is red for 25% of users, the whole Page Experience signal turns negative.
LCP — Largest Contentful Paint: perceived loading speed
LCP measures the time it takes for the largest visible element in the viewport to be fully rendered. In most cases this is the hero image, the main banner or the first large block of text above the fold. Google's target is clear: under 2.5 seconds is good, between 2.5 and 4 seconds needs improvement, over 4 seconds is poor. LCP depends on four main factors that add up: server response time (TTFB), render-blocking time caused by CSS and JavaScript, download time of the main resource and rendering time in the browser. Optimising LCP means working on all four factors together — compressing images isn't enough if the server takes 800ms to respond.
The most common causes of a slow LCP are unoptimised hero images, web fonts that block rendering, unoptimised critical CSS and JavaScript, and slow hosting. For images, the most effective solution is to use WebP or AVIF at the right size for each breakpoint, combined with loading="eager" and fetchpriority="high" on the element that will become the LCP. Many developers make the mistake of applying loading="lazy" to every image, including the hero: this delays the LCP element even further because the browser doesn't start the download until the image is close to the viewport. Another key optimisation is preload: adding <link rel="preload" as="image"> in the <head> tells the browser to download the LCP image immediately, before it has even parsed the whole DOM. For fonts, using font-display: swap or font-display: optional prevents render blocking. font-display: optional is the most aggressive choice: if the font isn't available within about 100ms, the browser uses the fallback and never switches — it completely eliminates the flash of invisible text (FOIT) but can lead to inconsistent fonts across pages.
Good: ≤ 2.5 seconds — positive ranking signal
Needs improvement: between 2.5s and 4s — neutral, worth optimising
Poor: > 4 seconds — negative signal, high priority
The value is measured at the 75th percentile of real user sessions.
INP — Interaction to Next Paint: responsiveness to interactions
INP (Interaction to Next Paint) replaced FID (First Input Delay) as the interactivity metric in March 2024. While FID only measured the delay of the first input, INP measures the latency of every interaction the user has with the page — clicks, taps and key presses — and reports the 98th percentile of those latencies as the final score. In practice, it measures how responsive your site is when the user actively interacts with it. The targets are: under 200ms is good, between 200ms and 500ms needs improvement, over 500ms is poor. INP is especially problematic on JavaScript-heavy sites: every click event has to wait for the browser's main thread to be free before it is processed. If heavy scripts are running in the background, a click on a button can feel "stuck" for half a second or more, even though the browser technically registered the event.
The most common causes of a high INP are long JavaScript tasks (tasks that block the main thread for more than 50ms), heavy event listeners, massive re-layouts caused by alternating DOM reads and writes, and unoptimised third-party libraries such as chat widgets, heavy analytics and A/B testing. To improve INP you need to split long tasks into smaller chunks using scheduler.yield() or setTimeout, move heavy logic into Web Workers (separate threads that don't block the UI thread), and reduce or defer the loading of third-party scripts. Google recommends using the Chrome DevTools Performance Insights panel to identify long tasks: every red bar in the flame chart marks a task that exceeds 50ms. The most effective approach is to profile the application during a real interaction — for example, recording what happens when the user clicks the navigation menu or an add-to-cart button — and then optimise the longest tasks one at a time.
CLS — Cumulative Layout Shift: the page's visual stability
CLS measures how much the page layout shifts unexpectedly during loading and use. Every time an element moves without the user having done anything, it adds to the CLS score. The score is a unitless value calculated as the fraction of the impacted area multiplied by the distance moved. A CLS of 0.1 or less is considered good, between 0.1 and 0.25 needs improvement, above 0.25 is poor. The classic case of high CLS is the button you're about to click that moves because an ad banner or an image that finishes loading appears above it. This is particularly frustrating on mobile and can lead users to accidentally click the wrong link.
The most common causes of CLS are images without explicit dimensions (the browser doesn't know how much space to reserve until the image has loaded), ads of variable size, web fonts that replace the fallback and change the size of the text, and content injected dynamically by JavaScript above existing content. The main fix for images is to always specify the width and height attributes in the HTML tag: this lets the browser calculate the aspect ratio in advance and reserve the right space. For ads, use containers with fixed minimum dimensions. For fonts, use size-adjust and ascent-override in your @font-face declarations to reduce the layout shift caused by font swapping. Another effective technique is skeleton loading: showing grey placeholders the same size as the incoming content drastically reduces CLS because the space is already reserved in the layout.
- Based on real Chrome users
- Reflect real network and device conditions
- Available in Search Console and PageSpeed
- Updated on a rolling 28-day basis
- Used by Google for actual ranking
- Controlled, reproducible environment
- Available immediately after every change
- Useful for debugging and local development
- Not used directly for ranking
- Can differ widely from real-world data
Tools to measure Core Web Vitals
Google PageSpeed Insights is the starting point: enter the URL and you get both field data (if available in CrUX) and Lighthouse lab data. The most important section is the field data, because it shows the real values at the 75th percentile for LCP, INP and CLS. The lab section is useful for debugging but doesn't necessarily reflect what Google sees. For an aggregated view of every page on the site, use Google Search Console: the "Page experience" report shows how many URLs on your site are green, orange and red for each metric, with details for groups of similar URLs. It's the most important tool because it uses the same data Google uses for ranking. The third essential tool is Chrome DevTools: the Performance panel lets you record and analyse exactly what happens during loading and interactions, pinpointing long tasks, blocking resources and layout shifts with surgical precision.
For continuous monitoring, consider installing Google's web-vitals JavaScript library directly on your site: it collects real user metrics and sends them to your analytics system, letting you see real values segmented by page, device and connection type. This is far more useful than running a PageSpeed test once a month: it lets you spot regressions immediately after a site update and understand which pages have problems that never show up in lab tests. Tools such as Vercel Speed Insights, Sentry Performance and Datadog RUM already offer this built in if you use those platforms.
How to optimise LCP: practical techniques for developers and non-developers
Convert to WebP or AVIF, resize to the actual display size, add fetchpriority="high", remove loading="lazy" if present, and add a preload in the <head>. Typical saving: 0.5–1.5 seconds of LCP.
Use a CDN to serve static content from the location geographically closest to the user. Enable HTTP/2 and Brotli compression. If you use WordPress, install a caching plugin such as WP Rocket or W3 Total Cache. Typical saving: 0.2–0.8 seconds of TTFB.
Add defer or async to all non-critical scripts. Extract the critical (above-the-fold) CSS and inline it in the <head>, loading the rest of the CSS asynchronously. Tools such as Critical or Penthouse automate this. Typical saving: 0.3–1.0 seconds.
Use font-display: swap in your @font-face declarations. Preload critical fonts with <link rel="preload" as="font">. Consider using system fonts as the primary fallback if the visual difference is minimal. Typical saving: 0.1–0.5 seconds.
Common mistakes that wreck Core Web Vitals
loading="lazy" to the page's main image is one of the most frequent and damaging mistakes. The browser delays downloading the image until it's close to the viewport — but the hero image IS already in the viewport on load. The result: LCP gets significantly worse. The hero image should always have loading="eager" (or no loading attribute) and fetchpriority="high".<script> tag block DOM parsing. Every kilobyte of synchronous JavaScript in the <head> delays both LCP and INP. Always use defer or async for non-critical scripts, and consider deferring them further with a 3–5 second timeout after the load event for non-essential scripts such as chats.Core Web Vitals for WordPress sites
WordPress is the most widely used platform in the world and also the one with the most widespread performance problems, often caused by heavy themes, poorly optimised plugins and inadequate hosting. The main problem is that by default WordPress loads dozens of scripts and styles even when they aren't needed for the page being viewed — every plugin adds its resources indiscriminately. The first optimisation is to stop unused resources from loading: plugins such as Asset CleanUp or Perfmatters let you selectively disable scripts and styles on specific pages. The second priority is caching: a plugin such as WP Rocket or LiteSpeed Cache (if your host runs a LiteSpeed server) drastically cuts server response times by generating static HTML versions of dynamic pages. For images, Imagify or ShortPixel automatically convert to WebP and compress images on upload. Finally, consider managed WordPress hosting such as Kinsta, WP Engine or Cloudways: they cost more than shared hosting but already include a CDN, advanced caching and servers optimised for PHP, and they are often the difference between a 4-second LCP and a 1.8-second one.
The impact of Core Web Vitals on rankings: how much do they really matter?
Ever since Google confirmed Core Web Vitals as a ranking factor, many SEOs have wondered how much they really weigh compared with other signals. The honest answer is: less than content relevance and backlinks, but enough to make a difference in competitive markets. Google has stated that Core Web Vitals are a tiebreaker — with equal content and authority, the site with better performance has an advantage. In practice, this means that if your site is poor on all three CWV and your main competitors are in the green, you're leaving rankings on the table. Conversely, optimising CWV won't work miracles if your content doesn't match the user's search intent or if you don't have authoritative links. The right strategy is to treat Core Web Vitals as a quality prerequisite: they need to be green so you aren't penalised, then you build rankings with content and link building. Correlation studies show that sites in the top positions tend to have better CWV than sites further down — but causation isn't easy to isolate. What is certain is that a better user experience leads to more time on site, fewer bounces and more conversions — benefits that go well beyond the ranking factor alone.
Optimising Core Web Vitals requires a careful technical analysis and targeted work: there's no universal recipe, every site has its own specific issues. If you'd like a professional analysis of your site's performance with a concrete action plan, explore the SEO service or contact me directly for a consultation.
If you want to apply this to your own project, take a look at my SEO and online visibility service: clear prices from €200/month, a free quote and a reply within 24 hours.
