Загрузка стороннего JavaScript на сайт

Тестовая веб-страница, отображающая влияние загрузки сайта с отключенными третьими лицами и без них

Влияние блокировки сторонних ресурсов на странице с использованием функции WPT "блокировать запросы" из “Использование теста веб-страниц для измерения влияния сторонних тегов” Энди Дэвиса

Примечание: 

WebPageTest также поддерживает две команды, работающие на уровне DNS для блокировки доменов. blockDomains - который принимает список доменов для блокировки, а blockDomainsExcept - принимает список доменов и блокирует все, чего нет в списке.

WebPageTest также имеет вкладку с одной точкой отказа (SPOF). Это позволяет имитировать тайм-аут или полный сбой при загрузке ресурса.

Разница между "SPOF" и "Блоком" заключается в том, что время ожидания SPOF медленно истекает. Это может быть полезно для тестирования сетевой устойчивости контента сторонних производителей, чтобы определить, насколько хорошо работают ваши страницы, когда службы находятся под большой нагрузкой или временно недоступны.

Обнаружение дорогостоящих кадров iframe с использованием длительных задач

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

Для обнаружения длительных задач для реального мониторинга пользователей (RUM) мы можем использовать API jаvascript PerformanceObserver и наблюдать за записями длительных задач. Поскольку эти записи содержат свойство атрибуции, мы можем отследить, какой контекст фрейма отвечал за выполнение задачи.

Ниже приведен пример, который будет регистрировать longtask 

<script>  const observer = new PerformanceObserver((list) => {

 for (const entry of list.getEntries()) {

// Attribution entry including "containerSrc":"https://example.com"

            console.log(JSON.stringify(entry.attribution));

 }

 });

observer.observe({ entryTypes: ['longtask'] });

</script>

<iframe src="https://example.com"></iframe>

записи в консоли, в том числе для "дорогого" iframe:

Чтобы узнать больше о мониторинге длительных задач, прочитайте ориентированную на пользователя книгу Фила Уолтона Производительность Показатели.

Как вы эффективно загружаете сторонний скрипт?

Если сторонний скрипт замедляет загрузку вашей страницы, у вас есть несколько вариантов повышения производительности:

Загрузите сценарий, используя атрибут async или defer, чтобы избежать блокировки анализа документов.

Рассмотрите возможность самостоятельного размещения скрипта, если сторонний сервер работает медленно.

Подумайте об удалении скрипта, если он не добавляет четкой ценности вашему сайту.

Рассмотрите подсказки ресурсов, такие как <link rel=preconnect>или <link rel=dns-prefetch>для выполнения поиска DNS для доменов, в которых размещены сторонние скрипты.

Выполнение jаvascript блокирует синтаксический анализатор. Это означает, что, когда браузер сталкивается со сценарием, он должен приостановить построение DOM, передать его движку jаvascript и разрешить выполнение сценария, прежде чем приступить к построению DOM.

Атрибуты async и defer изменяют это поведение.

При использовании асинхронности браузер загружает сценарий асинхронно, продолжая анализировать HTML - документ. Когда скрипт завершает загрузку, синтаксический анализ блокируется во время выполнения скрипта.

С помощью функции отсрочки браузер загружает сценарий асинхронно, продолжая анализировать HTML - документ. Сценарий не запускается до тех пор, пока не будет завершен синтаксический анализ.

Визуализация, сравнивающая влияние использования сценария против асинхронного сценария против отложенного сценария. Задержка отображается как выполнение после извлечения скрипта и выполнения синтаксического анализа HTML.

В общем, вы всегда должны использовать async или defer для сторонних сценариев (если только сценарий не выполняет что-то необходимое для критического пути рендеринга).:

Используйте async, если важно, чтобы скрипт запускался раньше в процессе загрузки. Это может включать, например, некоторые аналитические сценарии.

Используйте defer для менее важных ресурсов. Например, видеоплеер, который находится ниже складки.

Примечание

Если вас больше всего беспокоит производительность, вы можете подождать, пока ваша страница не достигнет ключевого момента для пользователя (например, после загрузки критического содержимого), прежде чем добавлять асинхронные сценарии. Вам также следует позаботиться о том, чтобы не async загружать библиотеки, подобные jQuery, только потому, что они исходят от стороннего CDN.

Примечание

В браузерах, основанных на мигании async , и defer в настоящее время снижают приоритет сетевого запроса ресурсов, чтобы он мог загружаться значительно позже, чем в случае блокирующего сценария. Это полезно знать, в частности, для аналитических сценариев.

Должны ли вы когда-нибудь загружать сторонние скрипты без async или defer?  Вы могли бы обосновать это, если сценарий является важной частью функциональности вашего сайта. 

Например, если вы загружаете свою основную библиотеку пользовательского интерфейса или фреймворк с CDN, в DevTools он будет помечен как "сторонний скрипт", но его следует рассматривать как неотъемлемую часть вашего сайта, а не как дополнение.

Обратите внимание, что не все сценарии работают при асинхронной загрузке. Проверьте документы на наличие любых сторонних сценариев, которые вы используете. Если вы используете сценарий, который не может быть загружен асинхронно, возможно, вам захочется рассмотреть альтернативу или, по возможности, исключить сценарий. 

Некоторые третьи стороны могут настоятельно рекомендовать загружать свои сценарии синхронно (чтобы опередить другие сценарии), даже если они будут работать нормально асинхронно, поэтому при оценке стратегий загрузки сторонних сценариев следует проявлять должную осмотрительность.

Примечание: async это не серебряная пуля. Если маркетинговая команда хочет загрузить на страницу большое количество сценариев отслеживания, это число все равно создаст узкие места, которые могут повлиять на то, как скоро пользователи смогут взаимодействовать со страницей при загрузке.

Используйте подсказки по ресурсам, чтобы сократить время настройки подключения

Установление соединений со сторонними источниками может занять значительное количество времени, особенно в медленных сетях. Многие шаги могут привести к задержкам, включая поиск DNS, перенаправление и, возможно, несколько обходов каждого стороннего сервера для обработки запроса.

Вы можете использовать подсказки ресурсов, такие как для выполнения поиска DNS для доменов, в которых размещены сторонние скрипты. Когда запрос на них, наконец, будет сделан, время может быть сэкономлено, так как поиск DNS уже выполнен.

<link rel="dns-prefetch" href="http://example.com">

Если сторонний домен, на который вы ссылаетесь, использует HTTPS, вы также можете рассмотреть поскольку это позволит как выполнять поиск DNS, так и разрешать циклы TCP и обрабатывать переговоры TLS. 

Эти другие шаги могут быть очень медленными, поскольку они связаны с проверкой SSL-сертификатов, поэтому серьезно отнеситесь к подсказкам ресурсов, если вы обнаружите, что время настройки сторонних разработчиков является проблемой.

<link rel="preconnect" href="https://cdn.example.com">

Сценарии "песочницы" с iframe

Бывают случаи, когда сторонние скрипты могут быть загружены непосредственно в iframe. Ограничивая такие сценарии рамками iframe, они не будут блокировать выполнение главной страницы. Это тот же подход, который использует AMP, чтобы убрать jаvascript с критического пути. Обратите внимание, что этот подход все равно заблокирует onload событие, поэтому постарайтесь не привязывать к нему критические функции onload.

Примечание. 

Chrome также изучает поддержку Политики функций - набора политик, позволяющих разработчику выборочно отключать доступ к определенным функциям браузера. Это может предотвратить нежелательное поведение стороннего контента на сайте.

Сценарии сторонних разработчиков для самостоятельного размещения

Самостоятельное размещение сторонних скриптов может быть вариантом, если вы хотите больше контролировать историю загрузки скрипта. Например, если вы хотите сократить время DNS или туда и обратно, улучшите заголовки кэширования HTTP или воспользуйтесь передовыми методами, такими как HTTP/2 server push. Самостоятельный хостинг может быть целесообразным, если сценарий считается критичным.

Самостоятельный хостинг может сопровождаться рядом серьезных предостережений:

Сценарии могут устареть. Это может быть серьезной проблемой, так как это мешает вам получать важные исправления безопасности без обновления вручную.

Сценарии, которые являются автономными, не будут автоматически обновляться из-за изменения API. Один пример: издатель, 90% дохода которого приходится на рекламу, обнаруживает, что реклама не показывалась в течение половины дня из-за изменения API, которое не учитывалось их собственным сценарием, что привело к потере дохода.

Альтернативой сценариям самостоятельного размещения было бы использование сервисных работников для их кэширования. Это может дать вам больший контроль над тем, как часто они повторно извлекаются из сети. 

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

A/B Тестирование небольших выборок пользователей

A/B-тестирование (или сплит-тестирование) - это метод для экспериментов с двумя версиями страницы, чтобы определить, какая из них работает лучше всего. Это делается путем включения обоих вариантов (A и B) для разных образцов трафика вашего веб-сайта. Выигрывает страница, которая обеспечивает лучший коэффициент конверсии.

A/B-тестирование-очень полезный инструмент для анализа пользовательского опыта и поведения.

Однако по замыслу A/B-тестирование задерживает рендеринг, чтобы выяснить, какой эксперимент должен быть активным. jаvascript часто используется для проверки того, принадлежит ли кто-либо из ваших пользователей к A/B-тестовому эксперименту, а затем для включения правильного варианта. Этот шаблон может привести к тому, что 100% ваших пользователей будут отправлены по большому дорогостоящему сценарию, даже если они не принадлежат к выборке, получающей эксперимент.

Хорошей альтернативой в этом случае является отправка сценариев тестирования A/B только для подмножества вашей базы пользователей (например, 10% против 100%), в идеале пытаясь решить, относятся ли они к тестовому образцу на стороне сервера. Это улучшает качество загрузки для большинства пользователей, но при этом делает возможным раздельное тестирование.

Ленивая загрузка Сторонних Ресурсов

Встроенные сторонние ресурсы (такие как реклама или видео) могут в значительной степени способствовать снижению скорости работы страницы при неправильном построении. Ленивая загрузка может использоваться только для загрузки встроенных ресурсов, когда это необходимо. 

Например, показ рекламы в нижнем колонтитуле только тогда, когда пользователь прокручивает страницу вниз. Другой шаблон-ленивая загрузка содержимого после загрузки содержимого главной страницы, но до того, как пользователь может иным образом взаимодействовать со страницей.

Иллюстрация, показывающая активы, которые имеют решающее значение для вышеупомянутого опыта складывания, и те, которые менее важны и могут быть лениво загружены.

Примечание: lazySizes - популярная библиотека jаvascript для ленивой загрузки изображений и iframes. Он поддерживает встраивания и виджеты YouTube. Необходимо проявлять осторожность при ленивой загрузке любых ресурсов, так как этот метод часто работает на jаvascript и может быть связан с проблемами при слабых сетевых подключениях.

В официальной документации DoubleClick есть указания по ленивой загрузке рекламы. При правильном использовании замедленная загрузка может увеличить общий процент просмотра объявления. Например, Mediavine переключился на рекламу с замедленной загрузкой и увидел 200%-ное увеличение скорости загрузки страниц.

Эффективная ленивая загрузка с наблюдателем пересечений

Исторически сложилось так, что решения для определения того, виден ли элемент в окне просмотра (для ленивой загрузки его содержимого), были подвержены ошибкам, что часто приводило к замедлению работы браузера. 

Решения часто прослушивали события прокрутки или изменения размера, а затем использовали API-интерфейсы DOM, такие как getBoundingClientRect (), для вычисления расположения элементов относительно окна просмотра. Это работает, но неэффективно.

IntersectionObserver- это API браузера, который позволяет нам эффективно определять, когда наблюдаемый элемент входит или выходит из окна просмотра браузера. Узнайте больше о том, как использовать его для ленивой загрузки ресурсов. lazySizes также имеет дополнительную поддержку для IntersectionObserver.

Аналитика может быть сложной

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

Избегайте document.write()

Сторонние сценарии иногда используют document.write() для ввода и загрузки сценариев. Это особенно верно в отношении старых сервисов, которые не обновлялись в течение некоторого времени. К счастью, многие сторонние компании предлагают возможность асинхронной загрузки самих себя, что позволяет сторонним скриптам загружаться, не блокируя отображение остального содержимого на странице.

Исправление для document.write() состоит в том, чтобы просто не вводить сценарии, использующие его. Начиная с Chrome 53, Chrome DevTools будет регистрировать предупреждения на консоли о проблемном использовании document.write():

Предупреждения консоли DevTools, выделяющие нарушения для стороннего встраивания с помощью document.write()

Чтобы узнать об использовании document.write() в масштабе, вы можете проверить наличие HTTP-заголовков, отправляемых в ваш браузер, когда происходит это вмешательство в Chrome. Lighthouse также может выделить любые сторонние скрипты, все еще использующие document.write() в отчете Lighthouse:

Аудит лучших практик Lighthouse, отмечающий использование document.write()

Используйте менеджеры тегов, но используйте их с умом

Примечание: Соблюдайте осторожность при использовании GTM. Хотя это может свести к минимуму накладные расходы на сторонние теги, это также делает тривиальным для тех, у кого есть учетные данные, добавление дорогостоящих тегов.

"Тег"-это фрагмент кода, который позволяет командам цифрового маркетинга собирать данные, устанавливать файлы cookie или интегрировать сторонний контент, такой как виджеты социальных сетей, на сайт. Эти теги влияют на производительность загрузки вашей страницы - дополнительные сетевые запросы, тяжелые зависимости jаvascript, изображения и ресурсы, которые может использовать сам тег.

Управление этими тегами со временем может превратиться в настоящую неразбериху, поскольку маркетинговые команды хотят добавить больше способов понимания пользователей, а инженеры пытаются свести к минимуму влияние тегов на пользовательский опыт. Для быстрого обмена опытом мы рекомендуем использовать менеджер тегов. Менеджеры тегов:

разрешить управление множеством фрагментов кода встраивания сторонних разработчиков из одного места (обычно через пользовательский интерфейс).

попытайтесь свести к минимуму количество сторонних тегов, которые необходимо развернуть на сайтах.

Примечание. 

Несмотря на то, что отдельные теги могут загружаться асинхронно, их все равно необходимо читать и выполнять по отдельности. Это может означать запрос дополнительных данных во время загрузки страницы. Менеджеры тегов решают эту проблему, сокращая количество вызовов, которые браузер должен совершать для них, до одного.

Менеджер тегов Google (GTM) - один из таких популярных менеджеров тегов:

"Менеджер тегов Google является асинхронным тегом, что означает, что при его выполнении он не блокирует отображение других элементов на странице. Это также приводит к асинхронному развертыванию других тегов, развернутых через диспетчер тегов Google, что означает, что тег с медленной загрузкой не блокирует другие теги отслеживания".

Менеджеры тегов могут повысить производительность загрузки страниц за счет уменьшения количества необходимых вызовов внешних ресурсов - до тех пор, пока вы** не** вводите большое количество тегов. Они также позволяют тегам собирать значения в одном уникальном месте.

Для GTM это Уровень данных. Если несколько третьих сторон хотят запустить данные отслеживания конверсий, они могут сделать это, извлекая данные из уровня данных.

Риски при использовании менеджеров тегов

При использовании менеджера тегов необходимо проявлять большую осторожность, чтобы избежать замедления скорости загрузки страниц. Это потому что:

Любой, у кого есть учетные данные и доступ, может легко добавить не только дополнительные теги, но и любой jаvascript, который он захочет. Хотя менеджеры тегов могут загружать теги асинхронно, это все равно может привести к чрезмерному количеству выполняемых и выполняемых дорогостоящих HTTP-запросов. Это можно свести к минимуму, разрешив публиковать версии только одному пользователю.

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

Благодаря нашему руководству по производительности, поощряющему вас реагировать на события в течение 50 мс, каждый добавленный прослушиватель событий диспетчера тегов уничтожает эту цель.

Избегайте сценариев, которые загрязняют глобальную область

Сторонние скрипты, внедренные в неизвестное, иногда могут загружать ряд собственных зависимостей jаvascript. Это может привести к загрязнению глобальной области и случайному повреждению страниц.

Также нет гарантии, что код, загруженный от третьей стороны, останется таким же, как вы видели во время тестирования. Новые функции могут быть запущены третьими лицами в любое время, что может привести к нарушению вашей страницы. Здесь могут помочь самотестирование, целостность субресурсов и безопасная передача кода третьей стороны (для снижения риска изменений в пути).

Обязательно проведите тщательный аудит загружаемых вами сторонних сценариев, чтобы убедиться, что они являются хорошими участниками.

Стратегии смягчения последствий

Добавление сторонних скриптов на страницу подразумевает уровень доверия к источнику. Существует несколько стратегий, которые вы можете предпринять, чтобы свести к минимуму их влияние на производительность и безопасность:

HTTPS является обязательным. На сайтах, работающих по протоколу HTTPS, не должно быть сторонних разработчиков, работающих по протоколу HTTP. Страница HTTPS, содержащая содержимое, полученное с помощью HTTP, называется страницей смешанного содержимого и будет содержать предупреждения о смешанном содержимом.

Рассмотрим атрибут песочницы в iframes. С точки зрения безопасности это позволяет ограничить действия, доступные из iframe. Ограничения включают allow-scriptsконтроль того, может ли контекст запускать сценарии.

Рассмотрим Политику безопасности контента (CSP). С помощью заголовка HTTP в ответе вашего сервера вы можете определить поведение, которому доверяют на странице. CSP можно использовать для обнаружения и смягчения последствий определенных атак, таких как межсайтовые сценарии (XSS).

CSP особенно эффективен, поскольку включает в себя такие директивы, как script-src, которые определяют допустимые, разрешенные источники для jаvascript. Ниже приведен пример того, как это можно использовать на практике:

<script src="https://not-example.com/js/library.js"></script>