{"id":551,"date":"2019-05-28T20:35:00","date_gmt":"2019-05-28T20:35:00","guid":{"rendered":"https:\/\/www.digitaldatatactics.com\/?p=551"},"modified":"2020-09-17T21:15:19","modified_gmt":"2020-09-17T21:15:19","slug":"adobes-performancetiming-plugin-with-some-improvements-and-an-explanation","status":"publish","type":"post","link":"https:\/\/www.digitaldatatactics.com\/index.php\/2019\/05\/28\/adobes-performancetiming-plugin-with-some-improvements-and-an-explanation\/","title":{"rendered":"Adobe\u2019s performanceTiming plugin, with some improvements and an explanation"},"content":{"rendered":"\n
\"33<\/figure><\/div>\n\n\n\n

(This is cross-posted form the 33 Sticks blog<\/a>)<\/p>\n\n\n\n

As Page Performance (rightfully) gets more and more attention, I\u2019ve been hearing more and more questions about the Performance Timing plugin from Adobe consulting. Adobe does have public documentation for this plugin<\/a>, but I think it deserves a little more explanation, as well as some discussions of gotchas, and potential enhancements.<\/p>\n\n\n\n

How It Works<\/h2>\n\n\n\n

Adobe\u2019s Page Performance plugin is actually just piggybacking on built-in functionality: your browser already determined at what time your content starting loading and at what time is stopped loading. You can see this in a JavaScript Console by looking at performance.timing<\/em>:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This shows a timestamp (in milliseconds since Jan 1, 1970, which the internet considers the beginning of time) for when the current page hit certain loading milestones.<\/p>\n\n\n\n

Adobe\u2019s plugin does look at that performance timing data, compares a bunch of the different milestone timestamps versus each other, then does some math to put it into nice, easy-to-read seconds. For instance, my total load time would be the number of seconds between navigationStart and loadEventEnd:<\/p>\n\n\n\n

1556048746779 (loadEventEnd) \u2013 1556048745659 (navigationStart) = 1120 milliseconds, or 1.12 seconds.<\/p>\n\n\n\n

Additionally, if I choose to, I can have the plugin grab information from the built-into-the-browser performance.getEntries()<\/em>, put it into session storage (not a cookie because it can be a long list), and put it into the variable of your choice (usually a listVar or list prop) on the next page. These entries show you for EACH FILE on the page, how long they took to load.<\/p>\n\n\n\n

Unfortunately, if I\u2019m sending my analytics page view beacon while the page is still loading, then the browser can\u2019t tell me when \u201cdomComplete\u201d happened\u2026. because it hasn\u2019t happened yet! So the plugin writes all these values to a cookie, then on your NEXT beacon, reads them back and puts them into numeric events that you define when you set the plugin up. This means you won\u2019t get a value on the first page of the visit, and the values for the last page of the visit won\u2019t ever be sent in. It also means you don\u2019t want to break these metrics down by page, but rather by PREVIOUS page- so often this plugin is rolled out alongside the getPreviousValue plugin. This also means that the plugin is not going to return data for single-page visits or for the last page of visits (it may collect the data but doesn\u2019t have a second beacon to send the data in on). for this reason, your Performance Timing Instances metric may look significantly different from your Page Views metric.<\/p>\n\n\n\n

What It Captures<\/h2>\n\n\n\n

Out of the box, the plugin captures all of the following into events:<\/p>\n\n\n\n