A performance score can point toward a problem, but an image inventory tells you what the page actually requested. The audit should include visible content, hidden carousel slides, CSS backgrounds, third-party pixels, duplicated candidates, and files served from cache.

The decision this guide supports

Turn a Network waterfall into a prioritized image worklist with evidence for each item.

Repeatable method

1. Define the test state

Record URL, viewport, DPR, browser version, cache setting, logged-in state, and network profile. Disable extensions that inject requests.

2. Filter and export the inventory

Reload with Network recording active, filter Img, and record URL, status, type, transferred bytes, resource size, initiator, priority, and timing. Save a HAR only if it contains no private data.

3. Match requests to rendered elements

Select suspicious rows and locate the initiator or DOM element. Identify hidden, duplicated, oversized, or late-discovered images.

4. Rank changes by evidence

Prioritize large unnecessary transfers, LCP discovery delays, duplicate requests, and missing responsive candidates. Keep cosmetic format swaps below confirmed delivery errors.

Create a bounded request-audit fixture

Start with one representative page and a short, repeatable route: open a fresh private window, set the chosen viewport, reload once, and filter the Network panel to image requests. The table below is a recording template, not a benchmark. Replace every illustrative value with the request your browser actually reports.

Field Illustrative entry
Page / template /product/example/
Image request card-800.webp
Initiator img, CSS, or script
Rendered slot 320 × 180 CSS px
Transferred bytes Record DevTools value; do not estimate
Cache / priority Record displayed state and priority

Keep screenshots of the filter and selected request with the date, browser version, network profile, and cache state. A single reload only describes that run; compare later runs only when the fixture and conditions remain equivalent.

What to record

Keep a dated table with test conditions and one row per request. Add CSS slot width, intrinsic width, currentSrc, and a proposed action with an owner. Store sensitive HAR files privately.

Do not turn a lab result into a universal rule

A result belongs to the source file, encoder, settings, browser, viewport, cache state, and date that produced it. Repeat the test on representative files before changing a production workflow.

Common mistakes

  • Reading resource size when transferred size is the needed measure
  • Leaving cache state undocumented
  • Ignoring images loaded by CSS or third parties
  • Optimizing a file before confirming it is used

Verification checklist

Repeat after changes with the same conditions, confirm request count and transferred bytes, inspect LCP, test a warm-cache navigation, and crawl a second template so a local improvement does not break global delivery.

Primary references

Related lab notes

About this guide

We distinguish documented platform behavior from our workflow recommendations. See the testing methodology, editorial policy, and corrections log.