The hidden cost of unoptimized images on mobile load times

A 2 MB hero image on 4G costs three seconds of LCP — and most sessions lost to load time never come back.

The short answer: Switch to WebP or AVIF, add srcset so mobile gets a smaller file, and make sure your hero image has fetchpriority="high" with no lazy loading. Those three changes alone can cut mobile image payload by 80% and shave 2-3 seconds off LCP on a typical product page.

The HTTP Archive 2025 Web Almanac puts the median mobile homepage at 2.56 MB. Images account for 911 KB of that — more than a third of total page weight, ahead of JavaScript, CSS, and fonts combined.

Why does mobile make this worse?

On a real 4G mobile connection with actual latency, a 2 MB hero image can hold up your Largest Contentful Paint by two or three seconds. On 3G it's often worse.

For most mobile pages, the LCP element is an image. The 2025 Web Almanac puts only 48% of mobile pages passing all three Core Web Vitals, and LCP is the metric that fails most often. That gap concentrates at the unoptimized end: pages with bad image handling cluster at the bottom of the LCP distribution, and the penalty compounds as connection quality degrades. A page that loads in 2.8 seconds on a strong 4G signal can tip over 5 seconds on a weak one, which is where Google's "poor" threshold sits and where session abandonment spikes.

What does "unoptimized" actually cover?

Teams use it loosely. The actual problems are distinct and they compound. Wrong format — PNG or JPEG where WebP or AVIF fits — adds 25-50% to file size. A full-resolution image served to a 390px screen sends 4-16x more pixels than the device can display. No srcset means every viewport gets the same large file. Missing lazy loading below the fold pulls all images into the initial load. No compression pass leaves lossy artifacts from the original camera file sitting in the payload.

I've pulled Lighthouse JSON on hundreds of product pages and the same combination shows up constantly: a 2400px JPEG with no srcset, no format fallback, and loading="lazy" applied to the above-fold hero. Someone read that lazy loading is good, applied it everywhere, and submarined their own LCP score. Reversing it takes one attribute. The harder part is usually convincing whoever originally added it that this was not a configuration error — the original decision was.

Format selection is the biggest lever

WebP cuts file sizes 25-35% compared to JPEG at equivalent visual quality. AVIF goes further — typically 40-50% smaller than JPEG. A page with ten product images switching from JPEG to AVIF can save 300-500 KB on a single load.

Browser support stopped being the blocker a few years ago. WebP is at ~94% global support per Can I Use. AVIF is at ~74% and climbing per Can I Use. Serve AVIF with a WebP fallback and a JPEG baseline. The <picture> element handles this without JavaScript:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="..." width="1200" height="630" />
</picture>

Always include width and height attributes. Without them the browser can't reserve layout space, which causes Cumulative Layout Shift as images load.

Hot take: Most teams should skip AVIF encoding entirely and stay on WebP. The browser support gap is small enough that you're encoding two modern formats for marginal gain, and AVIF encode times are slow enough to create real pipeline delays at scale. WebP with aggressive quality settings gets 80% of the savings at a fraction of the build complexity.

Responsive images

A 1200px-wide image served to a 390px screen sends 3x the pixels the device can display. With srcset and sizes, the browser picks the right file:

<img
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 50vw"
  src="hero-800.webp"
  alt="..."
/>

This alone cuts image bytes by 50-70% on mobile viewports. Pixel Wand generates WebP and AVIF derivatives at multiple breakpoints automatically on upload, strips EXIF data (20-50 KB per camera file), and serves via signed CDN URLs — so the application never has to touch the transform logic.

Lazy loading

Apply loading="lazy" to everything below the fold. Never to the LCP image. The canonical fix for prioritizing the hero is fetchpriority="high":

<img src="hero.webp" fetchpriority="high" alt="..." />

Google's fetch priority case study on Google Flights (documented at web.dev) showed measurable LCP improvement from this attribute alone. The reason it matters disproportionately: browsers deprioritize image fetches during the initial HTML parse to avoid blocking render-critical resources. Without the priority hint, your hero image may not start downloading until the parser clears the <head>. On a slow connection, that gap is where LCP time accumulates.

The cumulative effect on a real page

Lighthouse audit on a WooCommerce product page with five images:

	Before	After
Format	JPEG	AVIF + WebP fallback
Dimensions	2400px, one size	srcset at 400/800/1200px
Total image bytes (mobile)	~1.8 MB	~280 KB
LCP image	Lazy loaded, no priority	fetchpriority="high", not lazy
Below-fold images	All loaded on page load	loading="lazy"

That 1.5 MB reduction on a real 4G connection is roughly 2-3 seconds off load time.

FAQ

Do I need AVIF if my images are already WebP?

WebP already puts you ahead of most sites. AVIF adds another 20-30% savings at equivalent quality — worth adding as the primary source in a <picture> element with WebP as the fallback, as long as your encoding pipeline can handle it without slowing down deploys. That said, if your team is on a tight deploy cadence and AVIF encoding is adding 10-15 seconds to every image pipeline run, the tradeoff gets murky. I've seen teams burn a week wiring up AVIF support to claw back 80 KB per page. Run the numbers on your actual image inventory before committing. For most product catalogs under 500 images, the encoding overhead is manageable. For a site with 50,000 SKUs, it's a different conversation entirely — the math flips fast once you factor in CI time and storage costs for every variant.

What about images from a CMS or DAM where I don't control the output?

A DAM that generates format variants and responsive derivatives at upload time handles this without per-app transform code. Writing image transform logic in every app that touches your assets gets old fast.

Does image optimization help SEO directly?

Yes. Google uses Core Web Vitals as a ranking signal, LCP is the one most heavily influenced by image handling, and better scores move rankings on competitive queries — particularly on mobile.

My images look fine on mobile. Why does this matter?

A JPEG that looks identical to an AVIF at 280 KB might be 800 KB — the difference is load time, not pixels. Visual quality and payload size are separate budgets, and only one of them shows up in PageSpeed.

A few specifics worth adding: camera JPEGs often carry 20-50 KB of EXIF metadata the browser never uses, color profiles can add another 5-10 KB, and progressive JPEG encoding adds decode overhead on low-end Android hardware. None of that is visible to the eye. All of it costs time.

---

Pull up PageSpeed Insights on your site right now and look at the LCP image. Check the format it's serving. Check whether it has fetchpriority="high". If it's a JPEG without a WebP or AVIF source and no priority hint, that's the first fix.