WebP routinely produces files 25-35% smaller than an equivalent-quality JPEG, and unlike JPEG it also supports lossless compression and transparency — genuinely better than both JPEG and PNG at what each does, for browsers that support it. The catch is exactly that last clause: "for browsers that support it," which is why WebP delivery needs a fallback strategy, not a blind format swap.
What you'll learn in this lesson
- Adding a WebP conversion effect to an existing image style
- Why you serve WebP conditionally, never as an unconditional replacement
- The
<picture>element as the real fallback mechanism
Adding WebP conversion to a style
# Add a format-conversion effect after your existing scale/crop effects.
effects:
crop_scale:
id: image_scale_and_crop
data: { width: 300, height: 200 }
weight: 0
convert:
id: image_convert
data: { extension: webp }
weight: 1The image_convert effect runs after your sizing effects (note the higher weight) and outputs the derivative in WebP format instead of the source's original format — the same lazy-generation model from the earlier Image Styles lesson applies here too.
Why you never serve WebP unconditionally
<img> with a WebP-only source means those clients see a broken image instead of a slightly larger JPEG — a real regression, not an optimization, for whatever fraction of your traffic that affects.The real fallback mechanism: <picture>
<picture>
<source srcset="{{ image_style_url('article_thumbnail_webp', file_uri) }}" type="image/webp">
<img src="{{ image_style_url('article_thumbnail', file_uri) }}" alt="{{ alt }}">
</picture>The browser itself decides: if it understands image/webp, it uses the <source>; if not, it silently falls through to the plain <img> tag's JPEG/PNG source, no JavaScript or server-side browser-sniffing required. This is the standard, robust way to serve WebP — never a blind unconditional swap.
The Responsive Image module goes further
Core's Responsive Image module (covered fully in the next lesson) already generates <picture>/<source> markup for multiple screen-size breakpoints — adding WebP variants to a responsive image style combines both techniques: different sizes for different viewports, and the best format each browser supports, together.
Quick check: a developer proposes replacing every image style's output format with WebP directly, with no fallback. What's the risk? If you said clients that don't support WebP would see broken images entirely, not just a larger file, you've understood exactly why the
<picture>fallback pattern is mandatory, not optional.
Key takeaways
- WebP is genuinely smaller than JPEG/PNG at equivalent quality, but only for clients that support it.
- Add WebP via an
image_converteffect after your sizing effects in an image style. - Always serve WebP through a
<picture>/<source>fallback, never as an unconditional format replacement. - The browser itself picks the supported format — no JavaScript or server-side sniffing required.
Coming up next
You've now got format optimization covered. Next, the size dimension specifically: serving genuinely different image sizes to different screen widths with Responsive Images.