Lately, we had our entire website revamped and as a part of sanity, we redirected a 301 from our old url to new url, which was apparently in a new domain. But here came a challenge, there were a few URI’s we had provided to the the third party and the url they used pointed to the old domain. So we had to write exception rule in our nginx configuration file. After a lot of trial and errors, we figured a working solution for the same. I would like to share the generic version of the configuration file.
We wrote a rewrite rule for the 2 old URIs and redirected the rest of them to new domain successfully.
When your client sends a request to the server it will include a header saying which compression formats it will accept, As you can see it says it will accept gzip, deflate or br compression formats. The server will respond and if available will compress the result in a supported format. Here it supports gzip. Brotli is a new open-source compression format from google that improves on the performance of gzip in many cases. We only care about the HTTP compression.
Brotli only works on an https connection. Which is a good thing because we all want to encrypt the web, right? Installing Brotli
apt-get install brotli
Setting up on Apache
Apache has supported brotli since version 2.4.26 by way of the mod_brotli module. However, I can’t find any information on this so we are installing this module by kjdev
Install the Module
git clone --depth=1 --recursive https://github.com/kjdev/apache-mod-brotli.git
install -D .libs/mod_brotli.so /usr/lib/apache2/modules/mod_brotli.so -m 644
echo "LoadModule brotli_module /usr/lib/apache2/modules/mod_brotli.so" > brotli.load
This has added the .load file to the mods available. We need to create an accompanying config file called brotli.conf, adding:
git clone https://github.com/google/ngx_brotli.git
git submodule update --init --recursive
Rebuild Nginx with our new module
You should run nginx -V to get your config string and add:
cd /opt/nginx-1.13.1/ (or your own path)
./configure YOUR CONFIG STRING --add-module=/usr/local/src/ngx_brotli
Finally, add to your nginx.conf file
In conclusion, the setup for both Apache and Nginx is pretty painless. If the browser does not support brotli it can always fallback to the ever faithful gzip.
What the heck is Brotli?
Just like gzip, Brotli is also a compression algorithm. It is developed by Google and serves best for text compression. The reason being, it uses a dictionary of common keywords and phrases on both client and server side and thus gives a better compression ratio. It is supported by all major browsers :
Does your browser support Brotli? Browsers which support Brotli send ‘br’ along with ‘gzip’ in accept-encoding request header. If Brotli is enabled on your web server, you will get response in Brotli compressed format.
Gzip vs Brotli:
The advantage for Brotli over gzip is that it makes use of a dictionary and thus it only needs to send keys instead of full keywords. According to certsimple,
HTML files are 21% smaller than gzip.
CSS files are 17% smaller than gzip.
Note: Images should not be compressed either by gzip or Brotli as they are already compressed and compressing them again will make their sizes larger.
Fewer bytes transferred not only leads to faster page load but also helps in reducing costs of Content Delivery Network (CDN). Now that we know all these benefits, let’s see how to enable Brotli…
Embracing the Brotli side:
There were two ways by which we can deliver Brotli compressed assets:
Enabling Brotli on our web-server
Enabling Brotli on CDNs
We chose to go ahead with serving Brotli from our web servers and installed it on nginx. Google has provided a module for it which needs nginx to be installed from source. Once installed, the following settings need to be put in nginx conf file:
After this, all content types which are mentioned in brotli_types setting will be brotli compressed. Easy, wasn’t it!
Note: We have to keep gzip settings on nginx intact as clients who doesn’t support br should get gzip compressed files. Although nginx gives precedence to br if both are supported.
Here, our web server will send br compressed assets, then CDN will just cache it and pass on to the browser.
Another way to enable Brotli is via CDN. By this way you don’t have to write any code or install anything in your infra, but this will be a paid service. We went for the ‘Brotli from Origin’ approach (former), as it is more cost efficient and engineering is what we like to do.
Dynamic vs Static Compression:
We talked about a setting ‘brotli_comp_level’ above and promised to explain it later, so here it is. It indicates the compression ratio and ranges between 1 to 11. Higher the ratio, higher the time it will take to compress it. So we used the value 11 for our static assets. For Dynamic assets like API responses , we should use smaller values – a high compression time can backfire, and put all our efforts to improve latency to turmoil.
Brotli from Origin Now Available for Akamai
What is Brotli from Origin? Brotli from Origin specifically configures Akamai delivery to work well for customers that are providing Brotli-compressed resources at origin. The Brotli from Origin behavior allows for Akamai to deliver the Brotli-compressed resource when supported by the requesting user agent; otherwise, when not supported, non-Brotli resources are automatically used.
What are the benefits of Brotli from Origin? With Brotli from Origin, Akamai now has a comprehensive Brotli solution that can be applied for resources already compressed at the origin. By applying Brotli compression to resources, you can reduce bandwidth consumption and improve web performance above and beyond what gzip can do.
How do I enable Brotli from Origin?
To enable it, simply add the behavior through Property Manager (On/Off setting). It can also be enabled through the Property Manager API.
How is Brotli from Origin different from Akamai Resource Optimizer? Resource Optimizer takes resources from origin and applies Brotli compression to them as they come into the Akamai platform. They are then cached and delivered with Brotli compression. Brotli from Origin basically extends this approach to support resources already compressed at origin and enables them to be served through the Akamai cloud delivery platform and back to the browser. In other words, Akamai now supports both origins that provide Brotli compression as well as origins that do not. For origins that do not, Akamai now automatically provides Brotli compression.
100 Continue :- The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.
102 Processing (WebDAV) :- The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
101 Switching Protocols :-The server understands and is willing to comply with the client’s request, via the Upgrade message header field, for a change in the application protocol being used on this connection.The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response. The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.