I would like to share some insights on HTTP Compression . Hope your knowledge will help you optimize your website so they can run faster.

For a website, speed is always the top concern. It is difficult to hold the user back when a request placed on the user’s server , they have to wait a few tens of seconds to wait for a response return, or they simply can’t get rid of the loading indicator spins before being helpless.

Whether you have tried to optimize code, caching static files so that when you have a second request , you don’t have to go to the server get the file , or you have written an optimal sql to increase the time to retrieve data from the database . However, knowing HTTP Compression will also help your web speed better.

We first look once again at how a website is functioning. The conversation between client and server is as follows.

Client : Hey! Get yourself a file called index.html

Server : Wait a minute I look, well here is your index.html file, the file size is 100kb okay, because the file is a bit heavy, the process of moving difficult please wait 3s.

Easy-going client : Ok, I can wait !!!

Yes it is an easy client. What about the fastidious client ?

Difficult client : 3s, huh, too long, is there a way to reduce the file size to move faster?

And so HTTP Compression was born.

1. What is HTTP Compression?

HTTP Compression is a technique that can be integrated into web servers and web clients to improve transfer speed and bandwidth usage by nén files on the server to reduce file size, making the sending process to the client faster. .

Client : Hey! Get yourself a file called index.html

Server : Wait a minute, I’m looking for it, here it is your index.html file, I am trying to compress them to make the file sending process faster

Client : Good work buddy, it only took me a second to receive the file, and now I’ll extract it, but wait, what algorithm are you compressing with?

Server : Forget about me compressing with gzip, so next time I send it, I will send a compression algorithm for you to easily extract.

This is the most basic way to explain the process of compression and decompression of both parties. Here we will go in detail to see how it works offline.

2. Types of HTTP Compression

There are two types of HTTP Compression : End-to-end compression and Hop-by-hop compression . In that end-to-end compression end-to-end more popular. Let’s go find out about these 2 types

2.1. End-to-end compression

End-to-end compression is a method of significantly improving the performance of a website. The entire body of the message will be compressed on the server and then sent to the client . This compressed file will not change during the sending process to the client , though it may go through nodes trung gian (I will explain later on how these nodes).

Modern trình duyệt and server support compression methods, and the only thing to consider is the compression algorithm to use.

In the 1990s, compression technology has grown at a dizzying rate and many successive algorithms have been added to the set of viable options. Currently there are 2 most used algorithms: gzip and br .

To choose the compression method, the browser and server use mechanisms content negotiation by trình duyệt sends server compression algorithm through the Accept-Encoding header with the support algorithms and priority order from left to right. Then the server will choose one of them, use that algorithm to compress the body and then notify the browser the algorithm that it has used via the Content-Encoding header.

Content negotiation is the mechanism used to serve different representations of resources at the same URI, so that the user agent can specify which one is appropriate for the user (for example, image format, content encoding format). come on

The conversation between client and server is as follows.

Client : I can only extract the br and gzip algorithms, because br is the better algorithm I should prioritize, okay? Please read more in Accept-Encoding for the algorithms we can extract .

Server : I read the information, I sent the algorithm information I used to compress and note at Content-Encoding in the response, read there to apply the appropriate decompression algorithm.

But in fact, even though the client and server support the same compression algorithm, the server may still not compress the body of the response. The two common cases leading to this are:

• Data incoming Data has been compressed and the next compression does not make the file size smaller than the original size. This happens when compressing some image formats
• Server is overloaded and does not have enough resources to run due to a required compression operation. In fact, Microsoft recommends not compressing it if the server is using more than 80% of its capacity.

2.2. Hop-by-hop compression

Unlike end-to-end compression, hop-by-hop is the compression process that occurs on node , unlike end-to-end compression on the server .

In fact, connections between these nodes may use different compression algorithms. To do this, HTTP also uses the content negotiation mechanism as mentioned in the end-to-end compression.

As the diagram above, you can see some pretty similar end-to-end compression in how it works. Between these nodes also talk to each other by TE and Transfer-Encoding about encryption algorithms.

The story goes as follows:

Client A : Hey! Get yourself a file called index.html

Node 1 : There is a file request of the client, T can extract by gzip before sending to the client, compress this file when receiving from the server

Node 2 : Oke, I’ve saved the extractable m algorithm, I will forward the request to the server to get the file back

Server: I already sent the file to node 2, size 100kB

Node 2: I compressed it with the gzip algorithm and send it to Node 1

Node 1: I read each Transfer-Encoding that you compressed using br, I will extract them before sending them to the client .

Because the configuration of Transfer-Encoding not easy for Apache and Nginx server , hop-by-hop compression is quite rarely used, this configuration is often used at the proxy level.

3. Configure HTTP Comperssion with Nginx

By default, some nginx servers have configured gzip compression, you can look at the files etc/nginx/nginx.conf the default configuration is as follows:

The default configuration gzip on and gzip_disable "msie6"; . To customize the configuration to optimize compression , please uncomment all the above commands , I will explain through a bit of commands.

• gzip on : Of course, enable gzip compression mode
• gzip_disable “msie6” : Disable compression for User Agent do not support decompression. Specifically here is Internet Explorer before version 6 SV1 , you may not know msie6 is a special mark of regular expressions MSIE [1-6].(?!.*SV1)" .
• gzip_vary on: Set the response header Vary: Accept-Encoding . Some proxy have an error in that they serve compressed content to unsupported browsers. This setting helps the proxy save both compressed and uncompressed content files.
• gzip_proxied : Any allows processing all requests from the client.
• gzip_comp_level 6: This is the compression team level, 1 is the least, 9 is the most. You will have to trade between compression and save CPU to give the appropriate compression level.
• gzip_buffers 16 8k : Setting the number and size of compressed buffers. The default is 4 4k.
• gzip_http_version 1.1 : Enables compression in HTTP version 1.1. Because some configs cannot be installed on low HTTP versions.
• gzip_types : Compressed file formats.

After commenting off the configs, the test results are quite impressive. I tested the configuration using the gzip oneline test tool, the results are as follows.

Turn off compression configuration:

Default compression configuration:

Custom compression configuration:

Looking through the results of the test, we can see that the default compression configuration has been reduced to 1410 byte but the custom configuration has reduced 1378 byte .

Using the Page Speed measurement tool, the results are as follows

Turn off compression configuration:

Default compression configuration:

Custom compression configuration:

So has improved quite a lot =)))

4. Summary

So I have introduced through how HTTP Compression works as well as its effect in speeding up the website. However, when configuring the bridge, a number of points should help me

• Old browser: Although gzip_disable used, it is not anticipated that users will use the old browser. This leads to unzipped files, leading to errors in the website .
• Content compression: Most images and videos have been compressed. Do not try to compress them a second time. Only should compress html, css, js.
• CPU-load: compressing content when it receives a request will consume CPU time and save bandwidth. Often this is a good trade-off if you know the compression speed. There are many ways to pre-compress static content and send it. This needs further configuration; Even if it’s not possible, compressing the returned content is still a good thing. Using the CPU for a faster user experience is also quite worth it, when the attention is negligible.