WebP or AVIF: how to decide per image
Not every image needs the same format. This post walks through a simple decision process for hero photos, product shots, icons and screenshots.
Image performance, explained plainly
Your images are probably the heaviest part of your site.
On a typical page, images are commonly cited as making up around sixty percent of the total weight, more than scripts, fonts and styles combined. This blog covers what that means in practice: which formats actually help, how compression works without visible loss, and how alt text and lazy loading touch both accessibility and search at the same time.
Why this matters
Page weight is mostly a picture problem
Developers spend a lot of attention on JavaScript bundles and font loading, and both matter. But on most content-heavy sites, images are the largest single category of bytes sent to a visitor's browser, and they are usually the easiest category to reduce without touching a line of code.
Typical share of page weight taken up by images
Often cited around 60%, varying by site and content type
This figure moves around depending on the industry. A text-heavy news site will differ from a photography portfolio or an online store with hundreds of product shots. What stays consistent is the pattern: unoptimized images are the first place to look when a page feels slow, and they respond well to fairly simple fixes.
Why doesn't everyone fix this already?
Mostly because it happens quietly. A content editor uploads a photo straight from a phone or a stock library, the CMS displays it at the right visual size, and nothing looks wrong on screen. The file itself can still be several megabytes larger than it needs to be, and that extra weight is invisible until you check page speed tools or watch the network tab in a browser's developer console.
Formats
What WebP and AVIF actually are
Both are image formats designed to store the same visual information in fewer bytes than older formats like JPEG and PNG. Neither is exotic anymore. The question is less "should I use them" and more "does my CMS already support them, and how do I check."
Not sure which format to pick for a specific image?
As a starting point: use WebP as a safe general default because support is close to universal. Reach for AVIF on large photographic hero images where the extra byte savings matter most, and keep an eye on encoding time if your CMS processes images on upload rather than in the background. For small icons or simple graphics, SVG is often a better fit than either format.
Accessibility and search
Alt text does two jobs at once
Alt text was built for accessibility first. Screen reader software reads it aloud in place of an image, so a person who cannot see the picture still knows what it shows. That is the primary purpose, and it should stay the priority when writing it.
Search engines read the same attribute because they cannot interpret pixels directly. A clear, accurate description helps an image show up in image search results and gives a search engine additional context about the surrounding content. Writing genuinely descriptive alt text serves both audiences without any conflict between them.
- Describe what the image shows, not what you want it to rank for
- Skip phrases like "image of" or "picture of", screen readers already announce that it is an image
- Leave alt text empty (alt="") for purely decorative images so screen readers skip them
- Keep it concise, usually one clear sentence is enough
Loading behavior
Lazy loading and Core Web Vitals
Lazy loading tells the browser to hold off downloading an image until it is close to entering the viewport. Applied correctly, it can visibly change several of the metrics Google groups under Core Web Vitals, without touching the images themselves.
In practice: add the native loading="lazy" attribute to images below the fold, leave it off (or set to eager) for anything visible on first paint, and always include width and height attributes. The screenshot walkthroughs show where to find this setting in common CMS platforms.
Free tools
Compressing without visible quality loss
Compression removes data a viewer is unlikely to notice missing. Pushed too far, it introduces visible artifacts. The goal is finding the setting where file size drops sharply and the picture still looks the same to a normal viewer at normal screen sizes.
Around 75 to 85 out of 100 is where most photographs stop showing visible differences to the eye, while file size keeps dropping below that range.
- Squoosh (web-based, made by the Google Chrome team) lets you compare formats and quality levels side by side before downloading
- GIMP and Krita, both free desktop editors, include export dialogs with quality sliders and live file size previews
- Most operating systems include a basic image resizer, useful for scaling down an oversized photo before it ever reaches a compressor
- Many CMS media libraries include a built-in optimizer plugin that runs automatically on upload
Latest posts
Recent from the blog
Writing alt text that helps people, not just rankings
A short guide to describing images clearly for screen reader users, with notes on where search engines quietly benefit from the same habit.
The lazy loading mistake that hurts your LCP
Lazy loading the wrong image can quietly make your Largest Contentful Paint worse. Here is how to tell which images should stay eager.
Start with the walkthroughs
Screenshot-based, step by step, covering compression, format conversion, alt text and lazy loading in common CMS platforms.
Open the walkthroughs