Image optimization that isn't just "compress the JPEG"

"Just compress your images" is the most common piece of performance advice on the internet, and it's true as far as it goes, but it covers maybe a fifth of what actually determines how images affect a real page load. The rest is about format, sizing, loading strategy, and layout stability, and it's where most of the remaining performance budget actually gets spent or saved.

We run a full image pipeline audit on every performance engagement now, not just a compression pass, specifically because a client who's already compressed their images with a plugin frequently assumes the image performance problem is solved, when in practice compression alone was never more than a fraction of the actual opportunity.

Switching a JPEG to WebP or AVIF typically saves 25 to 50 percent of file size at equivalent visual quality, more than another round of compressing the same JPEG format ever will. AVIF specifically can go further still on photographic images, though encoding time and older browser support are real tradeoffs worth checking against your actual visitor base before committing to it as the only format served.

We typically serve WebP as the default with a JPEG fallback for the small remaining share of older browsers, and reserve AVIF for image-heavy sites, like a photography portfolio or a product catalog, where the extra file size savings justify the added encoding complexity and build time.

A 2000px-wide hero image displayed at 400px on mobile wastes most of its download regardless of how well it's compressed. The `srcset` and `sizes` attributes let the browser choose an appropriately sized version for the actual display size and device pixel ratio, which on a typical content site cuts total image weight on mobile by 40 percent or more compared to shipping one size to every device.

Modern frameworks with a built-in image component handle much of this automatically once configured correctly, generating the right set of sizes at build time rather than requiring a developer to hand-write srcset attributes for every image, which is part of why we default to these tools rather than a plain img tag on any new build.

Loading off-screen images lazily is good practice, but applying `loading="lazy"` to the hero image above the fold actively hurts your Largest Contentful Paint score by delaying the browser's decision to fetch it early. The rule we follow: eagerly load anything visible in the first viewport, lazy load everything below it.

This is a surprisingly common mistake even among developers who know the rule in the abstract, since a default "lazy load everything" setting in a CMS plugin or image component is an easy trap to fall into without auditing which images actually sit above the fold on a specific page template.

An image with no width and height attribute causes the browser to reserve zero space for it until it downloads, then shove surrounding content down once it arrives, which is the single most common cause of a poor Cumulative Layout Shift score. Setting explicit dimensions, or using a CSS aspect-ratio box, costs nothing and fixes this completely regardless of how fast or slow the image itself loads.

We treat this as a non-negotiable default on every image across every build, not a fix applied reactively after a poor CLS score shows up in an audit, since there's no real cost to doing it correctly from the start and a real, visible cost, both to score and to how janky a page feels, when it's skipped.

Format used versus format available, whether responsive srcset is implemented at all, whether above-the-fold images are eagerly loaded, and whether every image has explicit dimensions. These four checks, done properly, typically account for more real-world speed improvement than another pass of raw compression on already-reasonable JPEGs.

On a recent audit, applying just these four checks to a client's existing, already-compressed images cut total page weight by 61 percent and improved mobile Largest Contentful Paint by 1.3 seconds, with no new compression tooling involved at all, just fixing format, sizing, loading order, and dimensions on assets that were already reasonably compressed to begin with.

A dedicated image CDN, Cloudinary, Imgix, or a framework's built-in image optimization service, can handle format negotiation, resizing, and quality adjustment automatically at request time, based on the requesting browser and device, rather than requiring a developer to pre-generate every size and format combination manually. For a site with a large or frequently changing image library, this shifts the optimization work from a manual, error-prone process to an automated default that's hard to accidentally regress.

We recommend this specifically for content-heavy sites where new images get added constantly by non-technical staff, since it removes the dependency on every content editor remembering to compress, resize, and pick the right format before uploading. The CDN enforces the discipline that a manual checklist eventually stops being followed consistently once enough different people are involved in publishing.

Image performance regresses quietly and often, since new images get added by people who weren't part of the original optimization project and don't necessarily know the standards that were set. We build a lightweight recheck into any ongoing retainer, spot-checking newly published pages against the same four criteria, since catching a regression early is a five-minute fix and catching it a year later, after dozens of pages have drifted, is a much bigger cleanup project.

This follow-up has caught real regressions on more than one client site: a new marketing hire uploading full-resolution camera images directly into a CMS, unaware that the platform doesn't automatically compress or resize on upload. A quick check and a short conversation fixed the immediate problem and the underlying process gap that had allowed it.