Auditing Every Image Request: What We Found on Our Own Pages

A performance score tells you that something is slow. A request audit tells you which file, how big it is, when it starts and why it was requested. What does an image-request audit find on a real site, and how do you run one? We audited our own pages right after this site’s redesign, found one image responsible for more than two thirds of a guide’s weight, fixed it, and measured again. This guide shows the numbers and the method.

What we audited and how

Four pages of this site: the home page, the guide index, our format comparison and our lazy-loading guide. Each was loaded in Chrome 155 on a phone viewport (390 × 844 at 3× density) and a desktop viewport (1440 × 900), with the cache disabled and our slow mobile network profile. After the page had loaded, the script scrolled to the bottom in half-screen steps so that lazy images were requested too, then waited three seconds.

The data comes from the Chrome DevTools Protocol, the same source the DevTools Network panel reads: for every request we stored the URL, type, initial priority, start and end time, transferred bytes and, for images, the size the image was displayed at. We also noted which requests happened before any scrolling. Our methodology describes the network profile.

The main finding: one image was two thirds of the page

On a phone, the format-comparison guide transferred 1,381 KB after a full scroll. Our own images made up 1,019 KB of that, and a single file accounted for 937 KB: the panel of 100 % crops comparing JPEG, WebP and AVIF on a feather photograph. We had saved it as lossless WebP so that the comparison would not add compression artefacts of its own, and fine feather texture is exactly what lossless compression handles worst.

The fix was the same advice our guides give. The panel shown in the article is now a WebP at quality 90 (239 KB), and the lossless original is one click away for anyone who wants to inspect the artefacts pixel by pixel. The page dropped to 683 KB on a phone (−51 %) and 631 KB on desktop. Four other comparison panels on the site got the same treatment.

Reading the waterfall

The waterfall after the fix shows the page in the order the browser built it. The HTML document arrives first, then the stylesheet and three self-hosted font files (about 65 KB together). The advertising scripts follow, with the largest single script request on the page at 187 KB. Our five images are only requested as the reader scrolls, because all of them sit below the first screen and carry loading="lazy". None of them blocks the first view.

What the other pages showed

• Home page: 17–18 images on desktop for 169–173 KB, and 15 images for 471 KB on a phone after scrolling to the end. Every image was WebP with a srcset. The first result chart was requested at High priority and eagerly, the rest lazily. On the 3× phone, card images of 348 CSS pixels needed 1,044 device pixels, so Chrome chose the full 1,200-pixel files, as the srcset logic in our high-DPI test predicts.
• Guide index: on desktop, all 16 card images were requested at load time even though they are lazy, because the whole grid fits within the distance Chrome loads ahead (about 1,250 pixels, as we measured in a separate test). Together they weighed 103 KB.
• Advertising: every page transferred about 274 KB of advertising scripts on desktop, the same amount whatever the content. On a page without heavy images, that is more than our own HTML, CSS, fonts and images combined.

What the audit would have found before the redesign

We ran the same audit on the previous version of the site, a day before the relaunch. Without scrolling, the guide page requested none of its own images at all: the old guides had a single lazy-loaded figure at most, and their weight was almost entirely the 281 KB of advertising scripts. A lighter page is not automatically a better one; it had less to show. The point of an audit is to make sure the bytes a page does send are the ones that carry its content.

How to run the same audit in Chrome DevTools

1. Open the page in a private window so that extensions and cached files do not interfere, then open DevTools (F12) and the Network panel.
2. Tick Disable cache, choose a throttling profile such as Fast 4G or Slow 4G, and turn on device emulation for a phone.
3. Reload, wait, then scroll slowly to the end of the page so that lazy images load.
4. Filter by Img and sort by the Size column. Add the Priority column from the column menu.
5. For the largest images, hover the name to see the rendered size and the file’s real size, or select the image in the Elements panel and compare $0.currentSrc with its displayed width multiplied by devicePixelRatio.
6. Remove the filter and look at third-party requests too: on many sites they are the largest single block.
7. Save the log with Export HAR if you want to compare before and after, but keep HAR files private: they can contain cookies and personal data.

Practical conclusion

• Audit with a full scroll. Our heaviest file was lazy-loaded and would not appear in a load-only audit or in most automated scores.
• Sort by size first. One file was 68 % of the page’s weight; fixing it halved the page.
• Check the format choice for each kind of image, not only for photos. A lossless format that is right for a screenshot can be the wrong choice for a photographic panel.
• Look at third-party bytes separately, so you know which part of the page you control.

Limitations

Four pages of one site, one browser and a simulated network. Advertising requests vary between loads and visitors, and the audit does not measure their effect on timing in detail. Image byte counts include HTTP headers, so they can differ by a few hundred bytes from the file sizes on the server.

Data and files

Download devtools-audit-after.csv (220 rows, 32.2 KB) · Download devtools-audit-afterfix.csv (108 rows, 15.8 KB) · Download devtools-audit-before.csv (86 rows, 12.1 KB) · Method: testing methodology.