Understanding Modern User‑Centric Web Performance Metrics: LCP, TBT, and CLS

Author: Milica Mihajlija Original: https://calibreapp.com/blog/new-generation-of-performance-metrics Translation / Editing: Dan Shihao This is the first article in our Web Infra APM team’s series on experience monitoring; more will follow. Remember to follow us so you don’t get lost.

Traditional performance metrics such as load time or DOMContentLoaded focus on easily measurable technical details but often fail to reflect what users actually care about. A site may load quickly in terms of total time, yet if the page does not render useful content until the end, users stare at a blank screen. Likewise, a page may be technically “loaded” while JavaScript blocks the main thread, causing delayed interaction and frustration.

In contrast, the page on the right has a longer total load time but progressively renders useful content without excessive JavaScript blocking, resulting in a better user experience that raw load time cannot capture.

These observations motivate the creation of user‑centric performance metrics that focus on the browsing experience from the user’s perspective.

User‑centric performance metrics measure how quickly useful content appears, whether the page is interactive, and if interactions are smooth and without delay.

Users’ perception of a page’s speed is influenced by different moments during the loading experience, so several metrics aim to capture these aspects:

User Experience

Metric

Did something happen?

First Paint (FP), First Contentful Paint (FCP)

Is the content useful?

First Meaningful Paint (FMP), Speed Index (SI)

Is the content usable?

Time to Interactive (TTI)

These metrics bring us closer to measuring user experience, yet none are perfect. The industry continues to research and develop key indicators that better describe a good user experience.

The result of this research is three brand‑new performance metrics that fill gaps in the user‑experience story:

Largest Contentful Paint (LCP)

Total Blocking Time (TBT)

Cumulative Layout Shift (CLS)

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) represents the moment when the largest piece of content in the viewport becomes visible.

The largest element—such as a big paragraph of text in an article or a product image—generally conveys the most useful information about the page. Tests show that LCP closely approximates the time when the main content finishes loading.

In the example above, LCP occurs around 0.8 s when the banana image finishes loading.

To improve LCP, ensure you:

Eliminate render‑blocking resources .

Minimize the critical request chain by loading resources in the correct priority and order.

Compress images and serve appropriately sized variants for different devices.

Optimize CSS, compress files, and extract critical CSS .

Apply a font‑loading strategy to avoid flash‑of‑invisible‑text (FOIT).

Why LCP Matters

Browsers and performance monitoring tools have long reported paint metrics, but many of them suffer from clear drawbacks:

Metric

Definition

Problem

First Contentful Paint (FCP)

Time when the browser paints the first piece of DOM content.

Often unrelated to user‑perceived progress (e.g., loading spinners).

First Meaningful Paint (FMP)

Paint time after the most dramatic layout change.

Non‑standardized, hard to implement consistently; ~20 % inaccurate.

Speed Index (SI)

Speed Index (SI)

Complex, hard to interpret, and computationally intensive—cannot be used in real‑user monitoring (RUM) in mainstream browsers.

LCP differs because it is easy to understand, correlates well with user perception (similar to SI), and can be calculated and reported in RUM tools.

While LCP does not render other metrics obsolete—FCP still provides feedback on loading progress, and FMP experiments have informed LCP’s development—LCP is now available in Calibre, Chrome DevTools, and via the LargestContentfulPaint API, and is used by Lighthouse (v6.0+) to compute performance scores.

Total Blocking Time (TBT)

Total Blocking Time (TBT) describes activity on the JavaScript main thread.

It helps understand how long a page is unable to respond to user input during loading.

Most rendering, JavaScript execution, and user‑input handling happen on the main thread. When the thread is busy, user clicks are delayed until it becomes idle. Delays under ~50 ms are usually unnoticed; longer blocks cause perceivable lag.

TBT quantifies the time the main thread spends on long tasks (tasks > 50 ms) between First Contentful Paint and Time to Interactive.

What Is a Long Task?

A task running on the main thread for more than 50 ms is considered a long task; any time beyond 50 ms counts toward blocking time.

Total Blocking Time is the sum of blocking portions of all long tasks between FCP and TTI.

Example calculation:

Task

Task Duration

Blocking Time (> 50 ms)

1

75 ms

25 ms

2

25 ms

0 ms

3

85 ms

35 ms

4

30 ms

0 ms

Total Blocking Time

0 ms

If TBT is high, consider:

Code‑splitting JavaScript bundles and lazy‑loading non‑essential code.

Refactoring functions to do less work and execute faster.

Reducing frequent DOM queries.

Offloading heavy computation to Service Workers or Web Workers.

TBT vs. Time to Interactive (TTI)

Time to Interactive (TTI) measures when a page can reliably respond to user input—i.e., when the main thread has been idle for at least 5 seconds without long tasks.

TBT is calculated only between FCP and TTI.

TTI tells you when the thread becomes idle.

TBT quantifies how busy the thread was before it became idle.

Combined, TBT and TTI give a clearer picture of responsiveness; two pages may share the same TTI, but the one with higher TBT likely feels slower because long tasks block interaction.

Both Calibre and Lighthouse (v6.0+) include TBT in performance scoring.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) quantifies how many elements move in the viewport during page load.

Layout shifts can cause users to miss or accidentally click the wrong button, leading to frustration.

Even a few‑pixel shift can cause significant trouble, especially when ads load asynchronously or images appear later, pushing content down.

CLS measures the frequency of such shifts, introducing a new dimension of predictability to user experience.

Common causes of layout instability and their fixes:

Images without explicit width/height cause a 1×1 px placeholder that later expands; add width and height attributes.

Asynchronously injected content can shift layout; use placeholders to reserve space.

Ads loading later can push content; reserve ad space in advance.

Animating layout‑changing CSS properties; prefer transform for animations.

Font swaps that change size; use font-display: swap together with a font‑style‑matcher to match dimensions.

Measuring CLS

When an element moves during load, it is marked as unstable; its movement relative to the viewport determines a shift score. The score is the product of a distance fraction and an impact fraction.

Distance fraction – how far the unstable element moves.

Impact fraction – the proportion of the viewport area affected by the unstable element.

In the example, the element moves one‑third of the viewport height, giving a distance fraction of 0.33 . It occupies two‑thirds of the viewport area, giving an impact fraction of 0.66 . The layout‑shift score is therefore 0.33 × 0.66 = 0.2178 . The total CLS is the sum of such scores for all unstable elements.

Lower CLS scores are better; a score below 0.1 is considered good in Chrome’s field data. Some sites intentionally move content, so a higher CLS does not always indicate a bad experience, but monitoring CLS helps detect unexpected layout shifts and fix them.

CLS is available in Chrome’s User Experience Report, and can be measured programmatically via the Layout Instability API in JavaScript. Calibre and Lighthouse also expose this metric.

Improving Customer Experience with Modern Web Performance Metrics

Choosing the right performance‑monitoring tools and automating measurements are key to tracking optimizations and catching regressions. By leveraging modern user‑centric metrics, teams can continuously refine the user experience and build great products.

References

[1]

load time: https://developer.mozilla.org/en-US/docs/Web/Events/load

[2]

DOMContentLoaded: https://developer.mozilla.org/en-US/docs/Web/API/Window/DOMContentLoaded_event

[3]

Testing: https://calendar.perfplanet.com/2019/developing-the-largest-contentful-paint-metric/

[4]

Render‑blocking resources: https://web.dev/render-blocking-resources/

[5]

Minimize critical request chain: https://calibreapp.com/blog/critical-request

[6]

Extract critical CSS: https://web.dev/extract-critical-css/

[7]

Font loading strategy: https://www.zachleat.com/web/comprehensive-webfonts

[8]

Calibre: https://calibreapp.com/

[9]

Largest Contentful Paint API: https://wicg.github.io/largest-contentful-paint/

[10]

Performance score calculator: https://paulirish.github.io/lh-scorecalc/

[11]

Rendering webpages: https://calibreapp.com/blog/investigate-animation-performance-with-devtools#demystifying-rendering

[12]

Long tasks: https://web.dev/long-tasks-devtools/#what-are-long-tasks

[13]

Time to Interactive (TTI): https://calibreapp.com/blog/time-to-interactive

[14]

web.dev CLS article: https://web.dev/cls/

[15]

Cumulative Layout Shift: https://calibreapp.com/blog/cumulative-layout-shift

[16]

Add width/height to img: https://www.youtube.com/watch?v=4-d_SoCHeWE&feature=youtu.be

[17]

Avoid layout‑changing CSS animations: https://calibreapp.com/blog/investigate-animation-performance-with-devtools#layers-and-compositing

[18]

font‑style‑matcher: https://meowni.ca/font-style-matcher/

[19]

Purposeful content movement: https://web.dev/cls/#vs.

[20]

Fixing layout instability: https://dev.to/chromiumdev/fixing-layout-instability-176c

[21]

Measure CLS via Layout Instability API: https://dev.to/chromiumdev/measuring-cumulative-layout-shift-cls-in-webpagetest-5cle