Technical
Page Speed Grader
A lab score and the field data, kept apart
Enter a URL and get a lab run on a throttled connection: a score, the metric behind each part of it, the element that was the LCP, and separately the Core Web Vitals field data where enough real users exist to report it.
Get early accessWhat it returns
- A lab score from one simulated load, with the device class and the network throttling it ran under stated next to it rather than buried.
- Every metric that fed the score as a number: Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time and the rest, with the weight each carries.
- The specific element that was measured as the LCP, and the elements that moved during layout shift, because the fix is in the markup and never in the score.
- Core Web Vitals field data in its own section, labelled as measurement from real users, with an honest blank when the URL has too little traffic to report.
When this matters
A developer ships an image fix, the lab score jumps from the fifties to the high eighties, and Search Console still reports the URL group as failing Core Web Vitals a month later. Both readings are correct. The score came from one simulated load on a throttled connection in a datacentre. The assessment Google uses comes from a rolling window of measurements taken in real browsers, on real devices and real networks, including the slow ones. The lab run is a diagnostic that tells you which element to fix. It is not the thing being graded, and optimising the score instead of the experience is how a team spends a quarter moving a number nobody is measured on.
How to answer this today
Site audit works through performance across the site rather than one URL at a time, which matters because the slow thing is usually a template rather than a page, and because Core Web Vitals get assessed across groups of similar URLs. Checking one page on demand, including a competitor's, is the quick version of the same question and needs no project set up first.
Site auditWhy this is harder than it looks
Lab data is not field data
Core Web Vitals are assessed on measurements from real users. A lab run is a simulation with fixed throttling on hardware you do not own. A page can score well in the lab and fail the field assessment, or the reverse, and when they disagree the field data is the one describing what people experienced.
Lab runs move on their own
Run the same URL twice and the score shifts, sometimes by several points, depending on the machine, the network, and which third-party scripts happened to answer quickly. A single run is one sample. Treating a small difference between two runs as the result of a change is the most common misreading there is.
Field data has a traffic floor
Real-user data only exists where enough visits have been recorded. Many URLs have none and are only represented at origin level, and the window is rolling, so a fix shipped today cannot appear for weeks. A grader that invents a field reading for a quiet page is making it up.
A composite score hides the cause
The grade is a weighted blend, so one metric moving can swing it while the page feels identical, and two pages with the same score can be slow for entirely different reasons. The individual metrics and the element behind each one are the output worth reading. The number is just the headline.