Core Web Vitals analytics with real product context
Measure LCP, INP and CLS from real visitors, then connect slow experiences to pages, devices, funnels and conversions without collecting personal data.
Core Web Vitals summarize loading, interaction responsiveness and visual stability. They are most useful when they remain attached to a normalized page, device class, sample count and product outcome. A single site-wide score can hide both an excellent landing page and a broken checkout.
MetricFold captures real-user observations through browser performance APIs. It does not run a synthetic lab inside every visit, store raw URLs or attach performance to a durable anonymous profile.
The three measurements answer different questions
Largest Contentful Paint measures when the main visible content finishes rendering. Interaction to Next Paint measures responsiveness across user interactions and reports a high-percentile experience. Cumulative Layout Shift measures unexpected visible movement.
Time to First Byte is not a Core Web Vital, but it helps separate server and network delay from rendering work. Add it as diagnostic context rather than combining it into a made-up score.
Use the definitions and thresholds published by the Web Vitals project. Keep the measurement library version visible because browser support and implementation guidance evolve.
Report distributions, not only averages
An average can look healthy while a valuable device group suffers. MetricFold reports a p75 observation with the number of samples for each normalized path and metric. It also preserves a bounded distribution for investigation.
Do not compare tiny groups as if they were stable. A page with six samples does not deserve the same confidence as a page with six thousand. The dashboard should say when a result is sparse or truncated.
Separate device categories and meaningful page templates before inspecting individual URLs. Dynamic identifiers, query strings and fragments create cardinality without explaining performance.
Join speed to intended value
A slow page matters when it changes experience, accessibility or outcomes. Compare performance for visitors who completed a funnel step with those who did not. Look for concentration by browser, device, country-level region, release annotation and entry page.
This is observational evidence. Visitors on constrained networks may both experience slower pages and convert differently for unrelated reasons. Use the result to identify a reproduction matrix, then validate a fix with controlled lab measurements and a before-and-after release comparison.
For interaction responsiveness, keep the stable control identifier when the product supplies one. Never capture the visible label or full DOM target. A report that says checkout.submit had poor INP on mobile Safari is actionable without retaining the form contents.
Protect host-page performance
An analytics tracker should not materially worsen the metrics it measures. MetricFold uses a framework-free 0.32 kB gzip loader that queues calls and starts its complete runtime asynchronously, outside the critical rendering path. It batches transport work, avoids replay snapshots, does not fingerprint and treats collector failure as non-blocking.
The reference integration uses a deterministic Lighthouse fixture before and after installation. This proves the package stays within its own request, execution, long-task and layout-shift budgets under controlled conditions. It does not promise that every host application will receive a perfect score; the host's assets and runtime still determine the result.
Investigate by layer
When LCP regresses, inspect response time, render-blocking resources, image priority and client rendering. When INP regresses, inspect long tasks, event work, synchronous layout and the state update caused by the slow control. When CLS rises, inspect late dimensions, font swaps, inserted banners and animation.
Place release and incident annotations on the same time series. A sudden change aligned with a deploy is a stronger lead than a slow drift, although it still needs reproduction.
A practical performance review
Use a weekly review that answers:
- Which sufficiently sampled page templates crossed an investigation threshold?
- Is the slow tail concentrated by device or browser?
- Which funnel or product actions occur on those pages?
- Did conversion, abandonment, errors or support contacts move with performance?
- What changed in code, infrastructure, content or third-party scripts?
- Which controlled test will confirm the likely cause?
Keep performance beside behavior instead of exporting it to an engineering-only dashboard. Product, growth and engineering should see the same definition and reporting window.
Build a repeatable diagnosis worksheet
Begin each investigation with a page template, metric, percentile, sample count, reporting window and affected segment. Record the release boundary and the product action that happens on the page. This prevents an attractive site-wide average from replacing a reproducible performance question.
Diagnose LCP by its phases
Break the observed delay into server response, resource discovery, resource load and element render delay. The web.dev LCP guide explains these phases and common causes. If the resource is discovered late, inspect markup and priority. If it loads quickly but renders late, inspect client hydration, CSS, fonts and main-thread work. A CDN change cannot fix an element waiting behind application JavaScript.
Compare real-user evidence with a controlled trace on the same template and device class. Real-user measurement establishes prevalence; the trace provides the call stack and network waterfall required to repair it.
Diagnose INP from the actual interaction
The INP guidance treats input delay, processing and presentation delay as parts of the interaction. Retain the privacy-safe semantic control id and route template so an engineer can reproduce the interaction without collecting visible labels or input values. Look for long tasks, synchronous state work, expensive layout and third-party handlers.
Do not optimize only the median. A responsive majority can coexist with a severe tail on low-memory phones. Compare p75 with the distribution and eligible sample count, then segment only when the remaining group is still large enough to guide a decision.
Diagnose CLS from page lifecycle
Identify when shifts occur: initial load, hydration, consent UI, asynchronous content, font swap or interaction. The CLS reference distinguishes expected shifts associated with recent input from unexpected movement. Preserve dimensions for media and embeds, reserve space for late content and avoid inserting controls above the user's current reading position.
Connect regression evidence to product impact
| Signal | Supporting segment | Product evidence to compare | First reproduction |
|---|---|---|---|
| LCP p75 rises | Entry page + mobile network/device class | Bounce, CTA visibility and signup start | Cold load with production asset priorities |
| INP p75 rises | Semantic control + browser | Repeated click, abandonment and completion | Recorded performance trace for that action |
| CLS rises | Template + release annotation | Dead clicks and unexpected navigation | Slow load with layout-shift regions visible |
| TTFB rises | Country group + route template | All downstream web vitals | Origin, cache and database timings |
Correlation directs the investigation; it does not establish that speed caused the outcome. Validate a repair by shipping the smallest change, confirming the technical metric moved, and checking that the intended product guardrail did not regress. The friction analytics guide provides the companion interaction signals, while funnel analytics supplies the ordered outcome definition.
Keep collection within a strict budget
Measure transfer size, compressed size, execution time, long tasks, requests and layout shifts for the analytics client itself. Test a deterministic page with and without the tracker. Run the same fixture in CI and preserve the evidence with the release. Browser support and bundling can change even when feature code appears small.
The Performance Observer API can deliver entries without polling, but implementations still need feature detection and error isolation. The MDN PerformanceObserver reference documents the browser surface; unsupported observations should disappear cleanly rather than breaking the host application.
No global score proves every customer site will retain 100 in PageSpeed Insights. The defensible promise is a published tracker budget, non-blocking loading, no layout UI, bounded observers and a host-site before/after check.
Frequently asked questions
Is a lab Lighthouse score the same as real-user Core Web Vitals?
No. A lab run is a controlled diagnostic sample. Field analytics aggregates eligible observations from real environments. Use field data to prioritize and lab traces to reproduce.
Why show p75 instead of only an average?
A percentile describes the experience threshold for a share of observations and is less likely than an average to hide a slow tail. Always show the sample count and window beside it.
Does MetricFold store the element text that caused a slow interaction?
No. A product can supply a stable semantic control identifier. The report can connect that id to path, browser and outcome without retaining DOM copy or form contents.
What should be fixed first?
Prioritize sufficiently sampled regressions on high-value journeys, then select the earliest technical bottleneck that a controlled trace can reproduce. Avoid fixing a site-wide score without a page and interaction hypothesis.