Core Web Vitals: What They Are and How to Improve LCP, INP, CLS

Core Web Vitals are three Google metrics that measure the experience of a site’s real users: how fast the main content loads (LCP), how quickly the page responds to clicks (INP) and how stable the layout is (CLS). A page passes the assessment when 75% of page views have LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 – separately on mobile and on desktop. Google confirms that its ranking systems take these metrics into account, but content relevance matters more than good CWV scores.

What are Core Web Vitals?

Core Web Vitals (CWV for short) are a set of metrics developed by Google. Their purpose is to measure the real user experience on a page. They focus on three aspects of site quality: loading speed, responsiveness to interactions and visual stability. They give site owners and developers concrete numbers to work from when improving how comfortable a site is to use.

CWV are part of a wider set of aspects Google calls ‘page experience’. There’s no single ‘page experience’ signal – Google says its core ranking systems look at a variety of signals that align with overall page experience, and Core Web Vitals are one of them. For users, good scores mean faster and more predictable browsing: nobody likes waiting for a slow page or tapping the wrong button because an element suddenly jumped down.

From a site owner’s point of view, optimising CWV isn’t just a technical matter. A faster, more stable site means fewer abandoned visits and fewer obstacles on the way to conversion – whether the goal is a purchase, a newsletter sign-up or a contact form.

Where Core Web Vitals came from – and why Google introduced them

The Chrome team introduced Core Web Vitals in early May 2020, and on 28 May 2020 Google Search announced that they would become part of the page experience ranking signals. The update known as the ‘page experience update’ rolled out gradually from 15 June to the end of August 2021 – for mobile results first. The desktop version rolled out from 22 February to the end of March 2022.

The biggest change to the Core Web Vitals line-up was replacing First Input Delay (FID) with Interaction to Next Paint (INP) on 12 March 2024. FID only measured the delay of the first interaction, whereas INP assesses responsiveness throughout the whole visit. It shows that Core Web Vitals aren’t a closed set of rules: Google has a defined metric lifecycle (experimental → pending → stable) and announces changes to the stable set well in advance. Optimising user experience is therefore an ongoing process, not a one-off job.

The main reason for introducing Core Web Vitals was Google’s push to improve the overall quality of pages on the web. Users clearly prefer sites that load quickly, are visually stable and respond to clicks straight away – and CWV make it possible to put numbers on those three qualities.

Poor user experience also has business consequences. According to Google’s data (Think with Google, a study of mobile pages), the probability of a bounce increases by 32% as page load time goes from 1 to 3 seconds. Pages that load quickly and stay stable frustrate users less often and more often lead them further – to other pages, the offer and the form.

Are Core Web Vitals a ranking factor?

Yes, but with an important caveat. In its Search Central documentation Google says plainly that Core Web Vitals are used by its ranking systems and recommends achieving good results. At the same time it stresses that Search always tries to show the most relevant content, even if the page experience is sub-par. Page experience can matter mainly when there are many pages with similarly helpful content.

In practice this means improving CWV won’t drag weak content to position one, but it’s one of the elements that can decide the order when results are of similar quality. The benefits on the user side are much more certain: shorter loading times and a stable layout reduce abandoned visits regardless of where you rank in Google.

The main Core Web Vitals (CWV) metrics and what they mean

Core Web Vitals consist of three metrics that measure different, complementary aspects of user experience. All three are assessed at the 75th percentile of page views, separately for mobile and desktop. A page (or a group of URLs) only passes the assessment when all three metrics are in the ‘Good’ range.

Metric	What it measures	Good	Needs improvement	Poor
LCP	Loading of the main content	≤ 2.5 s	> 2.5 s and ≤ 4 s	> 4 s
INP	Responsiveness to interactions	≤ 200 ms	> 200 ms and ≤ 500 ms	> 500 ms
CLS	Visual stability	≤ 0.1	> 0.1 and ≤ 0.25	> 0.25

Largest Contentful Paint (LCP) – how fast the largest content element loads

Largest Contentful Paint (LCP) is a metric that measures the time from when the page starts loading to when the largest content element in the visible area (the viewport) is rendered. That largest element can be an image, a block of text, a video poster or a background image. LCP roughly marks the moment the user sees that the page’s main content has loaded – in other words, their first impression.

Google has set the following thresholds for assessing LCP:

LCP rating	Time (seconds)
Good	≤ 2.5
Needs improvement	> 2.5 and ≤ 4
Poor	> 4

Important: Google recommends that the 75th percentile of page views – calculated separately for mobile and desktop – falls within the ‘Good’ threshold. This means at least three out of four visits should see the main content load quickly.

LCP can be broken down into four sub-parts (web.dev also gives a rough share of each on a well-optimised page):

• Time to First Byte (TTFB): the time from when the page starts loading until the first byte of the HTML response arrives (approx. 40% of LCP). A long TTFB usually means slow hosting, no page cache or heavy database queries. I’ve covered this in detail in my post on improving TTFB.
• Resource load delay: the time between TTFB and when the browser starts downloading the LCP resource (target: under 10%).
• Resource load duration: the time needed to download the LCP element itself, e.g. an image (approx. 40%).
• Element render delay: the time between the LCP resource finishing downloading and it being rendered (target: under 10%). It’s usually caused by render-blocking resources, such as large CSS files or synchronous JavaScript.

The most common factors affecting LCP

• Images: very often an image (a header photo, a slider) is the LCP element. The usual problems are oversized files, no compression, an image deferred by lazy loading or set as a CSS background, so the browser only discovers it after downloading the stylesheet.
• Server response time: a slow server, no page cache or no CDN directly lengthen TTFB.
• Render-blocking resources: CSS and JavaScript files that have to be downloaded and processed before the main content can be displayed.
• No caching: without a server-side cache every page view takes longer to generate, and without a browser cache the browser has to download resources again on every visit.

How to check LCP and how to improve it

You’ll find data from real visits in the Core Web Vitals report in Google Search Console and in PageSpeed Insights (CrUX data). The quickest way to see which element is the LCP element and which of the four sub-parts takes longest is the Performance panel in Chrome DevTools or the diagnostics section of PageSpeed Insights. I cover the tools in more detail further down.

Improving LCP needs an all-round approach:

• Optimise the LCP image: use modern formats (WebP, AVIF), compress images and match their size to where they’re displayed (srcset). The LCP image should be in the HTML as a regular <img> tag, not a CSS background, and have the fetchpriority=”high” attribute. Never lazy-load the LCP image – use lazy loading only for images below the first screen.
• WordPress: since version 6.3, WordPress itself adds fetchpriority=”high” to the image it considers the likely LCP element and doesn’t add loading=”lazy” to it. It’s still worth checking whether your theme, page builder or lazy-loading plugin overrides this behaviour – for example in header sliders.
• Improve server response time (TTFB): fast hosting, page caching (in WordPress via a caching plugin or server-side cache) and a CDN that serves content from a server closer to the user.
• Cut down render-blocking resources: remove unused CSS and JavaScript, minify files and defer non-critical scripts (async or defer attributes).
• Set up caching: a server-side cache shortens page generation, and the browser cache speeds up repeat visits.

LCP is the ‘first impression’ metric. If the user waits a long time for the key content, the risk grows that they’ll leave before seeing anything. Since TTFB and resource load duration usually account for most of LCP, it pays to start with the fundamentals – the server, caching and the header image – and only then move on to fine-tuning the code.

Interaction to Next Paint (INP) – how responsive the page is to interactions

Interaction to Next Paint (INP) is a metric that measures a page’s overall responsiveness. It observes the latency of all mouse clicks, taps on a touchscreen and key presses throughout the entire visit – what counts is the time from the interaction to the next update of what’s on screen. Scrolling, hovering and zooming aren’t taken into account. The result is usually the slowest interaction; on pages with lots of interactions, one slowest interaction is ignored for every 50, so that a few random ‘hiccups’ don’t inflate the score.

INP replaced First Input Delay (FID) as one of the Core Web Vitals on 12 March 2024. FID only measured the delay of the first interaction – and only up to the point when the browser started handling it. INP covers the whole interaction, including processing time and displaying the change, throughout the visit.

Google has set the following thresholds for assessing INP:

INP rating	Time (milliseconds)
Good	≤ 200
Needs improvement	> 200 and ≤ 500
Poor	> 500

Important: as with LCP, Google recommends that the 75th percentile of page views falls within the ‘Good’ threshold.

Every interaction consists of three parts: input delay (waiting for the browser’s main thread to become free), processing time (running the event handler code) and presentation delay (recalculating the layout and rendering the change). The main factors affecting INP are:

• Long JavaScript tasks: long-running scripts block the browser’s main thread. As long as it’s busy, the browser can’t handle a click.
• Overloaded main thread: the main thread is responsible for parsing HTML, running JavaScript and rendering. In lab tests, a high Total Blocking Time (TBT) is the tell-tale sign of this problem.
• Third-party scripts: ads, analytics tools, chat widgets, tracking pixels and social media widgets run their own code, which competes with yours for the main thread.
• Large DOM (Document Object Model): the more elements on the page, the longer it takes to recalculate styles and layout after every change – which lengthens presentation delay.
• Inefficient event handling: overly complex JavaScript functions triggered by a click (e.g. shop filters or a mobile menu) lengthen processing time.

How to check INP and how to improve it

INP is a field metric – it needs a real interaction, so it can’t be measured in a lab test alone. INP data from real visits is shown in the Core Web Vitals report in Search Console and in PageSpeed Insights (the CrUX data section). Lighthouse in PageSpeed Insights doesn’t measure INP; the closest lab equivalent is TBT. To find a specific slow interaction, open the Performance panel in Chrome DevTools: the live metrics view shows INP for your own clicks, and a recorded profile shows which script was blocking the main thread.

Improving INP is all about optimising JavaScript and taking load off the main thread:

• Limit and defer third-party scripts: review what actually loads on the page. In WordPress it’s often plugins loading their scripts on every page even though they’re needed on one (e.g. a contact form, a slider, a chat widget). Remove what you don’t need and load the non-critical stuff later.
• Reduce input delay: break long main-thread tasks into smaller chunks and yield control back to the browser (e.g. with setTimeout or scheduler.yield()), so it can handle interactions in between.
• Optimise processing time: check in the performance profile where the browser spends most of its time and simplify that part of the code. In frameworks such as React it’s important to avoid unnecessary re-rendering of components.
• Update the UI before heavy processing: show visual feedback first (e.g. a loading indicator) and do the heavy work afterwards. For big calculations, consider web workers, which run off the main thread.
• Avoid blocking dialogs: the native alert, confirm and prompt dialogs block the main thread – it’s better to replace them with non-blocking UI elements.
• Reduce presentation delay: keep the DOM small and limit how much of the layout changes after an interaction, so the browser can render the next frame faster.

INP measures the quality of the whole visit, not just the initial load. That matters especially on pages with rich interactions – configurators, calculators, product filters or multi-step forms. If every click ‘stutters’, the user quickly loses patience before they ever get to convert.

Cumulative Layout Shift (CLS) – visual stability of the page

Cumulative Layout Shift (CLS) is a metric that measures a page’s visual stability. It counts unexpected layout shifts over the entire lifetime of the page – not just during loading. Shifts are grouped into ‘session windows’ (consecutive shifts less than 1 second apart, with a maximum of 5 seconds per window), and the CLS score is the highest score among those windows. Shifts that happen within 500 ms of a click, tap or key press are treated as expected and aren’t counted.

Google has set the following thresholds for assessing CLS:

CLS rating	Value
Good	≤ 0.1
Needs improvement	> 0.1 and ≤ 0.25
Poor	> 0.25

Important: as with the other metrics, Google recommends that the 75th percentile of page views falls within the ‘Good’ threshold.

The score of a single layout shift is the product of two factors:

• Impact fraction: how much of the visible area (the viewport) the unstable elements take up – across the previous and the current frame combined.
• Distance fraction: the greatest distance an element has moved, divided by the viewport’s larger dimension.

The main causes of high CLS

• Images and videos without dimensions: when an image or video has no width and height attributes (and no aspect ratio set in CSS), the browser doesn’t know how much space to reserve. Once the file loads, the content below it ‘slides’ down.
• Dynamically injected content: ads, cookie consent banners, promo bars and other elements that appear after the initial render and push existing content around.
• Web fonts: when text is first displayed in a fallback font and then swapped for the target font with different dimensions (the so-called FOUT – flash of unstyled text), the height and width of text blocks change, which shifts the layout.
• CSS animations: animating properties that affect layout, such as top, left, width, height or margin, forces the layout to be recalculated and can cause shifts.

How to check CLS

You can check CLS with the same tools as LCP and INP: field data in Search Console and PageSpeed Insights, and the details in the Performance panel in Chrome DevTools, which marks layout shifts on the timeline and shows which elements moved. Remember that a lab test (Lighthouse) only sees shifts during loading – shifts after scrolling or after using the page for a while will only show up in data from real users.

How to improve CLS

Improving CLS is mainly about making the page layout predictable:

• Set dimensions for images and videos: add width and height attributes to <img> and <video> tags (or set proportions with CSS aspect-ratio), so the browser can reserve space before the file loads. In WordPress, pay special attention to elements added by the theme and plugins: the logo, sliders, embedded videos.
• Don’t insert content above existing content: unless it’s a direct response to an interaction (e.g. expanding a section on click), don’t dynamically insert new elements above content the user can already see. A cookie banner works better as an overlay (position: fixed) than as a block that pushes the page down.
• Reserve space for ads and embeds: for ads, iframes and other dynamic elements, reserve the space in advance, e.g. with min-height or aspect-ratio.
• Optimise font loading: preload critical fonts (link rel=”preload”), consider font-display: optional and pick fallback fonts with dimensions similar to the target ones (e.g. with size-adjust in the @font-face rule), so the font swap doesn’t change the layout.
• Use CSS transforms instead of layout-changing animations: instead of animating top or left, use transform (translate, scale, rotate) – these animations don’t move the surrounding content and don’t affect CLS.

CLS is closely tied to trust. Unexpected shifts lead to accidental clicks, losing your place in the text and a feeling of not being in control. A page that ‘jumps’ simply looks less professional – and that directly affects whether a user is willing to leave their details on it.

Tools for measuring Core Web Vitals

Effective Core Web Vitals optimisation needs regular monitoring. Google offers free tools that show either data from real users (field data) or data from lab tests (lab data). Field data is what counts for assessing a page; lab data is for diagnosis.

Google Search Console (GSC)

Google Search Console is the essential tool for site owners, showing Core Web Vitals results for the whole site based on data from real visits (CrUX).

• Accessing the report: after logging in to GSC and choosing a property, open the ‘Core Web Vitals’ report in the side menu. The report has separate views for mobile and desktop.
• How the data is shown: the report assigns URLs the statuses ‘Good’, ‘Needs improvement’ and ‘Poor’. The data covers the last 28 days and represents the 75th percentile of results. A group’s status is set by its weakest metric – if INP is good but CLS is poor, the whole group is ‘Poor’.
• URL grouping: GSC groups URLs with a similar user experience, which makes it easier to spot problems affecting whole page templates rather than just individual pages.
• Limitations: the report isn’t real-time, and low-traffic sites may have no data in it at all. It also doesn’t point to the specific elements causing a problem – only to the page groups and metrics that need attention.

Google PageSpeed Insights (PSI)

PageSpeed Insights is Google’s free tool for analysing individual URLs.

• Field and lab data: at the top of the report PSI shows CrUX field data (LCP, INP, CLS from the last 28 days) – this is what corresponds to the Core Web Vitals assessment. Below that is a Lighthouse lab test in a simulated environment, useful for diagnosing problems. Lighthouse doesn’t measure INP; it shows Total Blocking Time (TBT) instead.
• Recommendations: since Lighthouse 13 (October 2025), the old audits (‘opportunities’ and ‘diagnostics’) have been replaced by insights – the same analyses shown in the Performance panel in DevTools, e.g. the LCP breakdown, render-blocking resources or DOM size.
• Overall score: PSI generates a Performance Score on a 0–100 scale, which is a weighted average of lab metrics. A score of 90 or above is considered good. It is not the Core Web Vitals assessment – a page can score below 90 and still pass CWV in field data (and vice versa).
• Switching between devices: results are separate for mobile and desktop – start with mobile, because that’s usually where the problems are bigger.

Chrome DevTools

The developer tools built into Chrome are for diagnosing CWV on your own computer – this is where it’s easiest to find the cause of a problem.

• Performance panel – live metrics: as soon as you open the panel you can see local LCP, CLS and INP values while using the page, without recording a profile. The panel can also fetch CrUX field data for the URL and compare it with your local result.
• Performance panel – recording a profile: lets you analyse main-thread activity in detail: long JavaScript tasks, layout shifts, the LCP element and its sub-parts. It’s especially useful for debugging INP and TBT.
• Lighthouse panel: lets you run the same lab test as PageSpeed Insights, but locally – e.g. on a staging version of the site that can’t be tested from outside.

The Web Vitals Chrome extension, recommended in many older guides, is no longer developed – Google ended support for it in January 2025 and moved its features into the Performance panel.

Chrome User Experience Report (CrUX): CrUX Vis and the CrUX API

CrUX is a public dataset of real Chrome users’ experiences – it’s what Search Console and PageSpeed Insights draw on.

• CrUX Vis: a free tool for browsing historical CrUX data for a domain or a single URL. The data is updated weekly. It replaced the old CrUX Dashboard in Looker Studio, whose connector was switched off after November 2025.
• Historical trend: lets you track how results change over time and judge whether the fixes you’ve deployed actually worked.
• CrUX API and BigQuery: for more advanced analysis. Since January 2025 the CrUX API has provided, among other things, LCP sub-parts for images, the LCP resource type (text or image) and round-trip time (RTT) data.
• Limitations: like GSC, CrUX needs enough traffic. The data covers a 28-day window, so the effects of changes aren’t visible straight away.

The web-vitals library (measuring on your own site)

If your site has too little traffic for CrUX, or you want to see results sooner than after 28 days, you can measure Core Web Vitals yourself. Google provides a small JavaScript library, web-vitals, which measures LCP, INP and CLS for real users and lets you send the results to, for example, Google Analytics or your own analytics system. The attribution build also tells you which element or interaction is responsible for a poor score.

It’s important to understand the difference between lab data and field data. Lab data (Lighthouse in PageSpeed Insights or DevTools) is collected in a controlled environment, which allows repeatable tests and precise diagnosis, but doesn’t reflect the variety of devices, networks and user behaviour. Field data from CrUX (available in GSC, PSI, CrUX Vis and DevTools) comes from real users, and that’s what the Core Web Vitals assessment is based on.

What changed in Core Web Vitals in 2025–2026?

The metrics and thresholds themselves haven’t changed: since March 2024 Core Web Vitals are still LCP, INP and CLS. What has changed are the tools and the way things are measured:

• January 2025: the CrUX API adds LCP sub-parts for images, the LCP resource type and network latency data (RTT). The same month, support for the Web Vitals extension ended – its features (live metrics, comparison with CrUX data) are now in the Performance panel in Chrome DevTools.
• October 2025: Lighthouse 13 replaced the old performance audits with the new insights (in PageSpeed Insights too). The way the performance score is calculated didn’t change.
• November 2025: the CrUX Dashboard in Looker Studio was retired – CrUX Vis is the replacement.
• July 2026 – Soft Navigations: from Chrome 151 (stable release on 28 July 2026) the Soft Navigations API is enabled by default. It makes it possible to measure the metrics in SPA-style applications, where moving to another page doesn’t reload the whole page. Google said it would only decide whether to include this data in CrUX after the API ships – until then it doesn’t affect the Core Web Vitals assessment in Search Console.

General Core Web Vitals optimisation strategies

Optimising Core Web Vitals means working on several fronts at once. Below I’ve gathered the strategies that most often improve results – noting which metric each one affects.

Image optimisation

Images are often the largest elements on a page, so they have a big impact on LCP – and missing dimensions affect CLS.

• Use the right formats: WebP and AVIF offer better compression than JPEG and PNG at comparable quality.
• Compression and the right size: compress images and don’t send a 3000 px wide file where it’s displayed at 800 px. WordPress generates several sizes of every image and a srcset attribute, provided your theme uses them.
• Set dimensions: width and height attributes let the browser reserve space and prevent layout shifts (CLS).
• Lazy loading – only below the first screen: images that aren’t visible straight away can load only when the user scrolls. This reduces the initial page weight. The LCP image and other images visible on load shouldn’t be lazy-loaded.
• Prioritise key images: use the fetchpriority=”high” attribute for the LCP image, and if the image isn’t visible in the HTML (e.g. it’s a CSS background) – link rel=”preload”.

Minifying and deferring JavaScript

Too much JavaScript slows down both loading (LCP) and the response to clicks (INP).

• Minify the code: removing unnecessary characters, spaces and comments reduces file size.
• Defer non-critical scripts: load scripts that aren’t needed for the initial render asynchronously (async) or deferred (defer), so they don’t block rendering.
• Remove unused code: regularly check which scripts are really needed. In WordPress the biggest source of unnecessary JavaScript is usually plugins and page builders.
• Break up long tasks: split long JavaScript functions into smaller tasks, so the main thread can respond to interactions in between.

Using a content delivery network (CDN)

A Content Delivery Network (CDN) is a network of geographically distributed servers that store copies of a site’s resources.

• Faster content delivery: a CDN serves resources from the server closest to the user, which shortens file download times – and, when whole pages are cached, TTFB too – ultimately improving LCP.
• Lower server load: spreading traffic across many servers takes load off the origin server, which helps keep response times short under heavy traffic. A CDN doesn’t improve INP, though – responsiveness depends on the browser’s work on the user’s device, not on the server.
• Better availability and security: a CDN provides redundancy and can protect against DDoS attacks.

Setting up effective caching

Caching means storing ready-made copies of pages and files, so they don’t have to be generated or downloaded from scratch every time.

• Browser caching: the browser stores static resources (images, CSS, JavaScript) locally, so it doesn’t download them again on the next visit.
• Server-side caching: full-page caching (in WordPress via a caching plugin or a server mechanism) and object caching (e.g. Redis, Memcached) reduce the load on the database and shorten TTFB, which feeds through to LCP.

CSS optimisation

CSS files control how the page looks and is laid out, and optimising them affects LCP and CLS.

• Minify CSS: as with JavaScript, remove unnecessary characters and unused rules.
• Reduce render-blocking CSS: avoid loading large stylesheets in the <head> that aren’t needed to display the first screen. Critical CSS (for ‘above the fold’ content) can be placed directly in the HTML.
• Font optimisation: as I mentioned in the CLS section, preloading fonts, font-display and matched fallback fonts prevent layout shifts.

Improving server response time (SRT)

Server Response Time (SRT), measured in practice as TTFB, is the first part of LCP – every millisecond of server delay pushes back the display of the main content.

• Choose reliable hosting: fast, stable hosting with an up-to-date PHP version is the foundation of good response times in WordPress.
• Optimise database queries: fast queries and indexes are key for dynamic sites. In WordPress they’re often slowed down by bloated plugins and too much data in the options table that gets loaded on every request.
• Reduce server load: besides a CDN and caching, you can consider a more powerful server or load balancing for high traffic.

Built-in WordPress optimisations

These days WordPress does some of the work itself – provided it’s up to date and your theme and plugins don’t get in the way:

• WordPress 6.3: automatic fetchpriority=”high” for the image most likely to be the LCP element, and no lazy loading for images visible on load.
• WordPress 6.8: built-in prefetching of pages (Speculative Loading, based on the Speculation Rules API) – enabled by default for logged-out users; the browser starts fetching a page when the user starts clicking a link. It works in Chromium-based browsers.
• WordPress 6.9: among other things, block styles loaded only when needed, also in classic themes, the option to set fetch priority for scripts, and dimensions in the video block that eliminate layout shifts.

Summary and recommendations

Core Web Vitals are three metrics – LCP, INP and CLS – that measure how real users perceive a page’s speed, responsiveness and stability. Google uses them in its ranking systems, but content relevance still matters more, so treat CWV as an edge when content quality is similar and, above all, as a way to give users a better experience. The switch from FID to INP in 2024 and the tooling changes in 2025–2026 show this is an area you need to keep monitoring, not something you fix once.

A practical order of work: check the Core Web Vitals report in Search Console, pick the weakest metric and the most important URL groups, diagnose the cause in PageSpeed Insights and the Performance panel in DevTools, deploy fixes and watch the field data over the next 28 days. If you’d like help with that kind of analysis, see how my technical SEO and site optimisation works.

FAQ – common questions about Core Web Vitals

What are Core Web Vitals in a nutshell?

They’re three Google metrics that measure user experience: LCP (main content loading, good score ≤ 2.5 s), INP (response to interactions, ≤ 200 ms) and CLS (layout stability, ≤ 0.1). They’re assessed at the 75th percentile of page views using data from real Chrome users.

Do Core Web Vitals affect Google rankings?

Yes – Google confirms its ranking systems use Core Web Vitals. At the same time it points out that the most relevant content can win even with a poor page experience. So good CWV scores mainly help when competing pages have similarly valuable content.

How is INP different from FID?

FID only measured the delay of the first interaction on a page. INP, which replaced FID on 12 March 2024, takes into account all clicks, taps and key presses during the visit and measures the full time until the response appears on screen.

Why does PageSpeed Insights show different results from Search Console?

Search Console shows CrUX field data for groups of URLs from the last 28 days. PageSpeed Insights shows field data for a specific URL (or the whole origin when the URL doesn’t have enough data) and, separately, a one-off Lighthouse lab test. The 0–100 Lighthouse performance score is not the Core Web Vitals assessment.

My site has no data in the Core Web Vitals report. What should I do?

The report needs a minimum number of visits from Chrome users, so small sites often don’t have it. In that case, measure the metrics yourself with the web-vitals library, and use the Performance panel in Chrome DevTools and a Lighthouse test for diagnosis.

How quickly will I see the effects of improving Core Web Vitals?

In lab tests – immediately after deployment. In field data (Search Console, CrUX) the change shows up gradually, because the results cover a 28-day window. So you’ll see the full effect after about four weeks.