Short answer
Use AVIF or WebP for photos with a JPEG or PNG fallback, SVG for logos and icons, and several widths delivered with srcset and sizes. Give every image dimensions, prioritize the main image, and lazy-load only images below the first screen.
Why images deserve special attention
HTTP Archive's 2024 Web Almanac, as cited by web.dev, found that an image is the Largest Contentful Paint element on 73% of mobile pages [1]. That makes image delivery central to passing LCP. Images also cause layout shifts when they arrive without reserved space: 66% of pages have at least one unsized image, from the same 2024 Web Almanac data [1]. A few disciplined habits deal with both problems.
Choosing a format
MDN's guidance for web images is to "prefer WebP or AVIF" for raster images, because they "generally provide better compression than PNG, JPEG, and GIF" [2]. Its comparisons give a sense of scale:
| Format | Best for | What MDN says about size |
|---|---|---|
| AVIF | Photos and complex images | Lossy AVIF around 50% smaller than JPEG at similar quality |
| WebP | Photos, and graphics needing transparency | Lossy WebP 25 to 35% smaller than JPEG; lossless WebP about 26% smaller than PNG |
| JPEG | Fallback for photos | Universally supported baseline |
| PNG | Fallback for graphics needing lossless quality | Larger than WebP for the same image |
| SVG | Logos, icons, diagrams | Drawn as vectors, sharp at any size |
For screenshots, diagrams, logos and line art, MDN recommends lossless encoding, and for anything drawn at different sizes it recommends SVG [2].
Providing fallbacks
MDN notes that AVIF is supported in Chrome, Edge, Opera, Safari and Firefox, but because support "has little historical depth" you should provide a WebP, JPEG or PNG fallback using the picture element [2]. The browser picks the first source it can use and falls back to the img element otherwise. MDN adds that two or three sources are typically all you need [2]. Many platforms and CDNs now negotiate formats automatically, in which case you may not need to write the markup by hand.
Serving the right size
A phone does not need the same file as a large desktop monitor. web.dev's responsive images guide recommends listing several versions in srcset with width descriptors, then using sizes to tell the browser how wide the image will be displayed, so it can choose the best file [3]. It suggests generating three to five sizes and notes that sending desktop-sized images to phones can use two to four times more data than needed [3]. One detail catches people out: sizes does not change how large the image appears; CSS still controls that.
Reserving space
When an image arrives without reserved space, everything below it moves, which counts toward Cumulative Layout Shift. web.dev's fix is to set width and height attributes on images and video, or to reserve space with CSS aspect-ratio [4]. Modern browsers use the attributes to calculate the ratio even when CSS makes the image responsive, so there is no reason to leave them out.
Lazy loading, done safely
Lazy loading delays images until they are about to scroll into view, which saves data and frees bandwidth for what matters first. It must not be applied to the main image. web.dev says "never lazy-load your LCP image, as that will always lead to unnecessary resource load delay" [5]. Shopify's theme guidance says the same in practical terms: apply loading="lazy" only to images outside the initial viewport, and eagerly load images visible at first, especially the LCP candidate [6].
Lazy loading by JavaScript, using attributes like data-src, has a similar risk. Google notes that 7% of pages hide their LCP image behind data-src, where the browser cannot discover it early [1].
Prioritizing the main image
The browser does not know which image matters most until it has laid out the page. The fetchpriority attribute lets you tell it. web.dev recommends marking the likely LCP image with high priority, but warns that doing this on more than a couple of images stops helping [5]. If the main image is set as a CSS background or loaded by script, web.dev says it "should be preloaded with a high fetch priority" [5]. Better still, put it in the HTML as an img element where the browser can find it immediately. Only 15% of eligible pages used fetchpriority in the 2024 data, so it is still an easy improvement for many sites [1].
Compression settings
There is no single right quality setting. Photographs usually tolerate lossy compression well, while screenshots and line art do not [2]. A practical approach is to pick a quality level, compare a few key images side by side at the size they are displayed, and adjust. Brand photography may deserve a slightly higher setting than background textures.
A short checklist
- Photos in AVIF or WebP with a fallback; logos and icons in SVG.
- Three to five widths per image, delivered with srcset and sizes.
- Width and height, or an aspect ratio, on every image and video.
- The main image in the HTML, not lazy-loaded, with fetchpriority high.
- Lazy loading for everything below the first screen.
- Upload rules written down so new images follow the same pattern.
A worked example: the hero image
Take a fictional home page whose hero photo is a 2400 by 1600 pixel JPEG of about 900 KB, set as a CSS background and lazy-loaded by a slider script. On a phone, that image is the LCP element. The browser cannot find it until the CSS and the slider script have both loaded, so resource load delay is long; then it downloads far more pixels than a 400-pixel-wide screen needs, so load duration is long too [5].
The fix touches every rule in this guide. Move the image into the HTML as an img element so the browser discovers it immediately. Remove lazy loading from it and add fetchpriority="high". Generate AVIF and WebP versions at four or five widths with a JPEG fallback in a picture element, and use sizes so phones download a small file. Add width and height so the space is reserved. In this kind of case the file a phone downloads can shrink to a fraction of the original, and the image starts downloading almost as soon as the HTML arrives.
Images that are not photos
Logos, icons and simple illustrations are often shipped as PNG files many times larger than needed. MDN recommends SVG for diagrams, charts and other images that must be drawn accurately at different sizes, and notes that most icons have vector versions that should be preferred [2]. An inline or cached SVG icon set is usually smaller than a set of PNG icons and stays sharp on every screen. Screenshots and line art that must stay raster images do better with lossless encoding than with heavy JPEG compression [2].
Video and animated images
Animated GIFs are among the heaviest files on the web for what they show. A short muted video file, or an animated WebP, is usually far smaller. Background videos deserve particular caution on mobile: they cost data and processing time and are often the LCP element without anyone realizing it. If you keep one, give it a lightweight poster image, reserve its space with an aspect ratio [4], and consider showing only the poster on small screens.
Keeping it that way
Image optimization tends to decay as new content is added. The most reliable protection is automation: let the platform or a CDN generate sizes and formats on upload, so authors cannot accidentally publish a 6 MB photo. Where that is not possible, write down simple upload rules, for example a maximum width and file size for each type of image, and check new pages occasionally. WooCommerce's performance guidance makes the same point for stores: choose suitable formats, compress before upload and serve appropriately sized images for each device [7]. For stores, our e-commerce speed work covers product galleries and collection thumbnails template by template.
Image format questions
Should every image be AVIF?
Not necessarily. AVIF often compresses best, but WebP encodes faster and is very widely supported. Many sites serve AVIF where supported and WebP or JPEG otherwise.
Does lazy loading always help?
Only for images below the first screen. Lazy loading the main image delays Largest Contentful Paint, which is the opposite of what you want.
Are width and height attributes still needed with responsive CSS?
Yes. Browsers use them to work out the aspect ratio and reserve space before the image loads, which prevents layout shift.
Sources
Opened and checked on November 3, 2026.
- The most effective ways to improve Core Web Vitals, web.dev. Primary documentation (cites HTTP Archive and Chrome data), last updated October 31, 2024.
- Image file type and format guide, MDN Web Docs. Reference documentation, last updated October 8, 2026.
- Serve responsive images, web.dev. Primary documentation, last updated November 5, 2018.
- Optimize Cumulative Layout Shift, web.dev. Primary documentation, last updated February 7, 2025.
- Optimize Largest Contentful Paint, web.dev. Primary documentation, last updated March 31, 2025.
- Performance best practices for Shopify themes, Shopify developer documentation. Primary platform documentation, checked November 3, 2026.
- How to optimize performance for WooCommerce stores, WooCommerce developer docs. Primary platform documentation, checked November 3, 2026.