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: sources/2024-07-28-zalando-opentelemetry-for-javascript-observability-at-zalando):
| 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¶
- sources/2024-07-28-zalando-opentelemetry-for-javascript-observability-at-zalando — FCP/LCP/INP/CLS captured via a custom OTel exporter, tagged with arbitrary attributes, used to measure "designer experience" page-performance impact.