Html5-boilerplate: jQuery local fallback: Chrome ne chargera plus les scripts via document.write sur des connexions lentes

Créé le 8 sept. 2016  ·  9Commentaires  ·  Source: h5bp/html5-boilerplate

via @jpdevries dans un commentaire sur 1039

En parlant de la solution de secours document.write () (dont je pense que les règles), qu'en est-il de cela?

Chrome ne chargera plus les scripts insérés via document.write () lorsque la connexion Internet est lente
https://developers.google.com/web/updates/2016/08/removing-document-write

A-t-on déjà discuté de la manière de répondre à cela?

Pas encore, mais merci d'avoir porté cela à notre attention.

Voici les éléments intéressants de la documentation liée

Avec ces données à l'esprit, l'équipe Chrome a récemment annoncé son intention d'intervenir au nom de tous les utilisateurs lorsque nous détectons ce modèle connu comme défectueux en modifiant la façon dont document.write () est géré dans Chrome (voir l'état de Chrome). Plus précisément, Chrome n'exécutera pas le

help wanted javascript

Tous les 9 commentaires

Merci d'avoir ouvert le numéro @roblarsen. Je me suis demandé si l'ajout de defer à tous les scripts inclus résoudrait ce problème?

Les scripts avec les attributs 'async' ou 'defer' seront toujours exécutés.

Quelque chose comme

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

le

<script defer>window.jQuery || document.write('<script defer src="js/vendor/jquery-1.12.4.min.js"><\/script>')</script>

est comme une sorte de defer début. Cela semble fonctionner, mais je ne sais pas si c'est correct.

Hm ... ou peut-être que les scripts jquery peuvent être asynchrones et que le plugin et les scripts principaux sont différés. Vous devez vous assurer que ceux-ci se chargent après jQuery bien sûr.

@jpdevries Je pense que la réécriture du script d'inclusion pour utiliser une interface DOM moderne (parentNode.insertBefore) comme celle utilisée par Google Analytics serait également quelque chose à examiner.

Discussions connexes à ce sujet qui peuvent aider à prendre la décision:

@FagnerMartinsBrack Merci pour les liens. Votre propre fil de discussion sur reddit a aidé à clarifier les choses. Tant qu'il y a une condition d'origine croisée, nous n'avons rien à craindre.

Une stratégie de report est à mon avis la meilleure option. Je n'aime pas du tout async, pour les scripts qui doivent être prêts dès que possible comme jQuery. J'ai suggéré une implémentation à plus long terme dans le fil WICG / interventions ...

@jpdevries Deux choses avec votre code 'différer':

  1. Le report sur un <script> s en ligne est obsolète par WHATWG. La mauvaise raison insuffisante invoquée était que personne ne l'utilisait ... Une histoire vraiment boiteuse, mais cela s'est malheureusement produit ... Donc defer création ne fonctionnera pas. :(
  2. L'ordre d'exécution «différer» a été bogué dans IE 8-9. Et il y avait des problèmes avec le déclenchement de l'événement «interactif» trop tôt dans IE 9-10, ce qui pouvait affecter l'exécution des scripts «différer». Ce dernier peut être contourné; Cependant, cela implique un hack et un script en ligne inférieur pour déclencher correctement 'interactif' ... Donc, la condition pour un passe-partout public utilisant defer est principalement d'attendre que l'utilisation d'IE10 meure.

@hexalys 😭 J'ai

Fermeture! Nous sommes en sécurité!

@roblarsen oh c'est génial! Chrome est-il revenu sur sa décision? Je suis curieux de savoir pourquoi nous sommes en sécurité parce que je ❤️ vraiment ce modèle

@jpdevries Il n'est déclenché que lorsque la requête est d'origine croisée, donc tout va bien. C'est une solution de secours locale après tout.

Cette page vous a été utile?
0 / 5 - 0 notes