Optimise? Optimise!

Over the past years, a web page load optimisation cult emerged. Honestly I was sceptical about it – internet speeds increase and I thought there is nothing to worry until you are hosting something really heavy like a multimedia entertainment portal. However we recently launched Nerrvana – Selenium testing cloud service and we found out that marketing site pages are loading slower than we expected. So I rolled up my sleeves and started the optimisation process.
After 10 minutes of searching I found out that all recommendations are basically the same and I took the most famous – “Best Practices for Speeding Up Your Web Site” from Yahoo. If you haven’t read it yet I recommend visiting this resource and reading it. It will help you understand why we are writing this post here. Your reaction may be different to mine, but mine was:

- Excellent, finally I found a full list of optimisation techniques with explanations
- Hmm, Ok we’ll try this one too
- Do I really need this one?
- Will this article finish soon?

Surely someone was able to implement all the recommendations, but I had other plans for the coming months, so I decided it would be nice to do less for more. Initially it was quite clear that not all recommendations will have the same effect, some will give a significant impact, and some won’t justify the effort. But how do you choose the right techniques? Yahoo optimisation results are published here and could be beneficial for us to study. I had a suspicion that the usual marketing site is different from Yahoo portals and our results will also be different. This was a point when I decided to optimise Nerrvana’s home page and share the results, hoping it will help you to determine the usefulness of these techniques.

So, to summarize all 35 rules from Yahoo’s article in relation to the normal marketing site, we can build the following list:

  1. Reduction of number of trips to the server by using the CDN and image sprites
  2. Minimizing CSS and JS
  3. Caching
  4. Compressing content with GZIP

Before we go any further let us show the initial data on the page load. All measurements were done in Firefox 13.0.1:

Page size 766.8Kb, download time – 3.55s, 3.3s, 3.33s.

Let’s begin. Before starting building sprites I checked our images. Of course, while building our web site, we always tried to create images optimized for the web, but nonetheless, it turned out that they can be reduced even further. For some of them I removed transparency, replacing it with the current background, somewhere just reduced resolution, eventually the page size went down to:

Page size544.6Kb, load time remained at 3.3s

This result strengthened my skepticism. Nevertheless, I decided to continue. The next step was to use the jQuery library from the CDN instead of a local version. In the screenshots below you will see CDN code.jquery.com. Later we moved to ajax.googleapis.com, because it allows the use HTTPS. That’s what we got by simply replacing the path to jQuery:

As you can see, the time dropped by 0.6 seconds, not bad for about 3 seconds of total load time, right? Well, we are at a point when we need to create sprites. I will not talk about specific tools; you can easily find them yourself. I just want to mention a very convenient plug-in for FireFox called Yslow, created by Yahoo. I found it very handy. With regard to the creation of sprites this plug-in shows downloadable images, placing them on the basis of the CSS or the direct insertion into HTML. Finally I created sprites and here are my next set of measurements:

Here, I think, we have the most interesting results so far. Let’s dwell on it a little bit. The total page size increased by about 17Kb, but the number of requests has decreased from 23 to 17. This leads to page load time decreased by another 0.25 seconds. Thus with two steps – CDN & sprites, we have already cut almost a second. Remember, we work with a pretty simple page. It was Friday evening and I wouldn’t promise to show you all the results, I would have stopped at this point and went to the pub. So I kept working on my blog post …

We finished with the reduction of the number of trips to the server by using the CDN and image sprites. Now it is time to minimize CSS and JS files. This is not as simple as it might seem at first glance. Implementation of the compression process is a hidden cost. Have you ever tried to edit a compressed CSS file? Not much fun, right? I am not a masochist and we immediately decided to use uncompressed files in development but compress them only on production systems. As a result we needed to make changes to the application. But that’s not all. There is some more to it. We needed to decide how to compress the files. The easiest option is to put responsibility on the person committing such a file. This, of course, quickly translates into a kind of punishment – you changed the file, then you must compress it.

We went the other way; we use Jenkins as a continuous integration server and he “gladly agreed” to take care of this. So we have prepared two new Jenkins jobs – one for CSS and the other for JS compression. From this point we did not need to remember about compression – a commit initiates Jenkins which in turn compresses files and deploys to the production server. As it takes time to “talk” to Jenkins and describe in detail what needs to be done, I mentioned earlier about the hidden costs of an implementation. However, we should stop talking integration talks. Let’s continue. As a tool for compressing, we chose YUI Compressor, because it knows how to compress both CSS and JS files. We obtained the following results:

Page size 501.8KB, load times – 2.5s, 2.38s, 2.6s.

As you can see we did not gain anything from compression. The explanation is quite simple – the page uses only one JS file (jQuery library loaded from CDN) and 2 CSS files with total size of less than 17Kb. If most of your pages are like this, using this technique appears to be a waste of time.

The next step is to set up caching. We set an expiration date of one week for pictures and 2 hours for HTML, JS & CSS. Results with a full browser cache:

Load times – 1.72s, 1.83s, 1.78s

These are excellent results, but do not be obsessed over them. The majority of visitors come to your site with an empty cache. This means that only regular visitors will be able to take advantage of this optimisation technique.

Finally we turned on content compression with GZIP. We obviously understood it won’t have any impact on our home page (btw, same reasons as CSS, JSS files minimisation) – too little content to compress. Nevertheless, the page size decreased slightly with small time load improvements:

Page size – 484.1Kb

Load time with empty cache – 2.52s, 2.55s, 2.53s

Load time with full cache – 1.72s, 1.72s, 1.69s

To summarize, the page size for our home page has been reduced from up to 766.8Kb to 484.1Kb, the average load time from 3.39s to 2.53s.

We also measured two more pages – FAQ which is even smaller and Get Started a big page with a large number of images. You can check results in the table below.

FAQ
  Page size Time 1 Time 2 Time 3
Initial 362.1KB 3.17s 3.58s 3.13s
Min CSS+JS 187KB 2.86s 2.08s 1.89s
With GZIP 167.2KB 2.05s 2.02s 2s
 
Get Started
  Вес Time 1 Time 2 Time 3
Initial 1 MB 5.14s 5.14s 5.2s
Min CSS+JS 668.1KB 4.06s 3.56s 3.86s
With GZIP 634.7KB 3.45s 3.5s 3.56s

/bimg src=”http://www.deepshiftlabs.com/dev_blog/wp-content/uploads/2012/07/after_use_jquery_from_cdn_small.gif” alt=”" title=”after_use_jquery_from_cdn_small” width=”700″ height=”192″ class=”aligncenter size-full wp-image-1730″ /время загрузки с пустым кэшем – 2.52c, 2.55c, 2.53c/td

This result strengthened my skepticism. Nevertheless, I decided to continue. The next step was to use the jQuery library from the CDN instead of a local version. In the screenshots below you will see CDN code.jquery.com. Later we moved to ajax.googleapis.com, because it allows the use HTTPS. That’s what we got by simply replacing the path to jQuery:

, created by Yahoo. I found it very handy. With regard to the creation of sprites this plug-in shows downloadable images, placing them on the basis of the CSS or the direct insertion into HTML. Finally I created sprites and here are my next set of measurements:

Here, I think, we have the most interesting results so far. Let’s dwell on it a little bit. The total page size increased by about 17Kb, but the number of requests has decreased from 23 to 17. This leads to page load time decreased by another 0.25 seconds. Thus with two steps – CDN td/tr
2.86с/td

Print this post | Home

Comments are closed.