I've recently started using the new _trackPageLoadTime function in Google Analytics to measure page load times. However, I have noticed a few pages appear with a huge "Average Load Time". One page is showing a time of 556.22 seconds! Several other pages show average times of 30+ seconds.

Clicking through to the page detail shows that the highest average times are the result of 1 really long load time of 100+ seconds (and most of the top ones only have a "Page Load Sample" of 1 or 2 people).

Are these just anomalies where the user lost connection or something? Is there any way to view the data without those anomalies?

2 Answers 2


Google Analytics Site Speed tracking utilizes the HTML5 Navigation Timing API. I wrote a fairly detailed answer on it on StackOverflow.

Specifically, it uses these 2 attributes on browsers that have the performance.timing object:

fetchStart attribute

If the new resource is to be fetched using HTTP GET or equivalent, fetchStart must return the time immediately before the user agent starts checking any relevant application caches. Otherwise, it must return the time when the user agent starts fetching the resource.

loadEventStart attribute

This attribute must return the time immediately before the load event of the the current document is fired. It must return zero when the load event is not fired yet.

That latter event corresponds to the window load event (window.onload). Though this is an important event, this is not the same as when your page becomes usable. So, your page could very well be functioning, but the onload event could be held up by a particularly slow resource on your page.

Does your site include external assets? Advertising? Many social plugins? It's possible that its causing your window load event to be delayed.

It's important to keep in mind that the sampling rate for this feature is by default very low. It's configured to try to sample 10% of visits, but in practice, depending on your level of support, it can be anything between 2%-4% of traffic. So, single outliers can have very significant effects on the quality of the data.

You can get a better idea of how reliable the data distribution is by drilling down into the particular pageview's sampling data to get the distribution

enter image description here

If you're interested in a different data point for your performance, you could use events to construct a custom performance tracker. (It would, however, ruin your bounce rate, as an event would count as an interaction.) For example, maybe the DOM Ready event is a better barometer of when your site becomes usable

if(window.performance && performance.timing)
var ms = performance.timing.domContentLoadedEventStart - performance.timing.fetchStart;
_gaq.push(["_trackEvent", "Performance", "Time to DOM Ready","",ms]); 

(Anecodetally, yes, its very common. Check out some of these times from one of my accounts):

enter image description here

  • 18,000 seconds?! That's 5 hours - how is it even possible for that to happen? Commented Oct 4, 2011 at 10:57
  • It's possible this deserves a closer reading of the spec. Maybe a failed load and a retry are seen as one page load, so that if I try to fetch the page, it fails, I forget about it and come back 5 hours later, it tracks the pageload time as 5 hours? That's the only logical explanation I can come up with.
    – Yahel
    Commented Oct 4, 2011 at 12:05

They could be someone on dial-up who took ages to load your page, or someone with a congested connection.

If you can find out when they visited you can exclude that day from your figures. Or if you can spot some other characteristic, such as their country or network, you can create a custom segment that excludes those visitors.

  • It didn't occur to me that dialup would make a huge difference but now I think about it, a user on 56k could take around a minute to load a page that loads for me in 1 second. I checked the dates and countries but they are all different. My best solution so far seems to be filtering where Page Load Sample is at least 100. Commented Sep 27, 2011 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.