Анализ производительности с помощью Chrome Dev Tools

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

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

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

Чтобы испытать инструмент на практике, предлагаем вам протестировать различные методы поиска проблем производительности и их решения. В этом мануале в качестве примера рассматривается веб-сайт Scotch.io, но вы может применить все инструкции к своему сайту.

Требования

Чтобы выполнить этот мануал, вы должны установить браузер Google Chrome на свой компьютер.

1: Подготовка браузера

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

  • Скорость загрузки
  • Производительность кода во время выполнения

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

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

Запустите браузер Chrome и откройте вкладку в режиме инкогнито (COMMAND+SHIFT+N в macOS или CTRL+SHIFT+N в Windows или Linux). Перейдя в режим инкогнито, откройте сайт, который вы хотите протестировать.

Затем откройте DevTools, нажав COMMAND+OPTION+I в macOS или CTRL+SHIFT+I в Windows или Linux. Если вы хотите изменить расположение консоли DevTools, нажмите на три вертикальные точки на панели инструментов и сделайте выбор в опции Dock Side.

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

Примечание: Вкладка Audits может быть скрыта за кнопкой со стрелкой More Panels.

Наша основная цель здесь – выявить узкие места в производительности сайта Scotch и оптимизировать их. Узкое место в программной инженерии – это ситуация, когда один компонент ограничивает возможности приложения.

На следующем этапе мы проведем аудит для поиска узких мест в производительности.

2: Проведение аудита

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

Во вкладке Audits в Chrome DevTools мы настроим инструмент аудита. Перед нами на экране следующие настройки:

  • Device: дает возможность переключать пользовательский агент между опциями Mobile и Desktop. По состоянию на третий квартал 2018 года более половины веб-трафика генерируется мобильными устройствами, поэтому мы будем проводить аудит Scotch.io в режиме Mobile.
  • Audits: этот параметр позволяет нам выбирать, какое качество приложения мы хотим оценить и улучшить. В нашем случае производительность является основной проблемой, поэтому вы можете снять все остальные флажки.
  • Throttling: позволяет имитировать условия просмотра веб-страниц на мобильном устройстве. Мы будем использовать опцию Simulated Fast 3G, 4x CPU Slowdown. Это поможет рассчитать, сколько времени займет загрузка страницы в условиях мобильного устройства.
  • Clear Storage: позволяет очистить все кэшированные данные и ресурсы для протестированной страницы, чтобы проверить, как посетители воспринимают сайт, открывая его впервые. Поставьте этот флажок, если еще не сделали этого.

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

3: Анализ отчета по аудиту

По завершении аудита на экране появится отчет. Давайте рассмотрим его подробнее.

В правом верхнем углу будет круглая диаграмма с числом внутри – это общая оценка производительности сайта по шкале от 1 до 100. Мы получили 55, а это означает, что производительность сайта может быть гораздо лучше. Разобьем отчет на разделы и проанализируем их по отдельности.

В разделе Metrics вы найдете количественное представление различных аспектов эффективности сайта.

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

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

В разделе Passed audits выделены виды проверки производительности, которые прошла веб-страница.

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

4: Устранение проблем

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

First Meaningful Paint

First Meaningful Paint сообщает вам, когда основной контент страницы становится визуально доступным. По данным аудита, прежде чем вы увидите основной контент, проходит около 3,4 секунды. Это можно подтвердить, нажав кнопку View Trace. Перейдите во вкладку Performance, где вы сможете просматривать различные состояния пользовательского интерфейса во время загрузки, чтобы узнать, что происходит в каждый конкретный момент времени.

Обратите внимание, в какое время контент страницы становится видимым.

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

Speed Index

Speed Index показывает, как быстро визуализируется контент на странице.

В нашем случае это заняло около 7.2 секунд.

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

First CPU Idle

Метрика First CPU Idle (также известная как First Interactive) сообщает, когда страница становится минимально интерактивной (свободного CPU достаточно, чтобы обрабатывать вводимые пользователем данные, такие как клики, смахивания и т.д.). Согласно данным аудита, это занимает примерно 6,5 секунд. Всегда рекомендуем сводить это значение к минимуму.

Чтобы решить эту проблему, вам необходимо предпринять те же действия, что и с метрикой Speed Index.

Time to Interactive

Метрика Time to Interactive показывает время, которое необходимо, чтобы страница стала полностью интерактивной. Аудит в нашем примере показывает 6,9 секунды. Интерактивность в этом контексте описывает точку, в которой:

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

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

Estimated Input Latency

Метрика Estimated Input Latency описывает реакцию приложения на ввод пользователя. По этой метрике аудит фиксирует около 170 миллисекунд. У приложений обычно есть 100 миллисекунд для ответа на ввод пользователя, а Lighthouse и вовсе нацеливается на 50 миллисекунд. Причина этого несоответствия заключается в том, что Lighthouse использует прокси-метрику, которая представляет доступность основного потока для оценки ввода, а не для его измерения.

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

Чтобы улучшить эту метрику, вы можете использовать воркеры для обработки некоторых вычислений, освобождая таким образом основной поток. Еще одна полезная мера – рефакторинг CSS, чтобы селекторы выполняли меньше вычислений.

5: Решение проблем в разделе Opportunities

В разделе Opportunities перечислены советы по оптимизации, которые могут улучшить производительность.

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

Чтобы исправить это, вы можете позволить браузеру использовать такие ресурсы, добавив атрибут rel к тегам ссылок:

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

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

Заключение

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

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

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

Раздел основ веба на сайте Google Developers – отличный ресурс для дальнейшего изучения производительности и методов ее оптимизации.

Tags: , ,

Добавить комментарий