+1 for webp.
Given that browser support for webp is quite broad now, it would be awesome if it was supported as part of the image transformation service.
A very common scenario on the web today is to have a source image where you need to provide variants in both A) the file format, as a fallbacks for older browsers, and B) the image size, for screen density.
For example, let’s imagine I have a high resolution PNG file as my source image at 1024x1024 pixels. And I want to be able to provide webp images for browsers which support it, but also provide PNG as a fallback as well as a variety of sizes for pixel density. If the image transformation service provided an additional parameter where you could specify the image’s file type (say type
), then you could write markup that specifies baseline functionality with enhancements for file format and sizing where supported:
<picture>
<source
srcset="
image.png?nf_resize=fit&w=100&h=100&type=webp,
image.png?nf_resize=fit&w=200&h=200&type=webp 2x
"
type="image/webp"
/>
<source
srcset="
image.png?nf_resize=fit&w=100&h=100&type=png,
image.png?nf_resize=fit&w=200&h=200&type=png 2x
"
type="image/png"
/>
<img src="image.png?nf_resize=fit&w=100&h=100&type=png" />
</picture>
Granted, you could iron out the API contract for this where type
is optional and fallsback to the image extension when not specified, but i’ve included it here for illustration purposes.
In the above scenario, a modern device like an iPhone with a retina screen would get the 200x200 webp image, a device that doesn’t support webp but has a high pixel density screen would get the 200x200 PNG, and an old device that doesn’t support webp or even the <picture>
element would get the basic 100x100 PNG—with each user agent only making 1 request for the appropriate image.
Being able to do these kinds of image transformations on the fly would be