The impact of html writing on gzip compression rate

A few days ago, I saw Xiao Du sharing an article in the group, "The impact of HTML writing on gzip compression rate", so I also analyzed this point.
I don’t know if you have read this article. The author is from WeiboLazy Exchange Meeting. Let me briefly describe its content here.

The Gzip algorithm is mainly composed of the Haferman and LZ77 algorithms.
If there are two pieces of content in the file that are the same, then as long as we know the location and size of the previous piece of content, and through a specific compression identifier,
we can determine the content of the next piece. So we can replace the latter piece of content with a pair of information such as the position length.

Example

After gzip compression, the size seen in the chrome developer tools is 563B.

After shuffling the order of the attributes of the input tag:

gzip compression, the size seen is 578B.

The content of the article is about this. Then, I thought about it decisively, would CSS have similar effects?
First write the attributes in the CSS file in order:

@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; line-height: 26px; color:green;}

The size seen by gzip is 463B
After the attributes are disordered:

@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; color:green; line-height: 26px;}

The size after gzip is 464B

From this we can conclude that not only html, but also CSS has similar effects.
Some people may ask, what will happen if there are other classes between the lines?

@charset "utf-8"; .f1{font-size:10px; color:red; line-height: 22px;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}

size:482B

@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}

size:480B

This result and the above conclusion It’s different.
It can be seen that the continuity between rows may also have an impact on the compression rate.
In other words, the greater the code similarity rate, the higher the compression rate.
Whether it is in terms of compression rate or code neatness and beauty, we should write the code in order, which facilitates the team and compression.

The difference in size/content values in the network of chrome developer tools:
In addition to researching this aspect, I discovered the Network/Size column in chrome developer tools Somewhat difficult to understand.
I have been struggling with his Size and Content for a long time. Don't know what they mean. Sometimes the size is larger than the content value, and sometimes the size is smaller than the content value.
After CJ’s guidance and my own experiments, the following results were obtained.

Size value refers to the size of network transmission content, which includes the gzip size of Request/Response headers and the gzip size of file content.
The Content value refers to the gzip decompressed size of the main content body, which is the size of the page file.

If you see that the Size is larger than the Content value, it means that its headers are much larger than the body's gzip decompression, and vice versa.
You may find that the size value obtained when the page is accessed for the first time is much less than the size value after refreshing. That's because the page has cache turned on, so there is no need to reload it from the network.
Personally, I feel that the value of FireBug is more intuitive than the value of Chrome. The size on FireBug is the value of gzip. It seems that the size of gzip is not found in chrome.
Unless the server-side returns a Content-Length field in the header information, you can also see the gzip size from this field. But this field is usually not output.

The above is the detailed content of The impact of html writing on gzip compression rate. For more information, please follow other related articles on the PHP Chinese website!