Hello, I would like to be sure that Brotli is actually faster. In my experience, while decompression is fast, compression can be extremely slow.
This is fine for static assets compressed by a build pipeline or at least when the compressed version is cached. It would be a problem for on-the-fly compression of dynamic content, which is what we're talking about here. I expect there's a setting for trading off compression time vs. compression ratio. It should be set appropriately. It isn't worth spending a lot more CPU to save a tiny bit of data transfer. The result could be slower, especially for users with fast connections. I would like to see a quick performance benchmark of gzip as currently implemented in Django vs. brotli with a setting you recommend, to see the effect on compression time (CPU use) and compression ratio. Best regards, -- Aymeric. Le ven. 14 sept. 2018 à 10:01, Johannes Hoppe <i...@johanneshoppe.com> a écrit : > Hi there, > > we all know the the wonderful GZip middleware that allows response > compression. Which is great especially if you are serving large responses. > > Now gzip is only one of many supported encoding types supported by many > browsers. The coolest kid on the block seems to be brotli right now. > It is both faster and smaller in most cases then gzip and has been > standardized in https://www.ietf.org/rfc/rfc7932.txt > > Of course there is already a package that adds brotli support to Django: > https://pypi.org/project/django-brotli/ > > But I would propose to refactor the GZip middleware into something like > "CompressionMiddlware" and add support for both GZip and Brotli > in the same middleware. > > I have the feeling something basing like response encoding should be build > into Django. Of course I would not add a hard dependency to brotli, > but add all methods to `Accept-Encoding` that are actually installed. > > What do you guys think? Is this worth a little refactoring? > > Best > -Joe > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/29cf5142-fa82-4d74-9d8f-5fb0c8be34d0%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/29cf5142-fa82-4d74-9d8f-5fb0c8be34d0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mUesYZ-tmwoXBXFhA4xf3xvdeFaL4O42_5kG_MSBaE7nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
