Site Speed, now even easier to access

Friday, November 18, 2011 | 2:23 PM

Labels: ,

Speed matters. Faster loading pages mean more visitors land on your site instead of waiting in frustration or leaving. The Google Analytics Site Speed report will help you learn which of your pages are underperforming, so you can address this potential barrier to your conversions.

The Site Speed report was launched a few months ago, but it required site owners to add an additional Google Analytics tracking code to see data in this report. Based on increasing user requests we are now making this feature available to all Google Analytics users and removing the requirement to modify your Google Analytics tracking code. As of today all Google Analytics accounts will automatically have the Site Speed report available with no extra work required from you.


Want to check out Site Speed in your account? It’s easy. Go to the content section and click the Site Speed report. There are three tabs within the Site Speed report for you to review: Explorer, Performance, & Map Overlay. Each provides a slightly different view of your site speed performance. The Explorer tab provides an overview of load time by page. The Performance tab buckets your site speed performance by page load time. The Map Overlay tab provides a view of your site speed experienced by users in different geographical regions (cities, countries, continents). Below are snapshots of the Performance & Map Overlay tabs.





If you have already been using the Site Speed report through the additional tracking script, you can keep using the report as before. Since the tracking code “ _trackPageLoadTime” is no longer required to enable Site Speed report, going forward Google Analytics will simply ignore it.

Interested in understanding the details of the Site Speed report sampling rate, tracking of virtual pageviews, and impact of redirects?
  • Sample rate - Google Analytics samples your page load times to generate this report. For the more technical minded users you can adjust this sampling rate by adding to your Google Analytics code the function - setSiteSpeedSampleRate
  • Support for virtual pages - If a virtual path was used in the _trackPageview call, that path will now also be associated with any site speed data collected from that page.
  • Redirection time - Redirects are now counted as part of the "page load time" metric, so it represents the total time a user perceives of your site loading. Current users of the Site Speed report may notice a small increase in page load times as a result of this update.
Still have questions? Check out the Google code site and Help Center articles on Site Speed. We hope you’ll gain insights from this newly updated report and be able to use it to optimize your pages.  Please share with us your thoughts on this report and any suggestions for future updates. 

- Nir Tzemah, Google Analytics Team

40 comments:

86plasticmachinery said...

It's a good news!

Menashe Avramov said...

Is there a way to reduce the redirection time?
I've never seen an article about redirection time :X

clubfreetime.com said...

I think creating a new version is an error: we all have too little time to do everything we need to get done and the last thing we need is to learn a new format of Google Analytics, when a feature could be just added to the old format. I wish that Google people understood that we don't really have time to learn new formats every time they come with new ideas. Use the old format, guys, and add new features to that. That would be really MUCH user friendlier.

antgiant said...

Please, please change this from displaying average load time to median load time. One outlying 60 second load will destroy the average for hundreds of great load times.

Josh said...

I agree that median should be used, or some other logic to disregard extreme cases. Also, by default, pages with samples of less than 10 or so should be disregarded, as they are sometimes completely inaccurate. I have hundreds of pages on my site, and sometimes one of the less popular ones with a have a page load sample of ONE, with a page load time of something ridiculous like four minutes, throwing all the stats off. Plus you have things like people who are loading the page through Google Translate and such also polluting the data.

Wim Leers said...

Besides the criticisms above regarding using the average instead of mean or geometric average, there are other issues.

Such as the average page load time of the site being based on all averages, whereas many averages are actually derived from one page load.

The result? I'm getting an average of 16 seconds, while the real average is closer to 1.5 seconds. This is for a site with >0.5M page views per month, so with plenty of opportunity to sample. For my smaller sites the results are even less useful.

It's nice to start doing this, but please at least do it somewhat well. In its current incarnation, it just plain sucks.

ClickZs said...

Hi,

The Site Speed report measures the page load time (latency) for a sample of pageviews for over all pages & Site which drives from one page load

Ameya said...

Hi,

Should we remove the extra line of code that we added earlier to the analytics code?

Bhuvan Chand said...

informative article... thanks

Dataconsulting said...

Hello, how GA collects this data? Do we have to put the code at the very beginning of the page in order to get accurate data?

Thanks!

hailong

ravi shrivastav said...

Previously when i activate _trackPageLoadTime” my data lost for 3 days..
Thanks for makeing active in default

ISO 9001 Checklist said...

I'm seeing huge increases in page speed loads in certain countries - such as the UAE. This goes >25secs for page load time, where US/UK traffic is 1sec. The UAE accounts for 5% of traffic - so it's not a small amount and is no doubt effecting the site score :(
Is there anything I could do about this?

satishk said...

RE: Outliers and average as the metric.

I agree that outliers can skew the average. We disregard extreme outliers (> 10 minutes) from average calculations. If a site finds the average to be high and most of the page loads are faster, it points to a long tail distribution for your website and you can do further analysis by checking the distribution of your page load times using performance tab. Please find more about performance tab in the links below.
http://analytics.blogspot.com/2011/09/site-speed-gets-upgrade-hello.html
http://www.google.com/support/analyticshelp/bin/answer.py?answer=1205784

RE: _trackPageLoadTime

This method is deprecated. For now, it ensures backward compatibility by setting the sample rate to 10% instead of default 1%. In future, we will ignore this call and your sample rate will fall to default 1%. You can change the site speed sample rate using setSiteSpeedSampleRate() if you need higher sampling.

http://code.google.com/apis/analytics/docs/gaJS/gaJSApiBasicConfiguration.html#_gat.GA_Tracker_._trackPageLoadTime

@DatConsulting, You don't need to make any modifications to your tracking code to collect page load times. GA collects this information using HTML5 NavigationTiming specification so the placement of your code in the page doesn't matter.

Sulka said...

Am I supposed to see some data in the report already? I can't see any performance data on reports on the multiple sites I'm tracking. Given this announcement is now several days old, I'd have expected some data by now.

BOOMERS FM said...

Salam Kenal......

satishk said...

@Sulka, You should see data in "Site Speed" report. If your sites are getting low traffic (< 100 visits per day), the default sampling ratio of 1% won't be sufficient for you. You can increase the sampling rate using setSiteSpeedSampleRate method. You can find more documentation at,
http://code.google.com/apis/analytics/docs/gaJS/gaJSApiBasicConfiguration.html#_gat.GA_Tracker_._setSiteSpeedSampleRate

japarus bin b4db0y said...

thank .. is good ..

Aditya said...

Question is littlebit irrelevant,but I have to ask..

How to increase traffic?? How to attract people to the website??

Stefan Fußenegger said...

This comment has been removed by the author.

Stefan Fußenegger said...

It is possible that average page load times increased due to this change? I've seen increases of about 20% for three different sites around November 17.

OTHMAN32 said...

Great! Thanks for this article !

NaplesReporting said...

Love the site speed report!

Perry Dyball said...

I too have seen a big increase in reported page load times since this change was implemented. Was an early adopter (opt-in) from around the end of May 2011. Having put the opt-in tacking in place in our GA code, do we know need to take it out?

Unknown said...

So it's been 11 days since this article which states I don't need to make any changes to access this data, and I still don't have any data in the report. The explorer graph is a flat line, the data grid shows all 0's and there is no data on the other 3 tabs. My GA account is >5 years old. Am I missing something ?

satishk said...

Thanks for your feedback folks. This will definitely help in improving this report for every one.

@Stefan/Perry, As mentioned in the article, if your website has more redirects before the users reach the landing page, your page load time can increase due to inclusion of redirection time as part of the page load time metric.

In addition to looking at the average metric, please take a look at "Performance" tab to understand how the page load time is distributed in several buckets.

If you see large increases, please check if it is isolated to Firefox since we have seen a bug with NavigationTiming implementation in Firefox which will be fixed in FF9
https://bugzilla.mozilla.org/show_bug.cgi?id=691547

@Perry, For deprecating this method, I copied my earlier response.

This method is deprecated. For now, it ensures backward compatibility by setting the sample rate to 10% instead of default 1%. In future, we will ignore this call and your sample rate will fall to default 1%. You can change the site speed sample rate using setSiteSpeedSampleRate() if you need higher sampling.

http://code.google.com/apis/analytics/docs/gaJS/gaJSApiBasicConfiguration.html#_gat.GA_Tracker_._trackPageLoadTime

@Unknown,

You should definitely see some data in "Site Speed" report. If your sites are getting low traffic (< 100 visits per day), the default sampling ratio of 1% won't be sufficient for you. You can increase the sampling rate using setSiteSpeedSampleRate method. You can find more documentation at,
http://code.google.com/apis/analytics/docs/gaJS/gaJSApiBasicConfiguration.html#_gat.GA_Tracker_._setSiteSpeedSampleRate

Unknown said...

Didn't notice that it would post as "unknown" until just now. I do find it interesting that a Google Property won't let me use my Google account as my identity and instead pushes me to OpenID.

My site receives an avg of 2000 hits a day with the peak of 3100 this year a few days ago.

Knowing this, do I still need to evaluate setting the Site Speed Sample Rate ?

Andrew S. said...

This is great! I wanted to create an alert that I could fire off to our IT director if the site-load time exceeds a certain threshold, but site-speed doesn't appear in the alerts dialogue. Will it eventually be available there?

Jon Lane said...

I'm also seeing lots of zero values - even in pages which have got > 50000 pageviews since this was implemented.

There are no other issues with our GA account....

thanks.

satishk said...

@Unknown, Site speed report uses HTML5 NavigationTiming API which is not supported in older versions of browsers.

The sampling is also done per session so once a session is in sample, page load time will be tracked for all page views in that session. I encourage you to increase the sampling rate beyond the default 1% to get better view of your site speed.

RE: account issue. That is strange! I am able to post using my Google account on this blog.

@Jon, We are looking into this issue. Please verify if most of your pageviews are coming from browsers not supporting NavigationTiming API.

@Andrew, Thanks for your feedback. We will consider this feature for future versions.

Hope this information helps.

Unknown said...

I will increase the sampling rate. Under the form it says

* "Unknown (Google Account) - Sign Out Follow up comments will be sent to "my google address" unsubscribe
* Open ID and then several choices

Since I am signed in I would have thought it would have simply used my Google account, weird. Not sure why it doesn't. Using Firefox 8.

Thanks for the help.

Jon Lane said...

@satishk - thanks for looking at this. Most of our traffic is coming from the recent versions of the browsers which should support this. Let me know if you need more details. Thanks again.

google said...

Thanks for the implementation.

However I've got a problem when using the API to extract the ga:avgPageLoadTime : I do not get the same value as within analytics...

Am I doing something wrong?

Robert said...

the google bot test the pages? and from different location? how does the load time data come from ?

Jeremy Hawes said...

Is it just me or is this not working?

robotautotposts said...

Thanks for the implementation.

satishk said...

@Jon, we don't see any unusual behavior with sites not seeing speed data. Do you have only urchin.js by any chance? Site Speed is only supported with ga.js. Please feel free to file a bug here or mention your site so I can take further look.

@google ;-), that shouldn't happen. Please verify the date range in report and API call.

@Robert, Google uses HTML5 NavigationTiming specification to track speed data.

Jon Lane said...

@satishk Could you ping me contact details at glengarry33@gmail.com and I'll let you know the site name? We are using ga.js. Cheers, Jon

SoloStocks said...

@satishk, I've checked it all over again and you are right, my problem is coming from fast-access mode.
What I do get is a lot of deviation (46%) when comparing a day measure from API against a daily point on the weekly view in GA. The weekly view in GA is generated in fast-access mode.
Restricting the date range in GA to the same day , fast-access is not applied and I do get the same value as per the API.
I would say that the fast-access mode seems to introduce quite a large degree of error on this metrics

One more thing, will it be possible to extract the tech stuff (Avg. Server Response Time,...) with the API?

Thanks a lot

Patrick

satishk said...

@SoloStocks, Technical metrics haven't been added to the API yet. Coming soon.

SoloStocks said...

@satishk, many thanks. I guess that I´ll have to switch to the V3.0 :-)