ellipsis flag icon-blogicon-check icon-comments icon-email icon-error icon-facebook icon-follow-comment icon-googleicon-hamburger icon-imedia-blog icon-imediaicon-instagramicon-left-arrow icon-linked-in icon-linked icon-linkedin icon-multi-page-view icon-person icon-print icon-right-arrow icon-save icon-searchicon-share-arrow icon-single-page-view icon-tag icon-twitter icon-unfollow icon-upload icon-valid icon-video-play icon-views icon-website icon-youtubelogo-imedia-white logo-imedia logo-mediaWhite review-star thumbs_down thumbs_up

Uptime, Downtime, All Around the World

Uptime, Downtime, All Around the World Andrew Edwards
How many times have you bailed on a site because it loads too slow?

How often do you suppose the site owner knows this is why you abandoned?

The gap between these two instances can get canyonesque, and the wider that gap, the harder it is for the site owner to understand what is driving their critical site-abandonment data.

To put this in historical perspective, we must briefly travel back to an age where dial tones preceded the screech of modems as they attempted to connect with a host. We were pretty much bound by the skinny copper-based throughput we endured, and we would get used to waiting as bits and bytes crawled towards our browser testing what often felt like our near-infinite patience. Sites were skinnier, too. Developers were caught between a customer's desire for a rotating globe (animation!) and the same customer's requirement that the page not "take forever" to load.

Flash forward: we are watching movies streamed to our "cell phones", which really are computers that have a two-way radio inside to exchange digitized voice and data with a nearby antenna. No antenna, no service. One bar, lousy reception and no movies. This scenario gets played large every day all over the world, not just with cell phones but with all computers and with rare exception, bedevils access to every site at some point at some time. And yet its impact is often overlooked.

How could something this basic get so buried?

My theory is that the notion of load-time is just not sexy enough. You can't solve it with standard web analytics alone and you can't solve it with better creative. And after all, are we not well beyond the stage where bandwidth, now cheaper than dirt, can pose a challenge? Who wants to think about how fast the cool new module loads, when all we're trying to do is provide a more attractive and functional interface? Making sure bandwidth is adequate must be someone else's problem, right?

It is difficult to imagine a marketer happy to know the site didn't load. But it's almost as difficult to imagine a huge percentage of marketers knowing that load time would be directly correlated to site abandonment. Often they don't know because their analytics tools don't tell them about load time. And when IT tells them the pages are loading at a rate of eighteen-and-a-half-nanoseconds-per-content-unit, they tend to get a troubled angry look on their face and pretend not to have heard. This is often because the load time data is without context. So who cares?

Every marketer needs to care about load time today, just as much now if not more than the days when "you've got mail" was not yet an esoteric punch line. Much of the entire marketing heft is carried now by the site. Its worldwide availability cannot be left to guesswork. And once known, load time needs to be fixed.

There are tools that can measure load time globally, and some can even perform synthetic testing on your behalf so you know where you are slow before it's too late. Were you wondering why abandonment in Mexico City is unnaturally higher than in Northern Virginia? It may be because in Mexico D.F. they never saw the full page. But wait, did that fancy page with a hundred tags on it not load okay in beta? And even in production? Doesn't matter. You cannot control, nor can you know without measuring, what happens at the end of the bandwidth pipe. Right there in Mexico City or close by, there may be a reason why your pages load slow. Armed with that knowledge, you can adjust your global bandwidth presence or take other ameliorative steps to gain better load in that geography. In addition, some enterprise application management suites have load-balancing capability beyond just server substitution.

We have already established it's a content vs. bandwidth battle all the way to the desktop. But some of the bandwidth bandits may surprise you. It is not always the interactive module, or the ads themselves stealing your nanoseconds. Sometimes--more times than you'd think--it's actually the stuff you never see that clogs the pipe. Think about tags, for instance. Every ad is tagged, and often enough you don't control the tag itself. And your analytics tool adds tags to the ad tags. These can bog you down either because they are too big in aggregate or because they are being served up remotely from another server that may be much slower than the one hosting your site!

Welcome to tag management. There are a number of ways to do it and tools to help. One way to fight tag overload is to have them load "asynchronously" or perhaps better put, in a "managed" manner that interferes minimally with the user experience. There are also tools that can reduce the amount of tags loading the page without reducing tag functionality. Often they include additional tag-management capability that makes them more and more a part of the essential digital marketing toolkit.

Today there is no need to accept abandonment rates at face value. Marketers can be well-informed and can fight back. If you see high abandonment, assume nothing, and check load time. Often, equipped with the answer to "why" and the tools to give you the "how", you can rest easier that Mexico City is not going abandon you.

Andrew Edwards is a managing partner at Technology Leaders (www.technologyleaders.com), a web analytics consulting and technology firm based in New York. He is a co-founder and former board member of the Web Analytics Association. A pioneer in the...

View full biography


to leave comments.