You build sites for mobile devices, right? Then you might've noticed the one pesky issue with responsive sites is the loading speed, especially when there's a slow cell connection. What you may not know is that there is a likely culprit for at least part of your problem — the ever-present social media buttons.
On small devices, such as mobile phones, bandwidth and latency are at a premium. The response time from the server can compound over a cell connection and cause some serious delays. That coupled with a generally smaller bandwidth, we have to be very careful about how much weight we put on a page. Those tiny Tweet, Like, +1 buttons you see on websites are actually brutally large elements to load for these constrained devices. How brutal? Let's take a look.
To test this, we created a very simple page with the three most commonly used social media buttons, embedded using the latest code from their vendors: Facebook's "Like" button, with a small counter, Twitter's "Tweet" button with a small counter, and Google's "+1" button with a small counter.
We tested each of the three buttons by loading them individually and as a group. We also loaded them both as cached and completely uncached. Anything local for the page was directly on the testing device. To arrive at our calculations for mobile load time, we're using an average of 100ms latency, based on the average latency of an iPhone 4S on Verizon 3G with full bars. LTE might be a bit faster ... well, until your battery dies.
Let's start with the really crazy stuff. To load the Facebook, Twitter and Google social media buttons for a total of 19 requests takes 246.7k in bandwidth. For perspective's sake, that's over twice the bandwidth and 3 times the number of requests required to load a complete, minified version of the entire Foundation framework. (Foundation packs down to about 113k, including images.)
Let's take a second to just let that sink in. Holy crap. Look at this resources chart from Chrome:
On a desktop, over a good Wi-Fi connection, the uncached load of just those elements is about 2.3 seconds. That may seem fast, but consider that your entire Facebook stream probably loads about that fast. Now consider the latency of 19 requests over a 3G connection, maybe with a mediocre signal and a lot of dropped packets. Ouch!
So who's the worst offender of the big three when it comes to loading a button? Here's the rundown of average load time, uncached and cached:
Twitter, despite gaining nothing from being cached, is still the overall fastest social media button to load. Facebook and Google+ are about the same the first time, but Facebook doesn't gain much from caching whereas Google+ becomes about twice as fast.
Don't misread us, we're not ready to say "ditch these buttons." The fact these buttons can load as fast as they do based on a complex social graph is impressive. They are optimized. However, that optimization is often not enough for limited devices.
We also don't want to downplay their utility — Facebook's "Like" button is pretty handy, Twitter's "Tweet" button fuels trends, and the Google+ "+1" button now apparently determines what we see when we search so that could turn out to be, you know…a pretty big deal.
That being said, it's worthwhile to do something faster for mobile devices. The solution is actually pretty simple: each of these services still has a simple link to do what you want. Worst case, you have three images for the buttons, and that means three requests all off your server. No additional requests, no huge JS to parse, and no massive download. It's not as sexy, sure. Users will have to load a second screen to take action, but at least you're not punishing everyone in order to have this utility.
Here's how simple the Facebook share URL is:
And here's Twitter:
And finally, Google+:
Obviously, there is utility not represented with this option — it won't add fans to your Facebook page the way the "Like" button does, or impact search like the "+1" button does, but it will create a faster, friendlier experience for the majority of your mobile visitors.
Have you seen other ubiquitous but glaring violations of mobile design? We'd love to hear about it, and what your solution is (or could be). Designing for arbitrary devices is still a bit of a minefield, but hopefully we'll all pin this down together.