The short answer
- Bytes, source pixels and rendered size answer different questions.
- Responsive candidates and device density prevent a simple one-to-one width rule.
- A static HTML scan finds candidates; runtime and field tools verify impact.
On this page
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.
Prioritize an inventory by ownership and page use
A useful list names the component that references each resource and whether you can replace it. A first-party hero can require an asset and template change; a third-party widget can require configuration or removal. Separate those tasks rather than preparing a replacement bundle for resources your site does not control.
Group variants of the same photograph and avoid counting every srcset candidate as a simultaneous browser download. Preserve alternate crops as distinct editorial uses. Start with important first-view assets and repeated oversized components, then work through less critical content. A prioritization label is a planning aid, not a measured Core Web Vitals severity score.
Close the audit with a live-resource check
Record the page, viewport, selected source, observed bytes, and proposed change. A static scan can help discover URLs, but a browser confirms the resource selected for a particular layout. If the scanner cannot obtain a value, mark it unknown instead of zero. Keep limits and truncation information beside the result.
After deploying the approved replacements, repeat the same navigation. Check the selected URLs and visible quality before comparing scores. A downloaded ZIP does not update the site. Document the template changes and preserve originals so a future content upload can follow the same standard rather than reintroducing the heavy source.
Sources and further reading
Technical references for the concepts in this guide. Examples with hypothetical values are illustrations, not measured results.
