CSS Tricks: Thinking Async(css-tricks.com)
css-tricks.com
CSS Tricks: Thinking Async
http://css-tricks.com/thinking-async/
6 comments
Don't include the name of the site in the title. Article has a lot of information on async javascript loading and nothing to do with CSS.
My bad. Unfortunately I cannot edit the submission anymore. Or I don't see the edit button - which I don't think is the case.
>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)
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)
Doesn't involving another third-party vendor add an additional point of failure to the system?
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.
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.
It is a tradeoff.
2 minor notes:
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.
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.
add('//www.google-analytics.com/ga.js', 'ga');The reason for #2 is that the domain name changes to ssl.google-analytics.com for the https version.
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.
[deleted]
1. Link? JQuery tutorials explain how to poll for successful completion of write-inserted script tags before calling client code.
Please change the title. I thought this was about loading CSS asynchronously. Turns out it's just the name of the web page.
I'm trying to do that, but I cannot find the edit button for it :|, I think that is not editable anymore.
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.
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.