It's a familiar pattern. A team profiles their app to figure out why a page feels slow. The JavaScript bundle is lean. The API is fast. The CSS is minified, gzipped, and tree-shaken. Everything the performance checklists ask for has been done.

The culprit, more often than not, is a single image. One asset, one network request, dragging the whole experience down. A 4MB hero image can outweigh the entire JavaScript payload of a production app, and unlike a slow API or a heavy bundle, nobody gets a warning when it happens.

This is the part of the web that most teams quietly under-invest in. Images are still, in 2026, the single largest contributor to page weight on most websites. Optimising images can do more for performance than almost anything else on the frontend.

Small wins compound. A correctly sized hero image, a sensible srcset, a loading="lazy" on a long product grid. Each one shaves real milliseconds off perceived load time. Image work touches the network, the browser, the CPU, the GPU, and the layout engine all at once. Getting it right teaches you more about how the web actually works than almost any other frontend topic.

The catch is that "image optimisation" is no longer one thing. It is a delivery pipeline. Responsive variants, network conditions, device capabilities, loading priorities, CDN transformations, cache headers, decoding cost, rendering behaviour. They all matter, and they interact with each other in ways that are easy to get subtly wrong.

This 8-part series walks through the techniques that hold up in production. Not a checklist. A mental model. This first article covers two things: why image optimisation matters in the first place, and what the browser is actually doing under the hood when it loads an image.