Site Speed Guide: How to Read Core Web Vitals in statpx
The Site Speed page in statpx answers a question lab tools can't: how fast does your site actually feel to the people using it? Instead of running a synthetic test from a single server, it aggregates real-user Core Web Vitals — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — from every visitor's own browser. This guide walks through what the page shows and how to read it.
It's Collected Automatically — Nothing to Configure
If you've already installed the statpx tracking snippet, Site Speed data is already flowing in. The snippet uses the browser's built-in PerformanceObserver API to capture LCP, CLS, and INP directly from each real page load, then reports them alongside your normal pageview data. There's no separate script to add, no sampling to configure, and no lab environment to set up — every visitor who loads your page silently contributes a real measurement.
Reading the Good / Needs Work / Poor Distribution
Each metric is bucketed into three tiers using the same thresholds Google uses for Core Web Vitals assessment:
| Metric | Good | Needs Work | Poor |
|---|---|---|---|
| LCP | < 2.5s | 2.5s – 4.0s | > 4.0s |
| CLS | < 0.1 | 0.1 – 0.25 | > 0.25 |
| INP | < 200ms | 200ms – 500ms | > 500ms |
The distribution bar on the Site Speed page shows what share of real visits fell into each tier over your selected date range. A healthy site should show the large majority of visits in the "Good" band. If "Poor" is more than a sliver, that metric is actively hurting user experience — and likely search ranking, since Core Web Vitals are a Google ranking signal.
LCP Trend, Slowest Pages, and Mobile vs Desktop
Below the distribution, the Site Speed page breaks the numbers down three more ways:
- LCP trend line — tracks your median Largest Contentful Paint over time, so you can see immediately whether a deploy made things faster or slower.
- Slowest pages — ranks individual URLs by their real-user LCP, so you know exactly which templates or content types need optimization first instead of guessing.
- Mobile vs desktop — splits every metric by device type. Mobile connections and CPUs are typically the bottleneck, and this view tells you whether that's true for your specific audience.
Together these views turn "the site feels slow" into a specific, prioritized list: which pages, which metric, and which device class to fix first. Pair Site Speed with your Core Web Vitals deep dive for the technical background on what causes poor LCP, CLS, and INP scores and how to fix each one.
Turning Slow Pages Into a Fix List
Once you've identified the slowest pages, cross-check them against your error tracking — a page that's both slow and throwing JavaScript errors is usually the highest-priority fix on the whole site, since it's actively breaking the experience for a real slice of your traffic. Re-check the LCP trend line a few days after any fix ships to confirm it actually moved the real-user numbers, not just your local test.
See your real-user Core Web Vitals for free
statpx collects LCP, CLS, and INP automatically from every visitor — no configuration, no sampling setup. Install the snippet and see your Site Speed dashboard within minutes.
Start for free →The Bottom Line
The Site Speed page exists so you never have to guess whether performance work is paying off. It's collected automatically the moment the tracking snippet is installed, bucketed into Good / Needs Work / Poor so you can spot problems at a glance, and broken down by page and device so you know exactly where to focus. Check it after every deploy and every redesign — real-user Core Web Vitals are the only speed number that actually reflects what your visitors experience.