Analyse Your Page - Speed Week, Day 1

Before you start worrying about how to improve the speed of your site you need to know whether or not to bother. You need to know if it's slow or not, which is a tricky one to call really. The most obvious sign the site is slow is when people tell you it is. This is normally what gets you worried. The other way is to actually look at the page load time, which is a little more scientific.

The best way (that I know of at least) to analyse page load time is using Firebug's Net panel.

Here's the contents of the Net tab after loading Lotus developerWorks:

This almost goes without saying, but, if you don't have Firebug yet, you must get it. It's singularly the most useful web developer's tool ever invented.

The Net panel tells us lots of things. Most useful for speed testing purposes is the overall page load time, shown in the dark grey summary bar at the bottom. We can see the page took 4.8s to load and is comprised of 52 separate requests.

We also get to see the time-line of how the page loaded. The list of items is in the order they were loaded and each entry tells you how long it took to load. You can even hover over any image item to see it or click the + sign to see header details for each file.

Try drilling down in to the page items by type. Below is the tab when we've limited the results to only the images and we can see that, of the 52 items that make up the page, 32 are images and took a total of 2.3s to load.

There's much more you can do with this panel. Even if you're already a Firebug user you might never have used it. So go and open it and load some of your sites to see how fast they are.

Page load speed is still not exactly an accurate science. In the same way Google Maps telling you the travel time from point A to B isn't either. There are too many variables to simply say "our homepage loads in X seconds" or to demand "Our homepage must load in X seconds". At what time of day? In which country? For dial-up users? What speed of broadband? etc.

Still, using Firebug to take an average over a few attempts to load the same page will give a good indication of how fast it is. Just don't test it on your internal network and expect internet users to see the same results!

Overall page load is only part of the equation though. We're just as interested in each single request made to the server and for the next few days this is what I will be talking about. Looking at how we can reduce the total time taken.

Before I go I feel compelled to mention HttpWatch, which doesn't offer the graphical timeline but is equally as useful, if not more so, in analysing page speed. Here it after loading the same page and in "summary" mode:

Here you get extra information like how many round trips to the server were made and how many TCP connections were made (more on that later in the week).

HttpWatch also lets you save the reports in CSV, XLS or its proprietary HWL format — which you can send to other HttpWatch user to load in the "studio".

The obvious choice has to Firebug though as it's free (unless you count the donation I made to its author) whereas HttpWatch isn't. They both compliment each other nicely though in any developer's toolbox and I'd recommend owning and using both.


    • avatar
    • Victor
    • Mon 26 Mar 2007 01:22 PM

    Very neat. Thank you for sharing. I use a firefox add-on called Load Time Analyzer. It provides a quick view of the milliseconds it took a page to load, and a bar chart on a separate page that you can scale. The think I like about it is that I work a lot with websphere portal and you can see when things are being loaded in parallel or not (parallel rendering is a portlet setting that is easy to forget to enable).

    • avatar
    • Bill E
    • Mon 26 Mar 2007 04:36 PM

    Would be great if IE had tools like that. Or is there? I know of fiddler, and that one IE attempt at a dev toolbar. Is there anything like this for the MS browser?

    • avatar
    • Jake Howlett
    • Mon 26 Mar 2007 05:10 PM

    IE has HttpWatch, as mentioned above, and the "developer toolbar" from MS. MS's dev toolbar looks like a big pile of steaming crap next to Firebug though. I'd go as far as saying it's fairly useless. Don't know of any better alternative for IE. That's why I tend to do all my development work in FF nowadays and pray it works first time in round when I come to test in IE. Not so long ago my approach was the other way round...

  1. Firebug is definitely a great tool. You can use the profiler to check how long your javascript function takes to run. That's another cool feature of javascript. Another free tool is IBM Page Detailer. You can get it at their alphaworks site.

  2. I assume we are talking about Domino driven websites here.

    I have been looking at how browsers' caching of resources from a Domino server works.

    For instance if a document, view or search result will be cached or not. If it gets cached, the browser won't even hit the server to display the page.

    If you have a View - like one that's embedded on a page, it generally won't be cached because the Domino server inserts a no-cache keyword in it's HTTP response header.

    You can influence the header using @SetHTTPHeader("Cache-control";"public") and @SetHTTPHeader("Expires"; a_date);

    With both views and search result-pages, users will often navigate back and forth between the list of documents/search results and the pages that they get to by clicking the elements in the list. If you don't look into caching the view/search result page, the browser user will hit the server every time they return to the list.

    • avatar
    • Michael Bourak
    • Tue 27 Mar 2007 12:04 PM

    to follow up on Jens post, I think it's often necessary to correlate Firebug network results with Domlog result. Very often, firebug tends to show request that are not view as real request by the domino server log... (particularily when you use @SetHTTPHeader and tells an element to be cachable)

    has anyone seen the same pb ?

    ps : no proxy tween me and domino

  3. Joe Hewitt's {Link} contribution to the web dev industry is even greater considering he has licensed Firebug as free software.

  4. @Michael

    I never used Firebug much for the network results, and I ams orry to say that I never compared domino logs with what the plugins say they request... Interesting.

    I have been using the Firefox LiveHTTPheaders addon and the Internet Explorer IEHTTPheaders addons to see what is going on. And one thing I have observed is that Internet Explorer seems to cache objects more often than Firefox does.

    If I remember correctly, it is the Last-Modified HTTP header field that Firefox seems to ignore when the web user requests the same URL the second time.

  5. My site's page loading time is worse than I thought. Firebug is just what I'm looking for. Thanks!

Your Comments


About This Page

Written by Jake Howlett on Mon 26 Mar 2007

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »


Here are the external links posted on the same day.

More links are available in the archive »

More Content