views:

796

answers:

8

I'm interested in knowing the actual average page loadtime for my webapplication.

Simplistically, how log does my average visitor wait before they can start using a page on my site. From when they click the link to my site until the site is finished rendering & ready to accept input.

The standard solution seems to be to use Javascript to compare the time from a script in the until a script in the window.onload() event.

(See: http://www.dreamincode.net/code/snippet1908.htm)

This doesn't seem like a very acturate measure to me, as it ignores the time taken to resolve my domain & receive enough HTML content to begin Javascript parsig.

It also looks like Safari fires window.onload before the page has actually finished loading (http://www.howtocreate.co.uk/safaribenchmarks.html).

Any ideas?

Is it possible to get the time a the current request was initiated via Javascript?
What event fires after everything is ready reliably across all browsers?

A: 

The most accurate way to calculate load times is on the server side: once the page is built, how much it takes to display on the user's browser will depend on:

  • Current network traffic;
  • User's computer specs;
  • Which browser he's using.

So, using JavaScript is not a great measure because there are a lot of factors you can't change in there.

The best thing you can do is measure the time each page takes to be generated on your server - that you can improve.

Needless to say, that will depend on which language you're coding in.

Seb
Actually, there are plenty of things you can do to improve client side render time; from including less / smaller images, improving js render time, putting stuff on a CDN etc etc.But I agree; having a breakdown of where the delays lie would be very useful.
David Laing
Granted; you're right. You can tweak JS as well; it's only I took your question server-side :)
Seb
A: 

One thing that can be done is to use Javascript to grab the current time when a client-side event occurs that triggers a post-back to your server. Passing this value back to your server side will allow you to render it back to the client as your initial 'trigger' time that you can compare against.

Instead of using onLoad, I believe you can put script inline at the end of the document so that it runs as soon as the browser renders that portion of the script. This will allow you to compare the current time when the inline script runs against the trigger time that was captured when the user initiated the call.

However, as mentioned by Seb, since you can only reliably control the server-side of the loadtime, it would be best to include in your metrics the server page generation time. If you have both metrics, you can at least see how much of the total time is taken by page generation, and how much is dependent on the various delays that could occur on the client-side.

Jay S
You can't rely on client-side time. It could be set to 8:00 AM on January 1969.
Josh Stodola
It doesn't matter what the client-side time is. Your server doesn't use it, you simply pass it back to the server so it can include it in the response. All the calculations are done client-side, so the client's time settings are used for both the before and after.
Jay S
A: 

I've always found the Pingdom Tools full page test very useful. It's not an in-code solution, but it does give you a good idea of how quickly (or not) your page loads.

Philip Morton
+2  A: 

FireBug has a "network timing mode" where you can see how long it took to download each resource which makes up your web page.

Plus you should measure the time your server needs to prepare the request. Since you can't influence the browser and the network, rendering time on your server should be as small as possible.

Aaron Digulla
+2  A: 

Firebug is a great resource for this and loads of other information about your page loads. Additionally, Firebug with YSlow goes one step further. YSlow has a hadnful of checks that it runs against your page and grades it's performance based on certain rules (are you using a CDN, is your CSS and JS compressed, etc.). I've found it invaluable to make some major improvements (JS compression is a great one) to my sites.

Milner
I agree, Firebug is a useful tool. However, it only measures the load time for MY PC/ browser / network; not an average time for the actual users of my site (with their weird and wonderful combinations of PC speed, network location, browser type etc etc)
David Laing
A: 

psuedo-code.


server marks start of processing the request.
server sends the output.
    script tag, marks start time.
    rest of html markup.
    client script , with server processing time in ms
    client script with window.load event + server-side time
    client script which sends the total back via an ajax call.
Tracker1
+1  A: 

Try Yahoo's YSLOW, it will answer your post of the questions, but it works only with FireFox (actually its a plugin for firebug)

A: 

The method I use is to create a session variable (wrapped in an if to check that it hasn't already been set) as the first thing in my index.php file (which every script runs through). Then, I have a pageLoad event in javaScript that posts back to a different script on the server that gets the session varaible time and subtracts it from the current time. This gives you the time it took for the request to hit your server, process, respond, and render.

just make sure you unset the session variable in the script you post back to so that the next time the page loads it sets a new session variable (as one doesn't exist because we unset it) and starts all over again. The only thing you may want to do is find the time the ajax took to request the server and subtract that, but it should be milliseconds.

Alex
I should add, I use YUI and an onDomReady method, which is a valid check for the page having completely loaded and the DOM being ready :-)
Alex