Google’s new +1 button is the widget du jour, with countless installations since its launch on June 1. But as it turns out, the +1 button could make pages up to two seconds slower, according to performance consultant Aaron Peters.
Since Aaron documented his performance audit on his blog, Google has responded by saying that they’re working hard on fixing the +1 button’s performance problems. But that doesn’t change the fact that there are a lot of people out there who have unwittingly inserted a chunk of code on their pages that could be dragging down their website’s performance.
The myth of “just a single line of Javascript”
Just because a widget provider is trusted and well known, that doesn’t mean you can assume they’re building fast tools. These tools often get touted as “just a single line of Javascript.” I’m here to tell you that “just a single line of Javascript” is a meaningless phrase that third-party tool vendors have invented to make their apps sound easy and low-impact.
To illustrate, here’s what the uncustomized +1 button’s code snippet looks like:
<!-- Place this tag in your head or just before your close body tag -->
<script type="text/javascript" src="http://apis.google.com/js/plusone.js"></script><!-- Place this tag where you want the +1 button to render -->
<g:plusone></g:plusone>
That’s it. But that little snippet of code contains one serious performance faux pas (recommending that you place the tag in the head, the negative consequences of which Aaron explains further in his post). It also includes a typo – the file is called over HTTP, but will be served over HTTPS – that will cause a redirect (read: delay) in how the page renders, most notably for people using IE8.
I don’t want you to think that I’m singling out Google for criticism. I’ve collaborated with folks at Google several times. They’re smart, conscientious people. They do good work. So let’s look at another famous widget: the Facebook “Like” button. Ecommerce consultant Matthew Ogborne did his own audit of the “Like” button, and immediately removed it from his site when he realized it was making his pages 1.34 seconds slower.
These are just two examples. The internet is rife with more — companies who, with the best of intentions, are creating widgets that bung up your page load. Taken individually, it’s easy to brush this off. What’s a second here, or a few hundred milliseconds there, after all? Not much, until you do the math and realize that you’re adding several seconds of load time to your pages.
(As an aside, if you want to learn the load times for a handful of common third-party tools — including the Digg widget, Google Analytics, and Quantcast – check out Steve Souders’s P3PC project.)
Why you need to care about site speed
John Ekman has already written an excellent post here about the impact of page speed on your Google search ranking. But site speed has also been linked to pretty much every other metric you care about: bounce rate, conversion, page views, customer satisfaction, and revenue. Whether you’re talking about mega-giants like Amazon (Powerpoint download) and Shopzilla (report) or smaller “mortal” companies like Artbeads (case study) and Edmunds (report), they’ve all found the same thing: when you make your site faster, you increase conversions by anywhere between 1% and 16%.
How to calculate whether a cool new third-party tool is going to help or hurt conversions
So… given the importance of making websites as fast as possible, and given the potential for third-party widgets to leech performance, how many people actively investigate the impact of button on their site? (If you answered “Practically none,” give yourself a prize.)
Third-party content is here to stay. Ads, social media widgets, recommendation engines — these are all here to stay, and with good reason. Overall, they add value and generate revenue. But you need to know how to separate the ones that are going to help you from the ones that could hurt you.
Here’s how to conduct a simple cost-benefit analysis when you’re evaluating prospective third-party tools:
- Perform an A/B test of your site, with and without the tool, in a real-world environment. Generate waterfall charts for both tests (for more on waterfalls, I wrote this post a while back that explains how to read them), and identify how long the third-party objects take to load. Note these benchmarks.
- From the tool vendor, get the number for the average conversion rate bump experienced by other sites that use the tool.
- Using Aberdeen’s widely accepted performance stat that a 1-second page delay equals a 7% loss in conversions, calculate the potential net conversion gain or loss. For example, if a tool slows down page load by 2 seconds, that means a 14% conversion loss. But if that same tool promises a 20% conversion increase, then that’s a net gain of 6% (not including the cost of purchasing the tool).
If you find that a widget has the potential to slow down your site beyond what is acceptable, let the vendor know. There’s a good possibility that they’re not aware of the problem, and like Google, they’ll be happy for the feedback so they can fix the problems.
Final tips: Optimize your pages and talk to your ad agency
And while you’re optimizing your third-party content, get your developers to, wherever possible, prioritize page elements so that non-essential content loads last rather than first.
This extends to ads as well, if you can get away with it. If your ad agency insists that ads remain a priority, then ask them how they ensure that they are optimizing the ads they serve to maximize performance. Slow-loading ads are a major cause of high bounce rates.
You’re not doing yourself or your advertisers any favors by decreasing your page views.
