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, reliability, SEO, and engagement signals that live right next to performance. Here's the whole set 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. Below, anything in the second bucket is flagged with a Disclaimer.
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.)
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.
- 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).
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 — a controlled run | Real User Monitoring: actual visitors, e.g. CrUX |
| 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 |
These are usually captured by RUM / error-tracking tools (Sentry, and the browser's own error and Resource Timing APIs). 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.
SEO: the frontend's slice
A chunk of SEO is frontend work, so parts of the SEO metric set land squarely on a frontend team — while others are pure growth outcomes the frontend only influences.
Frontend-owned:
- Core Web Vitals as a ranking factor. Frontend performance isn't only a UX concern — CWV are a Google ranking factor. Poor field CWV can suppress your ranking, which suppresses impressions, which suppresses organic traffic. The chain runs straight from a slow LCP to fewer visitors, so frontend performance work is also SEO work.
- Crawlability & rendering. Whether Google can see your content depends on the render strategy — SSR / static HTML is reliably crawlable, heavy client-side rendering (CSR) can hide content behind JavaScript. Indexed-page count and crawl errors are the signals here.
- Metadata & structured data. Titles, meta descriptions, canonical tags, Open Graph, and schema.org markup are all frontend output, and they shape how — and whether — a result shows up.
| Metric | What it measures | Frontend's role |
|---|---|---|
| Organic traffic | Visitors from unpaid search | Influenced, not owned — outcome metric |
| Impressions | How often you appear in results | Influenced via CWV + crawlability |
| Keyword rankings | Position for target terms | Mostly content/authority; frontend affects via CWV |
| CTR (click-through rate) | Clicks ÷ impressions | Partly frontend — titles, meta descriptions, and structured data (rich snippets) are markup you own |
Disclaimer. Organic traffic, impressions, and keyword rankings are outcome metrics — the frontend moves them indirectly (through CWV and crawlability) but doesn't measure or own them; they belong to a growth/content function. CTR sits on the boundary: the markup is yours, the demand behind it isn't.
Conversion & funnel
Conversion metrics measure whether visitors do the thing you want. The frontend heavily influences them — page speed, form UX, layout stability, and dead-end friction all move the number — but they're product/growth metrics, not frontend-health metrics.
| Metric | Definition |
|---|---|
| Conversion rate | % of visitors completing the goal action (signup, purchase) |
| Funnel drop-off | Where in a multi-step flow users abandon |
Disclaimer. These are business outcomes measured in the browser. A frontend team should watch them (a slow or janky step shows up as drop-off there), but the goal, the offer, and the pricing behind the funnel aren't frontend concerns. Treat them as a place your performance and a11y work shows up, not as a scorecard for the frontend itself.
Engagement signals
Two frontend-facing engagement metrics sit close to performance, but they're direction-ambiguous — you have to interpret them against what the product is for:
- Bounce / exit rate — % of users leaving after one page, and where they leave. Reads as friction and dead ends.
- Session duration & depth — time per session, and pages/actions per session. A longer session is good for a game or social app and bad for a checkout flow or support tool, where the goal is to get users done fast. Never assume "more time on site" is a win.
Beyond these, the broader product-analytics set — activation, feature adoption, stickiness (DAU/MAU), retention — is almost always captured by frontend event tracking (the instrumentation is yours to build and keep honest).
Disclaimer. Activation, adoption, stickiness, and retention are product metrics that merely fire from frontend code. They tell you whether the product delivers value, not whether the frontend is fast, accessible, or reliable. The frontend's stake in them is the instrumentation quality (events firing correctly, no double-counting), not the numbers themselves.
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.