How to optimise images for faster website loading

Image optimisation is usually described as a file-size exercise. Compress everything, ship smaller bytes, done. That helps, but it misses the part visitors actually feel: which image the browser chooses to download, how early it starts, and whether the layout jumps around while the page fills in.

For the file-size targets themselves, see reducing image file size for websites. This guide is about diagnosing and delivering.

Measure before you optimise

Optimising images at random is how people spend a day and gain nothing. Twenty minutes with the browser's own tools tells you where the weight is.

1. 1Open developer tools and reload with the Network tab filtered to imagesSort by size. Note everything over 300 KB — that list is your job for today.
2. 2Compare natural size with displayed sizeHover an image in the Elements panel. If the intrinsic width is more than twice what it renders at, the visitor is downloading pixels nobody sees.
3. 3Find the Largest Contentful Paint elementA Lighthouse or performance-panel run names it. On most pages it is the hero image, and it is the single image worth the most attention.
4. 4Throttle to a slow connection and reloadA fast laptop on office wifi hides every problem you are trying to find. Watch what appears first and what makes the page jump.

Fix the LCP image first

Largest Contentful Paint measures when the biggest element in the viewport finishes rendering. On a page with a hero image, that is the hero image, and it dominates the score. Everything else you do to images elsewhere on the page is a rounding error next to it.

• Never lazy-load it. loading="lazy" on the hero tells the browser to wait — the exact opposite of what you want for the element being measured.
• Give it `fetchpriority="high"`. It tells the browser this image outranks the others competing for bandwidth.
• Cap its dimensions. 1920–2400px wide is plenty. A 4000px hero is a slow page with no visible benefit.
• Compress it properly, then check it. This is the one image where quality genuinely matters, so judge it at 100% rather than trusting a number.

Lazy-load everything below the fold

For images that start outside the viewport, loading="lazy" is close to free. The browser defers them until the visitor scrolls near, which frees bandwidth for the content they can actually see.

The rule is simply: everything below the fold gets it, the hero does not. On a long article that can be most of the images on the page.

Serve the right size to each device

A phone does not need the desktop hero. srcset and sizes let the browser pick, using information — viewport width, screen density, sometimes network conditions — that you do not have at build time.

• Export each important image at two or three widths, for example 800, 1600 and 2400px.
• List them in srcset with their widths, and describe the layout in sizes so the browser knows how wide the image will be rendered.
• Let the browser choose. It will pick a smaller file on a phone and a larger one on a desktop, without any JavaScript.

Batch Image Tools can produce a whole size ladder from one source in a single pass, which is what makes this practical rather than tedious.

Stop the page jumping

Cumulative Layout Shift is the metric for content moving under the reader. Images are the usual culprit: the browser does not know how tall one is until it arrives, so it reserves nothing and everything below shuffles down when it loads.

Put width and height attributes on every <img>, set to the image's real pixel dimensions. CSS can still size it however you like — the attributes exist to give the browser the aspect ratio so it can reserve the right space in advance. This costs nothing and fixes most layout shift on a content site.

The file-level work, in one pass

Once delivery is right, the files themselves are straightforward:

1. Cap dimensions at the largest size the image is displayed at, doubled for high-density screens.
2. Convert to WebP — see WebP vs JPG vs PNG for the exceptions.
3. Compress once at quality 80, or 85–90 for anything containing text.
4. Strip metadata, which removes weight and any GPS coordinates that came with the photo.

Image Optimizer does all four with web defaults already set. Image Metadata Remover handles the last one alone when a file has already been optimised elsewhere.

What to expect

Image work reliably improves the metrics images are responsible for — LCP when the hero was the problem, CLS when dimensions were missing, total page weight in almost every case. It does not fix slow servers, render-blocking scripts or third-party embeds, and a page dominated by those will not transform because the pictures got smaller.

Measure before and after on the same throttled connection. If the numbers barely moved, images were not the bottleneck, and that is worth knowing before you optimise another four hundred of them.