使用GA测量单页面应用的页面加载时间

Question

I'm using Google Analytics in an SPA. For any virtual page redirects (like an AJAX call to refresh the body of the page), I'm getting a page load time of 0ms . Is there a way to track how long that takes, just as if it was a full page refresh? I'm hoping to include how long it takes for the AJAX call and also the time to download and display images that are loaded as a result.

Answer 1

As you have found, Google Analytics will not provide page timings for SPA's. This includes if you increase the site speed sample rate to 100. This is because Google Analytics calculate the page timings using the Navigation Timing API.

For example, DOM loaded would be:

$(document).ready(console.log((Date.now() - 
    performance.timing.domComplete)/1000))

To over come this problem, you will need to use custom metrics. The solution has three steps.

1) Set up a custom metric in GA.

Go to Admin > Property > Custom Definitions > Custom Metric.

Create a new Custom Metric, with the scope of Hit and the formatting type of time. Note: Specify time in seconds, but it appears as hh:mm:ss in your reports.

2) Set up a timer.

You will need to capture the time when you want to start the measurement of page load time.

An example solution to this might be by decorating all of your internal links, eg:

$('a[href*="stackoverflow"]').click(function(){
  time1 = Date.now()
})

3) Send the time eclipsed (in sec) to Google Analytics on the virtual pageview event.

When the virtual pageview event occurs (which triggers your virtual pageviews), retrieve the difference between the current time (Date.now()) and the time which the timer was started (time1).

Using Google Tag Manager, a custom javascript variable can be created as below:

function(){
  return (Date.now() - time1)/1000
}

This value then needs to be sent with the pageview, against the custom metric index set up in step1.

ga('send', 'pageview', {
  'metricX': pageLoadSpeed
});

Using the custom metric along with calculated metrics (eg {{virtualPageTimings}}/{{pageViews}}, you will be able to calculate your average virtual page timings.

Bonus:

To make the measurement more accurate, set up a secondary custom metric to count the number of virtual pageviews. This will make sure that pageviews which users are directly navigating to are not taken into consideration.

To do this, create a custom metric with the scope hit and the formatting integer.

Then with every virtual pageview, send the value 1 against the custom metric index. Eg:

ga('send', 'pageview', {
  'metricX': pageLoadSpeed,
  'metricX': 1
});

This allows for the calculated metric:

{{virtualPageTimings}}/{{virtualPageViews}}

Answer 2

If you checkout the Google Analytics docs, you can find out about the siteSpeedSampleRate option, which basically allows you to turn on your site tracking beacons for a percentage of your users.

By default this value is at 1 , but I'm assuming you might want to turn it to 100 . It might affect a bit in term of network usage since it will have to transfer more data to GA, so take that into account depending on your users and how they access your website (through mobile, bad coverage in some countries...).

You'll have to modify your tracking code to integrate something like the following:

ga('create', 'UA-XXXX-Y', { siteSpeedSampleRate: 10 })

Answer 3

You can send the timing manually, As everything on Google Analytics. But it's a little bit tricky to do,if I'm honest I would no do it unleast it's necessary. All the data on the time report are based on a hit called timing, this hit is send after the pageView and contains the following information. If you can see my example, I forced the tool to send the hit, just after the pageview goes another hit with a special list of parameters.

plt : Specifies the time it took for a page to load. The value is in milliseconds.
pdt : Specifies the time it took for the page to be downloaded. The value is in milliseconds.
dns : Specifies the time it took to do a DNS lookup.The value is in milliseconds.
rrt : Specifies the time it took for any redirects to happen. The value is in milliseconds.
srt : Specifies the time it took for the server to respond after the connect time. The value is in milliseconds.
tcp : Specifies the time it took for a TCP connection to be made. The value is in milliseconds.
dit : Used to send a random number in GET requests to ensure browsers and proxies don't cache hits. It should be sent as the final parameter of the request since we've seen some 3rd party internet filtering software add additional parameters to HTTP requests incorrectly. This value is not used in reporting.
clt : pecifies the time it took for the DOMContentLoaded Event to fire. The value is in milliseconds.

More info of this parameters on : https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters and You can see more info of this hit on https://developers.google.com/analytics/devguides/collection/analyticsjs/user-timings

So what happens now?, if I launch another pageview in this SPA, the second pageview on the same page will not carry this hit and you will ever get 0 of loadtime. You can use the command as the official documentation but if you use it you will notice that is not the same hit (i have to double check that). Other option is send it manually using the command 'send' and attaching the desire information. Check your pageview hit structure to be sure that your timming is actually attaching to your previous hit.

The comand to send the timming after the pageview is send will be something like that, use the &dl parameter or 'dp' parameter to attach the timming to the ajax page.

ga('send', {
  hitType: 'timing',
  '&plt': 1,
  '&pdt': 1,
  '&dns': 1,
  '&rrt': 1,
  '&srt': 1,
  '&dit': 1,
  '&clt': 1,
  '&dl': 'http://cl.edreams.com/',
});

Now all the values '1' needs to be updated for the correct one, now how to determine the time of each parameter not sure at all. Also remember that the sampling by default is only for the 1% of the sessions, send this hit only in a few cases.

Disclaimer : This is a very experimental implementation, we are forcing the Js to send unexpected information. Test it well before to pass it to a final project

Greetings