Core Web Vitals in 2026: the real thresholds, and why teams target 2.0s

If you have read that Google tightened the "good" Largest Contentful Paint threshold to 2.0 seconds this year, you have read something Google has not said. Its own documentation still puts the line at 2.5 seconds. Time to First Byte has not become a Core Web Vital either, and the three metrics that are Core Web Vitals are the same three as in 2024.

That does not make 2.0 seconds a bad number to aim for. It makes it a margin you choose, not a threshold you are graded against, and the difference changes how you plan the work. This article sets out what the thresholds actually are in 2026, why production teams deliberately aim inside them, and the checklist we use to get a site there and keep it there.

Key takeaways

• The thresholds have not moved. Google rates a page "good" at LCP of 2.5s or less, INP under 200ms and CLS under 0.1, each measured at the 75th percentile of real page loads.
• TTFB is a supporting metric, not a Core Web Vital. It still matters because it is the first slice of every LCP, and on mobile fewer than half of sites get it right.
• 2.0s and 150ms are margins. Field data is a distribution, and aiming inside the line is how you stay on the right side of it after the next release.
• LCP is where most sites fail. On mobile it is the weakest of the three metrics by a clear distance, and a common cause is a one-line mistake.
• Passing once is not the goal. A performance budget per template, enforced at release, is what keeps a pass in place.

What Google actually measures in 2026

Google Search Central lists three Core Web Vitals, and the page was last updated in December 2025:

INP is the newest of the three. It replaced First Input Delay on 12 March 2024, and FID was removed from the programme entirely. If a checklist you are working from still mentions FID, it predates that change.

The part most summaries skip is how a page is graded. Google does not take an average. As web.dev explains, a page passes a metric when at least 75% of real page views meet the "good" threshold, and mobile and desktop are assessed separately. The 75th percentile was chosen because it reflects what most visitors experience while staying resistant to a handful of outliers.

That single detail explains most of what follows. You are not trying to make one test run hit 2.5 seconds. You are trying to make three out of four real visits hit it, on the devices and networks your visitors actually use.

Where TTFB fits, and why it is not on the list

Time to First Byte measures how long the browser waits between requesting a page and receiving the first byte of the HTML. Google's guidance on it is direct: "Because TTFB isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the 'good' TTFB threshold." The suggested target is 0.8 seconds or less, not the 600ms some 2026 roundups quote.

So why include it in a Core Web Vitals checklist at all? Because TTFB is the first sub-part of LCP. Every millisecond spent waiting on the server is a millisecond the largest element cannot start loading. A site with a 1.5-second TTFB has already spent more than half of its LCP budget before the browser has parsed a single tag.

Treat TTFB as a diagnostic. When LCP fails and TTFB is high, the fix is on the server or at the edge, and no amount of image work will close the gap.

Why production teams aim for 2.0s and 150ms

If Google's line is 2.5 seconds, aiming for 2.0 can look like perfectionism. It is really an acknowledgement that the number you are graded on is a moving distribution.

Your 75th percentile shifts with traffic mix. A campaign that brings in visitors on older Android devices, a partner link that sends traffic from a region further from your origin, or a seasonal spike that puts load on the database will all move it. A site sitting at 2.4 seconds passes today and fails the week a new hero video ships. A site at 2.0 seconds has room to absorb that week.

The same reasoning applies to INP. A 150ms working target leaves room for the next analytics tag, the next A/B test script and the next chat widget, each of which adds work to the main thread.

The honest way to describe these numbers is as an internal budget. Write them into the performance budget for each template, say plainly that they are stricter than Google's, and you will not confuse the team the way an article claiming "the new 2.0s threshold" does.

Where sites actually fail

The HTTP Archive Web Almanac 2025 is the most useful public picture of real-world performance, because it reads field data from the Chrome UX Report across millions of origins. Its headline is encouraging and sobering at the same time.

Break the mobile pass rate down by metric and the bottleneck is obvious. 81% of mobile sites have a good CLS and 77% a good INP, but only 62% have a good LCP. Loading speed is where most sites fall off.

Page type matters too. Home pages pass less often than deeper pages: 45% on mobile against 56% for secondary pages. Home pages tend to carry the heaviest hero media, the most scripts and the most experiments, which is also why they are the right place to start.

LCP: the production checklist

web.dev's guide to optimising LCP splits the metric into four sub-parts, and working through them in order is the fastest way to find what is wrong:

1. TTFB, the wait for the first byte of HTML. Recommended share: roughly 40% of LCP.
2. Resource load delay, the gap between that first byte and the browser starting to fetch the LCP resource. Recommended: under 10%.
3. Resource load duration, the time to download the LCP resource itself. Recommended: roughly 40%.
4. Element render delay, the time between the resource arriving and the element appearing. Recommended: under 10%.

On many failing pages, the time goes into the two stages that should be nearly empty: load delay and render delay. The browser either found out about the image late, or had it and was not allowed to paint it. Those are both fixable without touching a single image file.

Make the LCP resource discoverable in the HTML. If the hero image is injected by JavaScript or set as a CSS background, the browser's preload scanner cannot see it until scripts or stylesheets run. Server-render it as an img element.

Never lazy-load the LCP image. Google puts it plainly: lazy-loading the LCP image "will always lead to unnecessary resource load delay". Even so, about one in six mobile pages still does it.

Give it priority. Add fetchpriority="high" to the likely LCP image. Browsers do not treat images as high priority by default, even when they are the most important thing on the page.

Roughly as many mobile pages actively delay their LCP image as prioritise it. For a site trying to pass, that is the cheapest win available.

Keep critical resources on your own origin. A hero image on a third-party CDN domain needs its own DNS lookup, TCP connection and TLS handshake before a byte arrives. Serving it from the same origin reuses the connection that fetched the HTML.

Cut render-blocking CSS. Inline the CSS needed for the first screen, and keep the rest from blocking the first paint.

Then, and only then, shrink the bytes. Serve responsive sizes, so a phone never downloads a desktop image, and use modern formats. The Almanac found that JPEG is still the format of 57% of LCP images on desktop, with WebP at just 11%. There is room here, but it is the third fix, not the first.

INP: the production checklist

INP is measured over the whole visit, not just the load. It takes the slow interactions users actually had, so a page that loads quickly can still fail if its filters, menus or forms respond sluggishly. web.dev splits each interaction into three phases: input delay before your handler starts, processing time while it runs, and presentation delay until the next frame paints.

Break up long tasks. Any task over 50ms is a long task, and while one runs the browser cannot respond to input. Split heavy work into smaller pieces and yield to the main thread between them. scheduler.yield() is built for this in Chromium-based browsers and Firefox. Safari does not support it yet, so fall back to setTimeout.

Do the visible update first. When a user clicks, update the part of the interface they are looking at, then defer everything else, such as analytics, storage writes and prefetching, to a later task.

Keep the DOM small. Every style recalculation and layout pass scales with the number of elements. Long pages can use content-visibility to skip rendering what is off screen.

Avoid layout thrashing. Reading a layout property such as offsetHeight straight after changing styles forces the browser to recalculate layout mid-task. Batch the reads, then the writes.

Audit the interactions that pay the bills. Test the form submit, the pricing toggle and the booking calendar on a mid-range phone, not a generic click on a developer laptop.

CLS: the production checklist

CLS is the metric most sites pass, but it regresses easily, usually when a new component arrives. web.dev's CLS guidance comes down to reserving space for everything before it arrives.

Set dimensions on every image and video. width and height attributes let the browser reserve the right box from the aspect ratio, and CSS can still make the image responsive.

Reserve space for ads, embeds and late content. Use min-height or aspect-ratio on the container, sized to the tallest state it can take.

Load fonts without reflow. Preload the critical font file, choose a fallback with similar metrics, and consider font-display: optional for body text.

Animate transforms, not layout. Moving an element with transform does not shift its neighbours. Animating top, left or height does.

Stay eligible for the back/forward cache. A page restored from bfcache appears fully loaded, with no load-time shifts at all.

On our own builds, we treat animated dashboard widgets as a CLS risk by default. Every one gets a locked outer height and hidden overflow, so content cycling inside it can never push the rest of the page around.

TTFB: the server-side checklist

Cache at the edge. Pages that are the same for every visitor, such as marketing pages, articles and documentation, should be served from a CDN cache, not rendered per request.

Pre-render what does not change. Static generation or incremental regeneration turns a database round trip into a file read.

Take work out of the request path. Personalisation, third-party calls and non-essential queries can load after the HTML, not before it.

Measure edge and origin separately. A slow TTFB can come from a cache miss, a slow origin or a distant user. You need to know which before choosing a fix.

Keeping a pass once you have it

Most sites do not fail Core Web Vitals because nobody tried. They fail because someone fixed it, and then six months of well-intentioned additions undid the work. A pass survives when it is governed like any other production requirement.

• A budget per template. Home, article, product and landing templates each get LCP, INP and CLS targets, written down, using the 2.0s and 150ms margins.
• A gate on new scripts. Any new third-party tag, widget or experiment that touches the first screen or a key interaction needs its cost measured before it ships.
• Lab checks in CI, field data in review. Lighthouse in the build pipeline catches regressions before release. Chrome UX Report data and Search Console confirm what real visitors experienced. Both matter, because a lab test runs one device on one network.
• A monthly look at the 75th percentile, by template and by device, not a single sitewide score.

It is also worth keeping the ranking effect in proportion. Google says that it "always seeks to show the most relevant content, even if the page experience is sub-par", and that good Core Web Vitals scores do not guarantee top rankings. The stronger commercial case is the one your visitors make. A page that paints quickly and responds instantly loses fewer of them before they reach the form.

That is how we scope web design and development: performance targets go into the build specification rather than a post-launch audit, because retrofitting speed onto a finished template costs more than designing for it. If organic search is the channel you are protecting, performance sits inside a wider SEO programme, and our guide to modern web design covers the build decisions that make these budgets achievable. For the crawler side of technical SEO, see how to handle AI scrapers in robots.txt and sitemaps.