Images give websites character and show products, people and projects in ways text alone cannot. They are also often among the page's heaviest resources.

Good image use is therefore more than compression. The browser should receive the right image, at the right size and time.

Display size and file size are different

An image displayed at 800 pixels wide rarely needs a 5,000-pixel original for every user.

Responsive images let the browser choose between several files. The srcset and sizes attributes allow it to retrieve a version better suited to screen width and pixel density. MDN recommends this approach to avoid loading larger images than needed.

The result may look the same on screen while using less data and loading faster.

The main image needs a different strategy

The image at the top may be the element measured as Largest Contentful Paint, LCP, in Core Web Vitals.

Google therefore recommends avoiding lazy loading on images likely to become the LCP element. If the main image is discovered late, the page feels slower even when the image file is not particularly large.

Critical images can also receive a browser priority signal through fetchpriority. Images should therefore not all follow one loading rule.

Lazy loading fits images further down the page

Images below the first screen often do not need to load immediately. Lazy loading can then save bandwidth and reduce network competition at initial load.

The same technique can delay content users see first. The loading strategy should therefore follow the image's role, rather than being a standard setting for everything.

Specify width and height

When the browser knows image dimensions in advance, it can reserve the right space before the file finishes loading.

MDN recommends explicit width and height attributes. This reduces the risk of text, cards and other elements moving during loading.

The difference is particularly noticeable on pages with many product images or cards. The final result may be identical while the loading experience is much steadier.

File format alone does not solve performance

Modern formats can reduce file size, and compression matters. But web.dev notes that poor LCP can also result from late resource discovery, low priority or delayed rendering.

Converting everything to WebP is therefore not a complete strategy.

Consider the entire chain: image size, when the browser discovers it, its priority, which version is chosen and whether the layout knows its dimensions in advance.

The CMS should automate good choices

On frequently updated websites, every editor cannot be expected to understand srcset, LCP and browser loading logic.

A useful publishing system can generate several image sizes automatically and let the frontend choose the right version for main images, cards, galleries and mobile views.

Performance then becomes part of the system, rather than something the publisher needs to remember.

Plan design and technology together

Image optimisation is not only a developer's concern. Cropping, aspect ratio and subject placement affect how well an image adapts to different screens.

A subject with important content at the edge may work poorly on mobile. An image that only works in 16:9 may be difficult to use in square cards.

The design phase should therefore account for different uses, such as main image, card, mobile and thumbnail.

The goal is not the smallest possible file. It is the right image quality for the situation, delivered without unnecessary data or waiting.