Tell HN: Your social widgets are losing you visitors right now
If you see a substring <script src="http:// or <script src="https:// in your HTML source - you are killing your site slowly.
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)
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).
Yet some sites load up to 2-5 minutes for me? Why?
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...
"platform.twitter.com" responds in 49-62 seconds! Uses <script src="http://... for their "retweet" button. Your site is STUCK until "platform.twitter.com" loads (1 minute).
Facebook's CDN responds within 30-50 seconds. The site doesn't load until it's loaded.
"www.stumbleupon.com"'s button loads in 20 seconds.
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).
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.
WordPress' social submit plugins are often have the same effect on your site.
The solution? Use async code and ask your plugin developer to move to async code.
It's not some futuristic HTML5 goodie that works only in modern browsers. It works everywhere.
Facebook has async code - use it! Google Analytics has async - use it!
Twitter doesn't give out async, but it's easy to do it, based on FaceBook and Google Analytics code:
<a href="http://twitter.com/share"
class="twitter-share-button" data-count="horizontal"
data-via="WhitePostsCom">Tweet</a>
<script>
(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);
}());
</script>
Replace the first part with your own code instead of WhitePostsCom one.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)
<!-- Start of StatCounter Code -->
<script type="text/javascript">
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);
})();
</script>
<noscript><div
class="statcounter"><a title="web analytics"
href="http://statcounter.com/" target="_blank"><img
class="statcounter"
src="[YOUR CODE HERE]"
alt="web analytics" ></a></div></noscript>
<!-- End of StatCounter Code -->
StumbleUpon? Adapt it from the above codes.Seeing someone asking you to insert '<script src="http://' into your code? Tell them to do better engineering and stop slowing down your site.
P.S. The reasons for hiccups of Twitter and FB's CDN might be poor peering, bad servers, anything real...
77 comments
[ 4.0 ms ] story [ 128 ms ] threadI'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?
Well worth the watch: http://www.youtube.com/watch?v=b7SUFLFu3HI
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.
Also open your HTML source and search for src="http, look if any of those are <script tags. Async loading scripts don't use src="http part.
Update: http://whiteposts.com/not-async
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!
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?
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).
I'm not sure how browsers render <script src in head, but probably the same.
Now I'm on a shared satellite link which is something like 8Mbps for 30 users.
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.
http://bar.meebo.com/
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.
Basically, any time a website takes ages to come up, I turn on Firebug's Net panel and monitor the laggy requests; and then, if warranted, kill them off with AdBlock. Similarly for offensive widgets.
The web is not safe to use without NoScript.
I just installed RequestPolicy addon after going through this thread, and am hoping it will be a good tradeoff (other reason for installing this instead of NoScript are those annoying ad-filled pages NoScript shows after its frequent updates, and its author's attempts to fiddle with ABP sometime back, making his integrity questionable).
I reinstalled NoScript a while back. IMO, the problems it prevents outweigh the problems it causes.
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.
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.
The ping is fine BTW - 50ms for widgets.digg, 200ms for digg. Which just helps to prove that it's a service problem.
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.
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
Has anyone managed to load adserver code with this method successfully? I'll be trying myself this weekend and will report back....!
(Incidentally, my own blog didn't live up to my own standards, and it's down pending me fixing that :)
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.
I also don't want to have crap slow page loads. It loads for me in under a second.
http://stackoverflow.com/questions/1834077/browser-support-f...
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.
Of course, they'll never visit your site again, but hey... that's what "social media" is for!
It's not that dignified, but did what I needed it to do.