Troubleshoot a webserver that does not apply gzip compression
Troubleshooting a webserver that does not apply gzip compression
Being a webserver administrator involves being responsible with initial deployment and configuration of the Linux based webserver, database, CGI backend and many others. Another interesting task is when you or your marketing department discovers that, after working weeks and months at the optimization of the server and web application, the website receives a bad mark from sites that measure website speed, optimization, gzip compression and many other factors.
Since this article is called “Troubleshooting a webserver that does not apply gzip compression”, let’s discuss a little about gzip compression and what is it good for (other than the fact that major web dealers yahoo, bing and google recommend it).
What is gzip compression and why is it good for a website:
Because of what it does. Originally HTTP and HTML (protocols that are the living soul of the web today) are based on TEXT content. We all know that a this type of content benefits the most from compression (see http://en.wikipedia.org/wiki/Data_compression).
Some web pages, CSS, Javascripts or any other types of text files could become quite large in size which is a good thing if this means your website evolves. But it can also be a bad thing because large files take longer to be transferred from your webserver to your customer’s web browser. For example a typical (nowadays) forum or core page of a website can reach more than 100Kilobytes. This amount of data is not transferred all at once, but in batches, known to networks as IP packets. The maximum size a packet can have in today’s internet is 1500 bytes so the the file would need to be split in 69 packets that have to be sent through the network on via a protocol called TCP. One of the benefits of this TCP protocol is that is reliable, it means that a sender (your Linux web server) sends few packets of these 69, waits for your customer’s operating system to acknowledge them and sends few more, increasing the number of packets everytime the client acknowledges previous packets.
Depending on distance between your server and your customer this can be unnoticeable at the speed of light (most data in Internet travels over fiber optic as a laser beam). If your server is on one continent and your customer is from a different continent, this transfer can even last up to one second, only for one file. Rest of the CSS and JS files also need to go through the same pipe.
So all webservers support GZIP compression for text files (images like JPG/JPEG/PNG are already compressed by standard).
How to investigate a case where your NGINX web server does not compress certain files:
GTMetrix is a website that analyses your website and marks it based on more parameters. If one of the bad marks is for “Enable gzip compression” than the thing I like to do to confirm is to construct an HTTP request to the website and confirm GTMetrix is right. You need to copy the URI of the file for which compression is not enabled.
This HTTP request that emulates a client or browser has to contain a specific attribute in it’s header to let the server know we support compression:
Simple HTTP request:
GET /static/js/some-java-script.js HTTP/1.1
Host: vpsie.com
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0If your website supports both HTTP and HTTPS, the easiest is to run a telnet command from any operating system command line to your website’s port 80. If your website supports only HTTPS you can open an HTTP session with openssl with the following command:
$ openssl s_client -connect website.com:443
This command will initiate an SSL/TLS handshake to your webserver, will show a lot of information related to this handshake and at the end will give you an empty prompt. Here is where we inject the HTTP request. Just copy it from the notepad and paste it in the terminal.
What follows is the HTTP header of the server’s response that tells us the status, content type and encoding and the content of the requested file:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 06 Feb 2015 18:48:05 GMT
Content-Type: application/javascript
Content-Length: 190493
Last-Modified: Fri, 06 Feb 2015 18:22:40 GMT
Connection: keep-alive
ETag: "54d50670-2e81d"
Expires: Sat, 06 Feb 2016 18:48:05 GMT
Cache-Control: max-age=31536000
Pragma: public
Cache-Control: public
Accept-Ranges: bytesIndeed, the server responds that the file is an “application/javascript”, but it is not gzip encoded. If we look now at the web server (nginx in this case) configuration file, we see that it enables compression for these content types:
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
But “application/javascript” is not in there. Modify nginx.conf and add this content type at the end of the line and leave the semicolon the last character of the line. Restart the nginx server and give it another try. Your boss will be happier now.
You can actually try those troubleshooting steps on our platform in few minutes utilizing our PCS (Private Cloud Solution) which allows you to have VPSie(s) on a private network – NAT – Port forward – traffic control for inbound and outbound – multiple gateway IPs which you could use for the load-balancing and failover.
