// you’re reading...

Web Development

Speed Up Your Web Site With Firebug and YSlow

I recently convinced a friend that the Firebug plug-in for Mozilla FireFox is an essential development tool. Well, it’s now time for me to praise YSlow, an extension to Firebug provided by Yahoo!, that analyses your web site, and recommends how to improve performance in the way of download speed. So if you want to learn how to speed up your web site, read on.

I’ve known about YSlow for some time. I analysed my site a while back, saw what needed to be done, but until recently did nothing. Much of what the plug-in recommended was not new to me. It was one of those tasks that I just never got round too.

However, having recently given my company website a facelift, I thought it was an opportune time to make amends. By providing a measurable benchmark (and even a score), YSlow can show you instantly what affect your site optimisations have made.

Some of the recommendations provided by YSlow, might not be available depending on your hosting set up, but most of the improvements are gained by applying common optimisations. Namely:

* compression of web assets
* setting HTTP Expires Headers on web assets
* minimising CSS and Javascript
* combining CSS and Javascript into fewer files

Much of the above can be achieved pretty easily thanks to some great free tools now available (see below).
before.jpg

before optimisation

after.jpg

after optimisation

Above is a snapshot of my YSlow metrics before and after optimisation. I managed to reduce the initial download size by 50 per cent, and decrease the number of HTTP requests from 18 to 11. These are the initial figures, before the cache is primed. In my case, the gains made after assets have been cached, were mainly with regard to the number of HTTP requests being made - reduced from 17 prior to optimisation, down to a single request.

Optimisation was relatively easy. Here’s how the improvements I made.

###Compression of web assets
Compressing the web assets reduces the payload size of each web request. Anything that is not already compressed (such as images) should be. The downside to compression is that the client (browser) must inflate the content upon receipt, but for many home computers these days, the processing power is ample for this task. Similarly, the server must deflate the content prior to sending it, thus putting a load on the server.

If your content is static, one approach is to compress all your assets and upload them to your web server, alongside the uncompressed assets. If you’re using Apache web server, a few Content Negotiation rules can then be added to the Apache config files to return the compressed assets, if the client supports it (the request headers indicate if compression is supported).

Another approach is to compress assets on the fly using Apache modules such as mod_deflate (Apache 2) or mod_gzip (Apache 1.3). This does put some load on the server, and may not always be supported by your web host (mine didn’t allow it).


<?php
ob_start( 'ob_gzhandler' );
?>

I went for a simpler solution. My site is templated using PHP, so adding these few lines to the top of my template header, compresses all the PHP web pages. The remaining web assets - CSS and Javascript are handled seperately (see below)

###Setting Expires Headers
Nothing new here, but how many web designers/developers think about ensuring that expiry headers are set correctly? There’s no rules as to what expiry to set. It all depends on what the site does. BBC News won’t want to cache their content for too long, but don’t want every hit to request their servers, so they set their content to expire after 10 minutes. My site content doesn’t change daily, so I set it to expire after one week.

Again, I used Apache rules to set both the HTTP Expires Header and the ETags, which had the desired effect. My rules in my .htaccess file were as follows:


<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 7 days"
</IfModule>
FileETag MTime Size

###Minimising and Combining CSS JavaScript
This is where optimisation gets clever. It’s a given that reducing white space or minifying CSS and Javascript files will reduce the payload size. The clever bit is in reducing the number of HTTP requests, by combining the files before minifying them. With the adoption of Javascript libraries such as JQuery, Prototype etc. plus the inevitable breakdown of CSS files into more manageable files, there is plenty of opportunity for optimisation here.

I used Combine. Simply drop combine.php into the root folder of my web application, and modify my HTML to call this script rather than URI to the various assets as shown below. Before I used combine, my HTML header referenced 12 CSS and Javascript assets. After using combine, this was reduced to just four.


<link rel="stylesheet" type="text/css" href="/css/reset-fonts-grids.css,base-min.css,styles.css,thickbox.css"/>
<script type="text/javascript" src="/js/jquery-1.2.1.js,jquery.easing.1.3.js,jquery.scrollTo-min.js,jquery.corner.pack.js,thickbox.pack.js,microbubble.pack.js"></script>

There are a other tools around like Combine such as minify, though I had problems with it combining some of the CSS files due to the presence of CSS hacks.

###Summary
As many of us web developers now use fast broadband connections, it’s easy to forget and ignore those less fortunate souls who, for one reason or another, are still on slower connections. YSlow is a quick, simple and measurable reminder of how we can improve the overall user experience with a few server-side configuration changes. It took me about 20 minutes to sort my site out, and in the future, it will take just minutes. You’ve no excuse!

Discussion

4 comments for “Speed Up Your Web Site With Firebug and YSlow”

  1. Some interesting ideas, particularly the use of HTTP Expires Headers.

    I wonderif whitespace in js and css files be taken care of by gzip compression (if your host allows it)?

    Also, does reducing the number of requests speed up the site? I thought that multiple requests (executed concurrently) would not take any longer.

    Oh, and the link to ‘my company website’ is to yslow instead :(

    Posted by Alun Coppack | December 18, 2007, 2:04 pm
  2. Now tell that to the rest of the bloated crap on the internet :-)

    Posted by Steven | December 18, 2007, 2:30 pm
  3. Judging by the CSS and JS files viewable in FireBug, I don’t think that whitepsace is actually stripped away, but it would be compressed. ‘Packing’ such files before placing them on the server would have the beenefit of require less process deflating and inflating.

    Browsers limit the number of simultaneous connections. IE (ghasp) actually follows the spec (RFC) and limits HTTP 1.1 to 2 simultaneous connections. See connections. Firefox’s about:config show 8 max connections and 2 max persistent connections. I guess persistent is for HTTP 1.1/keep. alive. Opera used to be set to 8, but I’ve not used it for a while.

    Link updated. Cheers Alun

    Posted by howie | December 18, 2007, 2:34 pm
  4. Nice work Howie!
    The work website I am involved in (you know it) used to buckle under peak loads of around 80,000 users in a 15 minute period.

    After some relatively simple optimisation, we can now successfully serve 160,000 and counting - we’ve yet to see our new limit (or generate it from load-testing).

    That was simply combining css / js files, reviewing cache-control directives, removing unnecessary images and tidying up crappy html.

    Other suggestions at the time ranged from getting a bigger pipe (this wouldn’t have helped) to using Akamai.

    Are the two weeks up yet, is it too late?

    • rich

    Posted by Rich | December 19, 2007, 10:32 pm

Post a comment