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).
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=0
If 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:
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.