Speed

The Speed section reports how fast your site actually felt to the people who used it. The tracking snippet reads the browser's own performance timings on every page load and reports them, so this is real-user measurement, not a lab test run from a datacenter on a fast connection. Speed data is never billed as events.

The metrics

LCP, INP and CLS are Google's Core Web Vitals and are the three that count toward search ranking. FCP and TTFB are there to explain a bad score rather than to define one.

The experience score

The headline number is the share of measured page loads where every Core Web Vital that could be measured was good. 90 or above is graded good, 50 to 89 needs improvement, below 50 is poor. It is deliberately one number: a site can post a respectable average LCP while a quarter of its visits are miserable, and this is the figure that notices.

Percentiles and devices

Every figure is a percentile across the window, not an average. An average is dragged around by one very slow visit; a percentile says how many visits were at least this good.

• p75 is the default and the web standard: 3 of every 4 measured visits were at least this good. It is the same aggregate Google grades a site on.
• p50 is the typical visit; p90 and p99 are the tail, which is where the complaints come from.
• The phone / desktop switch splits the same data by device class. Most sites are two different products here, and a combined figure hides which one is the problem.

What the section shows

• Vitals at a glance: each metric with its grade against the good, needs-improvement and poor thresholds.
• Vitals over time: the score and each metric across the window, so a regression is visible as the day it happened.
• Best performers and Pages to improve: the two lists that answer "where do I start", ranked by the traffic each page carries so effort goes where it counts. Pages with too few measured visits to grade honestly are left out of both.
• All pages: the full table, sortable by any metric.
• Where it's slow: the same numbers by country, device, browser and operating system. A site that is fine at home and poor overseas has a hosting or CDN problem, not a code problem.

What is dragging it down

Alongside the scores, the tracker reports what caused them, described structurally and never personally:

• The element that became the largest paint, and its image URL where the LCP is an image.
• The element that moved in the single biggest layout shift.
• The control the slowest interaction hit, and which kind of interaction it was.
• The script that blocked the main thread longest, which is usually a third-party tag rather than your own code.

Selectors are built from tags, ids and classes only. No page text is read, and script URLs are stripped of their query strings.

Google's own view

Below the real-user report, Numative also shows the Chrome UX Report figures for the site: Google's own field data, which is what search ranking reads. It is the secondary reference rather than the headline for two reasons. It only covers Chrome, and it is a rolling 28-day average recalculated daily, so consecutive days share 27 days of the same visits and a real regression takes weeks to show. The tracker's own measurements move the day the deploy lands. Details in SEO tools.

Elsewhere in the dashboard

• The Overview closes with a compact vitals card. Filter the dashboard to a single page and it reports that page's vitals rather than the site's.
• Each page's own detail view carries its vitals and bottlenecks.
• Anomalies leads with performance regressions, since a site-wide slowdown is exactly the kind of "what moved" that view exists to surface.
• A metric changing grade plants a flag on the traffic chart, and can send an alert.
• GET /api/v1/vitals returns the whole report, with attribution=1 for the bottlenecks. See the Stats API.