Core Web Vitals in 2026: What Still Matters and What Does Not
Core Web Vitals generate more panic than they deserve and less action than they need. They are a real signal, but a small one, and most of the effort spent on them goes into chasing lab scores rather than fixing the two or three things real users actually feel.
Here is where the metrics stand, how much weight to give them, and the fixes that return the most per hour of development time.
The Three Metrics and Their Thresholds
| Metric | Good | What it measures |
|---|---|---|
| LCP | ≤ 2.5s | When the largest visible element finishes rendering |
| INP | ≤ 200ms | How quickly the page responds visually to interactions |
| CLS | ≤ 0.1 | How much content unexpectedly shifts during load |
All three are assessed on field data at the 75th percentile, so the slowest quarter of your real visits decides the verdict. A fast developer machine on a fast connection tells you almost nothing about that.
What Still Matters
- Field data over lab data. Start every investigation in the Core Web Vitals report in Search Console, grouped by template. Fixing one template usually fixes hundreds of URLs.
- The LCP element. Identify the actual largest element, then preload it, serve it as a modern format at the right dimensions, and never lazy-load it. This is consistently the single highest-return fix.
- Third-party script budget. INP failures are usually caused by tags nobody owns any more. Audit them, remove the dead ones, defer the rest, and load chat widgets on interaction.
- Reserved space. Width and height on every image, fixed containers for embeds and ads, and no banners injected above content already on screen.
- Font loading. Self-host, subset, and use font-display swap. Web fonts routinely delay LCP by hundreds of milliseconds.
- Server rendering. Delivering real HTML rather than an empty shell helps LCP and is a prerequisite for reliable indexing and AI retrieval.
What Does Not Matter Much
- Chasing a 100 Lighthouse score. Beyond passing thresholds in field data, the remaining points are vanity.
- First Input Delay. Retired. If a tool or report still shows it, that report is out of date.
- Time to First Byte in isolation. Worth watching as a contributor to LCP, not as a target on its own.
- Micro-optimising kilobytes while a 900KB hero image and four analytics tags sit untouched.
- Expecting rankings to jump. Performance work protects position; it does not create relevance. Content and structure do that.
A Practical Order of Work
- Pull field data by template and pick the worst-performing template that receives real traffic.
- Fix its LCP element: correct format, correct size, preloaded, not lazy-loaded.
- Cut or defer third-party scripts on that template and re-measure INP.
- Add dimensions and reserve space until CLS is stable.
- Wait for field data to refresh — it uses a rolling window, so nothing changes overnight.
- Move to the next template and repeat.
Performance is the last section of my technical SEO checklist for a reason: it is worth doing well, and worth doing after crawling, indexing, and rendering are already sound.
Frequently Asked Questions
What are the current Core Web Vitals thresholds?
A page is rated good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. These are measured at the 75th percentile of real user visits, so a fast average with a slow tail still fails.
How much do Core Web Vitals affect rankings?
They are a genuine but small factor, and mostly a tie-breaker between pages of comparable relevance. Fixing speed will not make an irrelevant page rank, but a slow page can lose to an equally relevant fast one.
Is First Input Delay still relevant?
No. FID was retired and replaced by Interaction to Next Paint, which measures the full time from an interaction until the next visual update rather than only the initial input delay. INP is a considerably harder metric to pass on script-heavy pages.
Should I trust PageSpeed Insights scores or Search Console?
Search Console for assessment, PageSpeed Insights for diagnosis. Search Console reports field data from real visits, which is what gets evaluated. Lab scores are useful for finding the cause but can differ substantially from what users experience.
What usually causes a failing INP score?
Long JavaScript tasks, most often from third-party tags such as analytics, chat widgets, A/B testing, and ad scripts. Cutting or deferring those scripts almost always helps more than optimising application code.
Do Core Web Vitals matter for AI search visibility?
Indirectly. Retrieval systems care about whether content is present and parseable rather than how fast it paints. Performance still matters because the same fixes that improve loading usually also mean content is server-rendered and available in the initial HTML.
Not sure which template is dragging you down?
Run the free audit for a quick read, or get a full technical pass with a prioritised fix list.