Core Web Vitals in 2026: The Complete Website Speed Optimization Guide

Core Web Vitals are Google’s three measures of real-world page experience: how fast the main content loads, how quickly the page responds to input, and how stable the layout is while it loads. Google Search Central recommends that site owners “achieve good Core Web Vitals for success with Search and to ensure a great user experience generally,” and says this, along with other page experience aspects, “aligns with what our core ranking systems seek to reward.”

This guide explains the three metrics and their current thresholds, and how to improve each one. The thresholds and techniques come from Google’s documentation on web.dev and Search Central, checked on November 1, 2026.

What Are Core Web Vitals

According to web.dev, a page offers a good experience when it meets all three of these targets at the 75th percentile of page loads, measured separately for mobile and desktop:

Metric	What it measures	Good	Poor
Largest Contentful Paint (LCP)	Loading: when the largest visible element renders	2.5 seconds or less	More than 4 seconds
Interaction to Next Paint (INP)	Responsiveness to clicks, taps and key presses	200 milliseconds or less	More than 500 milliseconds
Cumulative Layout Shift (CLS)	Visual stability: unexpected movement of content	0.1 or less	More than 0.25

LCP is usually a hero image, a large heading or a block of text. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. web.dev explains that the final INP value is “the longest interaction observed, ignoring outliers”; for pages with many interactions, one of the slowest is ignored for every 50. CLS captures shifts such as text jumping down when an image, ad or banner loads above it.

These are the thresholds Google’s documentation lists as of November 2026. Claims circulating online that Google tightened the LCP target to 2.0 seconds aren’t supported by Google’s own pages, which still use 2.5 seconds.

How to Measure Your Site

Start with real-user (field) data, then use lab tools to diagnose problems:

Google PageSpeed Insights (pagespeed.web.dev) shows field data from real Chrome users, where enough traffic exists, alongside a Lighthouse lab test.
Google Search Console’s Core Web Vitals report groups your URLs as Good, Need improvement or Poor for LCP, INP and CLS, based on real-world usage data. It’s the best way to see which templates or page groups have problems.
Chrome DevTools (the Performance panel and Lighthouse) lets you record a page load or interaction and see what is slow. Run tests in an incognito window to keep browser extensions from skewing results.
WebPageTest (webpagetest.org) produces detailed waterfall charts showing when each resource loads.

Lab tests run on a single simulated device and connection, so treat them as diagnostic tools. Your field data is what Google’s thresholds refer to.

How to Optimize LCP

web.dev recommends breaking LCP into four parts: Time to First Byte, resource load delay, resource load duration and element render delay. Then fix whichever part is largest.

Speed up the server response. Time to First Byte (TTFB) is the first part of every page load. web.dev’s rough guide is that a good TTFB is 0.8 seconds or less, and it warns that a high TTFB can make a 2.5-second LCP “challenging, or even impossible.” Caching, a content delivery network and better hosting all help; our best web hosting comparison covers three popular hosts.

Make the LCP image discoverable early. The browser should find your hero image in the initial HTML, through a normal <img> tag with src or srcset. Don’t lazy-load the LCP image with JavaScript that hides its src. If the image is referenced only from CSS or JavaScript, web.dev suggests preloading it with high priority: <link rel="preload" fetchpriority="high" as="image" href="/hero.webp">.

Shrink the image. Serve appropriately sized images with srcset and use modern formats. web.dev says WebP images are usually 25 to 35% smaller than equivalent JPEG and PNG files, and that AVIF has shown savings of more than 50% compared with JPEG, depending on the content.

Reduce render-blocking resources. CSS and synchronous JavaScript in the document head delay rendering. Keep critical CSS small, defer non-critical JavaScript with defer or async, and remove scripts the page doesn’t need.

How to Optimize INP

Poor INP almost always comes from JavaScript keeping the browser’s main thread busy when a user interacts.

Break up long tasks. web.dev defines a long task as any task on the main thread that takes longer than 50 milliseconds. Split long-running work into smaller pieces and “yield to the main thread” between them so the browser can respond to input. web.dev recommends the dedicated scheduler.yield() API where available, and notes that older setTimeout()-based approaches have drawbacks.

Ship less JavaScript. Use the Coverage tool in Chrome DevTools to find code that a page loads but never runs. Remove unused plugins, widgets and tag-manager tags, and load the rest only on pages that need them.

Keep event handlers light. Do the minimum work needed to update the screen in response to a click or keystroke, and defer anything else, such as analytics calls or non-urgent updates, until after the next paint.

Watch third-party scripts. Chat widgets, ad scripts, social embeds and analytics suites all compete for the main thread. Audit them regularly and remove any you don’t need.

How to Optimize CLS

CLS is often the easiest metric to fix, because the causes are well understood.

Give media explicit dimensions. web.dev advises always including width and height attributes on images and video elements, or reserving the space with CSS aspect-ratio, so the browser can allocate the correct space before the file arrives.

Reserve space for ads, embeds and iframes. web.dev lists dynamically injected content without dimensions, such as ads, embeds and iframes, as a common cause of shifts. Set a minimum height on ad slots and embed containers.

Don’t insert content above existing content. Cookie notices, promotional bars and late-loading banners should overlay the page or use reserved space instead of pushing content down.

Handle web fonts carefully. web.dev notes that both font-loading behaviors, swapping in the web font after a fallback (font-display: swap) or hiding text until it arrives, can cause layout shifts. To reduce them, use font-display: optional (the web font is used only if it’s ready at first layout), deliver important fonts early (for example with preload), and match the fallback font’s size using size-adjust and related descriptors.

A Practical Order of Work

If you’re not sure where to start:

Check Search Console to see which page groups fail and on which metric.
Fix server response first if TTFB is poor, because it delays everything else.
Fix the LCP image (discoverability, priority, size and format).
Reserve space for images, ads and embeds to cut CLS.
Trim JavaScript, especially third-party scripts, to improve INP.
Re-measure. Field data in PageSpeed Insights and Search Console updates over the following weeks.

Optimizing Core Web Vitals isn’t a one-time task. Each new page template, plugin, ad placement or embed can change your scores, so check them after every significant change. If you run WordPress, our How to Set Up WordPress guide covers caching plugins, and our SEO for Beginners Guide shows where speed fits among other ranking factors.

Sources

Google Search Central — Understanding Core Web Vitals and Google search results — accessed November 1, 2026
web.dev — Web Vitals — accessed November 1, 2026
web.dev — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) — accessed November 1, 2026
web.dev — Optimize LCP — accessed November 1, 2026
web.dev — Optimize long tasks — accessed November 1, 2026
web.dev — Optimize CLS and Best practices for fonts — accessed November 1, 2026
web.dev — Time to First Byte (TTFB) — accessed November 1, 2026
web.dev — Use WebP images and Use AVIF to compress images — accessed November 1, 2026
Google Search Console Help — Core Web Vitals report — accessed November 1, 2026