Why it doesn't make sense to gzip all content from your web server

Save CPU resources by following these compression tips

Performance tuning your web server is super important. You can gain a significant speed boost while reducing server load by using caching and other techniques. From a client perspective, reducing network transmission and bandwidth is also important, that’s where gzip compression comes in.

Gzip has been in widespread use for over 20 years now. It’s a solid and performant compression algorithm most popular on unix based systems. Its ubiquity on the server side has prompted basically every web browser to support gunzip, the DEFLATE operation, meaning the browser can accept a gzip compressed payload and decompress it on the client side. This offers an opportunity to reduce bandwidth between a web server and a web client which results in faster page load times.

Because the client can automatically handle gzip compressed content, the web server can be configured to gzip content responses prior to transmitting them to the client. In most cases this makes sense to establish, but a complete blanket gzipping of all content is a waste of CPU resources on the server, here’s why.

Each time a resource is compressed on the server, the CPU must perform the work to apply the compression. Granted, it’s not a ton of work, but it can quickly add up if you’re hosting a busy website or many sites. If you can avoid pointless compression, you can make better use of your server hardware. There are two primary cases you want to avoid:

1) Image and PDF compression

You should not allow your web server to compress image files or PDF files. The reason being that these files are already compressed and by compressing them again you’re not only wasting CPU resources but you can actually make the resulting file larger by compressing them again.

One notable exception here are SVG file types. While not technically an image file, it can sometimes be lumped in with image content types. You should definitely compress SVG content as the file size can be reduced dramatically (usually 70%).

2) Small files

This one is a little less obvious and there are two components. For starters, if you’re compressing files that are smaller than the MTU size of a TCP packet, you’re wasting your time. 1500 bytes is the MTU size for the internet since that is the largest size allowed at the network layer. If you take a file that is 1300 bytes and compress it to 800 bytes, it’s still transmitted in that same 1500 byte packet regardless, so you’ve gained nothing. That being the case, you should restrict the gzip compression to files with a size greater than a single packet, 1400 bytes (1.4KB) is a safe value.

Another consideration with file size is the cost of compressing moderately small files. Some say that it’s not worth it to compress files smaller than even 5KB or 10KB. While that is a topic of debate, what’s clear is that you can reduce overall CPU usage on a web server (if it’s CPU starved) by increasing the file size threshold of gzipped content. This comes at the cost of increased bandwidth, but the proponents say speeds are high enough today that sending a 5KB transmission is nothing to worry about.

Clouding the issue, Google’s PageSpeed tool warns you that you should be gzip compressing basically everything, even sub 1400 byte files. This leads to some misconception when a client stumbles onto the tool and sees these uncompressed resources being flagged as a problem. If you keep these tips in mind and consider your typical server requirements, you can get more from your hardware by using the resources more efficiently.

ITWorld DealPost: The best in tech deals and discounts.