Increase Your Google Analytics Page Speed Hit Limit

Increase Your Google Analytics Page Speed Hit Limit

/

increase-your-ga-page-speed-limit

It’s not much of a secret that slow-loading pages on your site decrease the chances of a visit converting. Walmart, Google, and others have released data that point to real-world impacts from sluggish page load times. Enter the Page Timings report in Google Analytics – chock-a-bloc full of actionable metrics. You can see exactly which pages on your site are loading slowly, and you can apply Segments to focus on just the traffic you’re interested in.

There’s just one catch – the data is pretty heavily sampled. By default, Google Analytics collects timing data on just 1% of users who visit your site, or 10,000 hits per day, whichever comes first. You can increase the percentage of users that are sampled, but once you hit 10,000 hits, you’ll get no more data. My colleague Samantha Barnes has written an excellent guide that fleshes out this feature toe-to-tip.

What I’m here to tell you today is that you actually can exceed the 10,000 hit limit for your page timing data. How’s that, you’re asking? By using Events, of course.

How It Works

The page timing data you see in Google Analytics isn’t being gathered by any kind of JavaScript witchcraft on the browser: they come from the Navigation Timing interface, an API exposed by modern browsers that holds data on a slew of different and important steps the browser takes on the way to rendering a page. The Mozilla Developer Network has a a great guide to this API here.

Since this interface is available to any Joe Schmoe, we, too, can use it to get data about how long our pages take to load.

Capturing The Data

You can implement this through JavaScript on your page or through Google Tag Manager. We’ve even created a Page Load Timing GTM Recipe to make your life easier!

I’ve also provided instructions below:

  1. Create a new Google Analytics Event. Fill in all the normal information, your Google Analytics Tracking ID, etc.
  2. Give it whatever Category name pleases you best, I used “Site Speed”
  3. For the Action, fill in the Variable {{Page URL}}. Either type this, or choose it from the lego dropdown box.
  4. For the label, click the Variables drop down and choose Create a new Variable.
  5. Select the Variable type Custom JavaScript and paste the below into the field:

  1. Finally, select ‘True’ for the Non-Interaction Hit field. We’ll be firing this automatically and we don’t want this to artificially affect our bounce rate.

In the end, your Event should look something like this:

Once you’ve got that configured, you’ll need to create two Triggers – one to fire the tag, and another to block it when the API isn’t available. The firing Trigger is super simple – we’ll just use the built-in Window Load Pageview Type:

Next, we’ll need to create our blocking trigger; it should look like this:

Why Not Custom Metrics?

Custom Metrics are a great choice! If you’d like to gather the same metric in a Custom Metric, or pull out additional Timing API data and plug it into Events there, be my guest. The reason I’m recommending an Event here is that we need to fire the Event on window.load, which can come well after we’d like to send a Pageview, and thus we have to fire a second hit – so why not just use that hit for our data. If you’ve already got an Event firing on every pageview, you can just use a Custom Metric instead.

Keep in mind that adding this Event will effectively double the hits you’re generating; if you’re running close to that 10 million hit limit on a monthly basis, you should sample this hit, either through the sampleRate Field To Set or another Blocking Exception like the Blocking Trigger #7 Jon Meck outlines here.

So What Does This Do For Me?

Using your page speed timing data, you can learn which pages of your site are taking an abnormally long time to load. By sorting first by the Label, you can drill into just the pages that are going over a certain threshold, e.g. 2.0 seconds or higher, and begin to investigate why they’re not up to snuff. If you want to be really fancy, try the new Histogram Buckets feature in version four of the Core Reporting API. Some additional tools that will help you along your way:

  • WebpageTest.org, which allows you to run up to 9 simultaneous loads of a page and returns a handy waterfall of the results
  • PageSpeed Tools, which provide concrete recommendations on how to improve the performance of your pages
  • Chrome’s Timeline Tool, found in the developers console

Armed with your data and these tools, you can drastically improve the performance of your site (and hopefully your conversion rate, too).

Any questions? Sound off in the comments below.

Dan Wilkerson is a Software Engineer at LunaMetrics. He is passionate about web technology, measurement, and analysis. Dan is the winner of the 1999 Forge Road Elementary School Science Fair for his groundbreaking report on how magnets work. (ICP, take note.) Dan has worked at LunaMetrics in social media, as our marketing manager, and now in our analytics department.

  • https://plus.google.com/u/0/118019176902869966567/posts/p/pub steve

    When i set this up in analytics i just get “-1470064037.4” in the event label column

  • Dmitri Ilin

    Hi, Dan,

    thanks for the article. Probably, using the following variable to determine page load time with NT API could be a better option:

    function(){
    var result = ‘not available’, event = {{Event}};
    var performance=window.performance||window.webkitPerformance||window.msPerformance||window.mozPerformance;
    if (event === ‘gtm.load’ && !!performance) {
    var timing = performance.timing;
    result = Math.round((timing.loadEventStart – timing.navigationStart) / 100) / 10;
    }
    return result;
    }

    Thus, there’s no need to create the second “blocking” trigger. Instead, we can use a single trigger like this:

    Custom Event
    Event name equals gtm.load AND Page Load time does not equal not available

    And why can’t we use user timings instead of events?

    • Dan Wilkerson

      Hi Dmitri,

      That’s a totally valid way to do it. I generally prefer using separate variables for separate tasks because it makes things more obvious to the outside observer and I have often had to decompose variables like that later on when another tag needs the same functionality. It all comes down to preference and needs!

      Per your second question, User Timings are capped at 10k hits per day (a bit of an oversimplification, but accurate), just like our Page Speed Timings. Events have no such cap and provide pretty much the same functionality.

      Dan

Contact Us.

LunaMetrics

24 S. 18th Street, Suite 100,
Pittsburgh, PA 15203

Follow Us

1.877.220.LUNA

1.412.381.5500

getinfo@lunametrics.com

Questions?
We'll get back to you
in ONE business day.