via @jpdevries in a comment on 1039
Speaking of the document.write() fallback (which I think rules) what about this?
Chrome will no longer load scripts that are inserted via document.write() when net connection is slow
https://developers.google.com/web/updates/2016/08/removing-document-writeHas how to respond to this been discussed yet?
Not yet, but thanks for bringing this to our attention.
Here are the interesting bits from the linked doc
With this data in mind, the Chrome team have recently announced an intention to intervene on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome (See Chrome Status). Specifically Chrome will not execute the
Thank you for opening the issue @roblarsen. I've been wondering if maybe adding defer
to all included scripts would solve this?
Scripts with the ‘async’ or ‘defer’ attributes will still execute.
Something like
<script defer src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
<script defer>window.jQuery || document.write('<script defer src="js/vendor/jquery-1.12.4.min.js"><\/script>')</script>
<script defer src="js/plugins.js"></script>
<script defer src="js/main.js"></script>
The
<script defer>window.jQuery || document.write('<script defer src="js/vendor/jquery-1.12.4.min.js"><\/script>')</script>
is like some sort of defer
inception. Seems to work, but not sure if that is correct.
Hm...or maybe the jquery scripts could be async and the plugin and main scripts defer. Need to make sure those load after jQuery of course.
@jpdevries I think rewriting the include script to use a modern DOM interface (parentNode.insertBefore) like Google Analytics uses would be something to look at as well.
Related discussions about this that can help drive the decision:
@FagnerMartinsBrack Thanks for the links. Your own thread on reddit helped clarify things. As long as there's a cross-origin condition we don't have anything to worry about.
A defer strategy is the best option in my opinion. I don't like async at all, for scripts that must be ready ASAP like jQuery. I have suggested a longer term implementation in the WICG/interventions thread...
@jpdevries Two things with your 'defer' code:
<script>
s has been deprecated by WHATWG. The poor insufficient reason given was that no one used it... True lame story, but it sadly happened.... So defer
inception won't work. :(defer
is mainly waiting for IE10 usage to die.@hexalys 😭 I've been using defer inception for things like h5bp style CDNs with local fallback or doing feature detection before including something like a polyfill. That is a bummer!
Closing! We're safe!
@roblarsen oh that is great! Did Chrome revert their decision? I'm curious why we're safe because I really ❤️ this pattern
@jpdevries It's only triggered when the request is cross-origin so we're fine. It's a local fallback after-all.