Core Web Vitals: a practical guide to passing all three metrics

Core Web Vitals are Google's metrics for measuring real-world user experience on your site. They affect rankings, and more importantly, they affect whether visitors stay or leave. A page that loads slowly, responds sluggishly, or shifts content around while loading frustrates users -- and Google knows it.

As of 2026, the three Core Web Vitals are:

• Largest Contentful Paint (LCP): how quickly the main content loads
• Interaction to Next Paint (INP): how quickly the page responds to user input
• Cumulative Layout Shift (CLS): how much the layout shifts during loading

Here is how to pass all three.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element to render. This is usually a hero image, heading, or large text block. Google considers an LCP of 2.5 seconds or less as "good."

What causes poor LCP

• Slow server response times
• Render-blocking CSS and JavaScript
• Unoptimized images
• Client-side rendering without server-side fallback
• Slow third-party resources (fonts, analytics, chat widgets)

How to fix LCP

#### Optimize your server response time

Your server's Time to First Byte (TTFB) sets the floor for LCP. Target under 200ms.

• Use a CDN to serve content from edge locations
• Enable server-side caching for static and semi-static pages
• Upgrade hosting if your server is consistently slow
• Use HTTP/2 or HTTP/3 for multiplexed connections

#### Eliminate render-blocking resources

CSS and JavaScript in the <head> block rendering until they download and execute.

• Inline critical CSS (the styles needed for above-the-fold content)
• Defer non-critical CSS with media="print" and an onload handler
• Add defer or async attributes to non-critical scripts
• Remove unused CSS and JavaScript

#### Optimize the LCP element

Identify your LCP element (usually a hero image or heading) and optimize it specifically:

• For images: use modern formats (WebP or AVIF), set explicit width and height, add fetchpriority="high", and preload with <link rel="preload">
• For text: ensure fonts load quickly with font-display: swap and preload critical font files
• Avoid lazy-loading the LCP image -- it needs to load immediately

#### Reduce third-party impact

Each third-party script adds latency. Audit your scripts and:

• Remove scripts you do not actively use
• Load non-essential scripts after the page renders
• Self-host critical third-party resources when possible (fonts, for example)

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) in March 2024. While FID only measured the delay of the first interaction, INP measures responsiveness across all interactions during the page visit. Google considers an INP of 200 milliseconds or less as "good."

What causes poor INP

• Long JavaScript tasks blocking the main thread
• Expensive event handlers (click, scroll, keypress)
• Excessive DOM size (too many HTML elements)
• Heavy client-side frameworks without optimization
• Synchronous operations during user interactions

How to fix INP

#### Break up long tasks

The browser's main thread handles both rendering and JavaScript. Long JavaScript tasks (over 50ms) block the thread and delay interaction responses.

• Split long functions into smaller chunks using requestIdleCallback or setTimeout
• Use web workers for heavy computations that do not need DOM access
• Defer non-urgent work until after the page is idle

#### Optimize event handlers

Every click, tap, and keypress triggers event handlers. Slow handlers cause noticeable delay.

• Debounce scroll and resize handlers
• Avoid layout recalculations (reading layout properties then writing them) inside event handlers
• Use requestAnimationFrame for visual updates triggered by interactions

#### Reduce DOM size

A DOM with over 1,500 elements slows down every interaction because the browser has to recalculate styles and layout for more nodes.

• Remove unnecessary wrapper elements
• Use virtual scrolling for long lists
• Lazy-render content below the fold

#### Minimize main-thread work

Profile your page with Chrome DevTools Performance tab. Look for:

• JavaScript compilation and evaluation time
• Style recalculations after DOM changes
• Layout thrashing (repeated read-write cycles)

Cumulative Layout Shift (CLS)

CLS measures visual stability -- how much visible content shifts unexpectedly during loading. Google considers a CLS of 0.1 or less as "good."

Layout shifts are disorienting. When a user is about to click a link and the page shifts, they click the wrong thing. When text jumps while they are reading, they lose their place.

What causes poor CLS

• Images without explicit dimensions
• Ads or embeds that load after the page renders
• Dynamically injected content above existing content
• Web fonts that cause text to resize on load
• Animations that trigger layout changes

How to fix CLS

#### Set explicit dimensions on all media

Every <img>, <video>, and <iframe> should have width and height attributes. This lets the browser reserve space before the resource loads.

<img src="photo.webp" width="800" height="600" alt="Description" />

For responsive images, use CSS aspect-ratio to maintain proportions:

img {
  aspect-ratio: 4 / 3;
  width: 100%;
  height: auto;
}

#### Reserve space for dynamic content

Ads, embeds, and lazy-loaded content need reserved space:

• Use min-height on ad containers matching the expected ad size
• Set fixed dimensions on embed containers
• Use skeleton screens for content that loads asynchronously

#### Handle font loading properly

When a web font loads and replaces a fallback font, text can resize and shift the layout.

• Use font-display: swap with a closely-sized fallback font
• Preload critical fonts: <link rel="preload" href="font.woff2" as="font" crossorigin>
• Use the CSS size-adjust property on your fallback font to match the web font's metrics

#### Never inject content above existing content

Inserting a banner, notification, or cookie consent bar above page content pushes everything down. Instead:

• Use sticky or fixed positioning for top-of-page elements
• Reserve space for elements that will appear after load
• Animate opacity instead of height for reveal animations

Measuring your Core Web Vitals

Lab data vs. field data

Lab data (Lighthouse, DevTools) shows what could happen. Field data (Chrome User Experience Report) shows what actually happens for real users. Google uses field data for ranking decisions.

Check both:

• Lab data: Use SilverGecko's Web Vitals tool for instant measurements and actionable recommendations
• Field data: Check PageSpeed Insights or Google Search Console's Core Web Vitals report for real-user metrics

Prioritize by impact

If you fail multiple metrics, fix them in this order:

1. LCP -- has the biggest impact on perceived performance and user retention
2. CLS -- layout shifts cause the most frustration and misclicks
3. INP -- interaction delays matter most on pages with heavy user interaction

Monitor continuously

Core Web Vitals change as you add features, update content, and modify your site. Run regular checks with SilverGecko's Web Vitals tool and include Core Web Vitals in your quarterly SEO Audit to catch regressions before they affect rankings.