Frontend Development 11 min read

Airbnb Web Performance Metrics and Their Measurement

Airbnb tracks five real‑user performance metrics—Time To First Contentful Paint, Time To First Meaningful Paint, First Input Delay, Total Blocking Time, and Cumulative Layout Shift—using a mix of browser APIs and custom polyfills, combines them into a weighted Page Performance Score, and leverages that score to guide trade‑off decisions and detect regressions.

Airbnb Technology Team
Airbnb Technology Team
Airbnb Technology Team
Airbnb Web Performance Metrics and Their Measurement

This article introduces the key web performance metrics used by Airbnb, explains how they are measured, and discusses practical trade‑offs between them.

Airbnb measures five core metrics that reflect real user experience: Time To First Contentful Paint (TTFCP), Time To First Meaningful Paint (TTFMP), First Input Delay (FID), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). These metrics are chosen because they are easy to define, interpret, and compute, and they cover loading, interactivity, and visual stability.

Time To First Contentful Paint (TTFCP) measures the time from navigation start until any content (text, loader, etc.) appears on the screen. For direct requests Airbnb uses the Paint Timing API; for client‑side route transitions a custom polyfill is used:

// Simplified version of our FCP polyfill for client transitions
function onClientTransition() {
  requestAnimationFrame(() => {
    performance.measure('TTFCP');
  });
}

Time To First Meaningful Paint (TTFMP) measures the time until the most meaningful element (usually the largest image or headline) is rendered. Engineers mark this element with an id (the "FMP‑target"). A recursive check runs until the element is present and fully loaded:

let lastHeroElement;
// Simplified version of our TTFMP instrumentation
function recursiveCheckForFirstMeaningfulPaint() {
  const heroElement = document.getElementById("FMP-target");
  // To prevent false positives during client‑side route requests
  const isSameHeroElement = lastHeroElement === heroElement;
  const isImageHeroLoading = heroElement.tagName === "IMG" && !heroElement.complete;

  if (!heroElement || isSameHeroElement || isImageHeroLoading) {
    requestAnimationFrame(recursiveCheckForFirstMeaningfulPaint);
  } else {
    requestAnimationFrame(() => {
      lastHeroElement = heroElement;
      performance.measure("TTFMP");
    });
  }
}

TTFMP requires manual tagging of each page; if the tag is missing or its detection rate falls below 80 % an alert is raised. Because automatic identification of the most meaningful element is difficult, Airbnb does not rely on Largest Contentful Paint (LCP) for client‑side transitions, as the browser API only reports the initial paint.

First Input Delay (FID) measures the latency between a user’s first interaction and the browser’s response. A delay over 50 ms is perceptible. Airbnb forks the Web‑Vitals FID implementation to reset the measurement on client transitions.

Total Blocking Time (TBT) aggregates the time the main thread is blocked by long tasks (> 50 ms). High TBT can cause jank during scrolling or interaction. Because it is hard to attribute blocking to specific components, Airbnb also records a sub‑metric called "interaction time slice" that captures blocking within defined windows. TBT is currently only available in Chromium‑based browsers; no polyfill exists, so it is omitted where unsupported.

Cumulative Layout Shift (CLS) quantifies layout instability during a page session. Low CLS indicates a stable, predictable layout. Like TBT, CLS is not reported in browsers that lack support or a polyfill.

All five metrics feed into Airbnb’s Page Performance Score (PPS), a 0‑to‑100 composite score used for setting targets and detecting regressions. The relative weights are: TTFCP 35 %, FID 30 %, TTFMP 15 %, TBT 15 %, CLS 5 %.

Airbnb draws inspiration from Web Vitals and Lighthouse. Lighthouse provides synthetic audits, while Web Vitals supplies real‑user metrics. PPS combines real‑user data into a single score, complementing Lighthouse’s diagnostic capabilities.

A case study demonstrates how an A/B experiment altered the trade‑off between TTFCP and TTFMP. By removing an initial loading state and pre‑fetching HTML, TTFCP slowed down but TTFMP improved enough to outweigh the regression, leading to a permanent change guided by the PPS.

In summary, the metrics described correlate with positive user‑experience changes. The PPS system gives performance engineers a unified score to set goals, monitor regressions, and make informed trade‑off decisions across loading speed, interactivity, and visual stability.

frontendperformance optimizationmetricsweb performanceAirbnbweb-vitals
Airbnb Technology Team
Written by

Airbnb Technology Team

Official account of the Airbnb Technology Team, sharing Airbnb's tech innovations and real-world implementations, building a world where home is everywhere through technology.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.