Core Web Vitals in 2026: A Practical Speed Checklist for Business Websites

A slow website costs you twice: once in search visibility and again in visitors who give up before the page is usable. Core Web Vitals are Google's way of measuring that experience with real-user data, and they are the most practical speed targets a business website can work towards. This checklist covers what the metrics mean in 2026, how to measure them and what to fix first.

In short: To pass Core Web Vitals, at least 75% of real visits need a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less. Measure with field data from Search Console and PageSpeed Insights first. Then fix in this order: the main image and server response, heavy JavaScript and third-party scripts, then layout shifts.

The three metrics and their 2026 thresholds

A few rules shape how these are judged:

• The 75th percentile counts. A page passes when at least three out of four real visits meet the "good" threshold, assessed separately for mobile and desktop.
• INP replaced First Input Delay on March 12, 2024. FID only measured the delay before the first interaction. INP looks at interactions across the whole visit, so many sites that passed FID now fail INP.
• The thresholds have not changed since. Ignore articles claiming new 2026 thresholds; Google's published values are the ones above.

How to measure: field data first, lab data second

Field data comes from real Chrome users through the Chrome User Experience Report (CrUX). Lab data comes from a simulated test. Google's assessment uses field data, so start there.

• Google Search Console. The Core Web Vitals report groups similar URLs and shows which groups fail and why. It is the best overview for a whole site.
• PageSpeed Insights. The top section shows field data for the URL or origin over the past 28 days. The lower section is a Lighthouse lab test with specific diagnostics, including which element is your LCP and how its load time breaks down.
• CrUX Vis. Google's tool for viewing CrUX trends over time, which replaced the old Looker Studio CrUX Dashboard in late 2025.
• Chrome DevTools. The Performance panel shows LCP, INP and CLS live as you click around a page, which is the fastest way to reproduce a problem.
• Your own real-user monitoring. The open-source web-vitals JavaScript library can send metrics to Google Analytics 4 or another analytics tool. This matters for low-traffic sites, which often have too little traffic for CrUX data.

One common trap: a Lighthouse score is not a Core Web Vitals result. A standard Lighthouse page-load test cannot measure INP at all, because nobody interacts with the page; it reports Total Blocking Time as a stand-in. A green Lighthouse score with failing field data means real users on real phones are having a worse time than your test.

Fixing LCP: make the main content arrive fast

LCP is usually a hero image, a banner or a large heading. Find it in PageSpeed Insights, then work through this list:

• Speed up the server response. Aim for a Time to First Byte under about 0.8 seconds. Page caching, a CDN and better hosting fix most slow responses.
• Never lazy-load the LCP image. Lazy loading is great below the fold and harmful for the first image people see.
• Give the LCP image high priority. Add fetchpriority="high", and preload it if it is a CSS background the browser discovers late.
• Serve modern, right-sized images. Use AVIF or WebP, with srcset so phones do not download desktop-sized files.
• Remove render-blocking resources. Defer non-critical JavaScript, and keep the CSS needed for the first screen small.
• Avoid client-rendered hero content. If the main content waits for JavaScript to fetch data, render it on the server instead.
• Rethink sliders. Rotating hero carousels often delay LCP and are rarely worth it.

<img src="/hero-1200.avif" srcset="/hero-800.avif 800w, /hero-1200.avif 1200w"
     sizes="100vw" width="1200" height="600" fetchpriority="high" alt="Product range">

Fixing INP: keep the page responsive

INP problems almost always come from JavaScript keeping the browser's main thread busy when someone taps or types.

• Ship less JavaScript. Remove unused libraries and plugins, split code by page and load features only when they are needed.
• Break up long tasks. Any task over 50 ms blocks interaction. Split heavy work into chunks and yield to the browser between them.
• Update the screen first, do the heavy work second. Show feedback immediately on click, then run analytics calls, filtering or saving afterwards.
• Audit third-party scripts. Chat widgets, A/B testing tools, tag managers, heatmaps and ad scripts are frequent INP offenders. Remove what you do not use, and load the rest after the page settles or on first interaction.
• Use facades for heavy embeds. Show a lightweight preview for YouTube videos, maps and chat, and load the real thing on click.
• Keep the DOM lean. Very large pages make every update slower; paginate long lists or virtualize them.

For developers, yielding looks like this:

for (const item of items) {
  process(item)
  // Let the browser handle clicks and paint between chunks
  if ('scheduler' in window && 'yield' in scheduler) await scheduler.yield()
  else await new Promise((r) => setTimeout(r, 0))
}

Fixing CLS: stop the page from jumping

• Set dimensions on media. Give every image, video and iframe width and height attributes or a CSS aspect-ratio.
• Reserve space for late content. Ads, embeds, review widgets and promo bars need a fixed slot before they load.
• Overlay cookie banners instead of pushing content. A banner that shifts the page down counts against CLS.
• Tame web fonts. Preload key fonts, self-host them and use fallback font metric overrides so text does not reflow when the real font arrives.
• Insert new content below, not above. Only add content above what the visitor is reading in response to their own action.
• Animate with transform. Animating top, left, width or height moves surrounding content.

Hosting, CDN and caching

Many speed problems are infrastructure problems. This part of the checklist helps every metric at once:

• Host close to your audience, or use a CDN such as Cloudflare so Canadian and international visitors get files from a nearby location.
• Enable full-page caching for pages that are the same for everyone.
• Cache static assets for a long time, using file names that change when the file changes.
• Turn on Brotli or Gzip compression and HTTP/2 or HTTP/3.
• Keep your runtime current, such as a supported PHP version for WordPress.
• Make pages eligible for the browser's back/forward cache, for example by avoiding unload event handlers, so returning visits are instant.

Platform notes: WordPress, Shopify and Next.js

WordPress

• Choose a lightweight theme. Page builders such as Elementor add extra markup and CSS, so use their performance settings and avoid stacking add-on packs.
• Use one well-configured caching plugin, such as WP Rocket or LiteSpeed Cache, not several.
• Audit plugins regularly; every plugin can add scripts and database queries to every page.
• Recent WordPress versions add fetchpriority to the likely LCP image and, since WordPress 6.8, prefetch pages through speculative loading. Sliders and builders can still undo the first of these, so check the result.

Shopify

• Start from a lightweight, well-maintained theme, and be selective with sections that autoplay video.
• Apps are the most common slowdown. Uninstall unused apps and remove any code they left in your theme.
• Use Liquid's image_url and image_tag filters to serve responsive images from Shopify's CDN.
• Check the Web Performance report in your Shopify admin, under Analytics, Reports, which shows LCP, INP and CLS from real visitors.

Next.js

• Use next/image for automatic resizing and modern formats. For the LCP image, set fetchPriority="high" or loading="eager"; the old priority prop is deprecated in Next.js 16.
• Use next/font, which self-hosts fonts and adjusts fallback metrics to prevent layout shift.
• Load third-party code with next/script and a lazyOnload or afterInteractive strategy.
• Keep components as Server Components and add "use client" only where interactivity is needed, so less JavaScript reaches the browser. The useReportWebVitals hook sends field metrics to your analytics. Our Next.js vs React guide explains the rendering options.

How speed affects SEO and conversions

Google states that Core Web Vitals are used by its ranking systems, and it is equally clear that good scores do not guarantee top rankings. Relevant, helpful content comes first. Think of Core Web Vitals as a tiebreaker between pages of similar quality, and as a floor you should not fall below.

The commercial case is stronger. In a study commissioned by Google, "Milliseconds Make Millions" (2020), Deloitte Digital analyzed mobile data from 37 brands and found that a 0.1-second improvement in site speed metrics across the whole user journey was associated with an 8.4% increase in conversions for retail sites and 10.1% for travel sites. Your numbers will differ, but the direction is consistent: faster pages lose fewer visitors before they act.

Need a faster website?

We fix Core Web Vitals on WordPress, Shopify and custom sites, then keep them green. Our SEO services include technical audits and Core Web Vitals monitoring, and we also offer monthly website maintenance plans and one-off performance work, each quoted individually. If your site needs a rebuild instead, see our web development service and pricing. Send us your URL and we will tell you what is slowing it down.

Frequently asked questions

What is a good Core Web Vitals score in 2026?

A page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. These are Google's published thresholds and they have not changed since INP replaced FID in March 2024. Mobile and desktop are assessed separately.

Why does PageSpeed Insights show different results from Search Console?

PageSpeed Insights shows field data for a single URL plus a one-off lab test, while Search Console groups many similar URLs together. The lab test also runs on a simulated device and network, so it rarely matches real-user data exactly. Trust the field data for pass or fail, and use the lab test to find causes.

Do Core Web Vitals affect Google rankings?

Yes, but modestly. Google uses them in its ranking systems, yet relevance and content quality matter much more, and good scores alone will not lift a weak page. The larger payoff from a faster site is usually in conversions and lower bounce rates.

How long does it take to see improvements in Search Console?

Field data covers a rolling 28-day window, so a fix takes up to four weeks to show fully. When you click "Validate fix" in Search Console's Core Web Vitals report, Google monitors the affected URLs over a 28-day period before confirming. PageSpeed Insights' lab test reflects changes immediately, which is useful for checking your work in the meantime.