Images: The Largest Bytes, Rarely the Largest Block
Images are usually most of a page's weight and rarely the thing holding up interaction. They are also where the cheapest wins live — serving a 3000px photo into a 400px slot is a mistake that costs nothing to fix and shows up immediately in LCP.
Frame the diagnosis
Performance work starts from a symptom and a signal — never from a resource dashboard.
Weight is not the same as blocking
A page can be 4MB of images and paint its first screen in under a second, or 300KB of images and take four seconds. Weight measures how much data crosses the wire in total; blocking measures what the user waited for before seeing something useful. Only the second one is a user experience.
The distinction matters because the natural instinct — sort assets by size, compress the biggest ones — optimises weight. Most of that weight is usually below the fold and lazily loaded, which means it was never on the critical path in the first place. The image that matters is the LCP element, and it is often not the largest file.
The three questions to ask about images, in order: which one is the LCP element, when was its fetch discovered, and is it being served at anything close to the size it is displayed at. Dimensions are almost always the biggest single win and the least glamorous, because the fix is a build-pipeline change rather than an interesting engineering problem.
| Lever | What it fixes | Typical effect on LCP | Cost |
|---|---|---|---|
| Correct dimensions — stop serving 3000px into a 400px slot | Enormous wasted bytes and decode work | Large, immediate | Build pipeline work; usually a one-off |
| Discovery and priority — LCP image in initial HTML, prioritised | A fast fetch that started far too late | Large, immediate | Markup change; risk of over-prioritising |
| Modern format — AVIF/WebP with fallback | Bytes at the same visual quality | Moderate | Encoding pipeline, multiple variants to store |
| Responsive sources — per-viewport variants | Phones downloading desktop-sized assets | Moderate to large on mobile | More variants, more markup, CDN transform cost |
| Lazy loading below the fold | Bandwidth contention and total weight | Small on LCP, real on data cost | Near-zero — but never lazy-load the LCP image |
| Compression quality tuning | Bytes at some visual cost | Small once dimensions are right | Quality trade-off, subjective review |
| CDN delivery | Distance to the bytes | Moderate for distant users | Cost per GB, cache invalidation |
The dimensions mistake
The most expensive image bug in production is not compression settings. It is a content pipeline that stores whatever was uploaded and serves it unchanged, so a 3000×2000 photograph from a marketing laptop is delivered to a 400×267 slot on a phone.
That costs on three axes at once: bytes on the wire, decode time on the device CPU, and memory to hold the decoded bitmap — which is the *uncompressed* size, and is often far larger than people expect. A 3000×2000 image is roughly 24MB of decoded pixel data regardless of how small the compressed file is, and phones with constrained memory feel that.
The fix is unglamorous and highly effective: resize at the pipeline or CDN, serve per-viewport variants, and always declare dimensions in the markup so layout space is reserved and CLS does not fire (see Core Web Vitals as Signals, Not Scores).
1<img src="/uploads/hero-original.jpg">2 3# 3000 x 2000, 2.4MB JPEG4# Displayed at 400 x 267 on a phone5# Decoded bitmap: ~24MB of memory, regardless of file size6# No width/height -> layout shifts when it arrives7# Discovered late if injected by script8 9# "We turned quality down to 70" saves ~400KB10# and leaves the decode and memory cost untouched.1<img2 src="/i/hero-800.avif"3 srcset="/i/hero-400.avif 400w,4 /i/hero-800.avif 800w,5 /i/hero-1600.avif 1600w"6 sizes="(max-width: 600px) 100vw, 800px"7 width="800" height="533"8 fetchpriority="high"9 alt="...">10 11# Phone fetches the 400w variant: a fraction of the bytes,12# a fraction of the decode, a fraction of the memory.13# Dimensions reserve layout space -> no shift.14# Present in initial HTML -> discovered by the preload scanner.The quality-slider fix addresses bytes only. Correct dimensions address bytes, decode CPU and decoded-bitmap memory simultaneously — and the markup change also fixes discovery and layout shift.
Lazy loading, and the trap in it
Lazy loading below-the-fold images is close to free and genuinely useful: it removes bandwidth contention during the initial load and stops users paying for data they never scroll to. It is the correct default for anything not visible on the first screen.
The trap is applying it uniformly. Lazy-loading the LCP image delays the fetch of precisely the element the metric measures, because the browser must first do layout to determine the image is in the viewport before it will start the request. Teams routinely adopt a blanket lazy-loading rule and watch LCP get worse.
The rule that survives contact with reality: everything below the fold is lazy, the LCP candidate is eager and prioritised, and someone verifies which element is actually the LCP element per route rather than assuming. Verification matters because the LCP element changes when the design changes, and nothing warns you.
| Signal | Value | What it tells you | Verdict |
|---|---|---|---|
| Total image bytes, first screen | 2.1MB → 380KB | Genuine win on data cost and bandwidth contention | normal |
| Images requested on load | 34 → 6 | Fewer competing fetches, as intended | normal |
| LCP element fetch start | 180ms → 1240ms | The hero now waits for layout before its request begins | smoking gun |
| LCP, field p75 mobile | 2.8s → 3.6s | The metric got worse while the page got lighter | smoking gun |
| CLS, field p75 | 0.02 → 0.02 | Unchanged; dimensions were already declared | normal |
Key points
- Page weight and blocking time are different quantities; most image bytes are below the fold and were never on the critical path.
- The LCP image is the one that matters — identify it per route rather than assuming, because it changes when the design changes.
- Serving correct dimensions fixes bytes, decode CPU and decoded-bitmap memory at once, and usually beats format and quality changes combined.
- Decoded bitmap memory is a function of pixel dimensions, not file size — a small compressed file can still be a large memory cost.
- Lazy-load below the fold, never the LCP candidate; a blanket rule reliably makes LCP worse.
Follow the diagnosis
The causal chain, hop by hop — and the readings that invite the wrong conclusion.
- 1CMS → storage: an editor uploads a 3000×2000 photograph; the pipeline stores it unchanged because no resize step exists.
- 2Page → browser: the
<img>references the original, with nosrcsetand no declared dimensions. - 3Browser → network: a phone downloads 2.4MB to display it in a 400px-wide slot, competing with script and stylesheet fetches.
- 4Browser → device CPU/memory: the image decodes to roughly 24MB of bitmap, costing decode time and memory pressure on a constrained device.
- 5Layout → LCP: the paint of the largest element lands late, and because no dimensions were declared, the arrival also shifts the content the user was reading.
- • "Images are 80% of page weight, so images are the bottleneck." Most of that weight is below the fold. Check what the LCP element waited for.
- • "We compressed everything, so images are handled." Compression addresses bytes; a 3000px image still decodes as 3000px and still occupies bitmap memory accordingly.
- • "Lazy loading is always a win." Lazy-loading the LCP image reliably makes LCP worse, because the request waits for layout.
- • "The file is only 90KB, so it is cheap." Decoded memory tracks pixel dimensions, not compressed size.
- • "We moved images to a CDN, so image performance is solved." A CDN shortens the fetch; it does not change dimensions, decode cost or discovery order.
Measure, fix, validate
An optimization is not finished until the metric that motivated it has moved.
- • Which element is the LCP element per route, and the timestamp at which its fetch was initiated.
- • Intrinsic versus displayed dimensions for above-the-fold images — the ratio is the wasted-bytes multiplier.
- • Image bytes split by above-the-fold and below-the-fold, so total weight does not disguise what users actually waited for.
- • Decode time on a throttled device profile, which correlates with pixel dimensions rather than file size.
- • Field LCP p75 for the route and device segment, before and after any image change.
- • Resize at the pipeline or CDN so no image is served significantly larger than its largest display size, and generate per-viewport variants.
- • Declare width and height (or an aspect ratio) on every image so layout space is reserved and content stops jumping.
- • Make the LCP image eager, discoverable in the initial HTML, and explicitly prioritised; lazy-load everything below the fold.
- • Adopt a modern format with a fallback, once dimensions are already correct — the ordering matters, because format savings on an oversized image are savings on waste.
- • Verify the LCP element per route after design changes; add it to the release checklist rather than trusting it to stay stable.
- • Field LCP p75 for the affected route and device segment over a stable window, compared against the same window before.
- • The LCP element's fetch start time in a throttled cold load — it should move earlier, not merely download faster.
- • Transferred image bytes above the fold specifically, rather than total page weight.
- • CLS unchanged or improved, confirming dimension declarations did not regress layout stability.
- • Decode time on the throttled profile, which should fall roughly with the pixel-count reduction.
- • Multiple variants per image multiply storage and CDN transform cost, and complicate cache invalidation.
- • Modern formats need fallbacks and encoding infrastructure; the pipeline becomes something that must be maintained.
- • Aggressive quality reduction is a visual trade-off that needs human review, and the right setting differs by image type.
- • Prioritising the hero competes with script and stylesheet fetches — over-prioritising simply moves the delay elsewhere.
- • A build or CI check that fails when an image asset exceeds a maximum pixel dimension for its usage context.
- • A lint rule requiring width/height or aspect-ratio on every
<img>. - • A per-route check that the LCP element is eager and present in server-rendered markup.
- • A budget on above-the-fold image bytes per route, tracked per commit.
Accuracy
Performance numbers are conditional. These are the conditions.
- WEB-SPECIFICResponsive image markup, lazy-loading semantics and format support are browser-platform features with varying support and behaviour.
- ILLUSTRATIVEAll byte and timing figures are invented to show relative magnitudes. The decoded-bitmap approximation assumes 4 bytes per pixel, which is a rough model rather than a guarantee.
- ENVIRONMENT-SPECIFICDecode cost and memory pressure depend heavily on the device; constrained phones behave very differently from desktops with the same image.