For anything users load in a browser, "how fast is it?" is really three questions — loading, interactivity, and visual stability — and the frontend has its own metric stack for each, plus the accessibility and client-side reliability signals that live right next to performance. Here's the set a frontend team actually owns, in one place.
A note on scope. There are two kinds of "frontend metric" and it's worth keeping them apart. Some are frontend-owned — a frontend engineer directly moves them (Core Web Vitals, bundle size, a11y). Others are measured in the browser but owned elsewhere — almost all product and marketing analytics fire from frontend code, but the number describes the product or the business, not the frontend's health. This post covers only the first bucket. The second — SEO, conversion, engagement, retention — gets its own dedicated write-ups (linked at the end), because those metrics deserve to be judged by the function that actually owns them.
Every metric below carries the tool that produces it, tagged by access tier: ext
browser extension (Web Vitals extension, axe DevTools) · free free web service (Lighthouse,
PageSpeed Insights, Chrome DevTools, Chrome User Experience Report (CrUX), Search Console) ·
paid paid Real User Monitoring (RUM) / error SaaS (SpeedCurve, Calibre, DebugBear, Sentry,
Datadog) · api a browser API you read yourself (the web-vitals JavaScript library, the
Performance and Reporting APIs).
Core Web Vitals
Google's Core Web Vitals (CWV) are three metrics chosen to map onto the loading, interactivity, and visual-stability experience:
| Metric | Full name | Measures | "Good" threshold |
|---|---|---|---|
| LCP | Largest Contentful Paint | Loading — when the main content renders | |
| INP | Interaction to Next Paint | Responsiveness — lag from interaction to visible update | |
| CLS | Cumulative Layout Shift | Visual stability — how much the page jumps around |
(INP replaced the older FID, First Input Delay, in 2024 — INP watches every interaction, not just the first, so if you see FID in older docs, it's the predecessor.)
Measure with: all three share tooling — field via CrUX and Search Console (free) or a
RUM provider (SpeedCurve, Datadog, Sentry paid) collecting from the web-vitals library
(api); lab via Lighthouse and PageSpeed Insights (free) or the Web Vitals extension
(ext).
Supporting signals: TTFB and bundle size
Feeding into the vitals are two signals worth tracking on their own:
- TTFB (Time To First Byte) — server + network latency before the browser gets anything.
It feeds directly into LCP: you can't paint content you haven't started downloading.
Measure with: Lighthouse / PageSpeed Insights and the
Server-Timingheader, or CrUX for the field number (free). - Bundle size — every kilobyte of JavaScript must be downloaded, parsed, and executed on
the main thread, hurting both LCP (it delays render) and INP (it blocks the main thread
during interactions). Measure with:
webpack-bundle-analyzeror Bundlephobia, Lighthouse, and a CI bundle-size budget (free/api).
Lab data vs field data
The critical distinction in frontend measurement is lab data vs field data — where the number comes from changes what it can tell you:
| Lab data (synthetic) | Field data (RUM) | |
|---|---|---|
| Source | Lighthouse, WebPageTest (free) — a controlled run | Real User Monitoring: actual visitors, e.g. CrUX (free) or a RUM SaaS (paid) |
| Good for | Debugging, catching regressions in CI | Knowing what users actually experience |
| Blind spot | One device, one network — not your real audience | Can't tell you why without extra tracing |
Lighthouse in CI catches regressions before they ship; field data (the Chrome User Experience Report, which powers Google's ranking) tells you the truth about your real, diverse users. You need both.
Latency lives in the tail, not the average
Frontend latency is measured in percentiles, never averages — an average hides the tail. p50 (median) tells you the typical experience; p95/p99 tell you what your unhappiest users feel. A p99 of 2s means 1 in 100 requests is miserable — and on a page that loads 100 assets, almost every page load hits that p99 at least once. The tail is the experience.
Client-side reliability
Reliability isn't only a server concern — the same RED / Four Golden Signals framing (Rate, Errors, Duration) applies to what happens in the browser, and these are signals a frontend team owns:
| Metric | What it measures | Why it matters |
|---|---|---|
| JS error rate | Uncaught exceptions per session / page view | A spike often means a broken release users hit before your server metrics notice |
| Failed-request rate | % of client-initiated API/asset requests that error | Captures failures the backend's own dashboards may not attribute to a page |
| Crash-free sessions | % of sessions with no fatal error | The frontend analog of an availability SLO — a headline health number |
Measure with: error-tracking / RUM tools — Sentry, Datadog, Bugsnag, Rollbar (paid) — fed
by the browser's own error and Resource Timing APIs (api). The crash-free sessions rate
in particular is worth holding to an SLO the same way you'd hold a backend service to one.
Accessibility (a11y)
Accessibility is a measurable quality of the frontend, not a separate concern, and it belongs on the same dashboard as performance:
- axe violations — automated checks (via axe-core, the engine behind most a11y tooling) for missing labels, contrast failures, ARIA misuse. Cheap to run in CI.
- WCAG conformance — the standard, graded at levels A / AA / AAA; AA is the common legal and practical bar.
- a11y score — Lighthouse's rolled-up accessibility number. Useful as a trend, but automation only catches ~30–40% of real issues; the rest needs manual testing with a keyboard and a screen reader, so don't mistake a green score for an accessible site.
Measure with: axe DevTools or WAVE (ext), axe-core / Lighthouse / Pa11y in CI (free) — then
manual passes with a screen reader (NVDA, VoiceOver) for what automation can't see.
Where SEO, product & marketing metrics went
The frontend influences a lot of numbers it doesn't own — a slow LCP shows up as an SEO ranking drop, a janky checkout step shows up as funnel drop-off, a confusing empty state shows up as poor retention. But those are measured in the browser, owned elsewhere, and each set is best judged by the function that owns it. They live in their own posts:
- Measuring Marketing & SEO: Metrics That Actually Matter — SEO (Core Web Vitals as a ranking factor, crawlability, metadata & structured data, organic traffic, impressions, keyword rankings, CTR) plus acquisition and growth (CAC, LTV, attribution, ROAS).
- Measuring Product: Metrics That Actually Matter — conversion & funnel, engagement, activation, feature adoption, stickiness, and retention.
This post zooms in on the frontend. It's one stop on a broader tour — for the full picture across delivery, reliability, quality, and the rest, see Measuring Software Engineering: Metrics That Actually Matter, and for measuring team and individual performance without gaming it, see Measuring the Immeasurable.
