1 Jun 2011
Chances are, you already know about +1, Google’s new social sharing button. You may already have it installed on your site.* But did you check first to see what kind of performance impact it could have?
Come to think of it, if you’re reading this post, chances are you did check to see what kind of performance impact it could have on your site. But if you did this, you’re in a tiny minority.
At the risk of sounding like a curmudgeon, I see a lot of widget bandwagon-hopping, with people loading up their site with every new button and third-party tool that comes along, with little regard for the end result. In 2011, widgets are to websites what animated gifs were in 1996.
Google, of course, being Google, has addressed the performance question, if somewhat vaguely, in their technical FAQs:
No, there is no significant latency impact from the placement of the <script> tag. However, by placing the tag at the bottom of the document, just before the body close tag, you may improve the loading speed of the page.
In my ideal world, however, every new third-party button or app would come with an awesome set of detailed performance notes, like these ones that Lanyrd published with their badge release:
The initial person-v1.min.js script is 2215 bytes, and is served from our Amazon CloudFront CDN. It should load extremely quickly, and won’t block the loading of your page even if Lanyrd.com itself is unavailable.
That script than makes a single second call to Lanyrd to retrieve all of the necessary data, no matter how many different badges you have on the page. This call is handled by our Varnish cache server, so again it should be very fast.
Badge responses are cached for 10 minutes, so it may take up to 10 minutes for a new conference you are tracking or attending to show up on your page.
If Lanyrd is unavailable your page load time will be unaffected — the badges will simply fail to appear.
All third-party apps are not made equal
Sure, Google being Google, you can probably count on them to deliver a speedy tool**, but can you extend this same trust to every third-party content provider out there, no matter how mega-huge? (Correct answer: No.)
As ecommerce consultant Matthew Ogborne wrote about recently, all those kilobytes can pile up fast. He found that installing Facebook’s “like” button resulted in an extra 84k, which translated to 1.34 precious seconds. And as Tim Morrow pointed out at Velocity last summer, poorly implemented third-party content caused Shopzilla to lose most, if not all, of its hard-won performance gains.
For die-hard widget junkies, a couple of tips:
1. Defer widgets so they’re one of the last page objects to load.
This is a great optimization technique because the button is a piece of third-party code that can slow down a page, and it’s not crucial to how a page functions.
2. Perform a cost-benefit analysis for each widget.
You need to make sure that the conversion gains (or whatever gains you’re anticipating) promised by the widget are not going to be killed by the performance losses it forces on you. Here’s a simple how-to for conducting this analysis. You should also check out Steve Souders’s P3PC project, which provides load times for a handful of common third-party tools.
*As I will no doubt be installing it on mine.
**Edited 06/06/11 to add: Or maybe not. Aaron Peters has written this performance review of the +1 button. His conclusion: the button could add up to 2 seconds of extra load time to your site.