
CSS Tricks: Thinking Async - andreiursan
http://css-tricks.com/thinking-async/
======
ashray
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.

~~~
da_n
Just so you know, and easy mistake, but CSS-Tricks is the name of the website,
not a reference to the language being used.

------
geuis
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.

~~~
andreiursan
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.

------
pretzel
>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)

~~~
calvin
Doesn't involving another third-party vendor add an additional point of
failure to the system?

~~~
pretzel
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.

------
yahelc
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.

    
    
        add('//www.google-analytics.com/ga.js', 'ga');

~~~
nfriedly
The reason for #2 is that the domain name changes to ssl.google-analytics.com
for the https version.

~~~
paulirish
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.

------
CWIZO
Please change the title. I thought this was about loading CSS asynchronously.
Turns out it's just the name of the web page.

~~~
andreiursan
I'm trying to do that, but I cannot find the edit button for it :|, I think
that is not editable anymore.

------
ck2
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.

~~~
Evbn
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.

