I audit websites for carbon performance regularly, and I could write this article in my sleep: images are the problem. Not always, but on roughly 70% of the sites I examine, images account for more data transfer than everything else combined. And on most of those sites, the images could be 50-80% smaller with zero visible quality loss.
This is the single highest-impact, lowest-effort optimization for website sustainability. Let me get specific about how to do it right.
The State of Images on the Web in 2026
According to HTTP Archive data, the median webpage transfers about 1MB of images. The 90th percentile — which includes many e-commerce, media, and portfolio sites — transfers over 3MB of images per page. For context, the entire HTML, CSS, and JavaScript of a well-optimized site can fit in 200-300KB.
The waste comes from three sources: wrong format (using PNG or uncompressed JPEG when WebP/AVIF would be dramatically smaller), wrong dimensions (serving desktop-sized images to mobile devices), and wrong loading strategy (loading all images upfront instead of on demand).
Fix all three and you typically save 60-80% of image data transfer. On a page where images represent 70% of total weight, that translates to a 40-55% reduction in total page weight and proportional reduction in carbon emissions.
Format: WebP, AVIF, and When to Use Each
WebP
WebP was developed by Google and is now supported by all major browsers (97%+ global support). Compared to JPEG at equivalent visual quality, WebP files are 25-35% smaller. Compared to PNG with transparency, WebP is typically 50-70% smaller.
WebP supports both lossy compression (for photographs) and lossless compression (for graphics with sharp edges and text). It also supports transparency (alpha channel) and animation — making it a single-format replacement for JPEG, PNG, and GIF.
For most websites in 2026, WebP should be the default image format. The only reason not to use it is if you need to support very old browsers (IE11, which you probably should not support anymore).
AVIF
AVIF (AV1 Image File Format) is the newer contender. It delivers 20-40% smaller files than WebP at equivalent quality — particularly for photographs with complex detail. Browser support has reached roughly 90% globally (Chrome, Firefox, Safari 16.4+, Edge).
AVIF's encoding is slower than WebP (relevant for on-the-fly conversion), and its browser support is not quite as universal. But for sites where maximum compression matters — large photo galleries, e-commerce product images, media sites — AVIF provides the best ratio of quality to file size available today.
When to Use What
My recommendation: serve AVIF to browsers that support it, WebP as fallback, and JPEG as final fallback. The HTML picture element makes this straightforward:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description">
</picture>
For icons and simple graphics: use SVG (vector, resolution-independent, typically tiny). For very simple shapes: use CSS (zero additional HTTP requests).
Dimensions: Responsive Images Done Right
Serving a 2000px-wide image to a phone with a 375px viewport is pure waste. The browser downloads the full image, then scales it down for display. You paid the full data transfer cost for pixels nobody sees.
The solution is responsive images — serving appropriately sized versions for each device and viewport:
<img srcset="image-400.webp 400w,
image-800.webp 800w,
image-1200.webp 1200w,
image-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, 50vw"
src="image-800.webp"
alt="Description">
The browser selects the smallest image that covers the display area at the device's pixel density. A phone at 375px width and 2x density selects the 800w version. A desktop at 1440px width showing the image at 50vw selects the 1200w version. No wasted pixels.
The key decisions: how many size variants to generate (4-5 is usually sufficient), what breakpoints to use (match your layout breakpoints), and whether to account for high-DPI displays (yes, but cap at 2x — the difference between 2x and 3x is imperceptible at normal viewing distances).
Loading Strategy: Lazy Loading and Above-the-Fold Priority
Loading every image on the page immediately — even images below the fold that the user has not scrolled to — wastes data transfer. Lazy loading defers loading of below-the-fold images until the user scrolls near them.
In 2026, native lazy loading is the simplest approach:
<img src="image.webp" loading="lazy" alt="Description">
But do not lazy-load everything. Above-the-fold images — hero images, header logos, and any image visible without scrolling — should load immediately for the best user experience. The largest contentful paint (LCP) image specifically should never be lazy-loaded.
For pages with many images (galleries, product listings, blog archives), lazy loading can reduce initial data transfer by 70-90% — the user only downloads images they actually view.
Compression: Finding the Quality Sweet Spot
Compression quality settings are where the most wasteful bytes hide. The default quality in most image editors is 100% (or "maximum"), which produces files far larger than necessary.
The reality: for photographs, the visible difference between 100% quality and 80% quality is imperceptible to virtually all viewers. The file size difference is typically 2-3x. At 75% quality, very minor artifacts might be visible on close inspection in some images. Below 60%, quality loss becomes noticeable.
My recommendations: photographs (hero images, product shots): 80-85% quality. Thumbnails and listing images: 70-75% quality. Background/decorative images: 60-70% quality. PNG graphics: lossless, but ensure they are actually PNG-appropriate (if it is a photograph, use lossy WebP instead).
Automation: Making It Sustainable
Manual image optimization is tedious and unsustainable. Build it into your workflow:
Build-time optimization: Use tools like Sharp (Node.js), Squoosh CLI, or imagemin in your build pipeline. Every image that enters your repository or CMS gets automatically optimized.
CDN-level optimization: Services like Cloudflare Images, imgix, and Cloudinary can resize, reformat, and compress images on the fly, serving the optimal version based on the requesting device.
CMS plugins: WordPress plugins like ShortPixel, Imagify, or EWWW optimize images on upload. Ensure they are configured for WebP/AVIF conversion and appropriate quality settings.
The goal is to make optimization the default rather than an afterthought. When every image is automatically compressed, resized, and format-converted before it reaches a browser, your carbon footprint stays low without ongoing manual effort.
Measuring the Impact
Before and after any image optimization project, measure with Carbon Badge. You want to see: total page weight reduction, image-specific weight reduction (check browser devtools Network tab filtered by image type), per-page carbon reduction, and load time improvement.
In my experience, a thorough image optimization pass on an average corporate website reduces total page weight by 40-60%, per-page carbon by a proportional amount, and page load time by 30-50%. Those are meaningful numbers for a change that can be implemented in days, not months.