What is a reliable way to calculate actual (web) page loadtime

Question

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?

Answer 1

tl;dr

Use a headless browser to measure the loading times. One example of doing so is Website Loading Time.

Long version

I ran into the same challenges you're running into, so I created a side-project to measure actual loading times. It uses Node and Nightmare to manipulate a headless ("invisible") web browser. Once all of the resources are loaded, it reports the number of milliseconds it took to fully load the page.

One nice feature that would be useful for you is that it loads the webpage repeatedly. So, you could load the page multiple times and then average the values for a nice, round value. Also, since this script runs on the command-line, it's trivial to install on different machines and get actual loading times from various locations. (Load time depends not just on the server, but also the client and intermediaries)

Example usage:

website-loading-time rinogo$ node website-loading-time.js https://google.com
1657
967
1179
1005
1084
1076
...

https://github.com/rinogo/website-loading-time

Disclosure: I am the author of this project.

Answer 2

• Figure out how many bits you are transferring. (this converter helps: http://www.matisse.net/bitcalc/)

• Estimate or determine download speed (you can use this thing: http://speedtest.net)

• divide

Answer 3

http://www.webpagetest.org/ is an excellent resource for measuring load time

Also google chorme dev tools has a Timeline panel where you can record events, Here is a 2.5minute video showing you how Timeline in google chrome works http://www.youtube.com/watch?v=RhaWYQ44WEc

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.