Image optimization: the formats that actually matter and why

Image weight is still the single biggest contributor to a slow Largest Contentful Paint on most sites we audit. The fix isn't complicated, but the specific choices, which format, what compression level, what sizing strategy, matter more than most teams realize when they treat all modern formats as roughly interchangeable.

WebP typically delivers 25 to 35 percent smaller file sizes than an equivalent JPEG at visually indistinguishable quality, and it now has broad enough browser support to use as a default rather than an edge-case optimization. We serve WebP with a fallback for the rare older browser that needs it, using the picture element rather than relying on server-side detection that can be unreliable.

AVIF compresses further than WebP in most cases, often another 15 to 20 percent smaller, but it's slower to encode and support is slightly less universal. We reserve it for the highest-impact images, usually a hero banner, where the extra savings on the single most important image on the page are worth the added encoding complexity for the build pipeline.

Serving a 2000px-wide image to a 400px-wide mobile viewport wastes more bandwidth than the format choice ever will. We generate multiple sizes per image and use srcset so each device downloads only what it actually needs, which is usually the single biggest win available before format even enters the conversation at all.

Lazy loading images below the initial viewport keeps the browser from wasting early bandwidth on content nobody's scrolled to yet. The common mistake is lazy loading the hero image too, which delays the exact thing LCP is measuring and actively hurts the metric it's supposed to help, undoing the benefit lazy loading is meant to provide elsewhere on the page.

On one ecommerce audit, simply converting the existing JPEG product images to WebP and adding proper responsive srcset attributes cut total image payload on the category page by 58 percent, with no visible quality difference to a typical visitor. No new photography, no design changes, just a format and delivery fix that took under a day to implement across the templates.

Converting images to a modern format but leaving the original dimensions unchanged is a frequent half-fix we see. A perfectly compressed WebP image that's still 3000 pixels wide for a 600 pixel display slot wastes most of the format's benefit, since dimension and format optimization need to happen together, not as separate, disconnected steps.

For sites where users upload their own images, product photos, profile pictures, we run automated optimization at upload time rather than relying on manual process, since a manual step will eventually get skipped under real-world usage. This is set up once during the build and then runs invisibly for the life of the site.

Format choice and compression level are separate levers, and even within WebP or AVIF, an image can be compressed too lightly, leaving unnecessary file size on the table. We set explicit quality targets per image type, product photography compresses differently than a simple graphic, rather than applying one setting universally.

A focused image optimization pass on an existing site is usually one of the cheapest performance interventions we offer relative to its impact, often completed in a day or two, because it doesn't require touching page logic or layout, just the asset pipeline and delivery configuration around existing images.

Customer-uploaded review photos are often the least optimized images on an entire site, since they arrive at whatever size and format the customer's device happened to produce. We run the same automated optimization pipeline on these as on official product photography, since an unoptimized customer photo can be just as damaging to page speed as a poorly handled hero image.

Marketing teams sometimes hand off print-resolution source files, sized and compressed for physical printing rather than screens, assuming they'll be automatically optimized somewhere downstream. We explicitly verify the actual web-delivered file size in production, not just the optimization pipeline's configuration, since a misconfigured step can silently let an oversized print file through untouched.

Clients with years of accumulated, unoptimized historical content often have thousands of legacy images embedded in old blog posts and pages that were never touched by any optimization pipeline. We run a bulk retroactive optimization pass across this historical library as part of a broader performance engagement, since these old, heavy images continue dragging down page speed on older content that still receives meaningful organic traffic.

We also build automated alerts flagging any newly uploaded image that exceeds a defined file size threshold before optimization, catching the problem at the moment of upload rather than discovering months later, during a routine performance audit, that a content editor uploaded a multi-megabyte unoptimized photo that's been quietly dragging down one specific page's load time the whole time without anyone noticing the isolated but real impact it was having.

An image optimization pass that looks fine on a fast fiber connection in the office can still feel slow to a real visitor on a mid-tier mobile connection. We throttle testing to simulate typical mobile network conditions before calling any optimization work finished, since that gap between office testing and real-world conditions is exactly where a lot of otherwise solid optimization work quietly fails to deliver the improvement it should.

Serving the right format from the right server is only half the picture; the CDN's own caching and transformation settings determine whether that optimized image actually reaches the visitor quickly. We check that the CDN is caching optimized variants at the edge rather than re-processing images on every request, since a misconfigured cache policy can silently undo most of the benefit of an otherwise well-executed optimization pass.

We also verify that CDN-level automatic format negotiation, where supported, isn't quietly serving a heavier fallback format to browsers it can't confidently identify, which happens more often than teams expect with older or less common browser user agents. Catching this requires actually inspecting real response headers across a range of devices, not just trusting that a CDN's marketed automatic optimization feature is working as advertised in every case.