Measure what actually slows the page down: server response time, the size of the HTML document itself, and the scripts and stylesheets blocking the first paint.
Measuring rankings in
Runs the full audit on your live site. Your report opens in your dashboard.
Four measurements of different causes. Server response time is how long your origin took to send the first byte. Page weight is the size of the HTML document alone, before images, scripts and styles, so a large number here is markup and inlined data rather than media. Render blocking counts the scripts and stylesheets that must be fetched before anything paints. Caching headers report what you told browsers and CDNs to keep.
A single speed score tells you a page is slow. These four tell you which team has the work. Slow response time is a hosting or database problem. A heavy HTML document is usually a framework inlining its state. Render blocking is a build configuration issue. Missing caching headers make every repeat visit as expensive as the first, which is invisible in a one off test and obvious in your bills.
Over 600 milliseconds to respond is a warning and over 1,500 is a failure. An HTML document over 200 kilobytes is heavy and over 500 kilobytes delays the first paint on every single visit. no-store on a cacheable page means nothing is ever cached anywhere, including your CDN, which is worth checking because it is usually a default nobody chose. Fix the response time first: everything else is measured from the moment it ends.
These four numbers are causes rather than experiences. The audit pairs them with the Core Web Vitals reading and with page weight across the crawl, so a heavy document turns out to be a layout shipping the same markup everywhere rather than one slow page.
Two response headers from a marketing page, which between them explain a slow site better than any score does.
Four hundred kilobytes of HTML before a single image, script or stylesheet, and a caching directive telling browsers and the CDN to keep none of it. Every visit, including a repeat visit thirty seconds later, pays the full cost. The weight is almost never media at this size — it is an application inlining its state into the document, a page builder's markup, or the same component chrome emitted several times. And no-store on a cacheable public page is usually a default nobody chose rather than a decision.
$ curl -sI https://example.com/
HTTP/2 200
cache-control: no-store
content-length: 412893no-store on public pages defeats your CDN as well as the browser. Long, immutable lifetimes on fingerprinted assets; a sensible revalidation policy on documents.Under 200 milliseconds is good, under 600 is acceptable, and past a second the page feels broken before it has drawn anything. This is the number your hosting and application code control directly.
Usually an application inlining its data into the page, a large piece of embedded JSON, or markup generated by a page builder. It is separate from image weight and it delays the first paint on every visit, including cached ones.
Core Web Vitals reports what visitors experienced. This reports the causes we can measure directly on the response. They answer different questions and are most useful read together.
Written up properly, for the question a result usually raises next.
More free tools in speed and security, and the rest of the set at all free tools.
Free account, no card. Paste your URL and get a real, scored report of your AI and search visibility.
Measuring rankings in