The day StumbleUpon stumbled: Why we removed the SU button from our sites

You may have noticed that this blog recently got a much-needed facelift. As part of the process, our marketing team decided to refresh how we use social sharing buttons, both here and over on the Strangeloop blog. We pared down the number of buttons to the five we considered most relevant — Twitter, Facebook, +1, LinkedIn, and StumbleUpon — and made the sharing menu (which sounds more like something I want to eat than to click, but I digress) more prominent.

Because we drink our own Kool-Aid, we made sure all the buttons loaded asynchronously — all except the StumbleUpon button. We dug around for an asynch version, but there was none to be found. Then we tried to hack a workaround, using this tutorial from Stoyan Stefanov, but no dice (not a criticism of Stoyan’s tips, just the nature of this particular bit of code).

So we decided to do a little experiment.*

We kept the StumbleUpon button anyway, and decided to monitor it over time to see if we could perceive the performance difference with the naked eye.

It didn’t take long to notice the difference. On November 3rd, someone here noticed that the Strangeloop blog suddenly seemed painfully slow. She ran a WebPagetest to get some visibility into the problem, and while waiting for the test to render, checked my blog to see if it was suffering, too. It was.

The page test results showed pretty clearly where the problem lay:

WebPagetest: StumbleUpon button

We wanted to watch this scenario play out, so we kept hitting the refresh button and running page tests. It didn’t Viagra take the folks at StumbleUpon very long — no more than an hour or so, maybe even less than an hour — to get on top of the problem, which is a testament to their responsiveness.

But it was too late. We didn’t like seeing our pages take 14 or more seconds to load, or worse, hanging indefinitely. If we couldn’t use an asynchronous version of the SU button, we had to kill it. I like StumbleUpon, but that’s not a basis for sacrificing performance.

Takeaways:

  • If you run an e-commerce site, you know that downtime and slow pages cost you money. Unless you’re running an experiment of your own, make sure you’re using asynchronous versions of all your third-party scripts. (Get more tips and info  here.) As I’ve written about many, many, many times, you never know when a third-party content provider is going to crash and burn, taking your page down with it.
  • If you’re a developer who creates third-party scripts, it should be de rigeur to make those scripts  load asynchronously. This isn’t a nice-to-have feature any more — it’s a must-have.

*Speaking of experimentation, you might be interested to know that, at any given time, we also run split tests where we serve half our traffic an accelerated version of our site, and the other half an unaccelerated version. It’s all part of the Strangeloop petri dish.

Related posts: