Images and page speed: formats, sizes, lazy loading

Why images decide the loading time

Google writes that images are often the largest contributor to overall page size, which can make pages slow and expensive to load. Two of the Core Web Vitals depend directly on images. Largest Contentful Paint (LCP) measures loading: Google advises that the largest element should appear within the first 2.5 seconds after the page starts to load. On many pages that element is an image, for example a large photo at the top. Cumulative Layout Shift (CLS) measures visual stability and should stay below 0.1. Images that arrive without reserved space push the text down and raise this value.

The right format

• Photos: JPEG works everywhere. WebP and AVIF are often clearly smaller at a similar quality.
• Graphics with sharp edges or transparency: PNG, or WebP and AVIF, which can also be transparent.
• Logos and icons: SVG, because it stays sharp at every size and is usually very small.
• Google Search supports images in the src attribute in the formats BMP, GIF, JPEG, PNG, WebP, SVG and AVIF.

If you offer WebP or AVIF, you can keep a JPEG as a fallback in a picture element. The browser picks the first source it understands.

The right size

An image that is 2400 pixels wide but shown at 600 pixels wastes most of its bytes. Export images at about the width at which they are shown, and for sharp screens at about twice that width. Then compress them. In many image programs, a quality setting around the middle of the scale is enough for photos on the web. Check the result at full size before you replace the original.

srcset and sizes

One file never fits every screen. With srcset you offer several files of the same image and state the width of each file. With sizes you tell the browser how wide the image will be shown. The browser then picks the smallest file that is sharp enough.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

In this example, the image fills the screen on narrow screens and is 700 pixels wide on wider ones. Google recommends always keeping a fallback in the src attribute. Write a real alt text in place of the three dots.

Width and height against layout shifts

Without width and height, the browser does not know how much space an image needs until the file arrives. The text below it then jumps down. The web.dev guide on layout shifts advises: always include width and height attributes on images and video elements, with the pixel size of the file or at least the correct aspect ratio. Modern browsers set the default aspect ratio of an image from these values and reserve the space. In the CSS, width: 100% and height: auto keep the image flexible. If you cannot set the attributes, the guide names the CSS property aspect-ratio as an alternative.

Lazy loading

With loading="lazy" the browser loads an image only when it comes close to the visible area. This saves data for images further down the page. Google says about lazy loading: do not add it to content that is likely to be immediately visible when a user opens a page. Built-in lazy loading of the browser is available for images and iframes.

The LCP image

The largest image at the top, often a hero image or the main product photo, is the most important file of the page. The web.dev guide on LCP says: never lazy-load your LCP image. fetchpriority="high" is a hint to the browser to load it early. According to the guide, a high priority on more than one or two images no longer helps. Images whose address a script library hides in data-src, or that are only a CSS background, are found late by the browser. For a background image, the guide names a preload with link rel="preload" in the HTML. AVIF or WebP and a smaller file shorten the loading time as well.

To see how your pages perform, Google points to the Core Web Vitals report in Search Console. For a single page, the performance tools of your browser show which element is the LCP element and which elements shift the layout. Measure before and after a change, so that you know whether it helped.

A short checklist

• Is the largest image at the top loaded normally, not lazily?
• Does every img have width and height, or the space reserved with aspect-ratio?
• Is each file about as wide as it is shown, and compressed?
• Do large photos come in several widths with srcset and sizes?
• Are there JPEG or PNG files that could be WebP or AVIF?

Work with Do4U

The Image check reads one page and each image on it. For every file it reports the format, the file size and the pixels, and from the HTML width and height, loading, fetchpriority, srcset and sizes, picture sources and background images in style attributes. Do4U guesses the likely LCP image from the HTML. It does not measure it, because the real LCP element is decided by the browser. You get a table of the images with the findings, the total weight and a short summary. Images that JavaScript inserts and background images from external CSS files are not included. No AI is used, and the check is free, with a daily limit.

Do4U finds hints, you check and decide. Confirm the LCP element with the performance tools of your browser before you change the page.