I was recently tasked to come up with some recommendations on how to improve the speed of a web application for a client. The task was created because of the perceived slowness of the application when users were running the application over a cellular network. While there are usually code based optimizations that can be done I first set out to look for a simple change that could be implemented and would produce a huge impact.
Enterprise application development often entails writing applications that run over the web using a protocol called HTTP. The most prevalent client of this protocol is the web browser. Most devices, like laptops, phones and printers, have at least one web browser installed. Applications are built to send content to a web browser so that the content can be displayed to the person requesting it. The problem with this content is that it resides on a resource that can be very far away from the device with the browser. Depending on the bandwidth (i.e. How much data can travel per second) some content can take a long time to get from the resource it is stored on to the device that wants it.
The content sent by an application can be static or dynamic. The static variety can take advantage of caching where the content is retrieved only once and then it is stored closer to the web browser for a defined period of time. The dynamic variety is much harder to cache, because of the variability in the content and how often it should be refreshed. Caching can make the user experience much better when a user repeatedly visits a site. The problem with that approach is that many people won't bother coming back if the initial experience is poor. This experience becomes a major factor with devices that rely on cellular networks to transmit data.
My client had some pages that required a large amount of data to be downloaded. For a comparative example, let's look at a large page from Wikipedia's long page section. The content from Wikipedia is dynamic as people update it constantly. As an example let's say a page is 2,088,219 bytes long. Below is an approximation of how long it would take to download the page depending on the bandwidth. Note the time it takes for the user to load this page on a network with a poor connection. As you can imagine the users of the client's application were annoyed when a page took almost three minutes to load a page.
| Home (30 Mbps) | Strong Wireless (1 Mbps) | Weak Wireless (100 Kbps) |
| <1 second | 16.7 seconds | 167 seconds |
When I looked at the request/response exchange using Fiddler, I noticed that the page was taking less than two seconds to process and that the perceived slowness was simply due to the time spent downloading the page. The other thing I noticed brought a smile to my face because I knew I could make a change that would instantly make the user's experience better.
The application I was looking at happened to be running on Windows and using IIS as the web server. Supported versions of IIS have a feature that is disabled by default, called compression. Provided the client web browser supports it, this feature will take the content and shrink it before it sends it to the client. Provided the server CPU isn't frequently above 80%, turning it on provides spectacular results. Looking at the Wikipedia example from earlier, compression set at level "9" will result in the data being almost 90% smaller (267,932 bytes) and will also result in the user's experience being almost 90% faster.
| Home (30 Mbps) | Strong Wireless (1 Mbps) | Weak Wireless (100 Kbps) |
| <1 second | 2.14 seconds | 21.43 seconds |
I highly recommend looking at your web sites and applications to see if you can apply compression to your site. Your mobile users will thank you.
