Modifications to the 'performanceTiming' plug-in

[#1]

Overview

The 'performanceTiming' plug-in is extremely useful; however, the conditional logic triggering its s.performanceWrite function should be more robust.

Detail

The s.performanceWrite function (which calculates the performance timings and writes them to a cookie) is triggered as part of an interval timer; however, the interval timer relies on the performance.timing.loadEventEnd attribute being equal to 0 for the interval timer to be started, and if the plug-in is loaded with a delay of a few seconds, the loadEventEnd attribute may already be greater than 0 - as a result, the s.performanceWrite function is never called.

Suggestion

One solution is to include a flag that is set to true as part of the s.performanceWrite function executing; while this flag is false, s_doPlugins will repeatedly attempt to run the s.performanceWrite function.

[#2]

Hi BarryLennon​,

any chance you have a sample of the suggested solution to share?

Am experiencing the same issue.

best

fredrambert​

[#3]

Once I had looked into this a bit more, I decided to move away from the performanceTiming plug-in altogether.

There was a number of small quirky things that informed the decision, but a major factor was that the data was only being captured on the subsequent Page View call (or the Exit Link call, if there was one) - this meant that you end up missing one measurement in almost every visit, and it's worth noting that the missed measurement is for the load of the page on which the visitor chooses to leave.

On our site, it made more sense to read the measurements from the window.performance object directly and send them with the Page View call for the page on which the measurements were recorded.  To improve capture rates, if the measurements are not available at the point that the Page View server call is fired, any subsequent Link-tracking server call that goes off before the page is unloaded could be used.