Html5-boilerplate: Локальный резерв jQuery: Chrome больше не будет загружать скрипты через document.write через медленные соединения

Созданный на 8 сент. 2016  ·  9Комментарии  ·  Источник: h5bp/html5-boilerplate

через @jpdevries в комментарии к 1039

Говоря о резервном варианте document.write () (который, я думаю, правилен), что насчет этого?

Chrome больше не будет загружать скрипты, вставленные через document.write (), когда сетевое соединение медленное.
https://developers.google.com/web/updates/2016/08/removing-document-write

Обсуждалось ли еще, как на это ответить?

Пока нет, но спасибо, что обратили на это наше внимание.

Вот интересные фрагменты из связанного документа

Имея в виду эти данные, команда Chrome недавно объявила о намерении вмешаться от имени всех пользователей, когда мы обнаружим этот заведомо плохой шаблон, изменив способ обработки document.write () в Chrome (см. Состояние Chrome). В частности, Chrome не будет выполнять

help wanted javascript

Все 9 Комментарий

Спасибо, что открыли вопрос @roblarsen. Мне было интересно, может ли это решить добавление defer ко всем включенным скриптам?

Скрипты с атрибутами async или defer по-прежнему будут выполняться.

Что-то вроде

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

В

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

похоже на какое-то начало defer . Кажется, работает, но не уверен, что это правильно.

Хм ... или, может быть, сценарии jquery могут быть асинхронными, а плагин и основные сценарии откладываются. Конечно, нужно убедиться, что они загружаются после jQuery.

@jpdevries Я думаю, что можно было бы переписать сценарий включения для использования современного интерфейса DOM (parentNode.insertBefore), такого как Google Analytics.

Связанные обсуждения этого вопроса, которые могут помочь принять решение:

@FagnerMartinsBrack Спасибо за ссылки. Ваша собственная ветка на Reddit помогла прояснить ситуацию. Пока существует условие перекрестного происхождения, нам не о чем беспокоиться.

На мой взгляд, стратегия отсрочки - лучший вариант. Мне вообще не нравится async, для скриптов, которые должны быть готовы как можно скорее, например jQuery. Я предложил более долгосрочную реализацию в ветке WICG / вмешательства ...

@jpdevries Две вещи с вашим кодом отсрочки:

  1. Отложить на встроенном <script> s не рекомендуется WHATWG. Плохая и недостаточная причина заключалась в том, что никто не использовал его ... Настоящая неубедительная история, но, к сожалению, это произошло ... Так что defer начало не сработает. :(
  2. Порядок выполнения 'defer' был ошибочным в IE 8-9. И были проблемы с слишком ранним запуском «интерактивного» события в IE 9-10, что могло повлиять на выполнение сценариев «отложить». Последнюю можно обойти; Однако это включает в себя взлом и нижний встроенный скрипт для правильного запуска «интерактивного» ... Таким образом, условием для общедоступного шаблона с использованием defer в основном является ожидание прекращения использования IE10.

@hexalys 😭 Я использовал отсрочку начала для таких вещей, как CDN в стиле h5bp с локальным откатом или определение функций перед включением чего-то вроде полифилла. Это облом!

Закрытие! Мы в безопасности!

@roblarsen , это здорово! Отменил ли Chrome свое решение? Мне любопытно, почему мы в безопасности, потому что я действительно этот шаблон

@jpdevries Он срабатывает только тогда, когда запрос является кросс-источником, так что все в порядке. В конце концов, это местный запасной вариант.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги