Core Web Vitals in 2026: what actually moves rankings

What Core Web Vitals measure today

Core Web Vitals are three metrics that describe how a page feels to real visitors. Largest Contentful Paint (LCP) measures loading: how long until the main image or text block is visible. Interaction to Next Paint (INP) measures responsiveness: how long the page takes to react visibly after a tap, click or key press. Cumulative Layout Shift (CLS) measures visual stability: how much content jumps around while the page loads.

A page passes when at least 75% of visits are in the “good” range: LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1. Mobile and desktop are assessed separately, and mobile is almost always the harder one.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction; INP looks at the slowest interactions across the whole visit. Many sites that were comfortably green on FID turned amber or red on INP.

How much do they affect rankings?

Core Web Vitals are part of Google’s page experience signals. They do not outrank relevance: a slow page with the best answer will still beat a fast page with a weak one. Where they matter is between pages of similar quality, and in conversion — visitors leave slow, jumpy pages whatever their ranking.

That is why we treat vitals as a business metric first and an SEO metric second. Faster pages sell more, get more enquiries and cost less in paid traffic.

Field data versus lab data

Lighthouse and PageSpeed Insights lab scores run one simulated visit on a throttled device. They are useful for debugging, but Google ranks on field data from the Chrome User Experience Report (CrUX), collected from real Chrome users over 28 days.

Start in Search Console’s Core Web Vitals report to see which groups of URLs fail and on which metric. Then use PageSpeed Insights for the field numbers of a single URL, and Chrome DevTools’ Performance panel to find the cause.

Fixing LCP

Most LCP problems come from four places: a slow server response, a late-discovered hero image, render-blocking CSS and fonts, or an image that is simply too large.

• Get Time to First Byte under about 800 ms: full-page caching for anonymous visitors, a CDN, and fast database queries.
• Never lazy-load the LCP image. Give it fetchpriority="high", and preload it if it is set in CSS.
• Serve AVIF or WebP in the right size with srcset and sizes, instead of one large JPEG.
• Inline the critical CSS and load the rest without blocking; self-host fonts and use font-display: swap.

Fixing INP

INP is almost always a JavaScript problem. When the main thread is busy with a long task — anything over 50 ms — the browser cannot respond to the user’s tap until it finishes.

Audit third-party scripts first: chat widgets, heatmaps, A/B testing tools and multiple tag containers often add hundreds of milliseconds. Load them after interaction or on specific pages only. In your own code, keep event handlers small, debounce input handlers, and split long work into smaller chunks so the browser can paint in between. A very large DOM (several thousand elements) also slows every interaction, which is common with page builders.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

Fixing CLS

• Always set width and height (or aspect-ratio) on images, videos and iframes.
• Reserve space for ads, embeds and cookie banners instead of pushing content down when they load.
• Avoid injecting banners or notices above existing content after the page has rendered.
• Use font fallbacks with matching metrics (size-adjust) so text does not reflow when the web font arrives.

Laravel and WordPress specifics

On Laravel, the quick wins are production caches (php artisan config:cache, route:cache, view:cache), OPcache, Redis for cache and sessions, and eager loading to remove N+1 queries that slow the first byte. Build assets with Vite so CSS and JavaScript are minified and versioned, and move slow work such as emails and API calls to queues.

On WordPress, most problems come from plugins. Remove the ones you do not need, use a proper page cache (LiteSpeed Cache on LiteSpeed servers works very well), optimise images on upload, keep PHP on a supported 8.x version and be careful with heavy page builders.

Measure, then wait

Add the open-source web-vitals library to send real LCP, INP and CLS values to GA4 or your own endpoint, so you see changes within days instead of waiting for CrUX. Search Console’s report uses a rolling 28-day window, so after a fix it takes about four weeks before the status turns green. Validate the fix there once the new data is in.

If you want a quick first view of your own site, our free website checker flags slow responses, missing compression and other common causes.