Optimizing Images for Web Performance

Start by not sending pixels nobody sees

The single biggest waste on most pages is an image served at its original dimensions and displayed at a fraction of them. A 4000-pixel-wide photograph placed in a 600-pixel-wide column costs the visitor the full download and then discards most of it during rendering. On a phone connection that is seconds of waiting for detail that is never visible.

Work out the display width from the layout, not from the source file. If an image occupies a 600-pixel column, its useful size is around 1200 pixels — roughly twice the CSS width, so it stays sharp on high-density displays where two or more physical pixels cover each layout pixel. Beyond about 2× the returns fall away sharply while the bytes keep climbing.

This is almost always a larger saving than any amount of tuning a quality slider. Halving both dimensions removes three quarters of the pixels before compression even begins.

Choose the format by content

Photographs belong in a lossy format. WebP typically produces meaningfully smaller files than JPEG at comparable visual quality, and AVIF smaller still, at the cost of slower encoding and narrower support.

Screenshots, diagrams, logos, and anything with sharp text belong in a lossless format. JPEG handles high-contrast edges badly — the text acquires a visible halo — and often produces a larger file than PNG for flat graphics. Lossless WebP is usually smaller than PNG for the same content when support allows.

Anything that needs transparency rules JPEG out entirely, since the format has no alpha channel. PNG and WebP both handle it, and WebP can do so in lossy mode, which PNG cannot.

Simple icons and logos are frequently best as SVG. A vector file scales to any size without additional bytes, stays sharp on every display density, and is often smaller than a raster equivalent for flat artwork.

Serve different sizes to different screens

A phone and a widescreen desktop need very different images, and responsive markup lets the browser choose rather than forcing one compromise on both. The srcset and sizes attributes let you list several versions with their widths and describe how much layout space the image occupies; the browser then picks an appropriate file based on viewport and screen density before downloading anything.

The sizes attribute is the part most often written carelessly, and getting it wrong undermines the whole mechanism. It must describe the image's layout width at each breakpoint, matching the CSS. If it claims the image is full-width when the CSS puts it in a half-width column, the browser selects a file twice as large as needed and the optimisation is wasted.

For format choice, the picture element with multiple source entries lets you offer AVIF or WebP first and a JPEG or PNG fallback last. Browsers take the first format they support, so newer formats reach the clients that can use them without breaking anyone else.

Most modern frameworks generate this markup automatically from a single source file. Using the framework's image component is usually better than hand-writing srcset, because the generated sizes and format lists stay correct as the design changes.

Load the right things at the right time

Images below the fold do not need to be downloaded before the page is usable. The loading attribute set to lazy tells the browser to defer them until the reader scrolls near, which is a one-word change with a substantial effect on pages carrying many images.

The critical exception is the main image at the top of the page. Lazy-loading it delays the very thing the visitor came to see and makes the page measurably slower to feel ready. The large image above the fold should load eagerly, and on an image-led page it is worth marking it as high priority so the browser fetches it before less important resources.

Preloading can help for that one hero image and hurts if applied broadly. Preloading everything is the same as prioritising nothing, and it competes with the stylesheet and fonts the page needs to render at all.

Decorative background images specified in CSS are fetched only when the element that needs them is rendered, which gives some of this behavior automatically — but they are also invisible to responsive markup, so use them for decoration rather than for content.

Reserve space so the page does not jump

When an image loads without declared dimensions, the browser does not know how much room to leave. Content renders, the image arrives, everything below it shifts down. Readers experience this as the page jumping while they are trying to read, and it is a common cause of clicking the wrong thing.

The fix is to set width and height attributes on every image with the intrinsic pixel dimensions. Browsers use the ratio between them to reserve the correct space before the file arrives, then scale to whatever the CSS specifies. Setting the attributes does not lock the display size; CSS still governs that.

For images whose aspect ratio varies, an explicit aspect-ratio in CSS achieves the same reservation. Either way the goal is that the space exists before the content does.

This costs nothing, requires no build tooling, and is one of the most noticeable improvements available on a page that currently omits it.

Compression settings that are worth the trouble

For photographs, quality settings in the range of roughly 75 to 85 are where most people stop noticing degradation at normal viewing sizes, while the file keeps shrinking. Going above about 95 costs a great many bytes for differences almost nobody can see.

Strip metadata from published images. Camera settings, editing history, and GPS coordinates add bytes to every request and carry privacy exposure you probably did not intend to publish.

Do not compress the same image repeatedly. Keep a lossless master, and export a fresh optimised copy whenever the requirements change. Re-compressing an already-compressed file compounds the damage without a corresponding saving.

Automate it. Optimisation applied by hand is applied inconsistently and forgotten under deadline. A build step, an image pipeline, or a framework's image component gives every image the same treatment without anyone remembering to do it.

Measure rather than assume

Open your own site's network panel and sort requests by size. The largest few are almost always images, and the gap between their downloaded size and their displayed size is the available saving, visible immediately.

Test on a throttled connection and a mid-range device rather than on the machine you built the site on. A page that feels instant on a fast laptop over office broadband can be genuinely slow on a phone, and that is the experience most visitors have.

Field measurement matters more than a single laboratory score. A tool run gives a reproducible number for comparing changes; real-user data tells you what visitors actually experience across the devices and connections they have.

Fix the biggest item first, then measure again. Image performance work follows a steep curve: correcting the two or three worst offenders usually delivers most of the available improvement, and micro-tuning the rest rarely repays the effort.