Image Optimization for Faster Websites

Why images matter for speed

web.dev's guide to browser-level lazy loading notes, citing the HTTP Archive, that images are the most-requested asset type on most websites and usually take more bandwidth than any other resource. On many pages the largest thing in view when the page opens is a hero image, which makes it the element measured by Largest Contentful Paint (LCP), one of Google's Core Web Vitals. Images without reserved space also cause Cumulative Layout Shift (CLS), another of the three.

Choosing a format: JPEG, PNG, WebP, AVIF and SVG

MDN's image file type guide summarises the common formats:

• JPEG: lossy compression for still images, and still the most popular. A good fallback for photographs.
• PNG: lossless, so better for screenshots, diagrams and line art, and the fallback for any image that needs transparency, since JPEG has none.
• WebP: MDN calls it an "excellent choice" for both still and animated images, with much better compression than PNG or JPEG and support for transparency.
• AVIF: also much better compression than PNG or JPEG. MDN says it compresses slightly better than WebP but is not quite as well supported and does not render progressively, and recommends a fallback when you use it.
• SVG: a vector format for logos, icons and diagrams that must stay sharp at any size. MDN says to prefer the SVG version of an icon whenever one exists.

Browser support is wide now. Can I use lists WebP and AVIF as supported in current versions of Chrome, Edge, Firefox and Safari. Older browsers and some apps that open images outside the browser can still miss out, so the safe pattern MDN describes is the <picture> element: offer AVIF or WebP first, with a JPEG or PNG fallback that every browser can show.

A simple rule: photos in WebP or AVIF with a JPEG fallback, screenshots and graphics with sharp edges in lossless WebP or PNG, logos and icons in SVG.

Serve the right size: srcset and sizes

A photo from a camera or stock site is often far wider than the column it is shown in on a phone, and sending the full file wastes data. MDN's responsive images guide explains the fix:

• srcset lists the same image in several widths.
• sizes tells the browser how wide the image will be shown under different conditions, such as "full width on small screens, 600 pixels on larger ones".
• The browser then picks the smallest file that will still look sharp on that screen.

MDN notes that srcset, sizes and <picture> work in modern desktop and mobile browsers. <picture> also handles "art direction", where a phone gets a tighter crop of the same photo rather than a shrunken wide shot. WordPress has added srcset and sizes automatically since version 4.4, creating smaller copies of each upload; on a custom site your developer sets it up in the templates or the build.

Compression

Lossy formats discard detail to save space. MDN explains that photographs usually tolerate lossy compression because the lost detail is hard to see, while screenshots and text show artefacts around sharp edges, which is why they suit lossless formats. WebP and AVIF can do either, chosen when the file is saved.

There is no single correct quality setting. Export a few versions of a typical photo, compare them at the size they will be shown, and pick the smallest that still looks right. Then build the setting into an export preset, plugin or build step so new images do not slip through at full size.

Lazy loading, but not for the main image

Adding loading="lazy" to an image tells the browser to wait until the visitor scrolls near it. web.dev says this works in all major browsers without extra JavaScript, and advises: "Use loading=lazy only for images outside the initial viewport."

The main image at the top of the page is the exception. web.dev's LCP guide is direct: "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP." Some themes and plugins lazy-load every image by default, so check the hero image on your key pages.

Loading the main image first

The LCP guide also notes that browsers do not load images at the highest priority by default, because images do not block the page from rendering. web.dev's article on Fetch Priority shows how to raise it: add fetchpriority="high" to the LCP image so the browser fetches it sooner. It is a hint for the image that matters most; marking every image high would defeat the point. If the main image is set in CSS rather than HTML, the browser finds it late; the LCP guide shows how to preload it with <link rel="preload">.

Width and height, to stop layout shift

If the browser does not know an image's size, it lays out the text first and pushes it down when the image arrives. web.dev's CLS guide says: "Always include width and height size attributes on your images and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar." Modern browsers use those attributes to work out the space before the file loads, and the image still scales responsively with CSS.

Alt text

Speed is not the only job. The W3C's images tutorial says images must have text alternatives that describe the information or function they represent, so that people who cannot see them, including screen reader users, get the same content. It groups images by purpose:

• Informative images (photos, illustrations): a short description of the essential information.
• Decorative images: an empty alt attribute (alt="") so screen readers skip them.
• Functional images, such as an icon used as a link or button: describe what it does, not what it looks like.

The tutorial includes an alt decision tree for unclear cases. Our accessibility basics guide covers the rest of the page.

Image CDNs and services

On a site with many images, doing all of this by hand gets tedious. Image CDNs and image services, including those built into many hosting platforms and online shop systems, resize, compress and convert images on request and serve them from servers close to the visitor, often choosing WebP or AVIF for browsers that support them. Check what they do to quality and what they cost as traffic grows. They do not replace dimensions, alt text or the right loading behaviour for the main image.

A checklist

1. Photos in WebP or AVIF with a JPEG fallback; graphics in PNG or lossless WebP; logos and icons in SVG.
2. Every image served at roughly the size it is shown, using srcset and sizes.
3. A compression setting agreed and built into how new images are added.
4. loading="lazy" on images below the first screen, never on the main image.
5. fetchpriority="high" on the main (LCP) image.
6. width and height on every image.
7. Alt text for informative and functional images, alt="" for decorative ones.
8. Key pages tested in PageSpeed Insights on mobile, and again after redesigns.

On a landing page the hero image is usually the LCP element, so it is the first one to check; see our landing page checklist for the rest.

Frequently asked questions

Should I use WebP or AVIF?

Either works for photos. MDN says AVIF compresses slightly better but is not quite as well supported and does not render progressively. Serving AVIF or WebP inside a picture element with a JPEG fallback covers every browser.

Should I lazy-load all images?

No. Lazy-load images below the first screen only. web.dev says never to lazy-load the LCP image, usually the main image at the top of the page, because it delays it.

Why do images need width and height?

So the browser can reserve the right space before the image loads. Without them, text jumps down when the image arrives, which counts as layout shift (CLS).

What should alt text say?

What the image means in context. The W3C images tutorial says informative images need a short description of the essential information, functional images should describe the action, and decorative images get an empty alt attribute.

Do I need an image CDN?

Not for a small site with a handful of images handled well. On a site with many images, a CDN or image service that resizes and converts automatically can save a lot of manual work.

Is your site slow because of images? We build fast websites and look after existing ones, including image handling. See our website development and website maintenance services, or email info@creahive.com.