How to optimize images for the web: formats, resizing, lazy loading, and CLS

Images are usually the heaviest things a web page asks the browser to download. Over time they got bigger: MDN reports that between 2011 and 2019 the median image size grew from roughly 250 KB to 900 KB on desktop and from 100 KB to 850 KB on mobile, while total page weight roughly quadrupled. Get images wrong and pages load slowly; get them right and you cut bytes, raise your Core Web Vitals, and keep layout stable. This guide covers the four levers that matter most: format, size, lazy loading, and layout stability.

Pick the right format

The format you choose trades quality against file size. The most common web formats, per MDN, are AVIF, GIF, JPEG, PNG, SVG, and WebP. A good rule of thumb is: JPEG or WebP/ AVIF for photographs and still images, PNG for lossless images or when you need transparency, and SVG for anything that must scale — icons, logos, and diagrams. SVG is a vector format stored as text, so it can be drawn accurately at any size without quality loss, which is why MDN calls it the format for images that must be drawn accurately at different sizes. GIF, which compresses with the LZW algorithm, is fine for simple animations, but for animation sequences MDN recommends modern formats such as WebP or APNG instead.

Why WebP and AVIF win on file size

The older formats predate better compression. According to MDN's image format guide, lossy WebP images are on average 25–35% smaller than JPEG images of visually similar compression levels, and lossless WebP images are typically 26% smaller than the same image in PNG. AVIF goes further: lossy AVIF images are around 50% smaller than JPEG, and AVIF generally compresses better than WebP (MDN cites a median of 50% vs 30% compression on the same JPEG set). Both WebP and AVIF are royalty-free and supported in all current major browsers. Because formats like AVIF do not yet go back as far in browsers, MDN recommends serving them with a fallback using the <picture> element.

Serve the right size, not just the right format

Format fixes bytes per pixel, but size fixes how many pixels you send. A 4000-pixel-wide photo displayed in a 600-pixel card is mostly wasted bandwidth. MDN describes the <img> element's responsive-hint attributes for exactly this: srcset lists a set of candidate images at different sizes (plus widths, for example 800w), and sizes tells the browser how wide the image will be displayed, so the browser can pick the best candidate for the user's viewport and device. This is the difference between sending one oversized image to everyone and letting each device download only what it needs.

Keep layout stable: declare dimensions

When an image loads and the space around it was not reserved, the content below jumps — that is a layout shift, which hurts your Cumulative Layout Shift (CLS) score and frustrates readers. MDN's fix is explicit: use both width and height to set the intrinsic size of the image, allowing it to take up space before it loads, to mitigate content layout shifts. With dimensions declared, the browser reserves the box ahead of time and the image drops in without pushing anything. Using width: auto in CSS keeps the image responsive while honoring those declared intrinsic dimensions.

Lazy-load what is offscreen

Lazy loading is a strategy to identify resources as non-critical and load them only when needed, shortening the critical rendering path. It applies to offscreen content — images below the fold need no download before the user scrolls to them. The browser-native way is the loading="lazy" attribute on <img> (and on iframes); the load event then fires when the eagerly-loaded content is done, even if lazily-loaded images in the viewport are still arriving. For custom logic, MDN points to the Intersection Observer API, which notifies your code when an observed element enters or exits the viewport — the standard building block for viewport-triggered loading. One important caution: your above-the-fold image is often the page's largest contentful paint (LCP) element, so that image should stay eager and be optimized carefully rather than deferred.

FAQ

What image format should I use?

For photographs and still images, use JPEG or a modern format like WebP or AVIF. For lossless images or transparency, use PNG. For icons, logos, and diagrams that must scale, use SVG. GIF remains fine for simple animations, but WebP, APNG, or AVIF compress animations far better.

How much can WebP and AVIF actually save?

MDN reports lossy WebP images are on average 25–35% smaller than JPEG at similar visual quality, and lossless WebP about 26% smaller than PNG. AVIF goes further — around 50% smaller than JPEG — and generally compresses better than WebP. Since modern formats lack deep historical support, serve them with a JPEG or PNG fallback via <picture>.

Why does an image shift my layout?

If the browser has not reserved space for an image before it loads, the content below it jumps when the image arrives — a layout shift. Setting explicit width and height attributes tells the browser the intrinsic size so it can reserve the box up front, which mitigates layout shifts.

Does lazy loading hurt my LCP or SEO?

Native lazy loading defers offscreen images, which is usually a win. But the largest contentful paint (LCP) image — typically the hero at the top of the page — should be loaded eagerly and optimized, because delaying it can slow your LCP. Defer what is below the fold; prioritize what is visible first.

Summary

Optimizing images is a sequence of simple, high-impact decisions: choose a modern format (WebP or AVIF) for photos, keep PNG for transparency and SVG for anything that scales, send the right dimensions with srcset and sizes, declare width and height so nothing shifts, and lazy-load only what is offscreen. Together these cut hundreds of kilobytes from typical pages, improve your Core Web Vitals, and give you a faster, more stable site.