

Why loading third party scripts async is not good enough - sajal83
http://www.aaronpeters.nl/blog/why-loading-third-party-scripts-async-is-not-good-enough

======
recursive
> Doc Complete dropped from 3.63 seconds to 1.14 seconds (-214%).

This is a pet peeve of mine. Percentage changes should be measured using the
original value as the denominator, not the new value.

~~~
dredmorbius
The pedant uses the delta over the mean of the old/new values.

So: 100 * (1.14 )/((1.14 + 3.63)/2) or -104%

~~~
Rexxar
May be I'm missing something, but this way of computing a percentage seems
completely meaningless to me.

~~~
dredmorbius
It's unbiased toward either the beginning or ending value.

If you want to overstate a change, you'll use the smaller value as the
denominator. If you want to understate a change, you'll use the larger. If you
use the mean of the two, you're giving a value that's not biased by either of
the two extremes.

There are arguments for using other methods. As usual, Wikipedia has a good
discussion of alternatives:
<http://en.wikipedia.org/wiki/Relative_change_and_difference>

~~~
recursive
When talking about a starting value and a new value, I find the percentage
change formula on the page you referenced to be the most logical. When
considering a change, your frame of reference is usually the original value.

[http://en.wikipedia.org/wiki/Relative_change_and_difference#...](http://en.wikipedia.org/wiki/Relative_change_and_difference#Percentage_change)

------
bobds
I am not sure what this accomplishes, other than making the stats look better
in their monitoring tool. They pretty much seem to admit this:

"Conclusion: the loading, parsing and executing of the async third party
scripts are quite often very slow and this messes up our End User performance
stats in New Relic."

Delaying the dynamic insertion of scripts until after the onload event,
doesn't change anything. All the external crap will still be loaded. It might
even make the external assets load slower.

Another solution would be to choose a monitoring tool that distinguishes
between DOMContentLoaded (or the equivalent in non-Gecko browsers) and the
regular onload event.

[https://developer.mozilla.org/en/Gecko-
Specific_DOM_Events#D...](https://developer.mozilla.org/en/Gecko-
Specific_DOM_Events#DOMContentLoaded)

~~~
keltex
It helps the end user experience if you want to have some javascript run after
the DOM is loaded but not wait until all the 3rd party scripts have loaded and
run. Maybe the javascript runs some sort of animation.

Without this code, the animation would wait until facebook, google + and
twitter are all loaded, but with this code, the animation would start right
away.

~~~
bobds
If a script is supposed to run when the DOM is ready but external
scripts/stylesheets/etc are still being loaded, it should not attach itself to
the load event. The load event is supposed to run when the page has fully
loaded. By the way, IE9 now supports DOMContentLoaded and there are hacks to
simulate it in earlier IE versions.

Here is a demonstration:
[http://ie.microsoft.com/testdrive/HTML5/DOMContentLoaded/Def...](http://ie.microsoft.com/testdrive/HTML5/DOMContentLoaded/Default.html)

------
Mizza
> The question is: does this 1.14 seconds better reflect the user experience?
> In our opinion, yes. At that 1.14 second mark, all content has finished
> loading and is displayed on screen. The only stuff that comes after that are
> the aforementioned social sharing buttons and the Twitter Tweet Box (and on
> a blog post page, the Disqus comments would also come in late).

> There was a problem loading Disqus. For more information, please visit
> status.disqus.com.

I wasn't able to comment because I'm on a slow connection, and the rest of the
content hadn't finished loading by the time I had finished reading the
article.

~~~
pdenya
Is your comment meant to be a complaint or a compliment?

------
pdenya
I'm a little perplexed by the reactions to this research. Speeding up the
execution of javascript tied to the onload event might not be critical for
every site but understanding how these pieces fit together is always helpful.

------
ams6110
Quit loading so much shit on your pages and your load times will be fast.

------
mattmanser
_Being WPO consultants we of course made a big effort to make CDN Planet fast.
Our goal: the average page page load time must be <2 seconds for 95% of all
page views._

Isn't that a bit high? cdnplanet is actually impressively nippy for me, I'd
just expect them to aim for 1.5 sec.

~~~
sajal83
1.5 seconds for 95% of traffic is very ambitious, considering the users are
geographically disperse. Say someone from across the globe(RTT=300ms) visits
the site, it would take them minimum 600ms to even start rendering the page...

------
billpatrianakos
Seems nothing is good enough anymore! I give up. But seriously, all this does
is serve to make you feel better when looking at metrics and barely puts a
dent in real user experience. You're still blocking, you've still got the same
load times. The only only difference is that you're delaying the inevitable
and doing so doesn't always help user experience a bit. Waiting is waiting
whether you wait now or later.

~~~
sajal83
The difference is that earlier, if there is a load spike in monitoring, we
dont know if it was cause of 3rd party scripts or some problems with out
server/CDN. the former we can live with, but the latter is very bad.

Now after deferring the 3rd party scripts, we know for sure what the user
experience is with regards to the main content of the site.

~~~
billpatrianakos
Ok. Fair enough. I never thought of it that way. I stand corrected. I'm
tempted to argue that some third party scripts may be necessary for presenting
content and delaying them _can_ mess up a user experience. But we all know not
to do that so that point is moot however there are excepts, however few, to
every rule.

All that aside, though I'd say I just changed my mind to agree with you.

~~~
mjpizz
Definitely. Though with small modifications, you should be able to have your
cake and eat it too:

[http://www.olark.com/spw/2011/10/lightningjs-safe-fast-
and-a...](http://www.olark.com/spw/2011/10/lightningjs-safe-fast-and-
asynchronous-third-party-javascript/)

...this technique begins downloads immediately, but still avoids blocking
window.onload (just ran a brief test myself to verify this behavior).
Unfortunately, it requires the third-party provider to adopt LightningJS.
Here's to hoping that more providers take notice :)

