Speed advice on the internet has a habit of sounding like a command shouted from a passing car: “CONVERT EVERYTHING TO AVIF!” Then you try it, something goes sideways, and you end up with a homepage full of blank squares and regret.
So let’s do this properly.
WebP and AVIF can absolutely make your site faster. They can also create weird edge-case problems if you deploy them without a safety net. The goal here isn’t “new formats at all costs.” It’s “new formats, safely,” with fallbacks, testing, and a rollout strategy that won’t break your site at 2am.
WebP vs AVIF: what each is best at
Think of WebP and AVIF as two different kinds of suitcase packers. Both can help you travel lighter. One is fast and reliable. The other can compress like a wizard, but sometimes takes longer to pack.
Compression efficiency vs encoding cost
AVIF usually wins at squeezing file sizes down, especially for photos. You can often get smaller files at similar visual quality compared to WebP. The catch is that AVIF encoding can be slower and more CPU-hungry, which matters if you’re generating images on the fly or doing conversions at request time.
WebP is typically quicker to encode and decode, widely adopted, and still delivers strong savings compared to JPG and PNG.
So the trade is simple: AVIF often gives you smaller files, WebP often gives you easier operations.
Real-world use cases: photos, graphics, transparent images
For everyday website photos (product shots, blog images, banners), AVIF can be a big win when you’re chasing performance. WebP is also excellent here and often “good enough” while being simpler to roll out.
For graphics, logos, UI elements, and anything with sharp edges, you want to be a bit careful. These are the places where compression artifacts show up first, especially around text and high-contrast lines. Transparent images are supported by both formats, but they deserve a quick visual check in real page context.
A practical approach is to treat AVIF as your high-efficiency option for photo-heavy pages, and WebP as your sturdy workhorse across the board.
If you’re looking for a straightforward way to create AVIF files for testing or rollout, an AVIF image converter is a handy starting point.
Safe deployment strategy (no broken images)
This is the part most “quick tips” skip, even though it’s the part that prevents disasters.
The safe strategy is simple: serve the best format the browser can handle, and always have a fallback that every browser understands.
Format negotiation: AVIF first, WebP fallback, JPG/PNG last
The gold-standard pattern is:
AVIF first, then WebP, then JPG/PNG.
That way modern browsers get the smallest files, slightly older browsers still get WebP, and everything else still gets something it can display. No broken images. No awkward “works on my laptop” surprises.
Depending on your stack, this format negotiation can happen at the HTML level (picture/source), at the CDN layer, or at the server rewrite layer. The mechanism changes. The goal does not.
Responsive images: srcset and sizes planning
Modern image formats are only half the story. The other half is not shipping a 2400px-wide image to a phone that will display it at 390px.
Responsive images are how you stop that from happening. In practice, that means planning srcset and sizes so browsers can choose the smallest appropriate file for the viewport.
If you do this well, you often get speed improvements that feel almost unfair: pages load faster, bandwidth drops, and your “largest contentful paint” element stops being a heavyweight.
When to avoid conversion (small assets, already-optimized images)
Not every file needs to be touched.
If an asset is tiny, already optimised, or loaded rarely, conversion may add complexity without meaningful benefit. The same goes for assets where pixel-perfect edges matter and you’ve already got them in a best-fit format, like a well-optimised SVG icon.
A good rule is: prioritise the images that are large, above the fold, and frequently used across templates. Those are the ones that actually move the needle.
Implementation patterns by stack type
There are a few “shapes” this work tends to take, depending on your hosting stack. Each has its own personality, and its own ways of causing trouble if you’re not careful.
CDN image optimization approach
This is the “let the CDN do it” route. Many CDNs can automatically serve modern formats based on browser support, often by looking at the request headers and delivering AVIF or WebP when possible.
This approach can be extremely effective because it centralizes optimization and keeps your application simpler. It also means you can roll out improvements without rebuilding your site.
The main thing to watch is caching behavior. You don’t want a CDN to cache one format and accidentally serve it to incompatible browsers. A good CDN setup accounts for that using the right cache keys and content negotiation logic.
Build-time conversion approach (static sites, Next.js style pipelines)
Build-time conversion is the “clean and controlled” approach. You generate derivatives during your build process, store them alongside originals, and ship them as part of your deploy.
This is especially common in static sites and frameworks with image pipelines. The benefits are predictability and speed at runtime: you’re not doing expensive conversion work while users are waiting.
The tradeoff is storage and build complexity. But if you’re already using a modern build pipeline, it can be the most stable long-term solution.
Server-side rewrite approach (careful with caching)
Server rewrites can swap requested JPG/PNG files for AVIF or WebP versions behind the scenes. This can work beautifully, but it’s also where caching mistakes can cause confusing regressions.
If you go this route, treat caching as part of the feature, not an afterthought. You want to ensure that once a browser is served an AVIF, it keeps getting an AVIF when appropriate, and that other browsers don’t get “poisoned” caches with formats they can’t display.
This approach can be powerful. It just demands discipline.
Compatibility and testing
Modern formats are broadly supported, but “broadly supported” isn’t the same as “universally safe.” This is where fallbacks and testing keep you out of trouble.
Browser support reality check and fallbacks
Most modern browsers support WebP. AVIF support is also strong across current versions, but you still want fallbacks because edge cases exist: older devices, embedded browsers, certain in-app browsers, enterprise environments, and that one client who hasn’t updated anything since the dawn of time.
If you implement negotiation correctly, those users simply receive WebP or JPG/PNG without noticing. That’s what “safe deployment” looks like: nobody has to think about it.
How to detect regressions: visual, performance, analytics
A good rollout catches problems early, in three ways:
Visually, you want to compare before and after on real templates, especially images with text overlays, gradients, and sharp edges. Those are the first places artifacts appear.
Performance-wise, watch your page weight, image request counts, and anything tied to user-perceived speed like LCP.
And analytics matters too. If something breaks, you often see it as sudden changes: increased bounce rate on image-heavy pages, weird dips in engagement, or spikes in errors. When images fail silently, user behavior becomes your smoke alarm.
Operational tips
This is where you make the whole thing sustainable. A one-time conversion is easy. A system that stays fast and doesn’t become fragile over time is the real prize.
Cache invalidation strategy
Any time you change your image pipeline, you should assume caches will try to keep the old world alive.
Make sure you have a clear approach for cache invalidation when you swap formats or regenerate derivatives. Versioned filenames, cache-busting query strings, or controlled purge strategies are all common solutions. The point is to avoid serving stale assets or mixing old and new derivatives unpredictably.
Storage strategy (store originals, generate derivatives)
Keep your originals. Always.
Store the source files as your “truth” and generate WebP/AVIF derivatives as outputs. That way you can re-encode later if you change quality targets, swap encoders, or update your pipeline.
It also means you can roll back easily if a format introduces an edge-case problem in a specific template. Derivatives are replaceable. Originals are your safety rope.
Copyright @smorescience. All rights reserved. Do not copy, cite, publish, or distribute this content without permission.
