HTTP compression is a publicly standardized mechanism whereby a web server compresses the contents of the HTTP response before sending it; the compressed data is then being delivered to the client, where it is being decompressed and processed as usual (though more rarely, HTTP request compression could be used as well). It is available since version 1.1 of the HTTP protocol and is a simple and effective way to save time and network resources, and thus improve the end-user experience and customer satisfaction. It can significantly reduce the size of the web pages – up to 75% – and therefore provide the application users with better load times in their browsers.
Although the feature is supported by the majority of modern browsers, including mobile web browsers, in general one should be aware that still there could be browsers which do not work well with this functionality, or do not support it at all. In those cases the communication between the browser and the web server uses uncompressed data. Also, compression naturally comes at the cost of using additional CPU resources, but most of the times this is well worth it, considering the easy and fast way to improve the overall web performance that this solution offers.
The compression feature in a nutshell
The technology assumes that the client and server are capable of performing compression and decompression on their side, and requires from them a brief negotiation dialogue that goes like this:
- the web client declares its support for compression with the Accept-Encoding header in the HTTP request:
Accept-Encoding: gzip, deflate
Modern web browsers usually do this by default, so you don’t have to do anything on your side.
- If the web server sees this header in the request, it may (but is not obliged to) compress the response using one of the methods listed by the client. The web server notifies the web client of this via the Content-Encoding header in the response:
Getting started with Gzip on NetWeaver Cloud
Let’s take for example the explore-ui5 sample SAP UI5 application from the SAP NetWeaver Cloud SDK. Deploying that app without configuring any gzip compression, and requesting its initial page gives the following load experience:
And here is what Firebug shows for the GET request of the heaviest file, which also took the most time to be processed:
Let’s bring Gzip into the game now. For this purpose we will employ an open source third part library, called webutilities. It is Apache 2.0 licensed, and offers some nice features, like: easy to employ servlet/servlet filter mechanism which deals with the compressing; configurable set of mime types that are to be compressed; configurable compression threshold, etc. It also supports decompression of the HTTP request, if it is being sent compressed. We will stick to the default settings for the CompressionFilter given here. In essence this filter uses the standard JDK functionality in the java.util.zip package for performing the Gzip compression, which is to be found in classes like java.util.zip.GZIPOutputStream. That’s why you don’t need to package any additionalgzip utilities inside your application. The filter supports also the compress and deflate encodings.
From the technical point of view, we add the filter inside the application’s web.xml descriptor as shown in the project site:
<filter> <filter-name>compressionFilter</filter-name> <filter-class>com.googlecode.webutilities.filters.CompressionFilter</filter-class> <init-param> <param-name>compressionThreshold</param-name> <param-value>512</param-value> <!-- anything above 512bytes --> </init-param> <init-param> <param-name>ignoreURLPattern</param-name> <param-value>.*\.(png|gif|jpg|tiff|bmp|mpg|jpeg)</param-value> </init-param> </filter> <filter-mapping> <filter-name>compressionFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
and add the webutilities-<version>.jar and yuicompressor-<version>.jar files in WEB-INF/lib folder of the application:
Redeploying the app now shows significant improvement: the static content of our application is delivered 2.5 times faster in a four times smaller response:
Response headers now include the information for the gzipped contents (the same file is again the largest part of the response, and has taken the most time to be delivered):
Many other solutions exist that are providing similar functionality, which from a technological point of view is implemented via the standard Servlet Filter/ResponseWrapper mechanism. Most of them are utilizing the same java.util.zip approach for performing the compression. Of course, you could perfectly try them out and incorporate them into your SAP NetWeaver Cloud application; webutilities is just our choice for the sample shown here.
A notable example for a library which is more flexible and feature-rich in the compression aspect, is the Apache Commons Compress project. It offers several formats for the compressed files that it produces and handles. It also carries its own implementation of the zip format, which they claim to provide capabilities that go beyond the features found in java.util.zip. If you find yourself picky for the compression details, you may want to check this project closer.
Other types of clients
If your client is actually not a browser, you should check with its documentation for how to enable the Accept-Encoding header when sending requests with it. This should be sufficient in order to make use of the compression and its benefits. Although CSS and HTML files would normally make sense in a browser environment only, there could still be use cases where you could benefit from compressing the response; even if you are using a command line client for example (after all, saved time is saved time). In such cases you should keep in mind that you will have to take care for the decompression of the response instead of the browser. For example, on a Linux environment you could call wget and curl like that:
$ wget -O - --header="Accept-Encoding: gzip" <URL> | gunzip > output.html
$ curl -H Accept-Encoding:gzip,defalte <URL> | gunzip > output.html
The case of HTTPS
There shouldn’t be any general considerations and obstacles to compress HTTPS responses as well. That is, encryption and compression of the response don’t have any general problems to work together, as our sample application here shows.
Taking advantage of the HTTP compression mechanism is considered a best practice and is recommended by many experts on website optimization. Moreover, it is being widely used by many popular websites, so it is quite likely that you are already utilizing it in your daily work, realizing it or not.