Become a True Content Brand

Meet The New Digital Agency

iAcquire is in the business of content marketing—and, inevitably, so is your brand. We create content that powers your business, and develop strategies that forge the road ahead. Using market research, we ensure your brand’s content aligns with what your users are looking for in search and talking about in social. Welcome to the new way of doing content.

Adrian Vender breaks down each part of the Google Analytics Site Speed Report. Learn what data you should collect and the best way to analyze it.

Nobody likes a slow loading web page. With that in mind, you may have a lot of displeased visitors on your website.

Things may appear fine to you as you load your website from the comforts of your office computer connected to your blazing-fast Ethernet connection. But it’s not the same scenario for somebody loading your site from their 3G-connected phone or from their woefully slow Windows XP machine (check your GA data… they still exist). Geographic location and even web server performance can especially be important factors that affect your site’s speed.

Google Analytics has a data-rich Site Speed reporting section, but sometimes it can be quite overwhelming and difficult to determine how to make decisions off of that data. My goal here is to help pass on a little knowledge of what the reports are really saying and how to use the reports to help put some action after your analysis.

1. Are we collecting enough data?

The Google Analytics tracking code measures this information by leveraging the HTML5 Navigation Timing JavaScript API, which is basically a detailed time logger inside your browser. With this feature your browser keeps track of all the details about page loads, from the initial click request all the way through to the final loading of the page.

It’s important to note that not all browsers support the Navigation Timing feature. Most modern browsers do, but some (like Safari) do not. This will impact and decrease your overall sample set of page load data.

Another detail that will impact your overall sample size is a default setting in your Google Analytics tracking code that only collects page load data on 1% of your visitors.

Yeah, that’s pretty ridiculous. Fortunately, that can be changed by setting the _setSiteSpeedSampleRate() method to a higher number. You could go as high as 100% sampling, though GA says it will have a hard limit of 10K hits per day on a single web property.

All of these disclaimers and warnings about understanding your page load data sample size is so that you don’t FREAK OUT over the following image:

This site’s homepage had 8,834 pageviews with an average page load time of 24.83 seconds! This is the worst homepage in the world!

Oh… So it was an average time of 24.83 seconds based on a sample set of… 1 hit. Of course we shouldn’t jump to any conclusions with this result. But as obvious as this seems I have seen numerous bosses and directors quickly look at high page load results like this and freak out. I witnessed one director lose his cool and lash out at the developers for enabling this kind of poor performance. Things calmed down only after I pointed out that the data he was looking at was based out of a sample set of 2 visitors from the other side of the world with unknown network connections.

Website speed not only has an impact on your users, but also your job. It will benefit everybody to make sure you capture as much of a reliable sample set as you can and determine when you can make valid decisions from good data.

2. Analyze and Act

The Google Analytics Site Speed reports can be found in “Behavior -> Site Speed” section. Although there are a few different reports in this section, I’m going to focus on the ‘Page Timings’ section which focuses specifically on load times for your pages. These reports contains the following metrics tabs:

Site Usage: this report shows a page’s load time against other basic usage metrics like bounce rate and exit rate. Although it is valuable to find some correlations between high/low page loads and other usability metrics, this report doesn’t show the Page Load Samples column and you run the risk (again) of making decisions based on what might be small sample sets for each page.

Technical: This is my favorite report where I get to play detective and diagnose page load problems. This report features the average page load time, the page load samples, and also starts to break down the individual segments that make up the total page load time. I’ll review these more in a moment.

DOM Timings: This report continues the trend of breaking down the segments of total page load time, though the focus here is on the latter stages of page load i.e. browser loading and rendering.

I’m going to break down each time segment to explain generally what phase of the page loading it deals with, as well as what you can do to improve it.

Avg. Redirection Time – If a requested URL leads into any redirects, the timing of the redirects will be found here. If there are no redirects for a hit then this will be calculated to 0.

What you can do: Check to see if you have any daisy chain redirects and try to eliminate or reduce the chains. For quick manual checks I like to use Rex Swain’s HTTP Viewer with the auto-follow enabled.

Avg Domain Lookup Time – The amount of time taken for the DNS lookup of a page.

What you can do: Typically, DNS lookups are very reliant on a user’s ISP and any problem would be outside of your control.

Avg Server Connection Time – The amount of time spent to establish a valid connection to your web server.

What you can do: Although a user’s internet connection can still be a factor here, a slow connection may mean that you have a problematic web host. When a request goes inside the realms of your web host provider, you’re at the mercy of their data center’s network. If you use some kind of cheap-o web host provider, you may be getting what you pay for, especially if you’re in a shared hosting environment with server resources that are being exhausted. If you see problems here, consider changing to a different web server setup.

Avg Server Response Time – Now that a request has reached your web server, how long does it take for your server to process the request and start to send something back?

What you can do: A couple of things might be involved here. Your web server can be poorly configured to handle even a basic amount of user connections and processes. If you have an amateur configure your server settings it’s very likely that RAM and process allocations are NOT optimized. Get a seasoned web server administrator to configure your web server.

Another possibility is that you’re running a database-driven site and NOT taking advantage of caching. For example, if you are running a WordPress site and don’t use a caching plugin, then you’re making your server work way too hard. No matter what CMS you are using, if you have pages that query your database for content BUT that content relatively remains static over a period of time, you should be caching that content so your server only needs to generate that content once over multiple requests. Enabling database caching is one of the most significant ways to improve web server and page load performance.

Avg Page Download time – The amount of time for the browser to download the page from the server, just prior to rendering.

What you can do: User connection issues aside, having very large source code for your primary document can lead to slow load times. Be diligent in eliminating in-line styles by using CSS, and for-the-love-all-things-good PLEASE place your JavaScript in external script files and not in your main source code.

Avg Document Interactive Time and Avg Document Content Loaded Time – These are the really juice time segments that deal with browser rendering and all the factors involved with that. The first time metric deals with how long it takes the browser to parse through the document, while the 2nd time segment deals with that same things PLUS any deferred or parser-induced scripts.

What you can do: The Speed Suggestions in the Site Speed reports should be your new friend. These suggestions link out to Google’s PageSpeed Insights and provide very detailed suggestions on how to optimize any page’s rendering performance. You may be directed to optimize your images, minify your JavaScript, enable GZIP compression, among many other items. Find a trusted web developer to help you implement any suggestions found in these reports.

3. Remember what’s important

You can’t tackle all of your page load problems right away. Analyze the pages with the largest page load samples and compare their page load times against bounce rates, landing page conversion rates and other key usage and goal metrics.

I also recommend looking down the lists of metrics in your Technical and DOM Timings metrics tabs to see if any specific time segments have unusually bloated times across the board (i.e. all your pages have a slow average server response time). Identifying common system-wide problems and resolving them is the proverbial ‘low hanging fruit’ for site speed optimization.

Most importantly, remember that this is all for improving the experience for your users. Our goal is to allow users to experience content that addresses a specific intent/question/thought in their mind. Do what you can to prevent page load problems from becoming conversion repellent that interrupts that desired experience.

Thanks Adrian for covering this topic, I have a domain which is hosted on amazon ec2 free tier for testing. I am working on SEO of the site and it has started receiving organic traffic. Now the page speed timings are going awry in Google Analytics. I guess its time to upgrade the server.

RightTech

Thanks for an excellent write up – wish that Google provided this sort of clarity in their Help info!

I’ve noticed page load times reported in Google Analytics are a lot faster than what I get when using Webpagetest or other testing tools.

Part of that is just dependent on the location of the user/test host. But I think a big part is that Google reports an average which includes page visits that have already cached assets.

That would suggest Google Analytics is not a good tool for assessing landing page load times for first-time visits to your site.

I think you can get a better sense of this if you filter to show only new users. But that still leaves you with averages for a page that include when a person views the same page several times in a session, or visits it later in a session with many assets already cached.