Web Performance Metrics: LCP, FID, CLS, and Beyond

Intermediate

Every millisecond counts on the web. Research from Google shows that as page load time increases from one second to three seconds, the probability of a visitor bouncing rises by 32 percent. But for years, measuring "page speed" meant different things to different people. Some teams tracked DOMContentLoaded, others watched the load event, and a few relied on synthetic scores that had little correlation with what real users actually experienced. In May 2020, Google introduced Core Web Vitals — a small, focused set of metrics designed to capture the dimensions of user experience that matter most: loading, interactivity, and visual stability. This guide explains every metric in the modern web performance toolkit, what thresholds separate good from poor, how each metric is measured, and how infrastructure decisions — particularly the use of a CDN — influence each score.

What Are Core Web Vitals and Why Do They Matter?

Core Web Vitals are three specific metrics that Google treats as essential indicators of page quality. Unlike older speed metrics that measured browser-level events, Core Web Vitals focus on user-perceived experience. They are used as ranking signals in Google Search, appear in Chrome User Experience Report (CrUX) data, and are surfaced in tools like PageSpeed Insights, Lighthouse, and Google Search Console.

The three current Core Web Vitals are:

• Largest Contentful Paint (LCP) — measures loading performance
• Cumulative Layout Shift (CLS) — measures visual stability
• Interaction to Next Paint (INP) — measures responsiveness

Google evaluates these metrics at the 75th percentile of real-user data. That means your page must meet the threshold for at least 75 percent of all visits to be considered "good." This percentile approach prevents a handful of outlier sessions on slow networks from masking systemic problems.

How Is Largest Contentful Paint (LCP) Measured?

Largest Contentful Paint measures the render time of the largest image, video poster, or text block visible in the viewport. The browser continuously identifies the largest element as the page loads and updates the LCP candidate until the user interacts with the page (a tap, scroll, or keystroke). At that point, the final LCP candidate is recorded.

Elements considered for LCP include <img> elements, <image> elements inside SVGs, <video> poster frames, elements with a CSS background-image loaded via url(), and block-level elements containing text nodes. The metric was formalized in the Web Vitals specification after earlier attempts like First Meaningful Paint proved inconsistent across page types.

Thresholds:

• Good: LCP occurs within 2.5 seconds of when the page first started loading
• Needs improvement: LCP occurs between 2.5 and 4.0 seconds
• Poor: LCP occurs after 4.0 seconds

The most common causes of poor LCP are slow server response times (high TTFB), render-blocking CSS and JavaScript, slow resource load times for hero images, and client-side rendering that delays visible content. CDNs address the first issue directly by caching HTML at edge locations, and they tackle slow resource loads through image optimization, compression, and HTTP/2 prioritization.

What Is Cumulative Layout Shift (CLS) and How Does It Affect Users?

Cumulative Layout Shift quantifies how much visible content moves around unexpectedly during the page lifecycle. Every time a visible element shifts position without being triggered by user input, the browser records a layout shift. CLS aggregates these shifts using a "session window" approach: consecutive layout shifts that occur within 500 milliseconds of each other, with no more than 5 seconds in total duration, are grouped into a session window. The CLS score is the maximum session window value.

Thresholds:

• Good: CLS score of 0.1 or less
• Needs improvement: CLS between 0.1 and 0.25
• Poor: CLS above 0.25

Common causes of layout shift include images and iframes without explicit width and height attributes, dynamically injected content above the fold (such as cookie banners or late-loading ad slots), web fonts that trigger a Flash of Unstyled Text (FOUT), and third-party embeds that resize after initial render. The fix is almost always to reserve space in the layout before the content arrives — for example, using CSS aspect-ratio on image containers or preloading critical fonts with <link rel="preload">.

How Did INP Replace FID as a Core Web Vital?

First Input Delay (FID) was one of the original Core Web Vitals introduced in May 2020. It measured the time between a user's first discrete interaction (click, tap, or key press) and the moment the browser began processing the event handler. While FID was useful, it had a critical blind spot: it only captured the first interaction. A page could have excellent FID because the first click landed during an idle period, even though subsequent interactions were sluggish due to heavy JavaScript execution.

Google addressed this limitation with Interaction to Next Paint (INP), which officially replaced FID as a Core Web Vital on March 12, 2024. INP observes the latency of every discrete interaction throughout the entire page lifecycle — clicks, taps, and keyboard inputs. For each interaction, it measures the total duration from the input event through event processing to the next frame being painted. The reported INP value is typically the worst interaction latency, or for pages with many interactions, an approximation near the 98th percentile to avoid penalizing pages for rare outliers.

Thresholds:

• Good: INP of 200 milliseconds or less
• Needs improvement: INP between 200 and 500 milliseconds
• Poor: INP above 500 milliseconds

Poor INP is overwhelmingly caused by long JavaScript tasks that block the main thread. Solutions include breaking large tasks into smaller chunks using scheduler.yield() or requestIdleCallback(), deferring non-critical scripts, and reducing the total amount of JavaScript shipped to the client. While CDNs cannot fix application-level JavaScript inefficiency, they reduce the time it takes to deliver scripts to the browser, and some CDN providers offer edge-side script optimization that defers third-party tags automatically.

What Are TTFB, FCP, TBT, and Speed Index?

Beyond the three Core Web Vitals, several supporting metrics provide diagnostic insight into why a page performs the way it does. Understanding these supporting metrics is essential for debugging performance regressions.

Time to First Byte (TTFB)

TTFB measures the time from the start of navigation to when the browser receives the first byte of the HTML response. It encompasses DNS lookup, TCP connection, TLS negotiation, and server processing time. Google's recommended threshold is under 800 milliseconds at the 75th percentile. While TTFB is not itself a Core Web Vital, it is the single largest contributor to LCP in most architectures because no rendering can begin until HTML arrives.

A CDN dramatically reduces TTFB by serving cached HTML and assets from edge servers that are geographically close to the user. Where a direct-to-origin request might travel 200 milliseconds round trip across continents, a CDN edge hit can respond in under 20 milliseconds.

First Contentful Paint (FCP)

FCP measures when the browser first renders any content — text, an image, a background SVG, or a non-white canvas element. It signals to the user that something is happening. Google considers FCP good when it occurs within 1.8 seconds. FCP is affected by TTFB, render-blocking resources, and font loading strategy. Preloading critical fonts and inlining above-the-fold CSS are common FCP optimizations.

Total Blocking Time (TBT)

TBT measures the total amount of time between FCP and the Time to Interactive (TTI) during which the main thread was blocked long enough to prevent input responsiveness. Any task longer than 50 milliseconds is considered "long," and the amount exceeding 50 milliseconds is added to TBT. For example, a 120-millisecond task contributes 70 milliseconds to TBT. Google recommends keeping TBT under 200 milliseconds. TBT is a lab-only metric (it cannot be measured in the field), but it correlates strongly with INP.

Speed Index

Speed Index measures how quickly the visible content of a page is populated. It uses video capture of the page load to calculate the average time at which visible parts of the page are displayed. A lower Speed Index means the page appears to load faster. Lighthouse considers a Speed Index under 3.4 seconds good. Speed Index is useful as a holistic "how fast does this feel?" measure, but because it depends on viewport size and content, it is less actionable than individual metrics like LCP or FCP.

How Do CDNs Improve Every Performance Metric?

Content Delivery Networks improve web performance metrics across the board, though the mechanism varies by metric. Understanding these connections helps teams make informed infrastructure decisions. For a deeper exploration of CDN-specific optimization, see our guide on CDN and Core Web Vitals.

The table below maps each metric to the primary CDN optimization that improves it:

How Should You Measure Web Performance Metrics?

Web performance measurement falls into two categories: lab data (synthetic tests) and field data (real user measurements). Both are essential, and they serve different purposes.

Lab Measurement Tools

Lighthouse is the most widely used lab tool. Built into Chrome DevTools, it runs a simulated page load under controlled network and CPU throttling and reports LCP, CLS, TBT (as an INP proxy), FCP, Speed Index, and an overall performance score from 0 to 100. Lighthouse is deterministic and reproducible, making it ideal for CI/CD pipelines where you want to catch regressions before deployment.

WebPageTest provides more granular lab measurement, including filmstrip views, waterfall charts, and multi-step scripted tests. It supports testing from dozens of global locations with real browsers, making it valuable for measuring the impact of CDN configuration changes from specific geographic regions.

Field Measurement (Real User Monitoring)

Field data captures what real users experience across the full spectrum of devices, networks, and geographic locations. The Chrome User Experience Report (CrUX) is Google's public dataset of field performance data, aggregated from Chrome users who have opted into usage statistic reporting. CrUX data powers PageSpeed Insights and the Core Web Vitals report in Google Search Console.

For site-specific real user monitoring, the web-vitals JavaScript library (maintained by Google at web-vitals on npm) is the standard approach. It captures LCP, CLS, INP, TTFB, and FCP in production and can send measurements to any analytics endpoint. The library weighs approximately 1.5 KB gzipped and uses the same measurement logic that Chrome uses internally.

What Is the History Behind Web Performance Metrics?

Web performance measurement has evolved significantly over two decades. In the early 2000s, "page speed" meant the window.onload event — a single number representing when all resources (including every image, stylesheet, and script) had finished loading. This was a poor proxy for user experience because a page could be fully interactive long before onload fired, or it could appear blank long after.

The Navigation Timing API (first published as a W3C Recommendation in December 2012) gave developers programmatic access to timing milestones like domContentLoadedEventEnd and responseStart. This enabled TTFB measurement in the field for the first time. The Paint Timing API followed, surfacing First Paint and First Contentful Paint. The Largest Contentful Paint API, Element Timing API, and Layout Instability API then provided the primitives needed for LCP and CLS.

Google's announcement of Web Vitals in May 2020 was a watershed moment. By tying performance metrics to search rankings (initially announced for the "page experience update" that rolled out in June 2021), Google gave every site owner a concrete, business-case reason to care about user-centric performance. The transition from FID to INP in March 2024 refined the responsiveness signal, and ongoing proposals like Long Animation Frames (LoAF) continue to push the measurement frontier forward.

What Are Common Pitfalls When Optimizing Web Performance?

Pursuing better scores without understanding what the metrics actually measure leads to several common mistakes:

Optimizing lab scores while ignoring field data. A page can score 100 in Lighthouse on a developer's fast machine while performing poorly for real users on mobile networks. Always validate lab improvements against CrUX or your own RUM data.

Over-optimizing LCP by lazy-loading the hero image. Lazy loading is beneficial for below-the-fold images, but applying loading="lazy" to the LCP element actually worsens LCP because the browser delays loading the most important resource until it enters the viewport.

Ignoring the Vary header in CDN configurations. When your origin returns different content based on Accept-Encoding or Accept-Language but does not include the appropriate Vary header, CDN caches may serve the wrong variant to users. This can cause both performance degradation and functional errors. See our article on content negotiation for details on getting Vary right.

Adding third-party scripts without measuring impact. Each third-party tag — analytics, A/B testing, chat widgets, social embeds — contributes to TBT and can worsen INP. Before adding any script, measure its main-thread impact using Chrome DevTools' Performance panel or the PerformanceObserver API for long tasks.

Neglecting font loading strategy. Web fonts that block rendering delay FCP and can cause CLS when they eventually swap in. Using font-display: swap in your @font-face rules (or via the Google Fonts &display=swap parameter) ensures text is visible immediately with a fallback font, then smoothly transitions when the custom font loads. Preloading the most critical font file with <link rel="preload" as="font" crossorigin> further reduces the swap delay.

How Should Teams Build a Performance Monitoring Strategy?

An effective performance monitoring strategy combines automated lab testing, continuous field measurement, and clear performance budgets:

1. Set performance budgets. Define target thresholds for each Core Web Vital and key supporting metrics. For example: LCP under 2.0 seconds, CLS under 0.05, INP under 150 milliseconds, and a JavaScript bundle size under 200 KB compressed.
2. Integrate Lighthouse into CI. Run Lighthouse CI on every pull request to catch regressions before they reach production. Configure assertions that fail the build when metrics exceed your budgets.
3. Deploy real user monitoring. Use the web-vitals library or a commercial RUM provider to capture field data. Segment by device type, connection speed, and geography to identify populations that are underserved.
4. Leverage CDN analytics. Most CDN providers offer performance dashboards that show cache hit ratios, TTFB distributions, and error rates at the edge. Use these to validate that your CDN configuration is delivering the expected improvements.
5. Review monthly. Performance degrades gradually as features are added and third-party scripts accumulate. A monthly review of Core Web Vitals trends in Search Console catches slow regressions before they affect rankings.

Web performance is not a one-time project. It is a continuous discipline that requires measurement, budgeting, and systematic optimization across every layer of the stack — from origin server configuration and CDN tuning to front-end architecture and third-party script management. The metrics described in this guide provide the compass; the work of improving them never truly ends.