As a teenager, I once waited lit­er­ally hours to down­load a 30-second-long, 160×120 high­light reel of Frank Thomas clob­ber­ing a home run in the 1995 MLB All-Star Game. (When it finally fin­ished, I was fas­ci­nated to be able to see full-motion video on my com­puter and watched the clip per­haps 50 times.) Times cer­tainly have changed. Fast for­ward a decade or two and it’s a whole dif­fer­ent world. Inter­net users for the past sev­eral years, across all types of devices, are extremely sen­si­tive to site speed—how quickly the pages of your site load. In fact, as early as 2006, Google and Ama­zon were doing tests which clearly showed the impact of even just a few hun­dred addi­tional mil­lisec­onds on page load time in terms of lower traf­fic and lower con­ver­sion. Try search­ing the web for “site speed impact on con­ver­sion.” You’ll find dozens of results and per­haps hun­dreds of data points demon­strat­ing the value of site speed on the user expe­ri­ence and, there­fore, conversion.

If you’ve been look­ing for a way to mea­sure page load time against traf­fic and/or con­ver­sion in Adobe Ana­lyt­ics, we’ve now got you cov­ered via a very sim­ple plug-in devel­oped ini­tially out of a cou­ple of dif­fer­ent vari­a­tions by Adobe con­sul­tants Michael Bhalla, Matt Smed­ley, and Trevor Paulsen. This plug-in allows you to report on both traf­fic and con­ver­sion against page load times, and both are classification-compatible, mean­ing that you can build cus­tomized groups of page load times (“Less than 1 sec­ond,” “1−5 sec­onds,” etc.), allow­ing you to get as gran­u­lar or as broad as you like. For the rest of this post, I’ll walk you through the basic steps to install the code and get started mea­sur­ing load times, and talk about a few ques­tions to ask based on site speed data. Com­plete doc­u­men­ta­tion and code sam­ples are also avail­able in our help sec­tion.

Plug-in Code

Here is the snip­pet of code that you should drop into the plug-ins sec­tion of s_code.js or AppMeasurement.js. It should also work with any TMS that sup­ports plug-in usage.

/*
 * Copyright 2011-2013 Adobe Systems, Inc.
 * s_getLoadTime v1.36 - Get page load time in units of 1/10 seconds
 */
function s_getLoadTime(){if(!window.s_loadT){var b=new Date().getTime(),o=window.performance?performance.timing:0,a=o?o.requestStart:window.inHeadTS||0;s_loadT=a?Math.round((b-a)/100):''}return s_loadT}

Now, it’s worth not­ing that this plug-in takes advan­tage of the window.performance.timing object, which is sup­ported by cur­rent ver­sions of all major browsers. In many cases, not sup­port­ing older browsers is prob­a­bly okay; odds are you don’t have a large per­cent­age of users on older browsers. Fur­ther, the aspect of page load time that you can con­trol isn’t depen­dent on browser choice, so the busi­ness require­ment of under­stand­ing site speed impact on con­ver­sion can still be met. That said, if you want to make sure to cap­ture site speed data from users of older browsers, you can install this code snip­pet in the <head></head> sec­tion of your pages, near the begin­ning of that sec­tion and prior to call­ing any JavaScript, CSS, etc.

<script type="text/javascript">var inHeadTS=(new Date()).getTime();</script>

This will ensure that you’re cov­ered for all major browsers includ­ing older ones.

Plug-in Call and Assign­ment to Variables

The next step is to pick a cus­tom vari­able (or two) where you want to store load times. (In this exam­ple, I’ll use prop1. This could be any prop or eVar vari­able, or both. I’ll cover vari­able setup in the Admin Con­sole below. Here is how you call the plug-in within the s_doPlugins() func­tion in the JavaScript code. (For more infor­ma­tion on s_doPlugins(), see our prod­uct documentation.)

s.prop1=s_getLoadTime();

This will assign the page load time, in tenths of a sec­ond, to prop1. For exam­ple, if my page took 3.75 sec­onds to load, I would get a raw value of 38 in the Page Load Time (prop1) report. The report will look some­thing like this, initially:

Page Load Time report

(Hope­fully your val­ues will be much lower; I per­formed my tests while using air­port WiFi. Not quite as slow as my dial-up con­nec­tion from 1995, but close!)

Clas­si­fy­ing Page Load Times

You prob­a­bly won’t want detail down to tenths of a sec­ond for your report­ing; in most cases, that’s too gran­u­lar to be action­able in terms of work­ing with your inter­nal stake­hold­ers to under­stand how to improve usabil­ity. For­tu­nately, clas­si­fy­ing these val­ues is really easy, and only needs to be done once. Let’s say you want to group page load time by sec­onds, and also by broader groups, such as “5−10 sec­onds.” This is as sim­ple as set­ting up two new clas­si­fi­ca­tions based on the vari­able I am using for page load time, then build­ing a very sim­ple Excel file out of your clas­si­fi­ca­tion tem­plate. The key col­umn should be mil­lisec­ond val­ues from 1 through, say, 600 (which is 60 sec­onds, a VERY long page load time!). Do not use com­mas or peri­ods in this key col­umn. In the other columns, you will group these raw val­ues by sec­onds or other group­ings based on the level of gran­u­lar­ity you want in your report­ing. Upload via your web browser and within a few min­utes or hours, you should be all set. You should get reports that look like this, with val­ues that are avail­able for seg­men­ta­tion and are eas­ily under­stand­able by stake­hold­ers around you:

Page Load Time classified

As a bonus, you could also use the new Clas­si­fi­ca­tion Rule Builder with reg­u­lar expres­sions to even-more-quickly, even-more-easily build the clas­si­fi­ca­tions that you will need in order to report on page load times.

Where Should I Start with Page Load Analysis?

One of the great things about using clas­si­fi­ca­tions to great group­ings based on page load time is that you can seg­ment your vis­its and vis­i­tors based on these cus­tom group­ings to ana­lyze how behav­ior dif­fers based on this aspect of user expe­ri­ence. For exam­ple, you can cre­ate a seg­ment for vis­its where the land­ing page loaded in less than three sec­onds, and com­pare that against vis­its where the land­ing page loaded in 5–10 sec­onds. How did con­ver­sion rate dif­fer? It was lower for the group that had a slower expe­ri­ence early in their visit? Not shock­ing, but impact­ful when pre­sented to peo­ple design­ing heavy land­ing pages.

You can also eas­ily iso­late spe­cific pages that are load­ing slowly. Run one of your new clas­si­fi­ca­tion reports based on page load time. See the group that rep­re­sents “Longer than 5 sec­onds?” or sim­i­lar? Break that down by page to see which pages most fre­quently fall into that bucket. If a page you own is at that top of that list, it might be time to review the con­tents of that page and see if you can tighten it up a lit­tle bit. To enhance this jump­ing off point for analy­sis a lit­tle fur­ther, use the ad hoc analy­sis tool (f.k.a. Dis­cover) and per­form this break­down using “Exit Rate” (Exits/Page Views) as your met­ric. Now you can see which pages from the “very slow load time” bucket pro­duced the most exits when load time for that page was slow. You can then com­pare that with faster load times to see just how sig­nif­i­cant page load time is in dri­ving away prospects and customers.

Another fun use for page load data might be to write a lit­tle bit of code on top of our Real-Time API to pull these val­ues as they stream in to your report suite, and then report them out on a live dash­board in your IT depart­ment or else­where. You can even have it send you a note when load time spikes for a “slow page load” group of val­ues, along with the guilty page names. It’s a great way to know imme­di­ately if some­thing might be wrong.

There are dozens of other places where I might start to use page load time data to inform and enhance my user expe­ri­ence, but hope­fully these few will get you started. If you have oth­ers that you have found suc­cess­ful, or that you want to try, please leave a comment!

2 comments
kf1re
kf1re

Hey Ben,


Thanks for the very useful post - we're thinking of implementing this ourselves as it would give us some absolutely awesome data!


One question - does this work across all major devices as well?  Any particular 'watch-outs' or issues with e.g. iPads, etc?


Thanks,

Tim.

ericmatisoff
ericmatisoff

 If you're looking to add the inHeadTS code using Adobe DTM, 


Add full set of code from above as a "Top of Page" Page Load Rule using Sequential HTML.

Sweeeeeet