Measure the weight of a page and its resources

How to use the tool

Paste the URL of a page and click “Analyse”. The server reads the page, following up to five redirects, then lists the files its HTML declares: images (src, srcset and the sources of a picture element), scripts, style sheets, preloads, preloaded fonts, icons and video posters. It then queries up to 40 files in parallel, with a HEAD request that only asks for the headers. It switches to GET, without reading the body, when a server refuses HEAD or when its HEAD response does not give the compression of a text file or the size of a file. This step takes at most 7 seconds.

The result gives the total announced weight, its breakdown by type and the ten heaviest files, then four lists: text sent without compression, heavy images in an older format, static files without Cache-Control and files in error. Below them, the detail of every file checked: HTTP code, type, size, encoding and Cache-Control. When a page declares more than 40 files, the tool checks style sheets, scripts and fonts first, then images that are not lazy-loaded. The URL you analyse is not stored.

Total weight and the Lighthouse benchmarks

Lighthouse, Google’s audit tool built into Chrome, adds up the size of every request a page makes in kibibytes (1 KiB is 1,024 bytes) and lists the largest first. It flags pages above 5,000 KiB and recommends staying below 1,600 KiB, a target based on what a 3G connection can download while keeping Time to Interactive at 10 seconds or less. The same page puts the median payload between 1,700 and 1,900 KiB, based on HTTP Archive data.¹ This documentation was last updated in May 2019: the median dates from then.

The tool compares its total with these two benchmarks, but it only sees part of the files, as the last section explains. Lazy-loaded images are counted although the browser may only load them on scroll, and the tool says how many there are. The total is therefore an order of magnitude, to be confirmed with the PageSpeed speed test, which loads the page in a real browser.

Text sent without compression

HTML, CSS, JavaScript, SVG and JSON compress well. MDN asks servers to compress data as much as possible, and advises against compressing formats that are already compressed, such as JPEG or ZIP, which can make the file bigger. The server states the method it used in the Content-Encoding header: gzip, deflate, br (Brotli) or zstd (Zstandard), among others.⁶ Lighthouse treats as uncompressed the responses without a Content-Encoding of br, gzip or deflate. It recommends Brotli, keeps gzip as a fallback, and flags neither a response under 1.4 KiB nor a saving under 10% of the original size.²

The tool uses the same 1.4 KiB threshold. It cannot compute the saving, since it does not read the file: it flags every text file over 1.4 KiB that arrives uncompressed, and those whose size is not announced. It counts zstd as compression, since MDN describes it as such, while the older Lighthouse page does not mention it.^{2, 6} Its request announces br, gzip, deflate and zstd in the Accept-Encoding header.

Images in older formats

Lighthouse collects the BMP, JPEG and PNG images of a page, converts them to WebP, estimates their AVIF size and reports the potential saving. It leaves out any image whose saving would be under 8 KiB, and advises keeping a JPEG or PNG fallback for older browsers.³ For GIFs, it recommends MP4 or WebM video for animations and PNG or WebP for still images.⁴

The tool does not convert images. It flags JPEG, PNG, BMP and GIF files over 8 KiB, since a smaller file cannot save 8 KiB, except when the image sits in a picture element that already offers an AVIF or WebP version. It also checks srcset candidates and picture sources without adding them to the total: the browser downloads only one per image, depending on the screen. To examine a single file, the image dimensions and metadata tool reads its real type, its size in pixels and the data it carries.

Files without Cache-Control

Lighthouse considers a file cacheable when it is a font, image, media file, script or style sheet, answers 200, 203 or 206 and has no explicit no-cache policy. It gives the example of Cache-Control: max-age=31536000, one year, for static files that do not change, with a hash in the file name so that each version gets its own URL, and recommends no-cache for a file that changes and whose freshness matters.⁵

Without Cache-Control, MDN points out, caches may keep the response for a lifetime they choose themselves: this is heuristic caching, and MDN advises stating your requirements in that header.⁷ The tool therefore flags static files without Cache-Control and says when an Expires header is there instead. It does not judge the duration chosen, as Lighthouse notes that a longer duration is not always better.⁵ To read every header of a file, ETag and Last-Modified included, use the HTTP header checker.

What the tool sees, and what it does not

The tool reads the HTML as the server sends it, without running JavaScript. It therefore misses whatever scripts load afterwards: ads, analytics, embedded videos, images added by a carousel or a JavaScript application. It also misses background images declared in style sheets, and fonts they call without a preload in the HTML. A file whose host points to a private or local address, or that uses a port other than 80 and 443, is refused before any connection and listed as an error.

The size shown is the one the server announces in the Content-Length header. When the file is compressed, it describes the encoded form that is sent: the decompressed file is larger.⁶ A server that sends no Content-Length leaves the size unknown, and the file is left out of the total. Finally, the request comes from the nemociment.fr server: depending on its configuration, a server may answer your browser with another format or another compression.

Frequently asked questions