Core Web Vitals are three real-user metrics Google uses to measure a page's speed and visual stability: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). To pass, keep LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1.
You have probably seen the phrase "Core Web Vitals" in a PageSpeed Insights report or a Search Console email and wondered whether it actually affects you. It does. Core Web Vitals are Google's attempt to put numbers on something visitors feel every day: does the page load quickly, does it react when I tap, and does it hold still while I read? When any of those go wrong, people leave.
There are two reasons to care. First, users: a page that loads fast, responds instantly, and does not jump around keeps people on your site and makes them more likely to buy, sign up, or read on. Second, search: Core Web Vitals are part of Google's page experience signals, the group of ranking factors that reward pages which are pleasant to use. They are not the biggest ranking factor — relevance and content quality still lead — but when two pages are close, the faster, steadier one has the edge.
This guide is for site owners and WordPress users who want plain-English definitions, the exact thresholds that count as passing, and a practical list of fixes for each metric. It sits under our wider guide to website speed optimization, which covers the full picture of making a site fast. Don't worry if the metrics look intimidating at first — each one maps to a small set of fixable causes.
Core Web Vitals measure three different parts of the experience. Each has its own threshold — a cut-off value — that sorts your page into good, needs improvement, or poor. Google judges each metric at the 75th percentile, meaning 75% of your real visits must hit the "good" bar for the page to pass. The thresholds below are current as of 2026.
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on the screen to render — usually your hero image, a banner, or the main heading. In plain terms, it is the moment the page looks loaded to the visitor. A slow LCP feels like staring at a half-blank screen.
LCP thresholds (as of 2026): good is 2.5 seconds or less, needs improvement is between 2.5 and 4 seconds, and poor is over 4 seconds. LCP is heavily influenced by two things: your server response time (how quickly the server sends the first byte, known as TTFB) and the size and loading of the hero image. Fix those two and LCP usually falls into line.
Interaction to Next Paint (INP) measures how quickly the page visually responds when someone interacts with it — a click, a tap, or a key press. It looks at the delay between the action and the next time the screen updates, across the whole visit, and reports close to the worst interaction. A high INP is the lag you feel when you tap a menu and nothing happens for a beat.
INP thresholds (as of 2026): good is 200 milliseconds or less, needs improvement is between 200 and 500 milliseconds, and poor is over 500 milliseconds. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. The old FID metric only measured the delay on the very first interaction; INP measures responsiveness for the entire session, which is a far tougher and more honest test. INP is driven mainly by JavaScript — the code that runs in the browser — because heavy scripts keep the browser too busy to respond.
Cumulative Layout Shift (CLS) measures how much the page unexpectedly shifts around while it loads. It is a score, not a time. You have felt bad CLS when you go to tap a button, an image loads above it, and the whole layout jumps so you tap the wrong thing. CLS adds up every one of those unexpected moves.
CLS thresholds (as of 2026): good is 0.1 or less, needs improvement is between 0.1 and 0.25, and poor is over 0.25. The score has no unit — it is a ratio of how far things moved relative to the screen. CLS is almost always caused by images, ads, or embeds that load without reserved space, or by late-loading fonts that reflow the text once they arrive.
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | Loading | ≤ 2.5s | 2.5–4s | > 4s |
| INP | Responsiveness | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Visual stability | ≤ 0.1 | 0.1–0.25 | > 0.25 |
To pass Core Web Vitals overall, all three metrics must reach the "good" band for most of your real visitors. A single metric in the poor range means the page fails, so it pays to know which one is dragging you down before you start fixing.
Before you fix anything, measure. There are three tools worth knowing, and the difference between them matters more than most people realise.
Google PageSpeed Insights is the quickest place to start. Enter any URL at pagespeed.web.dev and it shows two sets of numbers: field data (what real visitors experienced over the last 28 days) at the top, and lab data (a single simulated test) below. This one page tells you both whether you are passing and where the bottleneck is.
The Core Web Vitals report in Google Search Console shows how your whole site is doing, grouped into "good," "needs improvement," and "poor" URLs for mobile and desktop. This is the report Google itself watches, and it is the best way to see the scale of a problem across many pages rather than one at a time.
The CrUX dataset — short for the Chrome User Experience Report — is the raw source of the field data both tools above rely on. It collects anonymous, real-world measurements from actual Chrome users who visit your site. If your page does not have enough traffic, CrUX may not have data for it yet, which is why brand-new pages often show "no field data available."
LCP is a race to paint the largest element. Almost every slow LCP comes down to a slow server, a heavy hero image, or code that blocks rendering. Work through these in order.
200ms. Faster hosting, less bloated code, and a lighter database all help — our guide to reducing server response time walks through the causes and fixes in detail.<link rel="preload"> and the attribute fetchpriority="high". Never lazy-load the hero image — that delays the very thing LCP measures.<head> can freeze rendering until they finish. Defer non-critical scripts with defer or async, inline the small amount of "critical" CSS needed for the top of the page, and load the rest afterwards so the hero can paint sooner.INP is almost entirely a JavaScript problem. When the browser's main thread is busy running scripts, it cannot respond to a tap or click, so the fix is to give it less work and to break the work into smaller pieces.
50ms without pausing, and it blocks the browser from responding the whole time. Split heavy work into smaller chunks and yield back to the browser between them so it can react to the user in the gaps.defer or async, and delay non-essential ones until after the user first interacts with the page.CLS is caused by things that arrive late and push existing content out of the way. The fix is to reserve the right amount of space up front so nothing has to move when the late content lands.
width and height attributes (or a CSS aspect-ratio) on every image and video. This tells the browser how much room to reserve, so text does not jump when the image finally loads. This one change fixes most CLS problems on its own.font-display: optional or swap and preload key fonts so the switch causes little or no movement. Matching the fallback font's size to the web font also reduces the shift.Chasing a perfect lab score while field data still fails. It is easy to obsess over the Lighthouse number because it changes instantly when you tweak something. But that number is a simulation on one device. If your Search Console report still shows "poor" URLs, the lab score is lying to you — fix for real visitors, not for the test.
Ignoring INP now that it replaced FID. Many sites passed the old First Input Delay easily and assumed responsiveness was solved. INP is much stricter because it measures every interaction, not just the first. If you have not looked at your INP since March 2024, check it now — plenty of previously passing sites quietly slipped into "needs improvement."
Not setting image dimensions. Leaving width and height off images is the most common cause of a failing CLS, and it is one of the easiest to fix. Add the attributes to every image and video and a large share of layout shift disappears in one edit.
Check Search Console monthly. Core Web Vitals are measured on a rolling 28-day window of real traffic, so scores drift as your site and your visitors change. A quick monthly look at the Core Web Vitals report catches a regression before it spreads across many pages.
Test new plugins and scripts before they go live. A single new plugin, ad tag, or tracking script can wreck INP or add layout shift. Measure a page in PageSpeed Insights before and after you add anything heavy, and drop it if the cost is not worth it. On WordPress, our guide to speeding up WordPress covers the plugins and settings that matter most.
Keep your platform lean. Fewer plugins, an efficient theme, current PHP, and enough server resources all keep every metric healthy at once. Bloat is the enemy of all three vitals, so treat every addition as a cost, not a freebie.
Set a budget and stick to it. Decide on target numbers — say LCP under 2.5s and INP under 200ms — and treat any change that breaks them as a bug to fix, not a number to explain away. Prevention is far cheaper than a rescue mission after rankings dip.
Core Web Vitals are three scores Google uses to measure how good a page feels to real users: how fast it loads (LCP), how quickly it responds when you tap or click (INP), and how much it jumps around while loading (CLS). Pass all three and your page is fast, responsive, and stable.
As of 2026, a good score is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. To pass overall, at least 75% of your real visits must hit the "good" band for every metric. A single metric in the "poor" range means the page fails.
Yes, but a modest one. Core Web Vitals are part of Google's page experience signals, so they can help a page rank when other factors are close. They will not rescue thin or irrelevant content — relevance and quality still matter most — but for two similar pages, the faster, steadier one has an advantage.
Field data comes from real visitors on real devices, collected in the CrUX dataset, and it is what Google uses for ranking. Lab data comes from a single simulated test in a tool like Lighthouse and is used for debugging. When they disagree, trust field data for whether you pass and use lab data to find out why.
Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay on the first interaction, while INP measures responsiveness across the whole visit. That makes INP a stricter, more realistic test, so some sites that passed FID need to improve their JavaScript to pass INP.
Field data comes from real Chrome users, so a page needs enough traffic before the CrUX dataset can report on it. New or low-traffic pages often show "no field data available." Until then, rely on lab data from PageSpeed Insights for guidance, and check back once the page has been getting visitors for a few weeks.
Fix whichever one is in the "poor" band, because a single failing metric fails the whole page. If more than one is poor, LCP is usually the best starting point since improving your server response time and hero image often helps the overall experience the most. Use PageSpeed Insights to see which metric is worst for real users.
Core Web Vitals boil down to three questions: does the page load fast (LCP ≤ 2.5s), respond fast (INP ≤ 200ms), and stay still (CLS ≤ 0.1)? Measure with PageSpeed Insights and Search Console, trust the field data for whether you pass, and fix the worst metric first — a faster server and hero image for LCP, lighter JavaScript for INP, and reserved space for images and fonts for CLS. Remember that INP replaced FID in March 2024, so responsiveness now counts across the whole visit. For the full picture of a fast site, continue with our main guide to website speed optimization, and if you run WordPress, our guide to speeding up WordPress turns these fixes into concrete plugin and setting changes.
The editorial team behind the Bitrich777 Hosting Help Center — practical, tested guides on web hosting, WordPress, servers, DNS, SSL, email, security and migration. Every walkthrough is reproduced on a live host before it is published.
View all guides by the Hosting Team Spotted an error? Tell us
