Two performance checks were not run for this scan

**What was not measured.** Two checks, and only two. *Images larger than their displayed size* compares each image's intrinsic dimensions with the box it is actually painted into, which requires a layout — the served HTML does not say how large anything ends up on screen. *Unused JavaScript* compares the bytes shipped with the bytes that executed, which requires a main thread and a coverage profile. Neither can be inferred from what a server sends, and we do not guess at them: a plausible-looking number we did not measure is worse than an honest gap.

**Everything else in this section was measured.** Render-blocking resources, uncompressed text subresources, legacy image formats, short asset cache lifetimes and the page-weight inventory are established from the served markup and the subresource responses, with no browser involved. **How this was measured, and what it could not see.** We fetched the page and then the subresources its HTML declares, and read what the server sent back. No browser was involved, so nothing here depends on how fast our machine is — but equally, **a resource that a script loads after the page arrives is invisible to this check**. A page that assembles its own asset list at runtime will look lighter here than it is. The number of subresources the page declared, and how many of those we asked about, are both stated in the page-weight finding; where they differ, this section examined a prioritised sample rather than the whole page.

**Why the browser run is gated.** It is not a capacity rule, though it is also that. Loading a page in headless Chromium executes that site's JavaScript and profiles the result, and the two findings it produces can be acted on by the site's owner and by nobody else — a reader scanning a stranger's site cannot deploy a smaller image or split someone else's bundle. That is the same line the port check draws: an anonymous scan gets the common port list, a verified owner gets the wider one.

**How to have them run.** Prove control of the domain, then run the scan again. Verification is per-domain and offers three methods — a DNS TXT record we name, a file at a path we name, or a meta tag on the home page — through POST /v1/ownership/verifications; it is re-checked periodically and lapses when control of the domain does. A scan started with that verification carries the browser run, and this finding is replaced by the two checks themselves.