Для тех, кто скрывается без разрешения, я выделил проблему, связанную с тем, как FireFox в настоящее время обрабатывает атрибут rel="preload".По меньшей мере, это не очень хорошо, и я предполагаю, что то же самое в Edge.
TL; DR: Не используйте rel="preload", пока оно не будет обработано более равномерно в основных браузерах.Кроме того, мой вопрос заключался в использовании jQuery из CloudFlare CDN, и цель CDN состоит в том, чтобы запретить посетителям (бессмысленно) загружать один и тот же контент снова и снова.Другими словами, rel="preload" не только действует по-разному между флагманскими браузерами, но и лишним, потому что смысл CDN в том, что посетитель будет уже загружать данный файл (ы) при посещении предыдущих веб-сайтов, которыетакже используйте тот же файл из того же CDN.
Нажмите здесь , чтобы просмотреть обзор текущей поддержки браузера для rel="preload".
Выводы
Chrome и, возможно, другие браузеры обрабатывают ресурсы для предварительной загрузки (более) правильно, хотя в целом нам, похоже, не хватает инструментов и документации о том, как правильно установить и запустить CSP и, надеюсь, этот ответ даст некоторое представление о тех, кто относительно новичок в CSP, таких как я.
Существует ряд проблем, с которыми я столкнулся при устранении неполадок в моих правилах CSP.Одним из них является то, что связывание атрибута as с typehint может работать против вас с текущими реализациями CSP в браузерах.Например, я пытался загрузить шрифт Google с as="font" подарком, который, если я правильно помню, вызывал дополнительные головные боли, пока вместо него не было установлено значение as="style".Я собрал (пожалуйста, добавьте / отредактируйте этот ответ, если вы можете проверить иначе), что это связано с тем, что связанный ресурс действительно является таблицей стилей, а не файлом шрифта.
Еще одна странная вещь, с которой я столкнулся, заключается в том, чтокогда вы предварительно загружаете ресурс, вы должны фактически «инициализировать» данный ресурс после его загрузки.Таким образом, вы можете либо клонировать элемент <link> с желаемым rel="stylesheet/script/etc" (который прямо противоположен принципу DRY), либо присоединить событие onload к элементу <link> (который не идет вразрез с DRY)., но действительно выглядит довольно архаично. Это 2019 год! Почему наш браузер не может сделать это для нас? Или, возможно, мы могли бы добавить поддержку браузера для чего-то вроде атрибута append="true", который автоматически и изящно обработайте это для нас).
Я подниму следующий абзац и фрагмент кода из следующего проекта GitHub , чтобы лучше объяснить onload «решение» (которое делает * 1044)* не работает в FireFox из-за ошибок CSP, которые я задокументировал в этом вопросе):
В браузерах, которые его поддерживают, атрибут rel=preload заставит браузер извлечь таблица стилей, но она не будет применять CSS после загрузки (просто извлекает ее).Чтобы решить эту проблему, мы рекомендуем использовать для ссылки атрибут onload, который будет применять CSS после завершения загрузки.
<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">
Как уже говорилось, это выглядит очень архаично.Нам не нужно выбирать между избыточным и архаичным кодом.
Я упомянул, что в Chrome реализована лучшая производственная реализация CSP, но предстоит еще проделать определенную работу.Кроме того, причина, по которой я завел эту дикую охоту на ведьм, была (естественно), что я работал над улучшением скорости и производительности веб-сайта, поэтому я использовал инструмент Lightouse / Audit от Chrome Inspector.Из всего проведенного мною тестирования может показаться, что ресурсы, которые мы должны ожидать, уже будут кэшироваться на компьютере клиента (Bootstrap, jQuery, Google Fonts и т. Д.), Очищаются перед выполнением аудита и перезагружаются для учета.в сгенерированном отчете.Это хорошо (я понимаю, что это желаемое поведение);однако, если бы у нас был разработчик радиобокса для переопределения очистки общих ресурсов через CDN при проведении наших аудитов, я считаю, что разработчик получил бы дополнительный уровень понимания производительности своего веб-сайта.Или, по крайней мере, дифференцируйте отчет, чтобы точно указать, сколько времени было потрачено на загрузку и инициализацию связанных ресурсов.
Эти зависимости не ограничиваются rel="preload".При устранении неполадок в некоторых случаях я пытался использовать альтернативные значения, например rel="connect", на первом ресурсе, с которым я ссылался, через CDN CloudFlare.При проведении исследования по этой теме я обнаружил следующую статью с этой информацией:
Последний совет о ресурсах, о котором мы хотим поговорить, - это предварительное соединение.Предварительное подключение позволяет браузеру установить ранние подключения до того, как HTTP-запрос действительно будет отправлен на сервер .Это включает DNS-запросы, TLS-согласования, TCP-подтверждения.Это, в свою очередь, устраняет задержку в обоих направлениях и экономит время для пользователей.
«Предварительное соединение - важный инструмент в вашем наборе инструментов оптимизации… оно может исключить множество дорогостоящих обращений из вашего пути запроса - в некоторых случаях уменьшая задержку запроса в сотни раз идаже тысячи миллисекунд.- Илья Григорик »
Но, к сожалению, preconnect работает аналогично в браузерах, которые не поддерживают preload.И легко все это перепутать, если вы думаете, что проблема связана с вашими правилами CSP, а не с разметкой.
Я надеюсь, что это обеспечивает некоторый контекст и помогает облегчить некоторое разочарование в отношении CSP и текущей (отсутствие) правильная реализация его в основных браузерах на сегодняшний день.Пожалуйста, не стесняйтесь редактировать этот ответ, чтобы улучшить его или добавить больше контекста и информации в пользу наших коллег-разработчиков.