Core Web Vitals Checklist for 2026 (INP, LCP, CLS)

Why Core Web Vitals still decide close rankings in 2026

Core Web Vitals are not a silver bullet. No amount of performance work will push a thin, unhelpful page above a genuinely better one. But in competitive technical queries almost every result on page one is written by someone who knows the topic — and when the content quality is roughly equal, the tie-breakers decide the order. Speed is the most measurable tie-breaker Google has.

There is a second, less discussed reason to care. Every performance problem is also a conversion problem. A page that takes four seconds to become interactive loses a large share of mobile visitors before they read a single sentence. Those visitors bounce back to the search results, and a consistently high bounce-back rate is a signal you do not want attached to your URL.

Three metrics matter in 2026:

• LCP (Largest Contentful Paint) — how quickly the main content paints. Target: under 2.5 seconds.
• INP (Interaction to Next Paint) — how quickly the page responds to input. Target: under 200 milliseconds.
• CLS (Cumulative Layout Shift) — how much the layout jumps while loading. Target: under 0.1.

All three are scored at the 75th percentile of real users, not on your laptop. That distinction matters more than anything else in this article. Your development machine is a fast device on a fast network with a warm cache. It is not your audience.

1. Fix LCP at the source, not with tricks

LCP measures when the largest visible element finishes rendering. On most blog and marketing pages that is either a hero image or a large block of heading text. The first job is identifying it precisely rather than guessing.

Open Chrome DevTools, run a Performance trace, and look for the LCP marker in the timings track. Chrome tells you exactly which element it chose. Developers routinely optimise the wrong image because they assumed the hero was the LCP element when it was actually a background graphic or a paragraph of text.

Serve the right image, at the right size, in the right format

An oversized hero image is the single most common LCP failure. If your layout displays the image at 800 pixels wide, shipping a 2400-pixel JPEG wastes roughly nine times the bytes for no visible benefit.

• Convert to AVIF with a WebP fallback. AVIF typically lands 30–50% smaller than WebP at equivalent quality.
• Generate responsive variants and let the browser choose with srcset and sizes.
• Add fetchpriority="high" to the hero image so the browser stops treating it as an ordinary resource.
• Never apply loading="lazy" to the LCP element. Lazy-loading the hero delays the exact thing you are being measured on.

A realistic hero image on a content page should land between 40KB and 120KB. If yours is measured in megabytes, you have found your problem and you can stop reading this section.

Stop blocking the first paint

Even a perfectly optimised image cannot paint while the browser is still parsing render-blocking CSS. A single large stylesheet in the document head is frequently the real LCP culprit, and it hides behind the image in most audits.

• Inline the critical CSS needed for above-the-fold content directly in the head.
• Load the remainder asynchronously so it never blocks the first paint.
• Preconnect to third-party origins that participate in the critical path, but limit yourself to three or four — each connection costs resources.
• Self-host fonts. A round trip to a third-party font host adds DNS, TLS and request latency before a single character appears.

Make the server fast enough to be irrelevant

Time to First Byte is a component of LCP. If your server takes 800 milliseconds to respond, you have already spent a third of the budget before the browser has any bytes to work with. Static HTML served from a CDN edge typically responds in under 100 milliseconds globally, which is why static site generation is such an effective performance strategy for content sites.

2. Protect INP by keeping the main thread thin

INP replaced First Input Delay because FID measured only the delay before the browser began processing an interaction. It ignored how long the handler ran and how long the resulting paint took, so pages that felt sluggish could score well. INP measures the entire interaction, from tap to visual update, which reflects what users actually experience.

Almost every INP problem reduces to the same cause: the main thread is busy doing something else when the user taps.

Break up long tasks

Any task exceeding 50 milliseconds blocks input for its full duration. If a user taps during a 300-millisecond task, they wait at minimum 300 milliseconds for feedback.

• Split large loops into chunks and yield between them with scheduler.yield() where supported.
• Move genuinely heavy computation into a Web Worker so it never touches the main thread.
• Defer non-critical initialisation until the browser is idle using requestIdleCallback.

Audit your third parties honestly

In most real-world audits, third-party scripts account for the majority of main-thread blocking time. Analytics, chat widgets, A/B testing tools, heat maps, consent managers and social embeds each add execution cost, and they compound.

Run this test: block all third-party scripts and re-measure. If INP drops dramatically, you now know the fix is a conversation with whoever owns those tags, not a code change. Load what survives that conversation after interaction, or replace it with a lighter alternative.

Reduce hydration cost

If you use a JavaScript framework, hydration is often the largest single task on the page. Consider rendering static content as plain HTML and hydrating only genuinely interactive islands. A blog post does not need a component tree; it needs text. The related work here is covered in cutting JavaScript bundle size by 60%.

3. Make CLS structurally impossible

CLS is the easiest of the three to fix permanently, because layout shift is almost always caused by reserving space too late.

• Set explicit width and height attributes, or a CSS aspect-ratio, on every image, video, iframe and embed. The browser then reserves the correct box before the asset arrives.
• Give ad slots, banners and dynamic notices a fixed min-height so their arrival cannot push content down.
• Preload your primary font weight and use font-display: swap with a fallback whose metrics are matched using size-adjust. Unmatched fallbacks cause a visible reflow when the web font loads.
• Insert new DOM content below the current viewport, or in an overlay, never above what the user is reading.

One warning: CLS is measured across the full page lifecycle, not just initial load. A shift triggered by a lazily-loaded element halfway down the page still counts against you.

Measure like a skeptic

Lab tools tell you what to fix. Field data tells you whether the fix worked. You need both, and you need to keep them in separate mental categories.

• Lighthouse and DevTools give reproducible diagnostics with a clear cause-and-effect chain. Their scores are simulated, so treat the number as a rough signal and the recommendations as the real value.
• Chrome UX Report and Search Console show real users at the 75th percentile over a 28-day rolling window. This is what actually counts, and it means your improvements take weeks to appear.
• A self-hosted web-vitals beacon gives you same-day feedback segmented by page template, device class and country — far more actionable than an aggregate score.

When testing locally, throttle to Slow 4G with a 4x CPU slowdown. That approximates a mid-range Android phone, which is the device most organic search traffic arrives on. Optimise for that device and desktop takes care of itself.

A realistic one-week plan

Trying to fix every page at once guarantees you finish none of them. Work template by template, highest traffic first.

1. Day 1 — Identify your top three templates by organic traffic. Pull their current field data from Search Console so you have a baseline.
2. Day 2 — Fix the LCP element on template one: correct format, correct dimensions, fetchpriority="high", no lazy-loading.
3. Day 3 — Remove or defer one third-party script. Just one, measured before and after, so you learn what it actually cost.
4. Day 4 — Lock dimensions on every image and embed across the template. This is tedious and it is the highest-certainty win available.
5. Day 5 — Inline critical CSS and make the rest non-blocking.
6. Day 6–7 — Repeat on templates two and three, then deploy and wait. Field data needs 28 days to fully reflect the change.

That single pass moves most failing pages into the green. The pages it does not fix usually have a structural problem — a heavyweight framework, an unavoidable third-party dependency, or a slow origin — and those need a plan rather than a checklist.

Common mistakes worth avoiding

A 100 in Lighthouse means nothing if field INP is failing. Optimise the experience, not the score.

• Optimising the Lighthouse score instead of the experience. A 100 in the lab means nothing if field INP is failing.
• Testing only the homepage. Most organic traffic lands on article and product pages, which usually perform worse.
• Adding a performance monitoring script that itself blocks the main thread. Measure the measurer.
• Expecting instant results. The 28-day window means today's fix shows up next month. Ship it and be patient.

Performance work is unglamorous and cumulative. Do the boring version consistently and your pages will outperform competitors who are still arguing about frameworks.

Frequently asked questions