Skip to content

CONCEPT Cited by 1 source

Core Web Vitals

Definition

Core Web Vitals is Google's standardised set of user- experience metrics for web pages, measured in the browser and intended as proxies for perceived page quality (loading, interactivity, visual stability). The set most commonly referenced, and the one Zalando instrumented (Source: ):

Metric Meaning Typical range
FCP First Contentful Paint 0-5000 ms
LCP Largest Contentful Paint ~600-2000 ms
INP Interaction to Next Paint 0-2000 ms (interaction-scoped)
CLS Cumulative Layout Shift 0-1 (unitless; ratio)

Google's thresholds (as of writing): LCP ≤2500 ms is good, ≤4000 ms is needs improvement; CLS ≤0.1 is good, ≤0.25 is needs improvement.

Measurement shape: single-value-per-page-load

Unlike most server latency metrics (which are many per second over time), Core Web Vitals are typically emitted once per page load — LCP fires when the largest contentful paint candidate is determined, CLS accumulates until page-unload, etc. This is why OTel JS's default histogram buckets ([0, 5, 10, 25, 50, 75, 100, 250, 500, 750, 1000, 2500, 5000, 7500, 10000]) fit CWV badly:

  • LCP typically sits in the 600-2000 ms range — OTel defaults would lump most LCP observations into the 1000-2500 ms bucket, losing all resolution where the p50/p75 lives.
  • CLS is 0-1 unitless — OTel defaults would put almost every CLS observation in the 0-5 bucket with no resolution at all.

Zalando solved this with custom histogram buckets per metric, declared via OTel's view + custom-aggregation API.

Alternative: events API for single-value metrics

The Zalando author discussed this mismatch with OTel contributors at KubeCon Paris, and flagged the events API as a potentially better fit for single-value-per-page-load signals than histograms.

Correlatable attributes

The load-bearing capability OTel metrics add over Zalando's prior custom RUM service is arbitrary OTel attributes on each CWV emission. Tag LCP with experience=designer, browser=chrome_126, ab_variant=T7, and you can filter / group by any of them at query time in the backend — which lets regressions correlate back to feature rollouts. The custom service had fixed columns and couldn't do this.

Seen in

  • — FCP/LCP/INP/CLS captured via a custom OTel exporter, tagged with arbitrary attributes, used to measure "designer experience" page-performance impact.
  • sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance — GitHub explicitly anchors its internal HPC (Highest Priority Content) metric to LCP: "We use HPC (Highest Priority Content), an internal metric closely aligned with Web Vitals LCP, to measure when the primary content (the content users care about) on the page is first rendered. Like LCP, this is anchored to a single HTML element selected by the browser." GitHub's Instant/Fast/Slow bucket thresholds (<200 ms / <1000 ms / ≥1000 ms) sit inside but are tighter than Google's good/needs-improvement LCP cutoffs (≤2500 ms / ≤4000 ms). Canonical wiki instance of an internal-metric variant of LCP with bucket-share consumption (distribution quality) rather than percentile reporting. See concepts/highest-priority-content-hpc.
Last updated · 542 distilled / 1,571 read