The article has to do with loading javascript asynchronously and not CSS (title is misleading..).
Great article but it fails to mention something important. A lot of 3rd party scripts use document.write. What this means is that even if you try to load them up asynchronously you will fail because the browser will wipe out the DOM when it gets to those calls.
What you need in that case is a document.write override. I use writecapture (http://github.com/iamnoah/writeCapture) for all my async needs since it'll load up scripts asynchronously but will override any document.write calls in them to make the script truly async. This prevents the DOM from getting wiped out on an async load.
>When you load JavaScript from a third party you should do it asynchronously.
When you load JavaScript from a third party, you shouldn't put it directly in your code! There exists a whole eco-system of providers that allow you to manage this now, called "Tag Management Systems"
I develop one of these (that is free to signup and use until you get to 1M PVs per month - opentag.qubitproducts.com).
OpenTag and most TMS-es have many advantages of putting specifc vendor code on your website.
* Only one line on each page - don't need to worry about bloating your home page. By doing this you get a nice separation of concerns between actual functional code and 3rd party code.
* Code can come from a tested library of vendor approved script templates - we have ovr 100 and are constantly growing.
* By using "universal variables" which telling the scripts specific values in a well-defined manner, you can easily configure scripts up. For example on a purchase confirmation page, you may have several scripts that fire off to remarketing, affilliate and analytics providers. By setting these variables up once, you can easily plug-in new variables when your marketing team requests it.
* You can tell scripts to only fire on certain scenarios - only on certain pages, or only when a visit came from a certain referrer or not when they come to a landing page with a specific utm parameter.
* Asyncs your document.write code at the click of a checkbox (or automatically if it is from the library)
It is another point of failure. I'd hope that this point has a lower frequency of failure than otherwise.
Consider:
Adding one line of code to a page and then adding 5 scripts added from a vendor-approved and tested library.
Adding 5 snippets of code to your own site in various sections on various pages.
Because you would be putting some everywhere, some on specific pages and some only firing on special rules, you actually have a lot that you have to manage. You could just put this in your CMS or in some version control, but then they aren't all in one place anymore, but scattered all over your code. If you want to remove something, do you just remove it in one place or everywhere? If you need to make a change are you sure you have done it in all the right places? If you need to just pause something right away, how do you do that, without changing your live site?
All these things require changes which have a higher likelihood of failing, than doing it through a properly controlled automated system.
1. This article offhandedly claims that document.write injection is async; it's been widely written otherwise; I'm curious as to what the evidence is.
2. In the Cleaning House section, the Google Analytics code can be loaded without the ternary statement, and just use the protocol neutral code that's already being used there for Facebook and Twitter.
I've spoken with the GA team a few times about this. While the protocol-relative URL works, it will throw an error in IE6 sometimes. Now you probably don't care about IE6 now. Good!
But the GA team is not promising the naked URL will always work over SSL, so best to use the ternary with the subdomain.
Except css and fonts are already non-blocking in modern browsers?
The problem is fonts aren't loaded until the renderer sees the need for them. This is especially annoying in Firefox. I was thinking of trying to force the renderer to load the fonts earlier in the <head> area on some invisible elements but it may be too smart and know they are invisible. But maybe the body itself can be temporarily assigned the webfonts.
You are pessimistic! I would love to meet the person who declined to implement advance font fetching and then chose to implement an optimization to refuse to load a font explicitly requested and used.
Great article but it fails to mention something important. A lot of 3rd party scripts use document.write. What this means is that even if you try to load them up asynchronously you will fail because the browser will wipe out the DOM when it gets to those calls.
What you need in that case is a document.write override. I use writecapture (http://github.com/iamnoah/writeCapture) for all my async needs since it'll load up scripts asynchronously but will override any document.write calls in them to make the script truly async. This prevents the DOM from getting wiped out on an async load.