Core Web Vitals are the three metrics Google uses to evaluate the user experience of a page: LCP for loading speed, INP for responsiveness and CLS for visual stability.

According to a Google study, the probability of a bounce increases by 32% when load time goes from 1 to 3 seconds.

NEXUS SYNERGY, a WordPress agency with an average Lighthouse score of 95+, walks you through the thresholds to aim for in 2026 and how to reach them.

Core Web Vitals are three metrics defined by Google to evaluate the real experience of visitors on a web page: LCP measures how fast the main content appears, INP measures responsiveness to interactions and CLS measures visual stability. Since June 2021, these signals have been part of how Google ranks search results.

At NEXUS SYNERGY, a WordPress agency specialized in web performance, we audit these three metrics on every project, and our 150+ delivered sites show an average Lighthouse score of 95+. This guide explains exactly what Core Web Vitals measure, the thresholds to aim for in 2026 and the optimizations that produce measurable results.

Developer measuring page performance on a laptop

What are Core Web Vitals and why did Google create them?

Core Web Vitals are a set of three indicators launched by Google in May 2020 to quantify the experience a visitor actually has on a page. Since the Page Experience update of June 2021, they have been part of the search ranking signals. In other words, a slow or unstable page starts with a handicap against a fast competitor with comparable content.

Each metric covers a specific dimension of the experience:

  • LCP (Largest Contentful Paint): how fast the main content of the page appears
  • INP (Interaction to Next Paint): how responsive the page is when the user clicks, types or taps the screen
  • CLS (Cumulative Layout Shift): visual stability, meaning the absence of layout jumps

Google evaluates these three values using real data collected from Chrome users, aggregated in the CrUX report (Chrome User Experience Report). For a page to pass, each metric must reach the "good" threshold for at least 75% of visits, on mobile and desktop separately. This point escapes many site owners: your page can feel instant on the office fiber connection and still look bad to Google, because most of your visitors browse it on 4G with an entry-level phone.

LCP: how fast your main content appears

LCP (Largest Contentful Paint) measures the time it takes to display the largest element visible on screen, usually a cover image or a large block of text. It is the first of the three Core Web Vitals and the most intuitive: it answers the question "when do I finally see the page?". Google considers an LCP under 2.5 seconds to be good. Beyond 4 seconds, on the other hand, the page is rated poor.

At NEXUS SYNERGY, we aim stricter: an LCP under 1.5 seconds on every site we deliver, because the difference between 2.4 and 1.2 seconds is felt immediately, even if both values pass in the green. The NovaTech case shows the scale of the possible gains. When we took over that site, loading took 6.2 seconds. After the rebuild, 0.9 seconds, and the Lighthouse score went from 34 to 98.

The causes of a poor LCP almost always come up in the same order:

  • Oversized images: a 2 MB PNG cover visual instead of an 80 KB WebP
  • Slow server: a TTFB (server response time) above 600 ms drags everything else down
  • Render-blocking resources: CSS and JavaScript files loaded before the content itself
  • No caching: every visit regenerates the page instead of serving a static version

A good LCP therefore starts with serious hosting and optimized images. The rest comes down to fine-tuning.

Close-up of an ethernet cable and router symbolizing the connection

INP: responsiveness, the official replacement for FID since March 2024

INP (Interaction to Next Paint) measures the delay between a user interaction, such as a click or a keystroke, and the visual update of the page. Google rates an INP as good under 200 milliseconds and poor above 500 ms. This metric officially replaced FID (First Input Delay) on March 12, 2024.

That replacement deserves a clarification, because a number of guides still ranking well on Google talk about FID as if nothing had changed. FID only measured the delay of the very first interaction, which made it easy to pass. INP observes every interaction of the session and keeps one of the worst. It is therefore much more demanding, and sites that passed FID effortlessly now fail on INP.

The usual culprits behind a degraded INP:

  • Excessive JavaScript: bloated page builders, multipurpose themes, dozens of active plugins
  • Third-party scripts: chat, ad tracking or A/B testing running on the browser's main thread
  • Long tasks: any JavaScript processing longer than 50 ms blocks the response to clicks

That is why our internal target is set at 100 ms, twice as good as Google's threshold. On WordPress, this means ruthlessly sorting through plugins and deferring every script that is not essential to the first render.

CLS: the visual stability of your page

CLS (Cumulative Layout Shift) quantifies unexpected movements of elements during loading. You know the scene: you go to tap a button, a banner slides in above it, and your finger lands on an ad. CLS measures exactly that frustration, as a unitless score. Below 0.1, the page is stable, but above 0.25 it is rated poor.

Of the three Core Web Vitals, CLS is often the simplest to fix, but also the most neglected. Four causes account for nearly all the problems:

  • Images without dimensions: without width and height attributes, the browser does not reserve the necessary space
  • Web fonts: the late swap from the system font shifts all the text on the page
  • Injected content: cookie banners, promo bars or ads added after the first render
  • Iframes and embeds: YouTube videos or maps inserted without a sized container

The golden rule fits in one sentence: reserve the space for every element before it loads. On the sites we audit, fixing image dimensions and font loading is usually enough to bring CLS well below the threshold.

Mobile and desktop comparison side by side on a desk

Which thresholds should you aim for in 2026?

Google classifies each metric into three zones: good, needs improvement, poor. These thresholds apply to the 75th percentile of real visits, which means 3 out of 4 visitors must get an experience at least as good as the threshold. The table below summarizes the official values in effect in 2026, along with the targets we apply on our own projects.

Metric Good Needs improvement Poor NEXUS SYNERGY target
LCP (loading speed) 2.5s or less 2.5 to 4s More than 4s Under 1.5s
INP (responsiveness) 200 ms or less 200 to 500 ms More than 500 ms Under 100 ms
CLS (visual stability) 0.1 or less 0.1 to 0.25 More than 0.25 0.1 or less

Three details change how you should read this table:

  • Mobile first: Google evaluates mobile and desktop separately, and mobile is almost always the weak link
  • 75th percentile: a flattering average is not enough, the slowest visits are what tips the verdict
  • 28 days of data: any fix takes about a month to show up in the CrUX report

Why aim stricter than Google? Because the "good" threshold is a hygiene minimum, not a performance goal. Between an LCP of 2.4 seconds and an LCP of 0.9 seconds, both pages pass in the green, but the second one converts better and keeps headroom on an average mobile connection. That headroom also protects your results during traffic spikes or algorithm updates.

How do you measure your site's Core Web Vitals?

Four free tools are enough to diagnose your Core Web Vitals, and all of them come from Google. The distinction to remember is between field data, coming from your real visitors over 28 days, and lab data, produced by a simulation under controlled conditions.

  • PageSpeed Insights: the reference tool, it combines CrUX field data and a Lighthouse lab audit for each tested URL
  • Search Console: its Core Web Vitals report groups your pages by status (good, needs improvement, poor) and tracks how they evolve over time
  • Lighthouse: built into Chrome DevTools, ideal for testing a page locally before it goes live
  • Web Vitals extension: it displays LCP, INP and CLS in real time while you browse

Watch out for a classic trap: Lighthouse does not measure INP, because a simulation cannot reproduce real human interactions. A Lighthouse score of 100 therefore does not guarantee passing Core Web Vitals in the field. As the official Web Vitals documentation from Google makes clear, only real user data counts for ranking. So start with Search Console for the big picture, then dig in URL by URL with PageSpeed Insights.

How do you optimize each metric in practice?

Optimizing Core Web Vitals follows a logical order: the server first, images second, JavaScript last. Reversing that order amounts to polishing the details of a page whose foundations are slow.

For LCP, work on server response time with fast hosting, full-page caching and a CDN, then convert your images to WebP or AVIF and preload the main visual. For INP, cut down JavaScript, defer third-party scripts and break up long tasks. For CLS, declare the dimensions of every media element and control how your fonts load.

  • LCP: server cache, CDN, WebP images, preloading the main visual with fetchpriority
  • INP: fewer plugins, deferred third-party scripts, JavaScript processing split into small tasks
  • CLS: declared image dimensions, reserved space for banners, fonts with an adjusted fallback

On WordPress, which powers 43.5% of websites according to W3Techs (2026), the room for improvement is often huge: a custom theme without a page builder beats any bloated setup, whatever caching plugin is installed. That is the approach behind our web performance service: start from the code rather than stacking patches. And when the site's structure is aging, a clean rebuild sometimes costs less than months of successive micro-optimizations.

What real impact do Core Web Vitals have on your SEO?

Let's be honest: Core Web Vitals are a moderate ranking factor. Google has said it repeatedly, excellent content on a slow page will beat weak content on a fast page. The metrics mostly act as a tiebreaker between two pages of comparable quality, and that tiebreaker weighs more on competitive queries.

The business impact, however, is anything but moderate. According to Google, the probability of a bounce increases by 32% when loading goes from 1 to 3 seconds. Deloitte's Milliseconds Make Millions study (2020) showed that a 0.1 second gain increases e-commerce conversions by 8.4%. We saw it on NovaTech: after going from 6.2 to 0.9 seconds, conversions grew by 127% in 3 months.

Three effects add up:

  • Ranking: an edge on contested queries, and easier crawling for Googlebot
  • Behavior: less bouncing, more pages viewed, user signals that strengthen your visibility
  • Conversion: every tenth of a second gained shows up in submitted forms and sales

Performance does not replace a solid SEO strategy, it multiplies it. The gains we see across our portfolio always come from combining the two, never from speed alone.

Technical team celebrating improved metrics

Frequently asked questions about Core Web Vitals

What does Core Web Vitals mean in plain terms?

Core Web Vitals is the official name Google gives to the three metrics that evaluate the user experience of a page: LCP for how fast the main content appears, INP for responsiveness to interactions and CLS for visual stability. You will find the term as is in Search Console and in PageSpeed Insights. Keep in mind above all that behind this technical vocabulary sits a very concrete question: is your site fast, responsive and stable for a real visitor on mobile?

Are Core Web Vitals a Google ranking factor?

Yes, Core Web Vitals have been part of Google's ranking signals since the Page Experience update of June 2021. Their weight remains moderate, though, because content relevance always comes first. Google uses them more as a tiebreaker between pages of equivalent quality, which makes them decisive on competitive queries. Their indirect influence actually exceeds their direct one: a fast page reduces bounce rate and improves the user signals sent to the search engine. Across the 150+ sites we have delivered, the correlation between technical performance and organic traffic growth holds up remarkably consistently.

What is the difference between FID and INP?

INP officially replaced FID on March 12, 2024 as the responsiveness metric of the Core Web Vitals. FID (First Input Delay) only measured the processing delay of the first interaction, which made it easy to pass for the vast majority of sites. INP (Interaction to Next Paint) evaluates every interaction of the visit and keeps one of the slowest, with a threshold of 200 milliseconds. It therefore reflects the real responsiveness of a page much better, especially on mobile. If you read a guide that still talks about FID in the present tense, be wary: its content predates 2024.

How can I check my site's Core Web Vitals for free?

PageSpeed Insights is the most direct tool: enter your URL and you get the field data from the last 28 days, plus a lab audit, free and with no sign-up. For an overall view, the Core Web Vitals report in Search Console classifies all your pages as good, needs improvement or poor. Round it out with the Chrome Web Vitals extension, which displays the values live while you browse your own site. If your site gets little traffic, field data may be missing: rely on Lighthouse in that case, keeping in mind that INP is not included.

Why is my Lighthouse score good while Search Console flags slow pages?

Because the two tools do not measure the same thing. Lighthouse runs a lab test on a given machine, at a given moment, with no human interaction. Search Console relies on CrUX data, collected from your real visitors over 28 days, including those browsing on 4G with a modest phone. A site can therefore score 95 on Lighthouse and fail in the field, particularly on INP, which Lighthouse cannot measure. For ranking, only field data counts. Treat the Lighthouse score as a development indicator, not as proof of compliance.

How long does it take to improve poor Core Web Vitals?

Expect anywhere from a few days to three months depending on how deep the problem runs. Simple fixes, for example compressing images or enabling a cache, produce immediate effects in the lab. The CrUX report, however, aggregates 28 days of data: Search Console therefore reflects your progress with roughly a month of lag. For a structurally slow site, with an overloaded theme or undersized hosting, a technical rebuild is often more effective than micro-optimizations. On the NovaTech project, the full rebuild took loading from 6.2 to 0.9 seconds and the Lighthouse score from 34 to 98.

Your Core Web Vitals tell the story of what your visitors actually experience, and every tenth of a second gained works for your rankings as much as for your conversions. To find out where your site stands, request your free performance and SEO audit: we analyze your three metrics and get back to you within 24 business hours with a concrete action plan.