Track site speed / load time with Google Analytics events

In the rebound an article about the tracking of your site's performance with Google Analytics. Almost a year ago I wrote this article in Dutch, but there are some improvements that made life easier. Google Analytics released the 'set events as goals' functionality that is really helpful here.

The script I'm going to explain will track page load time and page render time per individual URL. I know some other articles that describe a comparing technique but I really think the way I use it gives you more insights (at least for smaller sites).

Sitespeed tracking is important

I don't have to tell you how important it is to know how visitors experience your site. Sluggish sites will cost you money in the end. Site speed is a minor SEO ranking factor and fast sites tend to have more pageviews per visit and a higher conversion rate.

First the technical part

To get the right numbers in your Google Analytics account you have to add some extra scripts. First a script that tracks the starttime of the page loading proces:

<script type="text/javascript">loadtimer=new Date();</script>

Put this code directly after the <head> tag. Then put the next line just before the </head>:

<script type="text/javascript">rendertimer=new Date();</script>

And last but not least the event tracking code that can be everywhere in your code:

<script type="text/javascript">
window.onload = function()
_gaq.push(['timer._setAccount', 'UA-XXXXX-2'], ['timer._trackPageview']);
_gaq.push(['timer._trackEvent', 'loadtime', location.href, , parseInt(new Date() - loadtimer)]);
_gaq.push(['timer._trackEvent', 'time-to-render', location.href, , parseInt(rendertimer - loadtimer)]);

Please use a brand new profile with a different UA number for this script. If you use the same UA number as your regular Google Analytics script this script will mess up your data.

I used the simple "window.onload" as an example here. But in most cases you would use a more robust method for adding something to the onload event of your document.

The results

By adding this script you can see the actual time that it takes for a visitor to completely load a page. This is more reliabe than a n=1 measurement that a tool like WebPageTest can do (no bad words about that tool, it gives you a lot of other useful insights):

If you go to the "event" report you will see two new categories: "loadtime" and "time-to-render". The first one shows you the time it took to completely load the page. The second one is the time people stared at a blank page. If that time is to high you also need to do some updates. If you click on one of those categories you will get the screenshot shown above. The column "Avg. Value" gives you the time it on average took to load a page.

What you can do also is an analysis of the loadtimes per browser, campaign, keyword or country:

I now know my site is slow in the United States, India and China, just look at the numbers. So, if you are worldwide oriented this could be a really important report.

Google Analytics events as goals

It's possible to set an event as a goal in Google Analytics. I created this one to keep track of slow page load times:

Every time someone hits a page that takes longer than 5 seconds to load it will trigger this goal. My target is to keep this number as low as possible 😉

Additional comment:
The described technique only measures the load time after the server has send the first byte (TTFB = Time To First Byte). Make sure you also look at the process before that first byte. Aaron gave some more explanation in the comments.

Click to activate social bookmarks


31 thoughts on “Track site speed / load time with Google Analytics events

    1. That could be a reason, but the fact that my server is in Amsterdam only will have some impact too 😉 I should probably move my static content to a CDN.

  1. Great Work.

    But one important issue: Eventtracking has impact on the bouncerate. So I suggest that this extra tracking is made to another account (UA) to make sure not to spoil the bouncerate.

    1. Hi Jacob, I already mentioned that in the article: "Please use a brand new profile with a different UA number for this script. If you use the same UA number as your regular Google Analytics script this script will mess up your data.", but thanks for the critical look 😉

  2. Nice touch with the render timer there, Andre. I'll have to check it out when I have a moment to test it.

    Thank god GA have finally allowed us to use events as goals... I have been waiting too long for this.

    By the way, I too have noticed a similar thing with visits from Asia and Africa see my post on how page load times affect visitor behaviour ( One thing I've often wondered is that visitors who view two or more pages are more likely to experience fast load times due to browser caching and such.

    1. Hmm, good suggestion. The script should store if someone is looking at the first page within his visit or not. But still you don't know exactly what is cached and what not.

  3. Andre,

    Dank voor deze onwijs coole feature. We gaan hem zo snel mogelijk testen! Vooral omdat je een significante hoeveelheid data verzamelt waar je wat mee kan.

  4. Hi Andre,

    good to do a writeup of how this can be done in GA with the 'events as goals'.
    Your article is clear and I am happy to read you recommend measuring time-to-render. That is very useful. If you only measure loadtime, you can draw the wrong conclusions. Example: loadtime is 4 seconds: "not bad, not bad". But then if time-to-render is 3.6 seconds, the user experience should be considered bad because people are staring at a blank screen for a long time.

    A note on measuring the time-to-render in this way: it's the best you can do with (simple) inline JavaScript, but it will not always measure the real time-to-render. Let me explain:
    1) a browser will not start rendering until it has finished loading, parsing and executing everything in the HEAD section of the HTML. By putting the inline JavaScript rendertimer=new Date(); right before </head>, you are certain to capture the moment where the browser is done with the HEAD and *could* start rendering...
    2) but the rendering does not necessarily start then. For several reasons (e.g. a bunch of JavaScript code right after the <body> tag - very common in ASP.NET sites) the rendering of the page may start later. Sometimes the user does not see anything in the screen until page finishes loading.
    I recommend to do the following:
    - Use to find out when the real time-to-render is (Webpagetest measures from within the browser when something actually appears in the screen: Start Render. Tip: use the Video functionality in Webpagetest and look at the screenshots in the film strip, so you know what actually appears in the screen). Always do at least 3 runs per test per page.
    - Implement your tracking code and start tracking the loadtime and time-to-render in GA. After a few days, look at the numbers for time-to-render: is the average close to the numbers you saw in Webpagetest? If yes, keep tracking in GA and know that these numbers are 'real'. If no, well, then you may need to do some calculations, like time-to-render = time-to-render * 1.25, because the real start render time is 25% higher. But then you have to keep in mind the differences per browser, etc etc. so be cautious with these kind of calculations.

    BTW, thanks for the link to my blog in your site footer!

    1. Great tips Aaron, thanks for that. I absolutely agree with all your suggestions, you can't rely only on the numbers you will see in Google Analytics.

      1. Generally you want to track changes in load time more than absolute load times -- ie, last month 2% of views were slow, this week it's 8%, what did I do.

        Still, does anyone have any numbers on the relationship between JavaScript timing and something reported by say Firebug or Fiddler2?

        1. I don't have any numbers about the relationship of javascript timing and tools like Fiddler. But as soon as all browsers have implemented the W3C Navigation Timing specs there should be no difference. This new spec makes it easy for javascript to get the load times from the moment someone clicks a link to the full page load of the next page.

    2. Great post. I learned a few good things from this writeup. I had a couple of javascripts were included in the head of one of my websites (quite a long ones) I moved them to the Body and saved my visitors another second loading my website. Thanks again for your & for Andre on this great topic.

  5. Andre,

    txs. I want to suggest you update the article to make readers understand one important downside of this technique (or point them to this comment 😉

    By starting the load time timer with JavaScript at the top of the page, you don't measure an important part of page loadtime and time-to-render: the time between the request for the page (user clicks link in Google results or types in URL in browser address bar and hits Enter) and the time the browser receives the first few bytes of the HTML. Three or four things happen then:
    1) DNS lookup: convert host name to IP address (browsers/computers cache these lookups, so it may not happen)
    2) Connect: setup a connection to the server
    3) Send request: ask for a file (e.g. index.html)
    4) Wait for response: server creates/finds the file and starts sending it

    2, 3 and 4 always happen, 1 not always but often.
    1, 2 and 3 usually don't take long, 0.2 seconds in total.

    But 4 can take very long, if the site is on a slow server, as high as a few seconds.
    Imagine the sum of 1, 2, 3 and 4 takes 1.0 second and the loadtime measured in GA is 4.0 seconds. The real loadtime is 5.0 seconds, but you measure 4.0. That's a 20% difference!

    Take a look at this waterfall chart on, for the home page of

    See the long green bar at the top? That is server being slow.
    The load time tracking in GA will start at ~2.1 seconds (where the blue starts) and Andre will see a loadtime of (4.2 - 2.1 =) 2.1 seconds in GA.
    In reality, the loadtime is 4.2 seconds: 100% higher than measured in GA.

    Please always understand what you are measuring and what the data really means.

    1. Hmm, I could swear I already mentioned this in the article, but it was only in my head 😉 I added an extra line with a link to this comment.

  6. Hi,
    I really hope this is not a stupid question.
    I was wondering if it is necessary to paste this code on every page of your website?

    Thanks in advance for your help!

    1. I know, we were testing it for 3 months now. But the biggest flaw is that people have to turn it on in their tracking script. In my opinion Google should turn it on for everyone 😉

  7. i was searching for reduce website load time reasons, and found this article for tracking site speed with analytics. I have not used this code insert method for that. Will sure use and review the result for analytic event. Thanks for your knowledge.

Comments are closed.