

Tell HN: Your social widgets are losing you visitors right now - rarestblog

Recently a lot of sites are getting slow for me. The reason? They add a lot of social submit widgets that use non-async scripts.<p>If you see a substring &#60;script src="http:// or &#60;script src="https:// in your HTML source - you are killing your site slowly.<p>Using Twitter's official ReTweet button? You've slowed your site down by 60 seconds per each page (I don't know how many people are affected by this hiccup that lasts more than 5 days now for me, but you can easily fix it for everybody, see below)<p>Just to be clear. I'm on 35Mbps line in Russia near Moscow (4.3MBytes/s - very fast! 4ms ping to national traffic exchange point in Russia).<p>Yet some sites load up to 2-5 minutes for me? Why?<p>According to Chrome Dev Tools I receive main blog content, including all images within 1-2 seconds. (It's a 35Mbps!), but I don't see anything from your site on screen (even though it has finished loading), because...<p>"platform.twitter.com" responds in 49-62 seconds! Uses &#60;script src="http://... for their "retweet" button. Your site is STUCK until "platform.twitter.com" loads (1 minute).<p>Facebook's CDN responds within 30-50 seconds. The site doesn't load until it's loaded.<p>"www.stumbleupon.com"'s button loads in 20 seconds.<p>I'm not sure what the problem is, but I can tell you for sure - it takes minutes to load some sites with those buttons, it takes less than a blink after I add "127.0.0.1 platform.twitter.com" and others to /etc/hosts (that's not a way to solve it, it's a way to diagnose the problem, see below for solution).<p>Many of you use a lot of those buttons in hope that they will bring you visitors. But while they load - they lose you visitors that have to wait 2 minutes for your page to load.<p>WordPress' social submit plugins are often have the same effect on your site.<p>The solution? Use async code and ask your plugin developer to move to async code.<p>It's not some futuristic HTML5 goodie that works only in modern browsers. It works everywhere.<p>Facebook has async code - use it! 
Google Analytics has async - use it!<p>Twitter doesn't give out async, but it's easy to do it, based on FaceBook and Google Analytics code:<p><pre><code>  &#60;a href="http://twitter.com/share" 
  class="twitter-share-button" data-count="horizontal" 
  data-via="WhitePostsCom"&#62;Tweet&#60;/a&#62; 
  
  &#60;script&#62; 
    (function() {
    var src = document.createElement('script'); 
    src.async = true;
    src.src = document.location.protocol + '//platform.twitter.com/widgets.js';
    document.getElementsByTagName('head')[0].appendChild(src);
    }());                        
  &#60;/script&#62; 
</code></pre>
Replace the first part with your own code instead of WhitePostsCom one.<p>StatCounter doesn't give async, adapt it from the code StatCounter gives you: 
(There was a day when StatCounter didn't load in 2 minutes! Your site is stuck again if you don't do async)<p><pre><code>  &#60;!-- Start of StatCounter Code --&#62;
  &#60;script type="text/javascript"&#62;
  var sc_project=[YOUR CODE HERE]; 
  var sc_invisible=[YOUR CODE HERE]; 
  var sc_security="[YOUR CODE HERE]"; 
  (function() {
      var ga = document.createElement('script'); 
      ga.type = 'text/javascript'; ga.async = true;
      ga.src = document.location.protocol + '//www.statcounter.com/counter/counter.js';
      var s = document.getElementsByTagName('script')[0]; 
      s.parentNode.insertBefore(ga, s);
  })();
  &#60;/script&#62;
  &#60;noscript&#62;&#60;div
  class="statcounter"&#62;&#60;a title="web analytics"
  href="http://statcounter.com/" target="_blank"&#62;&#60;img
  class="statcounter"
  src="[YOUR CODE HERE]"
  alt="web analytics" &#62;&#60;/a&#62;&#60;/div&#62;&#60;/noscript&#62;
  &#60;!-- End of StatCounter Code --&#62;
</code></pre>
StumbleUpon? Adapt it from the above codes.<p>Seeing someone asking you to insert '&#60;script src="http://' into your code? Tell them to do better engineering and stop slowing down your site.<p>P.S. The reasons for hiccups of Twitter and FB's CDN might be poor peering, bad servers, anything really. You can't fix Twitter's and Facebook's software and servers, but you can let your visitors see your site without depending on how good do engineers at those companies do their job.<p>P.P.S. There is a good question in comments about how to diagnose your own site's problems: http://news.ycombinator.com/item?id=1771755<p>Problematic hosts list (the srcs that cause sometimes huge slowdowns for me) - just in case you need it:<p><pre><code>  widgets.digg.com
  platform.twitter.com
  static.ak.fbcdn.net
  www.stumbleupon.com
  i.ixnp.com</code></pre>
======
naner
In general I find these buttons obnoxious as hell (they are tasteful on some
sites like the NYTimes). This just adds insult to injury.

~~~
carbocation
Or perhaps this adds injury to insult.

~~~
donw
I wonder if injuries and insults commute...

------
jsz0
Incredibly annoying. I have a quad core machine, 16GB RAM, SSD, 100Mbit
broadband yet it takes 14 seconds for TechCrunch to fully load due to the Post
Up widget they use. Once it loads the page scrolling is not smooth at all. It
definitely makes me less likely to visit.

~~~
jrockway
I just adblock that shit. I know I should just not visit their site or
whatever, but if everything I wanted to read had to live up to my standards,
there would be nothing to read.

(Incidentally, my own blog didn't live up to my own standards, and it's down
pending me fixing that :)

~~~
danudey
This is my primary reason for running adblock. I can't tell you how many
clients have e-mailed me saying 'My site is down!' or 'My site takes a few
minutes to load', even though the site loads in about a second in Safari. When
I switch over to my (un-extended) Firefox install, I suddenly see the problem
- literally dozens of Javascripts, image requests, tracking pixels, and other
junk.

It's ridiculous. At one company we had a client who spent the last year
contracting us to add widgets and pixels and add-ons and buttons and
everything, until suddenly they found out that Google would be factoring in
page load times into their search results. Suddenly it was a rock and a hard
place - do they keep adding content without any proof of its value? But that
would hurt their search rankings - but but but, it adds value! It encourages
engagement!

It's ridiculous. They didn't even have any metrics showing that any of the
stuff they were adding was helping, or even being used. Likewise with the
search widgets. People are told that these things will 'drive user engagement'
and 'encourage social interaction', so they throw it in and assume that it's
made their site better.

------
rarestblog
I have written a very simple tester for these problems that you can use to
diagnose your own site: <http://whiteposts.com/not-async>

Now also shows the code to be replaced to make calls async.

If you like the tool - please upvote it at
<http://news.ycombinator.com/item?id=1772169>

------
100k
Google and Amazon have published research to the effect that even small
increases in page load time have a massive effect on traffic.

Social sharing is intended to boost traffic virally, but I wonder if these
stupid widgets are actually reducing traffic by slowing the page load so much.

Many of these submit tools could be replaced (with less functionality) with an
image button or text link.

~~~
dholowiski
Absolutley. When I set up caching and a cdn on one of my sites, I saw a 25%
increase In visits literally overnight. When I asked the developer of the
caching plugin, he said that many people report the same thing.

------
jasondavies
Warning: while the above async loading code works for Twitter, it won't work
for any JavaScript containing calls to document.write() as they'll append the
data to the end of the page depending on the browser (or even replace the
whole page!)

All is not lost though, as you can patch document.write to do the right thing
and write to an element's .innerHTML or equivalent. If you are a JavaScript
API provider though, please take heed and don't use document.write(). I'm
looking at you, PollDaddy!

~~~
bemmu
How would you handle waiting simultaneously on multiple scripts that all want
to use document.write?

I use some ad networks which want to call document.write to insert the ads.
First I patch the document.write to a function that writes to the innerhtml
for the first ad tag, then after that ad loads I change the function and start
loading the next one.

Obviously slower than doing it simultaneously. I suppose I could look at the
contents of how the function is called to determine which ad it came from, but
did you have some better idea?

~~~
jasondavies
That's a tricky one. I haven't tested this, but I think you should be able to
listen for the 'load' event on each of the script elements that you inject,
and patch document.write differently each time.

Let me know how you get on! I plan on doing something like this soon for some
of my sites that have AdSense (another document.write culprit).

~~~
toolate
I just pushed up a class I've been using to do this to github. It's a little
rough around the edges, but works in Firefox and IE. I've trialed with the
AddThis. <http://github.com/joshduck/Injector.js>

------
marcuswestin
Meebo made a presentation at Velocity this year about truly asynchronous
loading, among other performance secrets of the meebo bar. (FF can still block
using the suggested technique)

Well worth the watch: <http://www.youtube.com/watch?v=b7SUFLFu3HI>

------
csomar
There is another widget which shows a bottom toolbar that looks like the
Facebook one (and it offers sharing and chats and other crap). It makes the
website fucki*gly slow and sometimes interferes with the website JavaScript
and add nuisance like bad scrolling, selecting...

I finished up closing these sites as I open them. I would also recommend that
everyone that has a blog, implement the most minimalistic widgets, less
JavaScript and a simple design. The purpose of a blog is to read, if I want to
chat, I'll open Skype.

Coding Horror is a good example.

~~~
pavel_lishin
Is it the Meebo bar?

<http://bar.meebo.com/>

~~~
csomar
Yeah, that one!

~~~
ktsmith
The bar from www.wibiya.com is even worse. Not only is it slow to load but it
has notification pop ups and a bunch of other crap.

I'm sick and tired of all the sites that have decided to add bars to the top
and bottom of their pages and a billion social network buttons all over the
page. I'm at the point where even though I'm blocking most of them via adblock
new ones keep showing up so I just give up and stop going back to sites that
use them.

------
jasondavies
LABjs is a useful JavaScript library that lets you load JavaScript on-demand
and specify dependencies: <http://labjs.com/>

~~~
OmarIsmail
LABjs is great for making javascript not block the rendering of your page.
It's not just a simple switch though. Depending on how your code is
structured, and the various assumptions you've made there may need to be some
code changes. The biggest thing, is that if you load everything in LABjs -
including jQuery - then the document.ready event fires BEFORE ALL THE
JAVASCRIPT IS LOADED/EXECUTED. This is incredibly important because many many
people code with $(document).ready being the signal to run all sorts of stuff.
However, with LABjs the meaning of document.ready changes so you can't assume
that things like plugins have been declared when document.ready fires.

------
anthony_franco
This is really good advice. I'm surprised these big sites aren't using
something like CloudFront to serve their files.

~~~
rarestblog
Well, they kind of do. It's just that sometimes their CDNs have serious
hiccups and ALL sites that use non-async code are affected (when they
shouldn't be).

I'm really surprised at Twitter. They have good engineers, why are they giving
you non-async code, when the above code does the same thing exactly?

------
cont4gious
Did I miss something, or why are these in your head tag? Why not put them in
the body tag so they don't load until after the browser has rendered the page?

~~~
rarestblog
Sorry, but you aren't right. Those are mostly located in body tag. They are
requested as soon as encountered by browser, because they might issue
"document.write", so the execution of rest of HTML is delayed until that "src"
is loaded. That's exactly what causes the problem. Putting script into body
doesn't defer its execution.

I'm not sure how browsers render <script src in head, but probably the same.

~~~
briancray
Works same in the head. All scripts if not set to asynchronous will prevent
further rendering of the page until the script has finished loading _and_
running.

------
LabSlice
I've just spent several days improving the startup time of my ASP.NET based
business. Some things to note:

* Install both the 'Google PageSpeed' and 'YSlow' plugins for Firefox. They provide great metrics and tell you what's actually slowing down your page.

* Ensure that all images are sent out with a long expiry time. This is not the default setting for IIS. Just setting a long expiry for images, CSS and JS will easily give you a power-boost in your performance.

* Minimize JS and CSS using the 'Chirpy' plugin.

* Make sure to retrieve any library code for its respective CDN (ie. Microsoft AJAX<, Facebook etc.)

* And of-course, as above, make sure your plug-ins load asynchronously. The default code given to me for the 'Add-This' plug-in was synchronous and took about 1.5 seconds to retrieve. Quite silly that they don't give you asynch code by default for these plugins!

------
petercooper
I've experienced similar issues from here in the UK. While the Internet is
typically pretty fast for me, it seems that some CDNs sites use have verrrrry
flaky POPs in Europe. Tumblr is an example - frequently I can't load any
images on Tumblr sites even though the rest of the sites are speedy and fine.

------
stephencelis
I'm pretty sure you don't need to write the element with JavaScript. You
should be able to do the following:

    
    
      <script async src="//..."></script>
    

(Use 'async="async"' for XHTML.)

~~~
rarestblog
Not that simple, won't work on most browsers. Also if script has
document.write inside - will fail.

[http://stackoverflow.com/questions/1834077/browser-
support-f...](http://stackoverflow.com/questions/1834077/browser-support-for-
script-asynctrue)

~~~
stephencelis
More and more support for it every day:

<http://webkit.org/blog/1395/running-scripts-in-webkit/>

So there's also "defer," which is better-supported. The document.write issue
is also an issue for JavaScript element building, but the assumption is that
you won't blindly use these methods without testing, first.

------
rarestblog
It turns out (just read an article in Russian) that recently there was a huge
DDOS attack (100+ Gbit/s) that dropped major providers in Europe, DARPA(.mil),
major Russian search engine. 100GBit/s is enough to fill major landlines and
backbones (even in US, darpa.mil failed too). That might have been the cause
of delays. Nobody is sure whether the attack is over, but major datacenters
and DDOS protection providers failed to do anything against it.

Still, making your site independent with async scripts is good idea.

------
Stevenup7002
Those kinds of sites haven't gotten slow for me at all, and I'm only on 8Mbps
broadband. Thanks for bringing it to everyone's attention though, hopefully
it'll get fixed.

~~~
lukeschlather
Broadband penetration in the US was at 20% in 2007. 8Mbps is positively
luxurious. (When I lived in Ohio I was at 3Mbps advertised, which of course
translates to significantly less.)

Now I'm on a shared satellite link which is something like 8Mbps for 30 users.

------
mrjbq7
Delays of 30-90 seconds are rarely at the network level. Asynchronous is
generally better than synchronous, but it seems more detective work should be
done before declaring war on synchronous scripts.

Are other users in Russia affected? Are users on other ISPs affected? How
widespread is this problem? Are your ping times the same to "www.digg.com" as
to "widgets.digg.com"?

If there is any truth to this post, the problem should be fixable.

~~~
rarestblog
It's not at network level, it's probably at service level. Service takes too
long to respond (overloaded, not enough bandwidth, real-time replication,
deadlocks - you guess it). I don't know how widespread is the problem, but I'm
on a major provider and connection to everything else is very fine.

The ping is fine BTW - 50ms for widgets.digg, 200ms for digg. Which just helps
to prove that it's a service problem.

------
wardrox
I built some fairly clumsy code to fix this on one of the blogs I run. It
loaded the buttons in the footer of the page (so you can be reading the
article before all the nonsense has loaded) then moves them to the correct
places (the foot of the article) once ready. By the time you came to retweet
or what have you, it was loaded.

It's not that dignified, but did what I needed it to do.

------
JonM
I have problems with our adserver tags loading much slower than our pages. I
often use a CSS hack to that the adserver code loads at the bottom of the page
but is position in CSS at the top. However this can't be applied in 100% of
situations......

Has anyone managed to load adserver code with this method successfully? I'll
be trying myself this weekend and will report back....!

------
robryan
I have these problems developing with backend Facebook calls. In theory
facebook servers and our servers shouldn't have a load of latency between them
but it really makes the site noticeably slower. Definitely slow enough that I
would have to remove all the back end calls on page load if we were to push
facebook connect more.

------
messel
Does page caching help? I have that setup for my personal wordpress blog. I
really don't wanna have to modify all the javascript on my page. I've got
bigger fish to fry.

I also don't want to have crap slow page loads. It loads for me in under a
second.

~~~
freejoe76
Page caching doesn't matter if you're making a request to an external server.

------
dbaron
Even worse, the buttons hosted on wd.sharethis.com set frequent timeouts that
use up a measurable amount CPU (and laptop battery life).

(This is particularly bad when I open a large number of articles in tabs, to
read later.)

------
jrockway
Do the ads load quickly? If the ads load quickly but the content loads slowly,
people are more likely to click the ads.

Of course, they'll never visit your site again, but hey... that's what "social
media" is for!

------
sbov
I've seen some metrics drop by as much as 10% because of this issue. The drop
was pretty bewildering at first, but then I A/B tested including (but not
using) the javascript and saw the difference.

------
benrmatthews
Is there a service that let you check your site loading time and whether you
are using asynchronous loading? Would be useful to solve this problem.

~~~
barrkel
If you're using Firefox, the Firebug extension's Net panel (when active) shows
the Gantt chart of downloads.

~~~
jranck
You can also team Firebug up with Yahoo's fantastic benchmarking utility
YSlow.

------
duncanj
Are the delays in Russia due to a satellite? Those seem like very long delays.
I am usually annoyed by 5-15 second delays in the US.

~~~
rarestblog
No. I have 180ms _stable_ ping to news.YC, _stable_ 40ms ping to Google. It's
not a line problem.

Chrome Dev Tools show me that I receive content within 300-400ms of hitting
the page with all the images loading in about 2-3 seconds... and then there's
one huge 1 minute line associated with "platform.twitter.com",
"static.ak.fbcdn.net", "www.stumbleupon.com" (everything else being a short
ticks with 50-100ms receive time - it's a real 35Mbps line)

Any site that I measure with Chrome Dev Tools in any part of the world is fast
(seconds, milliseconds), the only parts that are slow quite sometimes are
those guys - T, FB, SU.

And yes - those are very long delay. Maybe Twitter and FB have some peering
problems - I don't know. I don't need to know. It's just that those can be
fixed easily so that we don't have to find out why T/FB have peering problems.

~~~
alex_c
For what it's worth, I often see this problem in Canada - it's not always the
offenders you list, but third-party widgets do significantly slow down page
loads relatively often.

------
konad
Or just put them after </body> but before </html>

~~~
jggube
In most cases for social media buttons supplied by these web services, you
can't. You will typically have to reference a JS library at the position of
the document you want to render the button at. You put them after </body> and
they'll render in that position in the document. The above tip is smart and
works around that by asynchronously updating the DOM when the scripts are
ready (i.e., downloaded).

If you meant "put the OP's scripts after the body element" -- yeah, you could
do that (at least for sure with GA async code, you can), and that would be a
good idea so that you serve and render CSS first, making your pages feel more
responsive. But that's not what your comment reads as.

------
jdavid
could it be china's great firewall? these sites all load snappy for me and i
am on a 45mbps local ethernet loop in san francisco. sounds like a network
edge problem.

~~~
rarestblog
I'm not behind China firewall. I'm in Russia (near Moscow).

~~~
jdavid
yes, and there is not a direct connection between the US and Russia, the
internet will take the shortest traced route. So, if one site traces well
through china. Then an IP that is nearby, might actually start the connection
using that route. It's hard for me to believe that Russia has opted not to
allow any traffic what so ever to route through China.

