Resources
Core Web Vitals in 2026
Core Web Vitals are three metrics — LCP, INP and CLS — assessed against real user data at the 75th percentile. INP replaced FID in March 2024. Their ranking effect is modest; their effect on conversion is not.
What are the three Core Web Vitals and what are the thresholds?
Core Web Vitals are LCP, INP and CLS, each assessed at the 75th percentile of real user measurements over a rolling 28-day window. A site passes if all three are in the 'good' band for the majority of real visits.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | How long until the main content renders | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP — Interaction to Next Paint | How responsive the page feels when tapped | ≤ 200ms | 200–500ms | > 500ms |
| CLS — Cumulative Layout Shift | How much content jumps while loading | ≤ 0.1 | 0.1–0.25 | > 0.25 |
The thresholds are deliberately coarse, and being 'needs improvement' rather than 'poor' still costs you. Aim for comfortably inside the good band rather than at its boundary.
What does the 75th percentile actually mean?
It means 75% of real visits to your site were faster than that value, and 25% were slower. It is not an average, which is why averages flatter slow sites — a single very slow visit barely moves an average but sits squarely in the worst quarter of a percentile.
The practical consequence is that you optimize for the slowest quarter of your traffic, not your fastest. A page with a 1.2s average LCP can still have an LCP of 4 seconds for a quarter of visits, and that quarter is what the metric reports. Look at the distribution, not the mean.
Why should I trust field data over lab data?
Lab tools — Lighthouse and PageSpeed Insights' diagnostic mode — run a synthetic test on a server somewhere, on a specific device, with a cold cache, against a first visit. That is useful for diagnosis and close to useless as a measure of what users experience.
Field data comes from actual Chrome users and is what Google uses for the Core Web Vitals report and for ranking. The sources are the Chrome UX Report (CrUX), Search Console, or your own real-user monitoring.
| Source | What it gives you | Caveat |
|---|---|---|
| Search Console → Core Web Vitals | Field data grouped by page, with pass/fail | Only pages with enough data appear; 28-day window |
| Chrome UX Report (CrUX) | Aggregated field data for any origin URL | Requires sufficient sample size before data appears |
| PageSpeed Insights (field) | Field data if it exists, lab diagnosis otherwise | May silently fall back to lab only |
| PageSpeed Insights (lab) | Detailed diagnosis of what is slow and why | Not representative of real users |
| RUM (your own) | Exactly your users, split by device and connection | Costs money and takes implementation |
How do I fix a slow LCP?
LCP measures when the largest visible element finishes rendering — usually a hero image, headline block or video poster. Diagnose by running PageSpeed Insights and reading the LCP element breakdown, which tells you whether the delay is server response, resource load, or render delay.
- Reduce Time to First Byte. If the server takes over 600ms to respond, nothing else you do matters much. Caching, a CDN, and removing render-blocking server work come first.
- Preload the LCP image. If the hero image is discovered late in the HTML, it cannot start downloading early. Add a preload hint for that exact file.
- Stop lazy-loading the LCP image. Lazy-loading the main hero image is a common and costly mistake — it delays the very element the metric measures.
- Right-size the image. Serve modern formats at the dimensions actually displayed. A 2400px hero shown at 800px is wasted bandwidth.
- Remove render-blocking CSS and JS. Critical CSS inline, everything else deferred.
What replaced FID and what causes a poor INP?
INP replaced First Input Delay in March 2024 because FID only measured the latency of the *first* interaction and ignored everything after it. A page could score well on FID while remaining unresponsive for the rest of the session. INP measures the full latency of *every* interaction across the page's life, which is why it correlates far better with how responsive a site actually feels.
INP measures from when the user interacts to when the next frame is painted. The causes, in order of frequency.
| Cause | Why it hurts INP | Typical fix |
|---|---|---|
| Long JavaScript tasks on the main thread | The thread is busy, so the click cannot be processed | Break work into chunks, defer non-essential scripts, move computation to a worker |
| Oversized third-party scripts | Tag managers and chat widgets add blocking work | Audit and remove unused tags; load async; consider a consent-mode server-side approach |
| Hydration cost on a client-rendered app | The main thread rebuilds the page after interaction | Reduce component count, defer hydration for below-the-fold content |
| Expensive event handlers | A handler doing heavy work blocks paint | Move work off the interaction path, debounce |
What causes layout shift?
CLS measures unexpected movement of visible content during load. It is almost always caused by content arriving after the initial paint and pushing things that were already on screen.
- Images and videos without explicit dimensions. The most common cause by a wide margin. Set width and height attributes and the browser reserves space before the file loads.
- Ads, embeds and iframes with no reserved space. Reserve a placeholder with a min-height matching the final size.
- Web fonts swapping after first paint. Use font-display: optional or preload, or match the fallback metrics closely.
- Content injected above existing content. Banners and consent bars pushed in above the fold shift everything below them.
- Skeletons of the wrong size. Placeholder blocks that do not match final content dimensions cause a shift when the real content lands.
How much do Core Web Vitals actually affect rankings?
Less than most SEO content claims, and you should be sceptical of anyone promising otherwise. Core Web Vitals are a relatively small ranking signal compared with relevance and authority, and Google has not suggested they carry large weight.
The stronger case is conversion, not ranking. A page that shifts under the visitor or takes four seconds to respond loses people before they read a word. The evidence for the conversion effect is considerably stronger than the evidence for the ranking effect, and it is measurable in your own data.
| Argument | Strength of evidence | Note |
|---|---|---|
| CWV improves rankings | Weak | A confirmed signal, but a small one relative to relevance |
| CWV improves conversion | Moderate to strong | Speed and responsiveness affect abandonment measurably |
| CWV is a ranking factor at all | Confirmed | Google has stated this directly |
| Passing CWV guarantees traffic | False | A fast page with no content still gets nothing |
The right way to prioritize them is as a conversion project that also happens to satisfy a ranking signal — not as an SEO tactic. If your traffic already converts well and your rankings are poor for content reasons, CWV work is a low priority regardless of how badly it currently scores.
Frequently asked questions
What are the current Core Web Vitals thresholds?
LCP good at 2.5 seconds or less, INP good at 200 milliseconds or less, CLS good at 0.1 or less. Each is assessed at the 75th percentile over 28 days. Aim comfortably inside the good band rather than at its boundary — 'needs improvement' still costs you.
What is INP and why did it replace FID?
INP stands for Interaction to Next Paint. It replaced First Input Delay in March 2024 because FID only measured the latency of the first interaction and ignored everything afterwards, so a page could score well while remaining janky for the rest of the session. INP measures the full latency of every interaction across the page's life.
Should I trust my Lighthouse score or my Search Console data?
Search Console. Lighthouse runs a synthetic lab test on a cold cache and is a diagnostic tool, not a measurement of your users. Start from the Search Console Core Web Vitals report, use Lighthouse to diagnose causes, then re-check field data after 28 days. Teams that optimize the Lighthouse number often see no change in Search Console.
Do Core Web Vitals affect rankings much?
They are a confirmed but relatively small signal compared with relevance and authority. Be sceptical of anyone claiming otherwise. The stronger and more measurable case is conversion — slow, unresponsive pages lose visitors before they see what you are selling.
My LCP image is lazy-loaded. Is that the problem?
Frequently yes, and it is a common mistake. Lazy-loading the LCP image delays the exact element the metric measures, because the browser cannot discover it until it is in view. Exclude the hero image from lazy-loading and add a preload hint for it, then check the LCP element breakdown in PageSpeed Insights.
How long does it take to see Core Web Vitals improve?
The fix itself is usually live within days, but the field metric updates on a rolling 28-day window and Search Console reports lag slightly behind that. Expect to wait four to six weeks before the Search Console number reflects a change. Re-run a lab test immediately to confirm the underlying fix worked.
Can I pass Core Web Vitals without improving the site?
Only if your traffic is small, because the metrics are percentiles of real sessions. A site with very few visitors may have no data reported at all, which is technically a pass and practically means nothing. The honest answer is that on a site with real traffic, passing requires genuine improvement.
Should I prioritize Core Web Vitals or content?
Content, almost always. Relevance and quality determine whether there is anything worth ranking for; Core Web Vitals determine whether people stay once they arrive. Fix indexability and content first, then performance — unless you already have traffic converting badly, in which case speed is the higher-value work.
Keep reading
Want this applied to your business?
Stop guessing what to prioritize. Get a straight answer on where your marketing is leaking money, and what to fix first.
Book a free 30-minute audit