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). If you’ve tried loading your website from slower connections, and are basing it on a CMS like WordPress or Joomla, you might start wondering “why is WordPress so slow – is it my website? The server?” There are many other factors to consider as well, such as 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?
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.
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.
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.