DTM pageload timings

[jor63980046]

Hello,

We are using a custom JavaScript inside AEM DTM to track the timings of the page loads.

The custom script uses the performance.timing objects and looks like this:

return performance.timing.loadEventEnd - performance.timing.navigationStart; 

The value is stored in a evar and prop (we tried both).

This works fine when we test it in the console (satellite debug enabled), but when we inspect the value delivered by the DTM custom script, we end up we a negative number, because the loadEventEnd is 0.

We tried different approaches with onLoad, domReady, ... page rules, all with the same result.

Any help is much appreciated!

Thanks.

[simpil]

Hi jor,

I have check this for you and here is the result.

1. When testing it in the Console (I assume you did not put in a Breakpoint to test it) the loadEventEnd Value is already set. Because everything has finished loading.
2. When using any other approach within DTM than 'onLoad' the loadEvent has not been triggered yet and that´s why the value is 0.

The problem with onLoad is the moment onLoad is being triggered the loadEventEnd does not contain the value yet.
I have tested this in Google Chrome by adding an evenListener to the Window Object:

window.onload = function(){

  console.log(JSON.stringify(performance.timing)); <- This way you get the actual object and not the Object pointed towards. check ths value for loadEventEnd, for me it always has been 0.

  console.log(performance.timing.loadEventEnd); <- This value is 0

  setTimeout(function(){

    console.log(performance.timing.loadEventEnd); <- This value is set

  }, 0);

}

Long story short with the default functionality of DTM you will not be able to capture performance.timing.loadEventEnd.

If you really need to have those values been properly tracked you can send a second call to Adobe using a EventBasedRule but this way you destroy your default Bounce Rate and double your Server Call costs to Adobe (at least for Page Views).

[BarryLennon]

Hi Jor,

Broadly speaking, the approach to this is to store the calculated value and pick it up on the next page load; the value is then analysed against "Previous Page Name" (or a dedicated "Performance Timing Page Name" variable).

That's the approach taken in Adobe's performanceTiming plugin with an additional bit of functionality that picks up the measurements on Exit Link-tracking calls as well.

[robertsimAD · Accepted solution]

Hi Jor,

Instead of using performance.timing.loadEventEnd, you will have to calculate the timing at when you invoke your function.

If you are calculating from performance.timing.navigationStart, you can use performance.now() to return the page load time at the point you invoke your function.

Note, in s_getLoadTime plugin, the start time is performance.timing.requestStart. If you decide to use this as your start time instead, you will have to calculate in this manner:

performance.timing.navigationStart + performance.now() - performance.timing.requestStart

Note: going through the following chart will aid in understanding when the respective performanceTiming markers are set with their respective values. The chart can be found in the W3C Navigation Timing recommendation document:

[adilk]

Hi Barry,

How can performanceTiming be used with Adobe Launch? Would you be able to provide the steps for this.

Thanks.

[BarryLennon]

Hi adilk​,

I wouldn't recommend any longer the use of Adobe's performanceTiming plugin:  in my view, the "lost" measurements (you will miss almost every single "exit page", i.e. the last page of the visit) are too important to ignore.

A better approach, in my opinion, is to write your own Data Element that calculates the measurements you want from the performanceTiming object (with reference to "navigationStart") and assigns these values to Events.  This sounds more complicated that using the provided plug-in; however, I think that including an Adobe plug-in in Launch is not that easy.

The primary benefits:

• No missing "exit page" measurements
• Capture measurements on the page where they are relevant (easier for end-users to understand)
• Choose the measurements that you are interested in

The downsides:

• It may be necessary to build in a delay to the firing of the Page View in order to wait for "loadEventEnd" to be populated (if your site fires its Page View relatively quickly; ours doesn't, so this is not a problem)

[adilk]

Hi Barry,

The website I'm looking at has been built in Angular and so, the first page load has the correct performance metrics in performance.timing variables. On second page load onward, loadEnd event timestamps stay the same as page 1 as the browser does not make a full round trip to load the content of the second page.

[BarryLennon]

In that case, @adlik, I think there are two parts to what you could consider doing:

1. If it were me, I would capture the "real" timings on the initial page load, event if it meant potentially delaying the initial Page View call to wait for the browser to make them available in `performance.timing`
2. For the "dynamic" page views (i.e. those subsequent ones), I would work with the Devs to define at least two timing events:
   1. "Navigation" - i.e. the point at which the user triggers an action that prompts a "dynamic" page load
   2. "Load Complete" - i.e. the point at which the dynamic page load is considered to have completed
   3. NOTE:  if your site is doing a lot of AJAX-style downloading of content, you could have other timings that represent the request being completed (e.g., "Content Downloaded"), and so on