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.
Skip to the 
You can subscribe to an individual
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).
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?
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...
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.
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.
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
Joe Hewitt's {Link} contribution to the web dev industry is even greater considering he has licensed Firebug as free software.
@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.
My site's page loading time is worse than I thought. Firebug is just what I'm looking for. Thanks!