Updated: 12 June 2013
Social sharing buttons are ubiquitous on the web, marking sites like smallpox scars on a 18th century courtier. They are often blamed for slowing down page performance. How much page weight do they add? How much extra data overhead? How much would they slow down one of my pages?
I've loaded a typical load-out of social sharing buttons onto a copy of this page - Tweet This, Facebook Like, Google Plus, and the Disqus commenting system.
I used Chrome's network inspector to compare the time-to-load, page size, and number of HTTP requests for both pages. I also compared the cached and uncached state of this page.
Here's the page with all the buttons for comparison.
I'm looking for the overall page-weight difference (in kilobytes), time-to-load, and HTTP requests (the more, the worse).
Even stripped-back of widgets, this page makes 15 HTTP requests, thanks to using Bootstrap, jQuery, and Google Analytics.
Adding four social widgets added 64 HTTP requests to this page, and ballooned the page size from 80kb to 480kb. Yowza.
|Buttons||Buttons, 2nd load||No buttons||No buttons, 2nd load|
|Time to load||7.68 s||1.46 s||0.972 s||0.626 s|
|Page size||481.31 kb||25.48 kb||83 kb||4.35 kb|
The button-festooned version took an extra 6.22 seconds to load.
If 1 million people loaded the page, that would be a total of 1727 hours collectively lost waiting for the page to load: 71 days.
At the median American wage, that's $77,715 lost.
1 million PC's running for 1 second is 27.7 kWH. TImes by 6.22 = 172 kWH.
At median electricity rates, that's only $86.
Adding buttons added 398.81kb to the page.
Extrapolated to 1 million users, that's 379.8 GB of extra data sent.
Using my draft carbon/data math, I come up with a figure in the region of 7.41 tons - 4 transatlantic flights worth.
There are lot more factors to be accounted for before extending this method to a real production website. I didn't use any techniques to try and cache or reduce the data load (but then, many real sites don't bother either).
Most of these costs are externalities - they don't immediately effect your site or business - but certainly effect your users. Users are sensitive to slow and laggy experiences, and so those extra seconds end up hurting the bottom line as users lose confidence in your service or convert in lower numbers. So, judge the total cost of these buttons against their supposed benefits before you deploy them.
Many web folk, especially those involved in Responsive Design, are getting into the idea of the Page Budget - setting a sane total page size in data terms. This ensures a speedy-loading experience for users, and optimal performance on mobile. There's no set preferred page size budget, but I've heard 500kb mentioned as a comfortable size. Our social buttons took up most of that on their own.
It'd be nice to just get rid of the social buttons. Many sites have. See A List Apart for instance: they provide simple links to sharing locations, keeping their pages clear of hefty plugins.
It should be possible to make a business case for and against the buttons - based on understanding what usage and conversion your existing buttons have, versus what the potential upswing in conversion would be if you cut them. An A/B test would help decide this.
Failing which, cut selectivly. Which of your existing buttons can you most afford to lose? Cut the unused ones if you can.
Cut them from pages where people aren't sharing. If no-one ever shares from the "contact us" form page, then that's a clue that the buttons can go.
Or look into fancy conditional loading techniques.
Thanks for reading. Feel free to leave a comment (on the other page).