Support Forums

Improved image optimisation on Netlify / Netlify Large Media

It would be great to add more transformation options to large media. Things like this: GitHub - axe312ger/sqip: "SQIP" (pronounced \skwɪb\ like the non-magical folk of magical descent) is a SVG-based LQIP technique. would be really useful!


Better image optimisation! Add support to next-gen images like webp :slight_smile:


Add support to QUIC.

Image optimization for Large Media would be great as well


Please add support for Brotli soon! I’ve had great success running it on DigitalOcean and it makes a real difference.


Netlify already gzips files transparently.

However, it would be excellent if Netlify supported serving of precompressed files if present. The reason is that you can often gain a 3-8% savings by using the zopfli algorithm for gzipping, which is fairly CPU intensive and should be done in the build step rather than on a per-request basis.

The same goes for supporting brotli. Dropping a /static/my.js.gz or a /static/my.js.br could transparently serve the right format if requested.


we have a thread, here on supporting brotli:

If we decide to implement, we’ll let you know when we can - we know this is an ask for several people.

As far as serving precompressed files - this is the first time someone has requested this - can you outline your use case a bit more and potentially your experience with this?


Zopfli can reduce the size of files beyond what a simple gzip pass can, but it takes much longer to compress. I think it’s unreasonable to expect Netlify to compress responses with zopfli transparently, but we could achieve the same gains by compressing files in the build process. It would then be up to Netlify to look for a <filename.gz> and serve that if present, instead of gzipping “on the fly”.


Second here for webp format and on transforms.


I’ve also used Zopfli to compress files to <filename>.gz, and I think this sounds like a good idea to be more flexible. This would also allow to add new compressions, e.g. .br for brotli, much easier, as the compression can be done in userspace.

I would be great if both changing quality and transforming the image format was built-in transformations. Such as automatically choosing the best image format based on the Accepts header (e,g, webp, or future JPEG XL), or requesting a specific format with &type=webp. Allowing a quality transform for 0-1 (e.g. q=0.8) would be great as well.


We’re super excited to let you all know that we have implemented Brotli support! We know that many of you have been waiting for this for some time, here it is.


Another suggestion for the snippet injection: Snippet injection Improvement

Cloudflare supports it that way. it is great because you don’t need to worry about the browser not supporting webp. I’d love to see it on netlify. Especially because it has the potential to boost your Google speed index for pages with many images.

1 Like

Now there’s even .avif, which is supposed to be superior to .webp (https://chromestatus.com/feature/4905307790639104).

Would be awesome if this could be used for modern browsers without worrying about breaking older ones.

I would also love to see webp image support please!

1 Like

+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:

      image.png?nf_resize=fit&w=200&h=200&type=webp 2x
      image.png?nf_resize=fit&w=200&h=200&type=png 2x
  <img src="image.png?nf_resize=fit&w=100&h=100&type=png" />

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 :fire:

1 Like

Any more information for format optimizations? That’s all that is really keeping me from switching from 11ty-image plugin over to Netlify LFS. WebP and AVIF seem like good options to start.


1 Like

Another vote for webp support