Core Web Vitals Explained: LCP, INP, and CLS (2026 Guide)

Google uses Core Web Vitals as part of how it ranks pages, and your visitors feel them on every visit. This guide explains what each of the three metrics measures, the thresholds that count, and a prioritised list of fixes for WordPress, custom PHP sites and JavaScript apps.

1. The three metrics and their thresholds

Each metric has three bands. Passing means reaching "good" on all three for at least 75% of page loads, measured by real Chrome users, not by your own laptop.

LCP is usually the hardest to fix, because it depends on server speed, caching and image weight together. INP is about JavaScript discipline. CLS is mostly about reserving space for images, ads and embeds.

2. LCP: Largest Contentful Paint

What it is. The time from the start of navigation until the largest content element, usually the hero image or the main headline, is visible. It answers "how fast did the page feel loaded?" PageSpeed Insights shows which element is your LCP element.

What makes it slow, roughly in order of impact:

1. Slow server response (time to first byte, TTFB). Old PHP, no page cache, slow database queries or heavy plugins all show up here. Google treats a TTFB of 0.8 s or less as good; if yours is well above that, fix it first, because everything else waits for it.
2. Render-blocking CSS and JavaScript. Large stylesheets, synchronous third-party scripts and web fonts loaded without font-display: swap.
3. A heavy LCP element. A 2 MB hero JPEG with no smaller versions for phones.
4. Client-side rendering. Single-page apps that show a skeleton and draw the real content only after JavaScript runs.

Fix it in this order:

<!-- In the page head: fetch the hero image early -->
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

<!-- Load scripts that are not needed for first paint later -->
<script src="/js/chat-widget.js" defer></script>

Diagnose it. In PageSpeed Insights, open the "Largest Contentful Paint element" diagnostic. In Chrome DevTools, the Performance panel marks LCP on the timeline and breaks it into time to first byte, resource load delay, load time and render delay, which tells you which fix applies.

3. INP: Interaction to Next Paint

What it is. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. It measures the delay from a click, tap or key press to the next visual update, across the whole visit, and reports close to the slowest one. FID measured only the first interaction; INP catches the third click on "Add to cart" or a stuttering search box too.

What makes it slow. Almost always JavaScript on the main thread: long tasks over 50 ms, heavy framework re-renders, blocking analytics and third-party widgets, and animations that force the browser to recalculate layout.

How to fix it:

• Break up long tasks. Yield to the browser between chunks of work with scheduler.yield() where supported, or setTimeout.
• Debounce input handlers. Search-as-you-type doesn't need to run on every keystroke; wait 150 to 300 ms.
• Animate with transform and opacity. Changing top, left, width or margin forces layout work.
• Move heavy work to a Web Worker. Large JSON parsing, image processing and client-side search are good candidates.
• Cut unnecessary re-renders in React and similar frameworks, for example with memoisation.
• Delay third-party scripts until after the page is interactive.

Diagnose it. Record a Performance trace in Chrome DevTools while you click and type as a visitor would, then look for long tasks on the main thread. Check field data in PageSpeed Insights first, to confirm INP is actually a problem for your visitors before you spend time on it.

4. CLS: Cumulative Layout Shift

What it is. A score for unexpected movement of content while the page is in use. It has no units; Google counts the largest burst of layout shifts during the visit. 0.1 or less is good.

The five classic causes and fixes:

1. Images without dimensions. Give every image width and height attributes, or a CSS aspect-ratio, so the browser reserves the space.
2. Ads and embeds that load late. Reserve their space with a min-height on the container.
3. Web fonts swapping in. Use font-display: swap, preload the main font, and use the size-adjust descriptor so the fallback font takes up the same space.
4. Content inserted above existing content, such as a cookie banner that pushes the article down. Use a fixed overlay, or insert it below.
5. Animations that change layout properties. Use transform instead of animating height, width or margin.

<img src="hero.webp" width="1200" height="630" alt="Product range">

<div class="ad-slot" style="min-height: 280px">
  <!-- the ad script fills this space -->
</div>

Diagnose it. In Chrome DevTools, open Rendering and turn on "Layout Shift Regions"; shifting areas flash as the page loads. PageSpeed Insights lists the elements that shifted most.

5. Lab data versus field data

A site can score 95 in Lighthouse and still fail in the field, because real visitors use slower networks and older phones than your development machine. Search Console's Core Web Vitals report is the scoreboard.

Field data is a rolling 28-day window, so a fix you ship today shows fully only after about four weeks. Don't judge a change by the next day's numbers.

6. Tools for measuring

For a hands-on checklist with more code examples, see the Web Vitals and Lighthouse optimisation checklist.

7. A prioritised fix list

For a typical WordPress site on shared hosting, this is a sensible order by effort and effect.

8. WordPress checklist

• One page cache plugin, such as WP Super Cache or W3 Total Cache, with cart, checkout and account pages excluded on a shop.
• A lightweight theme such as Astra or GeneratePress, rather than a theme with every feature switched on.
• An image optimisation plugin, such as ShortPixel or EWWW Image Optimizer, to create WebP versions.
• Delete inactive plugins; clean up expired transients, post revisions and oversized autoloaded options with care and a backup.
• Remove scripts you don't use, such as emoji support or embeds, with a small plugin or a few lines in a child theme.

9. When it's the hosting, and where Domain India fits

Signs the server side is the bottleneck:

• consistently high TTFB, even on a simple page with caching on;
• faults in cPanel's Metrics › Resource Usage at busy times;
• 503, 504 or 508 errors when traffic rises;
• a slow admin area regardless of how many plugins are active.

First find what the server is spending its time on: my website is slow walks through it, including external calls without timeouts, which a bigger plan does not fix. If your site has genuinely outgrown its plan, a larger shared plan gives it more resources, and a VPS gives you root access to tune PHP-FPM, caching and the database yourself. A Domain India VPS is self-managed.

Prices on the cards are Domain India list prices and exclude 18% GST.

Frequently asked questions

Ready to improve your scores? Measure your key pages in PageSpeed Insights, work through the fix list above, and open a ticket if Resource Usage shows your site hitting its limits.