If the async script is fetched before the
DOMContentLoaded, then parsing will be blocked.
Hmm…yep, according to the diagrams given by W3C, there is a gap within ‘parser’ line when <script async> do execution. I think it’s mostly because of the potential f*cking document.write() calls? While the SPEC also describe that async attr means ‘executed in parallel’ with parser…weird.
If async is present, then the script will be executed as soon as it is available, but without blocking further parsing of the page.
Well. Cant get your point of “without blocking further parsing of the page.” ;)
FWIK, script defer will be executed after parsing complete and before DOMContentLoaded. While for the script async, the SPEC do describe that it will be fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes).
However, I have no idea why script defer always be executed earlier than async one in real profiling in Chrome, even the async one available much earlier. As the SPEC described at HTML 5.1 8.2.6 The End (of parsing): Spin the event loop until the set of scripts that will execute as soon as possible and the list of scripts that will execute in order as soon as possible are empty. There is no specific order I can find.
Nice post BTW, expecting a further discussion with you.