Measure three different things
File bytes affect transfer and decode work. Intrinsic width and height describe the source pixels. Rendered dimensions describe the space the browser gives the image in the layout.
A 2400-pixel image rendered at 400 CSS pixels may be oversized, but device pixel ratio and responsive variants matter. The goal is not to force every source to equal its CSS width; it is to serve an appropriate candidate for the display conditions.
| Signal | What it tells you | What it cannot prove alone |
|---|---|---|
| Transfer bytes | Network weight | Whether dimensions are appropriate |
| Intrinsic size | Available source pixels | Actual rendered size |
| Rendered size | Layout footprint | Which responsive candidate downloaded |
| width / height | Reserved aspect-ratio space | Visual quality or byte efficiency |
A candidate, not a verdict
Consider a card image declared as 1600 × 1200, transferred at 420 KB and rendered around 360 × 270 CSS pixels. It deserves inspection: resize or add a `srcset` candidate near the required density, then encode and measure again.
By contrast, a 180 KB hero rendered across a 1440-pixel desktop may be dimensionally appropriate even though it is the largest image on the page. Priority depends on user-visible position, responsive behavior and field performance—not rank by bytes alone.
A disciplined audit loop
CompressByURL's scanner parses one public HTML response without executing scripts. It is useful for discovery, but it cannot see every client-rendered image or reproduce a user's full runtime environment.
- Check `<img src>`, `srcset`, `<picture>` sources, lazy-load attributes, preloads and social metadata separately.
- Flag missing width and height because reserved aspect ratio helps prevent layout movement.
- Inspect the actually downloaded candidate in browser developer tools when scripts or responsive selection matter.
- Re-run a performance measurement after replacement; an HTML scan is not a Core Web Vitals test.