It makes a single server-side fetch of the page and records two things: how long the full HTML took to arrive, and how many kilobytes of it there were, uncompressed. Fetch time is scored against 500 ms, 1.5 s, 3 s and 6 s bands; HTML weight against 100, 300, 700 and 1,500 KB. The overall score is the average of the two. Because the fetch goes through our rendering service, the time includes a little of that service's own overhead — treat it as a ceiling on your server's real time to first byte rather than an exact figure.
What it is not: this is not Lighthouse, PageSpeed Insights, or a Core Web Vitals report. It does not load images, scripts, fonts or stylesheets, and it cannot measure Largest Contentful Paint, Cumulative Layout Shift or Interaction to Next Paint — those need a real browser rendering the page. Use this to catch a slow origin or a bloated HTML document in a few seconds; use a lab or field tool for the full picture.
How to fix what it finds
- Slow fetch time — cache rendered pages at the CDN or in the framework (full-page caching, static generation, ISR), take slow database queries out of the request path, and keep the origin close to a CDN edge. A cold serverless function or an uncached dynamic render is the usual culprit on modern stacks.
- Heavy HTML — look for data that has been inlined: base64 images, large inline SVGs, hydration payloads (
__NEXT_DATA__,__NUXT__) that duplicate the rendered content, and inline<style>or<script>blocks that belong in cacheable external files. Make sure gzip or Brotli compression is on, but fix the source too — the browser still parses the full document.