Comment by linsomniac | Hacker News Reader

Comment by linsomniac | Hacker News Reader

We just had tried brotli and decided not to implement it yet.

One of our devs just returned from a conference super excited about brotli. I'm the ops guy and want to try to support excitement, so I spent the better part of 2 days setting up an experiment, but I was skeptical. I'd been keeping my eye on brotli for years.

I first went out and looked for some existing evaluations of brotli, and found years old write-ups, one from Cloudflare from 2015, and another but I can't remember the details there. They both concluded that brotli wasn't ready yet, but they were also old...

Our stack uses Apache on Ubuntu 16.04, and the first stumbling block was that the Apache version on 16.04 is just a bit before the mod_brotli was added. So I used Ansible to spin up an 18.04 web server which did have the right version of Apache. But, apache is built without brotli support. So I ended up having to build my own custom packages, which went fairly smoothly.

We have one particular asset that right now we would like to speed up. It is a big JSON data structure. The dev did some testing and found that his 350K data-set (with gzip) ended up as 320K with brotli.

Maintaining our own custom Apache packages, and possibly having to upgrade our entire stack from 16.04 to 18.04, plus resolve known problems with OS packages that we've seen in 18.04, for a <10% compression gain, for our cherry-picked "best example for brotli wins"?

Our decision was that if we could have just turned it on via changes to the Apache configs, we would have done it. But as it is, it's not worth it for us to do.

YMMV.

Cloudflare now supports Brotli compression through their Dashboard (it's in the Performance tab). We've been using it for at least a month and haven't had any issues with it.

We didn't do any before/after testing to see how much data it saved our users but the small tests we've done in the office showed around a 2-5% size reduction for our static assets which was great to see for all the effort of toggling a switch.

I understand this isn't because of some evil plot or crazy corporate machination, and I'm talking of different teams, but it's interesting how Google (which spends a lot of resources on developer relations and web performance education) created Brotli, released it, and then mostly stopped advocating for it.

May be because Brotli was mainly for WOFF2 font format, so mission accomplished?

None of that has anything to do with brotli. Blame the distro or the package maintainer.

His point is that brotli's advantages aren't big enough to justify it until it becomes ubiquitous. Compression improvements of less than 10% just don't justify much effort to get ahead of the curve (in most situations).

Does it matter? The OP's evaluation methodology, for better or worse, is the one a big segment of the population uses to evaluate new technologies. It's critical to make sure that packaging is smooth, defaults are set reasonably, and tutorials are up to do --- otherwise, nobody's going to use your stuff no matter how good it is.

2.5 is the development branch. That should not be used in production.

The versions I was speaking of were Ubuntu 18.04 = 2.4.29, Ubuntu 16.04 = 2.4.18, mod_brotli was introduced in 2.4.26.

Part of Operations is weighing new and shiny features versus the maintenance cost of supporting them. You can make an amazing amount of work for yourself by deciding you are going to run the latest and greatest, and becoming the maintainer of your own custom distribution. My shop is on the small side for deciding to bite that off though, so we try to leverage Ubuntu's expertise in doing that whenever possible.

The problem you're describing is more about your choice in stack than brotli. NginX solved this problem with dynamic modules. I would argue that compiling your own software is a core part of servers and apart of running any service on the web that you are developing custom software with. It should be an automated process with release schedules the same as anything else, because not knowing how to build your stack will become painfully obvious when the 'official' releases have a problem.

Apache has dynamic modules too, and they're generally better designed. In nginx they were added later and a module compiled against one version of nginx won't work against any other. With Apache you could download a mod_brotli binary module and use it with any (2.4) Apache build.

(I used to work on mod_pagespeed)

That's what I had hoped for, but I didn't come across any stand-alone builds of mod_brotli, only the one included with 2.4.

We're going to have to agree to disagree there. Leveraging other people's work in building an LTS is money well spent, especially when you can get it for free. Managing your own custom builds, is a fairly big job when done right, even when automated.

I know how to build my stack, it's encoded in Debian packages all around the Internet.

Cloudflare analysis divides size difference by time difference. That function is commutative and cannot be used for meaningful comparisons. This leads to faulty numbers and faulty analysis.

Speaking of Cloudflare, they do brotli encoding for you at the free tier. Not sure about other CDN's but I'm sure it's a matter of time.

It makes sense at the scale of a CDN, but I can't see it being worth it for anyone else (re: other threads here).

Reply on news.ycombinator.com