How to measure HTML Page Load Time?

[Rob]

Is there any method in javascript to measure the load time of an HTML
page? e.g., starting from the user hit enter until the page is fully
loaded.

 

[rf]

Is there any method in javascript to measure the load time of an HTML
page? e.g., starting from the user hit enter until the page is fully
loaded.

Firebug will tell you this.

 

[Rob]

Firebug will tell you this.

OK. But I need to write a program for doing this...any function that I
can call?

 

[rf]

OK. But I need to write a program for doing this...any function that I
can call?

Yes. Hook the keydown event (amongst others) to notice when the user presses
enter (or clicks on a link, or submits a form). Hook the onload event to
notice when the page is fully loaded.

However think about where you might do this? The user presses enter on page
1 to cause page 2 to load. As soon as page 2 arrives page 1 is discarded,
along with any script it contains, including any variables you might have
carefully set, such as the time the enter key was pressed.

The only way to do this is to somehow keep the script available while the
new page loads. Causing the new page to load in an iframe, or another frame
in a frameset, is the way to go. The script however is now not part of the
subject page but another page, the page doing the measuring.

 

[gimme_this_gimme_that]

I'm not clear on where you want this program to run.

Once you get the value what do you want to do with it?

Are you wanting to monitor a URL?

Are you running Windows or UNIX?

Why do you think this is a JavaScript question?

Do you want a script that visits a URL and allows you to record how
long it takes a page to render - and then insert that value into a
database?

To navigate to the page you want to measure - do you have to log in
first?

 

[transpar3nt]

The only reliable way that I know of doing this is using a server side
script such as PHP or ASP. It would create a time variable upon
request and another at the bottom of the script, and finds the
difference between the two. Not sure if your server supports one of
those.

 

[rf]

The only reliable way that I know of doing this is using a server side
script such as PHP or ASP. It would create a time variable upon
request and another at the bottom of the script, and finds the
difference between the two. Not sure if your server supports one of
those.

Which will tell you exactly how long that script took (fractions of a
millisecond), not how long the page[1] took to load

[1] plus linked files, plus images, plus round-trip-to-the-server time plus
lost and retransmitted paket time plus who knows what else.

 

[Jorge]

The only reliable way that I know of doing this is using a server side
script such as PHP or ASP. It would create a time variable upon
request and another at the bottom of the script, and finds the
difference between the two.  Not sure if your server supports one of
those.

Which will tell you exactly how long that script took (fractions of a
millisecond), not how long the page[1]  took to load

[1] plus linked files, plus images, plus round-trip-to-the-server time plus
lost and retransmitted paket time plus who knows what else.

<http://jorgechamorro.com/cljs/034/>


window.onload= (function () {
var now= +new Date();
return function () {
alert(((+new Date())-now)+"ms")
};
})();

 

[rf]

The only reliable way that I know of doing this is using a server
side script such as PHP or ASP. It would create a time variable upon
request and another at the bottom of the script, and finds the
difference between the two. Not sure if your server supports one of
those.

Which will tell you exactly how long that script took (fractions of a
millisecond), not how long the page[1] took to load

[1] plus linked files, plus images, plus round-trip-to-the-server
time plus lost and retransmitted paket time plus who knows what else.

<http://jorgechamorro.com/cljs/034/>


window.onload= (function () {
var now= +new Date();
return function () {
alert(((+new Date())-now)+"ms")
};
})();

If this does what I think it does it is measuring the time between a) when
the browser has received the HTML file, decoded it, done a few other things
and finally decided to hive that CDATA off to the javascript engine and b)
when the browser has finally decided that the page has been fully downloaded
and (possibly) rendered.

OK. But what about the time between when the user "presses enter" to request
the page (as per the OPs specifications) and the browser actually gets the
page, stage a) above?

For a page that has, say, no externally linked files and no images or other
things that require a round trip back to the server (ie a simple HTML file
with perhaps some inline (or in the head) CSS) your measured time will be
sub-millisecond. The user perceived "load time" will be tens, or even
hundreds of milliseconds.

From where I am to anywhere like the U S of A, the UK and other such
northern places my single round trip time to the server is *at least* 300
milliseconds.

A more realistic page with say half a dozen images and css files and such
might fare better. The browser gets the HTML and fires off a bunch of
requests for the images etc. Lets say they take two "round trips" to the
server (the browser sends multiple gets). You are still missing the initial
round trip to get the HTML so your measurements are low by that time. Low by
one third.

 

[Jorge]

OK. But what about the time between when the user "presses enter" to request
the page (as per the OPs specifications) and the browser actually gets the
page, stage a) above?

Well. That's all than you can get ~easily.

OTOH, if you could append (somehow) the exact time of the GET request
as a parameter to the URL: example.com/index.html?now=1232797568688,
it could be read from the script and accounted for.

 

[rf]

Well. That's all than you can get ~easily.

OTOH, if you could append (somehow) the exact time of the GET request
as a parameter to the URL: example.com/index.html?now=1232797568688,
it could be read from the script and accounted for.

Yep. I thought of that a while ago and it will work quite well.

Probably easier though, as I have mentioned before, to spy on the
transaction from another frame.

We probably have to now wait for Rob to reappear and tell us what he really
wants this for anyway.

 

[RoLo]

Is there any method in javascript to measure the load time of an HTML
page? e.g., starting from the user hit enter until the page is fully
loaded.

<html>
<head>
<script>
var t0=(new Date()).getTime();
</script>
</head>
<body onload="alert(((new Date()).getTime()-t0)/1000);">
</body>
</html>

this should give you a good aproximation

 

[Thomas 'PointedEars' Lahn]

<html>
<head>
<script>

var t0=(new Date()).getTime();

var t0 = new Date();

</script>
</head>
<body onload="alert(((new Date()).getTime()-t0)/1000);">

<body onload="window.alert(new Date() - t0);">

Uses automatic type conversion, avoids runtime errors and rounding issues.


PointedEars

 

[dhtml]

transpar3nt wrote:
The only reliable way that I know of doing this is using a server
side script such as PHP or ASP. It would create a time variable upon
request and another at the bottom of the script, and finds the
difference between the two. Not sure if your server supports one of
those.
Which will tell you exactly how long that script took (fractions of a
millisecond), not how long the page[1] took to load

[1] plus linked files, plus images, plus round-trip-to-the-server
time plus lost and retransmitted paket time plus who knows what else.

<http://jorgechamorro.com/cljs/034/>


window.onload= (function () {
var now= +new Date();
return function () {
alert(((+new Date())-now)+"ms")
};
})();

If this does what I think it does it is measuring the time between a) when
the browser has received the HTML file, decoded it, done a few other things
and finally decided to hive that CDATA off to the javascript engine and b)
when the browser has finally decided that the page has been fully downloaded
and (possibly) rendered.

That is a useful measurement. So is time to content rendered
(DOMContentLoaded).

OK. But what about the time between when the user "presses enter" to request
the page (as per the OPs specifications) and the browser actually gets the
page, stage a) above?

That's latency. For that, the Firefox plugin "lori" is useful.

[...]

A more realistic page with say half a dozen images and css files and such
might fare better. The browser gets the HTML and fires off a bunch of
requests for the images etc. Lets say they take two "round trips" to the
server (the browser sends multiple gets). You are still missing the initial
round trip to get the HTML so your measurements are low by that time. Low by
one third.

Except that CSS is usually a static request. For complex apps, the
"html" portion (the original req) usually includes queries to a middle
tier or database.

client req ---> server --> server process --> server resp -->

A css file would not have much server processing; it would be a static
file that might even be cached. A dynamic jsp w/db queries would not be
cached, would require server processing.

There are several components to page load time:
1) Latency (time to first byte)
2) time to load HTML content (DOMContentLoaded)
3) perceived visual rendering
4) time to onload

#3 - perceived visual rendering. When using a table layout that is not
table-layout: fixed, and/or does not have column widths, the table will
render more slowly, especially if the table has a lot of images (it will
be a lot slower in IE). So the perceived visual rendering will be
slower, perhaps up to a few seconds.

Garrett