Metrics Reference
This page describes each metric Pulsecadence collects, its definition, collection methodology, and the thresholds Pulsecadence uses to classify values as Good / Needs Improvement / Poor.
Largest Contentful Paint (LCP)
Definition: The time from when the user initiated navigation to when the largest visible content element (image or block-level text) fully renders in the viewport.
Collection: Pulsecadence uses the LargestContentfulPaint performance entry type via PerformanceObserver. The final LCP value is the last entry before the user first interacts with the page (click, key, or scroll). For SPA navigations, a new LCP observation window starts after each route change.
Thresholds:
| Value | Classification |
|---|---|
≤ 2,500 ms | Good |
2,500 – 4,000 ms | Needs Improvement |
> 4,000 ms | Poor |
Why p75: Pulsecadence uses p75 as the primary reporting percentile for LCP. The p75 means 75% of your real users experienced LCP at or below this value — which also means 1 in 4 sessions was at or above it. This directly correlates with bounce probability on slow connections.
Interaction to Next Paint (INP)
Definition: The p98 interaction latency across all user interactions (clicks, taps, and key presses) in a session. It represents the responsiveness of your page to user input throughout the entire session lifecycle.
Collection: Uses the PerformanceEventTiming API. Pulsecadence records all interactions with duration > 40ms, then takes the p98 across the session to derive the per-session INP value.
Thresholds:
| Value | Classification |
|---|---|
≤ 200 ms | Good |
200 – 500 ms | Needs Improvement |
> 500 ms | Poor |
Cumulative Layout Shift (CLS)
Definition: A measure of visual stability. CLS quantifies how much the page layout unexpectedly shifts during the lifetime of the page, using an impact fraction × distance fraction formula.
Collection: Uses the LayoutShift performance entry type. Pulsecadence records individual shift events with their element attribution and aggregates into the session CLS score.
Thresholds:
| Value | Classification |
|---|---|
≤ 0.1 | Good |
0.1 – 0.25 | Needs Improvement |
> 0.25 | Poor |
Time to First Byte (TTFB)
Definition: The time from the start of navigation to when the first byte of the HTML response is received. TTFB captures server processing time and network latency to the nearest edge node.
Collection: Uses the PerformanceNavigationTiming entry: responseStart - requestStart.
Thresholds:
| Value | Classification |
|---|---|
≤ 800 ms | Good |
800 – 1,800 ms | Needs Improvement |
> 1,800 ms | Poor |
Custom timing marks
Definition: Any performance.mark() call made by your application code. Pulsecadence automatically captures these alongside Core Web Vitals.
Collection: Uses PerformanceObserver with the mark entry type. Mark values are the timestamp in milliseconds from navigationStart. Pairs of marks with the same prefix are automatically diffed to compute duration metrics (e.g. hydration-start / hydration-end produces a hydration duration metric).
Usage:
performance.mark('data-fetch-start');
await fetchUserData();
performance.mark('data-fetch-end');Both marks appear in the dashboard individually, plus a derived data-fetch duration metric at p50 / p75 / p95.