Эта статья — перевод оригинальной статьи "Performance Analysis with Chrome DevTools"

Также я веду телеграм канал “Frontend по-флотски”, где рассказываю про интересные вещи из мира разработки интерфейсов.

Вступление

Когда речь идет о производительности, разработчики часто используют Lighthouse, Perfbuddy или аналогичные инструменты анализа производительности. Но когда целевой сайт имеет защиту от ботов, получить информацию не так просто. В этой статье блога мы сосредоточимся на том, где искать признаки узких мест в производительности с помощью Chrome Devtools.

Подготовка

Даже если доступ к автоматизированным инструментам анализа производительности ограничен, вкладки Network, Performance и Performance Insights в Chrome Devtools все равно можно использовать. Чтобы сделать это, нужно провести некоторую подготовку.

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

Некоторые страницы в значительной степени полагаются на механизмы хранения данных на стороне клиента, такие как indexedDB, localStorage и sessionStorage. Cookies также могут мешать. Поэтому полезно использовать кнопку "Clear site data" на вкладке "Application", чтобы убедиться, что остающиеся данные не помешают вашим результатам.

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

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

Общие узкие места: ресурсы

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

Мы должны искать доказательства того, что ресурсы изображений обслуживаются из CDN с надлежащим сжатием. Мы можем проверить ресурсы по одному и посмотреть, содержат ли они заголовки Content-Encoding: gzip или Content-Encoding: br. Если эти заголовки отсутствуют, мы обнаружили одно узкое место, которое можно устранить, подавая изображения с использованием сжатия gzip или brotli при их подаче.

Заголовки в запросах к ресурсам могут указывать на другие признаки ошибок. Также может случиться, что изображения обслуживаются из CDN, например, fastly, но если на ресурсах есть заголовки fastly-io-error, это может означать, что что-то неправильно настроено.

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

Рендеринг на стороне сервера может улучшить SEO в целом, но стоит проверить размер файла index.html, потому что иногда это может быть контрпродуктивно. Рекомендуется, чтобы HTML-файлы не превышали 100 кб, чтобы метрика TTFB (Time To First Byte) не превышала 1 секунды.

Если страница использует полифиллы, стоит проверить, какие полифиллы используются. IE11 больше не поддерживается, и загрузка ненужных полифиллов для этого браузера замедляет время загрузки страницы.

Вкладка Performance Insights

Вкладка Performance Insights в Chrome DevTools позволяет пользователям измерять загрузку страницы веб-сайта. Для этого проводится анализ производительности сайта и предоставляются показатели различных аспектов процесса загрузки страницы, таких как время, необходимое для отображения страницы, время загрузки сетевых ресурсов и время, необходимое для интерактивности страницы.

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

Выполните следующие шаги, чтобы запустить анализ:

  1. Откройте Chrome Devtools

  2. Выберите вкладку "Performance insights"

  3. Нажмите на кнопку "Measure page load"

Анализ предоставляет нам подробное представление водопада запросов с цветовой кодировкой по типам запросов. Это может помочь вам определить запросы, которые блокируют/замедляют рендеринг страницы, и/или дорогие вызовы функций, которые блокируют основной поток. Он также предоставляет вам информацию о важных показателях производительности, таких как DCL (DOM Content Loaded), FCP (First Contentful Paint), LCP (Largest Contentful Paint) и TTI (Time To Interactive). Вы также можете имитировать дросселирование сети или процессора, или включить кэш, если этого требует ваш сценарий использования.

DCL - это время, необходимое для разбора исходного HTML-документа и построения DOM. FCP - это время, необходимое для отображения на странице первого содержательного элемента, например, изображения или текста. LCP - это метрика, измеряющая скорость загрузки самого большого элемента на веб-странице, например, изображения или блока текста. Быстрый LCP помогает пользователям как можно быстрее увидеть основное содержимое страницы, что может улучшить общее впечатление пользователя. TTI - это время, необходимое для того, чтобы страница стала полностью интерактивной, то есть все необходимые ресурсы были загружены, и страница реагирует на действия пользователя.

Вкладка "Performance"

Кнопка "start profiling and reload page" на вкладке "Performance" в Chrome DevTools позволяет пользователям проводить анализ производительности веб-сайта и просматривать подробную информацию о загрузке и рендеринге страницы. Нажав на эту кнопку, инструмент смоделирует пользователя, посещающего веб-сайт и взаимодействующего с ним, а затем предоставит метрики и другую информацию о процессе загрузки страницы.

Выполните следующие действия, чтобы запустить анализ:

  1. Откройте Chrome Devtools

  2. Выберите вкладку "Performance"

  3. Нажмите на кнопку с иконкой "обновить".

Очень полезной частью этого представления является подробная информация, предоставляемая о главном потоке. Мы можем взаимодействовать со стеками вызовов и находить функции, которые могут выполняться слишком долго, блокируя основной поток и задерживая метрику TTI (Time To Interactive). Выбор функции дает всевозможную информацию об этой функции. Можно посмотреть, как долго выполнялась функция, какие другие функции она вызывала, а также напрямую открыть эту функцию на вкладке Sources.

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

Заключение

Chrome DevTools - это мощный инструмент для анализа производительности веб-приложений. С помощью вкладки "Network" можно выявить проблемы с ресурсами, которые могут замедлять загрузку страницы. С помощью вкладок Performance insights и Performance можно выявить проблемы, которые могут быть причиной медленной загрузки сайта, и принять меры по оптимизации кода для повышения производительности. Будь вы начинающий или опытный разработчик, Chrome DevTools - незаменимый инструмент для анализа и повышения производительности веб-приложений.

Комментарии (0)