Измерение критического пути рендеринга

Илья Григорик

Опубликовано: 31 марта 2014 г.

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

  • Подход Lighthouse запускает серию автоматических тестов для страницы, а затем генерирует отчет о производительности CRP страницы. Этот подход обеспечивает быстрый и базовый общий обзор производительности CRP конкретной страницы, загруженной в ваш браузер, что позволяет вам быстро тестировать, повторять и улучшать ее производительность.
  • Подход Navigation Timing API фиксирует показатели реального мониторинга пользователей (RUM) . Как следует из названия, эти показатели собираются в результате реального взаимодействия пользователей с вашим сайтом и обеспечивают точное представление о реальной производительности CRP, наблюдаемой вашими пользователями на различных устройствах и в сетевых условиях.

В общем, хороший подход — использовать Lighthouse для выявления очевидных возможностей оптимизации CRP, а затем оснастить свой код API-интерфейсом Navigation Timing API, чтобы отслеживать, как ваше приложение работает в реальных условиях.

Аудит страницы с помощью Lighthouse

Lighthouse — это инструмент аудита веб-приложений, который запускает серию тестов для заданной страницы, а затем отображает результаты страницы в сводном отчете. Вы можете запустить Lighthouse как расширение Chrome или модуль NPM, что полезно для интеграции Lighthouse с системами непрерывной интеграции.

Чтобы начать, прочтите «Аудит веб-приложений с помощью Lighthouse» .

Когда вы запускаете Lighthouse как расширение Chrome, результаты CRP вашей страницы выглядят так, как показано на следующем снимке экрана.

Аудит CRP Lighthouse

Дополнительную информацию о результатах этого аудита см. в разделе «Цепочки критических запросов» .

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

Навигация

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

Итак, что означают эти временные метки?

  • domLoading : это начальная временная метка всего процесса, браузер собирается начать анализировать первые полученные байты HTML-документа.
  • domInteractive : отмечает момент, когда браузер завершил анализ всего HTML и построение DOM.
  • domContentLoaded : отмечает момент, когда DOM готов и нет таблиц стилей, блокирующих выполнение JavaScript — это означает, что теперь мы можем (потенциально) построить дерево рендеринга.
    • Многие фреймворки JavaScript ждут этого события, прежде чем начать выполнять свою собственную логику. По этой причине браузер фиксирует временные метки EventStart и EventEnd , чтобы мы могли отслеживать, сколько времени заняло это выполнение.
  • domComplete : как следует из названия, вся обработка завершена, и все ресурсы на странице (изображения и т. д.) завершили загрузку — другими словами, счетчик загрузки перестал вращаться.
  • loadEvent : на последнем этапе каждой загрузки страницы браузер запускает событие onload , которое может активировать дополнительную логику приложения.

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

  • domInteractive отмечает, когда DOM готов.
  • domContentLoaded обычно отмечает, когда готовы и DOM, и CSSOM .
    • Если нет парсера, блокирующего JavaScript, то DOMContentLoaded сработает сразу после domInteractive .
  • domComplete отмечает, что страница и все ее подресурсы готовы.
<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <script>
      function measureCRP() {
        var t = window.performance.timing,
          interactive = t.domInteractive - t.domLoading,
          dcl = t.domContentLoadedEventStart - t.domLoading,
          complete = t.domComplete - t.domLoading;
        var stats = document.createElement('p');
        stats.textContent =
          'interactive: ' +
          interactive +
          'ms, ' +
          'dcl: ' +
          dcl +
          'ms, complete: ' +
          complete +
          'ms';
        document.body.appendChild(stats);
      }
    </script>
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Попробуйте это

Предыдущий пример может показаться немного устрашающим на первый взгляд, но на самом деле он довольно прост. API синхронизации навигации фиксирует все соответствующие временные метки, и наш код ожидает срабатывания события onload — напомним, что событие onload срабатывает после domInteractive , domContentLoaded и domComplete — и вычисляет разницу между различными временными метками.

Демо-версия NavTiming

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

А как насчет DevTools?

Хотя в этих документах иногда используется панель Chrome DevTools Network для иллюстрации концепций CRP, DevTools не очень подходит для измерения CRP, поскольку не имеет встроенного механизма для изоляции критически важных ресурсов. Запустите аудит Lighthouse , чтобы выявить такие ресурсы.

Обратная связь