Html5-boilerplate: jQuery local fallback: Chrome will no longer load scripts via document.write over slow connections

Created on 8 Sep 2016  ·  9Comments  ·  Source: h5bp/html5-boilerplate

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-write

Has 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

All 9 comments

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:

  1. Defer on an inline <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. :(
  2. 'defer' execution order has been buggy in IE 8-9. And there were issues with the 'interactive' event firing too early in IE 9-10 which could affect 'defer' scripts execution. The later can be circumvented; However that involves a hack and a bottom inline script to trigger 'interactive' correctly... So the condition for a public boilerplate using 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

roblarsen picture roblarsen  ·  5Comments

alrra picture alrra  ·  18Comments

klutchdev picture klutchdev  ·  18Comments

amilajack picture amilajack  ·  19Comments

roblarsen picture roblarsen  ·  10Comments