How HTML and CSS Attribute Order Impacts Gzip Compression Size

Recently I saw a post titled "The Impact of HTML Writing Style on Gzip Compression Rate" and decided to investigate the claim. The author, from a Weibo discussion group, suggested that the way HTML is written can affect gzip compression.

Gzip combines Huffman coding and the LZ77 algorithm. When a file contains identical blocks, the compressor can replace the later block with a reference to the earlier one, using the position and length of that block.

Example:

After gzip compression, Chrome DevTools shows a size of 563 B.

When the order of attributes in an <input> tag is shuffled:

gzip reports a size of 578 B.

The same effect appears in CSS. Writing CSS properties in a consistent order yields a gzip size of 463 B, while shuffling the property order results in 464 B:

These observations lead to the conclusion that not only HTML but also CSS benefit from a consistent attribute/property order for better gzip compression. The continuity between lines also matters; when extra classes are inserted between lines, the size can change (e.g., 480 B in the example), showing that line continuity influences compression.

In short, higher code similarity yields higher compression rates, and orderly code improves both compression and readability for teams.

Understanding Chrome DevTools Network Size vs. Content

Beyond the compression experiments, I clarified the meaning of the Size and Content columns in Chrome's Network panel. Size represents the total amount of data transferred over the network, including the gzip‑compressed request/response headers and the gzip‑compressed body. Content shows the size of the response body after gzip decompression, i.e., the actual page file size.

If Size is larger than Content, the headers contribute more to the transferred data; if smaller, the body’s gzip size dominates. The first load of a page often shows a smaller Size than subsequent reloads because caching reduces the amount of data that needs to be fetched.

FireBug displays gzip values directly, while Chrome does not show gzip size unless the server provides a Content‑Length header containing the compressed length.