Performance
/dashboard/<siteId>/performance — how fast the site was for the people who
actually loaded it. Every number is a 75th percentile (p75): the value that
three quarters of page loads beat, which is how Core Web Vitals are meant to
be read.
Five vitals, one tile each, computed over the current range and the filters this screen honours.
| Tile | Measures | Good | Poor |
|---|---|---|---|
| LCP | Largest Contentful Paint: when the biggest thing above the fold rendered | ≤ 2.5 s | > 4 s |
| INP | Interaction to Next Paint: the slowest response to a tap, click or key press | ≤ 200 ms | > 500 ms |
| CLS | Cumulative Layout Shift: how much the page moved while it loaded | ≤ 0.1 | > 0.25 |
| FCP | First Contentful Paint: when anything rendered | ≤ 1.8 s | > 3 s |
| TTFB | Time to First Byte: how long the server took to start answering | ≤ 800 ms | > 1.8 s |
Between good and poor is Needs work. The thresholds are Google’s published ones.
Each tile shows:
- the p75 for the range, with a Good, Needs work or Poor chip;
- a bar splitting every load that reported the vital into the three ratings;
- a delta against the previous period. Lower is better for every vital, so a drop is green;
- how many page loads the number rests on.
Click a tile to plot it. Which tile is selected is local state, not part of the URL.
The selected vital’s p75 per bucket. Buckets follow the range exactly as on
Overview: hours for today,
yesterday and 24h; days for 7d, 30d, 90d, week and month;
months for 12m. A bucket with no loads is a gap, never a zero, and the line
is drawn across it.
The legend under the chart repeats the thresholds for the vital in view.
Breakdowns
Section titled “Breakdowns”Two panels, both following the selected tile.
| Panel | Tabs | Rows fetched |
|---|---|---|
| Pages | one, by path | 30 |
| Audience | Device / Country / Browser / OS | 6 / 30 / 10 / 10 |
Rows are ranked by number of loads, not by how slow they are, so a page seen twice with a terrible LCP does not outrank the home page. Each row shows the loads behind it and the selected vital’s p75, coloured by rating. Eight rows are shown, with Show all to expand.
Every row is a link. Clicking Mobile under Device writes device=mobile
into the URL and re-reads the whole screen for mobile loads, the same
drill-down model as everywhere else.
Filters
Section titled “Filters”The vitals report carries fewer dimensions than an event, so only these
filter keys apply here: path, country, device, browser, os and
hostname. Any other chip in the filter bar (a referrer, a campaign, a goal)
is ignored on this screen rather than emptying it.
Where the numbers come from
Section titled “Where the numbers come from”The tracker measures every vital itself, with the browser’s
PerformanceObserver. There is no extra library to install and nothing to
configure.
- One report per real page load. It is sent once, when the page is first
hidden or closed, over
sendBeaconso it survives the tab going away. - LCP is the last candidate before the first interaction; after a click, tap or key press it stops updating, as the specification requires.
- CLS is the largest 5-second session window of layout shifts with no more than a 1-second gap between shifts, ignoring shifts within 500 ms of an input.
- INP is the slowest interaction on the page, ignoring one outlier for every 50 interactions.
- FCP and TTFB are read straight from the paint and navigation timing entries.
- Single-page apps report once per real navigation. A client-side route change does not produce a new report: LCP, FCP and TTFB only exist for a page the browser actually loaded, and the report is filed under that landing path.
Empty state
Section titled “Empty state”Until the first report arrives for the range, the screen shows the snippet for the site and the five thresholds. A brand-new install usually reports within a minute of the first visitor leaving the page.