Web performance directly affects user experience, conversion rates, and search rankings. Studies consistently show that every 100ms of added latency costs measurable engagement. Yet many teams track the wrong metrics or rely on synthetic scores without understanding what they actually measure.

This guide breaks down the metrics that matter, why they matter, and how to improve them.

Core Web Vitals: The Big Three

Google's Core Web Vitals are the three metrics that define real-world page experience. They are measured on actual user devices via the Chrome User Experience Report (CrUX) and directly influence search rankings.

Largest Contentful Paint (LCP)

LCP measures loading performance — specifically, how quickly the largest visible element in the viewport renders. This is usually a hero image, a heading block, or a large text paragraph. A good LCP is under 2.5 seconds.

Common causes of poor LCP and their fixes:

• Slow server response — Use edge caching, a CDN, or server-side rendering to reduce Time to First Byte (TTFB). Every millisecond of server delay pushes LCP further out.
• Unoptimized images — Serve images in modern formats (WebP, AVIF), use responsive srcset attributes, and lazy-load below-the-fold images while eagerly loading the LCP element.
• Render-blocking resources — Defer non-critical CSS and JavaScript. Inline critical CSS for the above-the-fold content to avoid additional round trips.
• Client-side rendering delays — If your page relies on JavaScript to render the main content, consider SSR or static generation so the HTML arrives ready to paint.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) in March 2024 and measures overall responsiveness throughout the entire page lifecycle. Unlike FID, which only captured the first interaction, INP tracks the delay between every user interaction (clicks, taps, key presses) and the browser's visual response, reporting the worst case.

A good INP is under 200 milliseconds. Achieving this requires:

1. Breaking up long tasks — Any JavaScript task that runs longer than 50ms blocks the main thread. Use requestIdleCallback, scheduler.yield(), or break work into smaller chunks with setTimeout.
2. Deferring non-critical scripts — Analytics, chat widgets, and third-party embeds should load after the page is interactive. Use async or defer attributes and lazy-load heavy libraries.
3. Avoiding layout thrashing — Reading layout properties (like offsetHeight) immediately after writing styles forces the browser to recalculate layout synchronously. Batch DOM reads and writes separately.
4. Reducing DOM size — Pages with thousands of DOM nodes are slower to update. Virtualize long lists and remove unnecessary wrapper elements.

Cumulative Layout Shift (CLS)

CLS measures visual stability — how much the page layout shifts unexpectedly during loading and interaction. A good CLS score is under 0.1. Layout shifts frustrate users because elements move just as they are about to click or read them.

The most effective CLS improvements:

• Explicit dimensions on media — Always set width and height attributes on images, videos, and iframes so the browser reserves space before the resource loads.
• No content injection above the fold — Avoid inserting banners, cookie notices, or ad slots above existing content after initial render. If you must show them, reserve fixed space in the layout.
• Font loading strategy — Use font-display: swap with font metric overrides, or preload your web fonts to minimize the text reflow when custom fonts replace system fonts.
• CSS containment — Apply contain: layout to components that change size independently, preventing their reflow from cascading to sibling elements.

Beyond Core Web Vitals

Core Web Vitals cover the essentials, but a complete performance picture includes additional metrics:

• Time to First Byte (TTFB) — Measures server responsiveness. Target under 800ms. High TTFB delays everything downstream.
• First Contentful Paint (FCP) — The moment any content renders. Faster FCP gives users visual feedback that the page is loading.
• Total Blocking Time (TBT) — Lab metric that sums all long task durations beyond 50ms. Strongly correlates with INP in the field.
• Speed Index — Measures how quickly the visible area of the page is populated. Useful for comparing overall perceived loading speed between builds.

The key principle: measure in the field, debug in the lab. Use CrUX or RUM tools to identify what real users experience, then reproduce issues with Lighthouse, WebPageTest, or Chrome DevTools to find root causes. Synthetic tests alone miss the variability of real devices and networks.