Мы все были там - просматривая результаты поисковой системы одну за другой в поисках подходящей гифки с котиком, которую можно было бы отправить нашим коллегам. Если для загрузки какого-либо веб-сайта требуется более двух встряхиваний ягненка, нас нет. Зачем ждать медленного веб-сайта, если мы можем перейти на следующий веб-сайт одним нажатием кнопки?

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

Как асинхронность может улучшить производительность?

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

<script src="example.js"></script>

По умолчанию, когда браузер анализирует документ и достигает этой строки, он начинает получать файл JavaScript с сервера. Затем он будет ждать, пока файл не будет возвращен, после чего он проанализирует и выполнит файл JavaScript. Только после этого он продолжает синтаксический анализ остальной части HTML-документа.

Если парсер обнаружит ваш тег script перед отображением видимого контента, ваши пользователи застрянут в ожидании момента удовлетворения. Если загружаемый файл JavaScript не является абсолютно необходимым для показа контента вашим пользователям, вы излишне подталкиваете своих пользователей искать в другом месте . Инструменты тестирования производительности веб-сайта, такие как Google PageSpeed ​​или Lighthouse, часто будут отмечать синхронно загружаемые скрипты по этой причине.

Синхронный пример

В целях иллюстрации я создал довольно простую веб-страницу, содержащую тег script, подобный упомянутому выше. Тег script помещается в head документа. Тег script загружает файл JavaScript размером 844 КБ в необработанном виде или 175 КБ в сжатом виде (файл передается через Интернет в сжатом виде, что означает, что он сжимается для экономии места и времени).

Используя инструменты повышения производительности в Google Chrome, мы видим, что «первая отрисовка» откладывается до тех пор, пока наш файл JavaScript не будет загружен и выполнен. Первая краска - это момент, когда пользователю показывается исходный контент, и он является ключевым показателем производительности веб-сайта. Общее время между началом загрузки страницы и первой отрисовкой составляет 571 миллисекунду. Почти все это время мы ждали загрузки и выполнения файла JavaScript.

Асинхронный пример

Теперь давайте попробуем загрузить файл JavaScript асинхронно. Для этого мы добавим атрибут async к тегу script следующим образом:

<script src="example.js" async></script>

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

Давайте посмотрим, как это повлияет на производительность в нашем примере сценария.

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

Есть ли недостатки?

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

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

Предполагая, что мы устанавливаем расширение Adobe Target через Launch и решаем загружать среду выполнения Launch асинхронно, код расширения Adobe Target не будет выполняться достаточно рано, чтобы скрыть содержимое по умолчанию, прежде чем оно будет показано пользователю. Без дополнительных мер предосторожности пользователи могут столкнуться с мерцанием, когда Target позже заменит контент по умолчанию персонализированным контентом. Подобного поведения можно ожидать и с другими инструментами тестирования и оптимизации; это не относится к Adobe Target.

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

Еще одно соображение заключается в том, что Launch всегда предоставляет тип события Page Bottom, который позволяет пользователям запускать правило в тот самый момент, когда анализатор браузера достигает нижней части тега body. Поскольку среда выполнения Launch, скорее всего, завершит загрузку после того, как будет достигнута нижняя часть страницы, тип события Page Bottom может не активировать связанные правила в ожидаемое время. По этой причине при асинхронной загрузке Launch мы предлагаем не использовать тип события Page Bottom, а вместо этого учитывать типы событий Library Loaded, DOM Ready, Window Loaded или другие типы событий.

Как мне загрузить Launch асинхронно

Выше мы узнали, как добавить атрибут async к тегу script, чтобы скрипт загружался асинхронно. Для кода внедрения Launch это означает изменение этого:

<script src="//assets.adobedtm.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js"></script>

к этому:

<script src="//assets.adobedtm.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js" async></script>

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

Затем удалите нижний код страницы внизу тега body:

<script type="text/javascript">_satellite.pageBottom();</script>

Это код, который сообщает Launch, что парсер браузера достиг нижней части страницы. Поскольку Launch, скорее всего, не будет загружен и запущен до этого времени, вызов _satellite.pageBottom() приведет к ошибке. Как упоминалось ранее, следствием этого является то, что тип события Page Bottom может вести себя не так, как ожидалось.

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

Вы видели повышение производительности при загрузке Асинхронно? Сталкивались ли вы с проблемами, о которых должны знать другие пользователи? Если да, мы будем рады услышать об этом в комментариях ниже.