Short answer: For each image, compare its rendered CSS size and device-pixel ratio with the selected resource’s intrinsic dimensions, then examine transferred bytes, format, quality, and cache status. Aggregate the excess by component and page template so fixes target systems, not isolated files.
An image can be wasteful in several ways. It may contain far more pixels than the slot needs, use an inefficient format, carry unnecessarily high quality, include unneeded metadata, or miss the cache. One number cannot diagnose all of them.
What should you capture in the browser?
Record the page URL, image element or component role, rendered width and height, device-pixel ratio, currentSrc, intrinsic width and height, encoded content length, transferred bytes, content type, loading priority, and timing. Also capture whether the image was the LCP element.
The selected resource’s intrinsic dimensions can be compared with rendered dimensions multiplied by DPR. If a 400 CSS-pixel slot on a 2x device receives a 1600-pixel-wide file, the dimensional ratio is 2 relative to the 800-pixel physical need. That does not translate directly into twice the bytes because content and encoding matter, but it identifies a sizing problem.
MDN documents currentSrc, naturalWidth, and related properties on HTMLImageElement. Browser performance APIs and developer tools can provide timing and transfer information, subject to cross-origin timing permissions.
How do you estimate avoidable bytes?
The most reliable method is to generate an appropriate comparison derivative for the actual slot, using the same crop, format, and quality policy. Compare its encoded size with the selected response. The difference is a concrete opportunity rather than a geometric guess.
At scale, you can approximate dimensional waste from area ratio and flag large outliers for exact regeneration. Do not claim that halving width always quarters transfer size; image entropy, format headers, encoder settings, and responsive crop all affect the result.
Separate cache transfer from representation size. A browser memory-cache hit may transfer zero bytes but the underlying resource can still be oversized for first-time visitors. Record encoded object bytes as well as observed network transfer.
Which root causes should reports distinguish?
Classify oversize selection, missing responsive candidates, inaccurate sizes, source upscaling, format fallback, excessive quality, cache miss, and duplicate request. Each maps to a different owner and fix.
Oversize selection often points to the sizes attribute or a sparse width ladder. Too many near-identical variants points to variant explosion, not insufficient candidates. A heavy correctly sized image may need format or quality work.
Duplicate requests can come from a preload that does not match final markup, a URL mutation during hydration, or two visually overlapping elements. A waterfall view is more informative than a byte inventory in that case.
Lab audit or field measurement?
Use both. Lab runs provide detailed, repeatable traces across chosen viewports, DPRs, and network conditions. They make it easy to inspect markup and test a candidate fix. Field data reveals the actual distribution of layouts, devices, routes, and cache states.
Google’s Lighthouse documentation describes its properly size images audit, which is a useful diagnostic starting point. Do not stop at the score; trace flagged resources back to the component and delivery policy.
In field monitoring, sample image observations to control volume. Aggregate by stable component name and preset, not by full signed URL. Full URLs can have high cardinality and may contain sensitive tokens.
How do you prioritize fixes?
Estimate total impact as avoidable bytes per view multiplied by affected page views, then consider whether the image is render-critical. A moderate saving on the LCP image may be more valuable than a larger saving far below the fold. Also prioritize systemic fixes that improve many assets.
Start with wrong sizes, missing candidates, and unconstrained sources. Then review format and quality. Finally address smaller metadata opportunities. This order tends to deliver meaningful savings without lowering visible quality.
Segment by mobile and desktop. An average can hide a mobile layout that routinely downloads desktop candidates. Review upper percentiles and top offending templates, not only the global mean.
How do you prove the fix worked?
Repeat the same lab scenarios and compare selected URLs, intrinsic dimensions, bytes, and timings. Confirm that visual quality and layout stability remain acceptable. Then watch field distributions after rollout.
Use versioned transformation URLs so old cached objects do not contaminate the comparison. Track cache hit ratio and cold-transform rate; a new policy that saves bytes but creates many one-off derivatives may shift cost elsewhere.
Image payload waste becomes manageable when it is described as a chain of evidence: slot, selected candidate, representation, transfer, and page role. That evidence points directly to the responsible component, markup rule, or image policy.
Leave a Reply