Новое определение «загрузки страницы» в эпоху одностраничных приложений
Веб-сайты больше не являются веб-сайтами. Точнее, веб-сайт больше не является «сайтом», а единым статическим местоположением. Вместо этого гонка за созданием более захватывающего цифрового опыта делает веб-сайты более динамичными и интерактивными, а контент и логика обновляются в режиме реального времени. Веб-сайты теперь часто называют «веб-приложениями», независимо от того, содержат ли они тележки для покупок в электронной коммерции, галереи мультимедиа/контента, программные порталы или другие функции.
Эта эволюция позволила разработчикам создавать более привлекательные возможности для пользователей, но некоторые из основополагающих представлений о том, как мы измеряем производительность веб-сайта, не поспевают за этими изменениями. Например, хотя время загрузки страницы остается ключевым показателем измерения веб-приложений, определение этого термина больше не полностью соответствует тому, как веб-приложения разрабатываются и используются. Это особенно верно в связи с переходом к «одностраничным приложениям», таким как React или Angular. Результат может значительно превысить или занизить время загрузки вашей страницы или полностью пропустить загрузку некоторых страниц. И это может исказить ключевую метрику, которую все заинтересованные стороны используют в разработке, бизнесе, маркетинге и ИТ для принятия важных решений о своих веб-сайтах.
Просмотр определения загрузки страницы
Итак, как мы должны думать об этом новом мире загрузки страниц?
В 2010 году сообщество веб-производителей сделало большой шаг вперед, когда Chrome, Firefox и Internet Explorer начали реализовывать спецификацию W3C, которая впоследствии стала стандартом Navigation Timing API. Повышенная прозрачность времени загрузки страницы была общепризнанной необходимостью, и, хотя можно было вручную встроить инструментарий синхронизации в веб-сайт, этот новый API браузера предоставил менее навязчивый стандартный способ получения этой информации из самого веб-браузера. Спецификация Navigation Timing продолжает активно использоваться и обновляться, с расширенной поддержкой и улучшением детализации синхронизации.
API описывает ряд вех, происходящих во время загрузки страницы, завершающихся событием window.load
. Когда срабатывает событие window.load
, оно отмечает конец процесса загрузки документа, когда все объекты в документе находятся в DOM, а все изображения, сценарии, таблицы стилей и подкадры завершили загрузку. . Для статического веб-сайта при запуске события window.load страница полностью загружается в окно браузера, полностью отображается и готова к использованию.
Процесс загрузки страницы для традиционных веб-сайтов
Для статических веб-сайтов событие window.load точно отражает, когдаДля статических веб-сайтов событие window.load точно отражает, когда страница загружена и готова к использованию.
Новый мир динамического контента
Однако современные веб-приложения спроектированы и спроектированы по-разному. Чтобы создать богатый пользовательский опыт, они активно используют вызовы AJAX и выполнение JavaScript для манипулирования страницей и изменения контента, представлений и взаимодействия с пользователем намного позже 9.0015 событие window.load .
Мы можем видеть это по количеству вариантов использования:
- Динамическая загрузка контента: Динамическое извлечение настраиваемого контента на основе потребления пользователем
Примеры: Индивидуальный новостной/видеоконтент на основе шаблонов просмотра пользователем, индивидуализированные рекомендации продуктов для корзины покупок, персонализированная информация об учетной записи пользователя , чтобы ускорить начальную загрузку страницы за счет уменьшения количества задействованного контента
Пример: Прокрутка карусели фотоальбома, приборной панели или виджетов контента
- Сторонние виджеты: Извлечение компонентов и контента из внешних служб
Примеры: Виджеты социальных сетей из Twitter или Facebook, виджеты обратной связи, виджеты обсуждений, медийная реклама
- Контент в реальном времени: Непрерывный опрос серверной системы для извлечения обновленных данных
Примеры: Отслеживание игр в реальном времени, результаты выборов, живые блоги, трансляции событий
- Предварительно загруженный контент:
Незаметная загрузка контента за кулисами для более удобного взаимодействия с пользователем
Примеры: Новостные сайты с бесконечной прокруткой, которые автоматически загружают следующую статью, когда пользователь прокручивает первую, автоматически воспроизводя видеоконтентСобытие 0015 window. load больше не отображает полное представление о работе пользователей.
Процесс загрузки страницы для современных веб-приложений
Для динамических веб-приложений, которые продолжают извлекать содержимое, событие window.load больше не соответствует моменту загрузки страницы и ее готовности к использованию.
Динамические представления с одностраничными приложениями
Одностраничные приложения (SPA), часто созданные с использованием фреймворков или библиотек, таких как React, Angular, Ember, Backbone и других, выводят эти идеи о динамическом взаимодействии с пользователем на новый уровень. SPA представляют собой не только динамический контент или виджеты, но и отображают совершенно новые представления для пользователя как часть изменения маршрута. Нажав на ссылку, пользователи могут подумать, что они перешли на другую страницу, но на самом деле они могли просто динамически вытащить контент, повторно отрендеренный на стороне клиента, без полного обновления страницы.
Видимость для отслеживания этих изменений маршрута стала важной, поскольку пользователи воспринимают их как новую «мягкую» загрузку страницы. Однако событие window.load
не может отслеживать эти изменения маршрута и будет рассматривать эти последующие действия пользователя и действия по изменению маршрута как часть исходной загрузки страницы.
Примечательно, что в то время как многие разработчики реализуют SPA с использованием этих фреймворков JavaScript, другие рассматривают SPA больше как философию дизайна, способ динамически генерировать новые представления для своих пользователей без загрузки новой страницы. Они могут предпочесть не полагаться на фреймворк — и кривую обучения/привязку, которая приходит с предварительно созданными каркасами фреймворка — и создать что-то индивидуальное на основе принципов SPA. Однако, что в конечном счете имеет значение, так это возможность разграничить начало и конец этих изменений маршрута, чтобы вы могли измерить, что на самом деле испытывают пользователи.
Понимание «истинного» взаимодействия с клиентом при загрузке вашей страницы
Между динамическим содержимым и SPA разрыв между событием window.load
и моментом, когда пользователь может фактически использовать страницу, становится все более значительным. Страница может занять всего 200 мс для запуска события onload, но к тому времени, когда все вызовы AJAX будут завершены и DOM установится, может пройти 1000 мс (или даже вдвое больше), прежде чем страница будет полностью отображена и готова к использованию. Это более позднее время является более точным представлением опыта клиента.
И это только упрощенный пример. Многие современные веб-интерфейсы используют сразу несколько вариантов использования дизайна, что может еще больше замедлить «настоящее» взаимодействие с пользователем со страницы. Для компаний, которые заботятся о своем цифровом клиентском опыте, получение истинного представления о клиентском опыте загрузки страницы может быть поучительным опытом, раскрывая, сколько времени действительно требуется пользователю, чтобы начать взаимодействовать с веб-контентом, не говоря уже о влиянии этого. может иметь ключевые показатели, такие как конверсии, вовлеченность и цифровой доход.
Измерение загрузки страниц в новом мире динамических веб-страниц
window.load
остается важной метрикой, но оно все больше и больше отражает только частичную историю загрузки страницы клиентом. Давайте взглянем на мониторинг SPA в New Relic Browser, чтобы увидеть, что происходит после первоначального события загрузки страницы для приложения Angular: когда произошло событие window.onload. Это гораздо более полная информация, чем window.load
, которое пропустило бы все вызовы AJAX и выполнение JavaScript, которые произошли впоследствии, и значительно недооценило бы, как долго пользователи ожидали использования страницы. В приведенном выше примере казалось, что в некоторых случаях для загрузки страницы требуется 3 секунды на основе события
, тогда как на самом деле для завершения страницы во внешнем интерфейсе потребовалось около 10 секунд.
Такая более глубокая видимость загрузки страниц полезна, хотя в одностраничном приложении может оказаться, что изменения маршрута составляют большую часть взаимодействия с пользователем, чем загрузка страниц. В этом же приложении Angular мы видим, что на самом деле пропускная способность трафика при изменении маршрута выше, чем при загрузке страницы.
Точно так же, как мы можем изучить время загрузки страницы, мы также можем детализировать время изменения маршрута с помощью инструментов SPA New Relic Browser, не зависящих от фреймворка. Независимо от того, какой фреймворк используется, или даже если что-то специально создано на основе принципов SPA, мы можем получить такое глубокое представление о производительности этого внешнего интерфейса.
Как только вы получите представление о том, что на самом деле испытывают клиенты во время загрузки страниц и изменения маршрута, возникает следующий вопрос: как это улучшить.
Ознакомьтесь с публикацией Клэя Смита о создании одностраничных приложений для работы в сети, чтобы узнать о некоторых передовых методах; его советы применимы к любому современному динамическому внешнему приложению, особенно к одностраничным приложениям.
Ресурсы:
- Документация New Relic Browser — Отличия от традиционного времени загрузки страницы
Джеймс Нгуен
Джеймс Нгуен — директор по маркетингу продуктов в компании New Relic, расположенной в Сан-Франциско.
Мнения, выраженные в этом блоге, принадлежат автору и не обязательно отражают точку зрения New Relic. Любые решения, предлагаемые автором, зависят от среды и не являются частью коммерческих решений или поддержки, предлагаемых New Relic. Пожалуйста, присоединяйтесь к нам исключительно в Исследовательском центре (discuss.newrelic.com) для вопросов и поддержки, связанных с этим сообщением в блоге.