Which format and size to serve your images in

Look at the total weight of a page and the thing carrying the load is almost always the images: fonts run to a few hundred kilobytes, scripts to a few hundred kilobytes, and images comfortably reach several megabytes. The ratio is the same on most sites. There is a good side to it too, because this is the cheapest place to fix, and it gets solved without touching a single line of code.

Dimensions come before format

The most common mistake is loading an image at the size it came out of the camera. A photograph four thousand pixels wide, displayed inside a card at eight hundred, gets scaled down and drawn by the browser, the extra pixels do nothing at all, and the visitor still pays for every byte. Three thousand two hundred pixels wasted.

The rule is short. The width you serve should not exceed twice the largest width it is displayed at; two is plenty for retina screens, and going to three buys nothing anyone can see.

That single change, before any format has been touched, cuts page weight by more than half on most sites without a single image visibly degrading.

Format is a choice between three

AVIF. Produces the smallest file of the three at the same visual quality. Encoding is slow, and since that is a build-time cost it never reaches the visitor.

WebP. Comes out a little larger than AVIF. In exchange it encodes quickly, its support reaches back to older browsers, and it can stand alone without needing a fallback.

JPEG. The fallback. Still reasonable for photographs, and it sits last in the picture element, meaning it only gets downloaded when the other two cannot be decoded.

PNG is left for sharp-edged graphics and small images that need transparency. Serving a photograph as PNG multiplies the file size against the same photo as JPEG and gives nothing back in quality.

Do not forget to reserve the space

Writing the width and height on an image lets the browser reserve room before the file has even arrived. Leave them out and the text shifts downward. That shift is measured as Cumulative Layout Shift.

The values belong on an image scaled by CSS too, because the browser reads the aspect ratio from them and does not impose the pixel numbers as the real size. It only reads the ratio.

Load order

The large image at the top of the screen is the largest contentful element on most pages, which means it decides the Largest Contentful Paint measurement directly. One file, one number.

Do not put lazy loading on that image. Lazy loading was designed for images below the fold, and applied to the top one it makes the browser deliberately delay the download while the measurement gets worse. The detail is in web.dev, “Optimize Largest Contentful Paint”.

Lazy loading suits every other image, because most visitors never reach the bottom of a page and those files never get downloaded at all.

The checklist

Four questions, about five minutes per page.

How many pixels wide is the largest image being served at, is the format AVIF or WebP, are the width and height written? Then ask one more. Is the top image arriving with lazy loading by accident?

If all four are right, the image work is done. Next stop is the fonts.