Skip to main content
Performance Auditor — flags page resources whose size is at or above a warning limit (500 KB by default) or a fail limit (1000 KB by default), both set per monitored URL.

Performance

Oversized assets delay rendering and inflate data transfer, especially on mobile.

Configurable

Both size limits are per-URL preferences, so a media-heavy site can raise them without changing the auditor.
This auditor loads the monitored page in a headless browser, collects every resource referenced by img, script, link[rel=stylesheet], video and iframe elements, and reports each one whose size is at or above the warning limit: as a warning while it stays below the fail limit, and as a failure once it reaches the fail limit.

How it works

  1. Threshold check — before loading anything, the auditor checks that sizeLimitBytesWarning is lower than sizeLimitBytesFail. When it is not, the audit fails with a single check that names both values, and nothing is measured.
  2. Page loading — opens the URL with Playwright (Basic auth is honoured) and waits for the load event. A page that answers HTTP 403, HTTP 429 or a Cloudflare challenge is reported as blocked; any other HTTP error, or a browser error, ends the audit with an ERROR.
  3. Resource discovery — reads the src / href of img, script, link[rel=stylesheet], video and iframe elements. Relative and protocol-relative URLs are resolved against the final page URL; data:, blob: and other non-HTTP URLs are skipped.
  4. Size lookup — sends an HTTP HEAD request per resource and reads Content-Length. When the answer has no Content-Length (chunked or streamed responses) or the HEAD fails, a GET downloads the body, up to sizeLimitBytesFail, and counts its bytes; a download that reaches the limit is reported as “at least” that size. Resources are measured eight at a time, each request limited to 5 seconds. A resource that neither request can size is reported as INFORMATION.
  5. Comparison — every resource whose size is at or above sizeLimitBytesFail produces one FAIL check; every resource at or above sizeLimitBytesWarning and below sizeLimitBytesFail produces one WARNING check. Each check carries the resource URL, its size and both limits in data (sizeInBytes, sizeIsLowerBound, sizeLimitBytesWarning, sizeLimitBytesFail).

Preferences

An invalid value (missing, zero, negative, fractional) makes the auditor fall back to that preference’s default and log a warning. A warning limit equal to or above the fail limit is not an invalid value: it makes the audit fail until the thresholds are fixed.

What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. Sizes are shown in MB with two decimals (1.20 MB); a size measured by a download that stopped at the fail limit reads at least 0.98 MB.

Output documentation

Risks and considerations

Large assets hurt Core Web Vitals

  • Oversized hero images and videos are the most common cause of a slow Largest Contentful Paint.
  • Big JavaScript bundles block the main thread and delay interactivity on low-end devices.

What this auditor does not check

  • Resources loaded dynamically after the load event (for example by scripts or CSS url() references) are not discovered.
  • A resource behind a slow server (more than 5 seconds per request) is reported as unmeasured rather than compared with the limits.
  • The limits apply to every resource type alike; they do not distinguish a 1 MB video from a 1 MB script.