Legacy audits в chrome как включить

Обновлено: 28.06.2024

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

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

Панель Elements

Используется для выбора и редактирования любых HTML элементов на странице. Позволяет свободно манипулировать DOM и CSS.

Вкладка содержит две кнопки: Выбор элемента с помощью курсора и Переключение в режим выбора устройств, она пригодится при разработке адаптивных интерфейсов, мобильных версий сайтов или для тестирования страниц с разным разрешением монитора. При выборе любого DOM элемента на вкладке Styles будет отображаться все CSS правила применяемые к нему, в том числе и неактивные. Все правила разбиты на блоки и упорядочены по убыванию специфичности селектора. Можно на лету менять значения, деактивировать и дописывать новые правила и смотреть как это влияет на отображение. Также для выбранного элемента DOM доступно еще несколько вкладок: Event Listeners — содержит все события относящиеся к данному элементу, DOM Breakpoints — точки останова для элемента и Properties — список всех свойств для элемента. Также могут быть дополнительные вкладки добавляемые расширениями для Chrome.

Ключевые возможности:

Просмотр и редактирование в лайв режиме любого элемента DOM.
Просмотр и изменение CSS правил применяемых к любому выбранному элементу в панели Styles.
Просмотр всего списка событий и свойств для элемента на соответствующих вкладках.

Панель Console

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

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

Ключевые возможности:

Панель Sources

Инструмент Sources представляет собой своего рода IDE, где мы можем посмотреть все файлы подключенные на нашей странице. Мы можем посмотреть их содержимое, отредактировать код, скопировать его или сохранить измененный файл, как новый файл. Данную вкладку можно использовать и как полноценный редактор кода подключаясь к локальным файлам через Workspaces.

Также Sources используется для отладки JavaScript используя брейкпоинты. Для работы с брейкпоинтами предусмотрено большое количество специальных кнопок и доп. возможностей о которых больше можно узнать в официальной документации.

Ключевые возможности:

Отладка Вашего кода с помощью брейкпоинтов.
Использование браузера в качестве IDE с помощью Workspaces.
Запуск сниппетов с любой страницы.

Панель Network

Позволяет мониторить процесс загрузки страницы и всех файлов которые подгружаются при загрузке. Ее удобно использовать для оптимизация загрузки страниц и мониторинг запросов.
На панели отображается таблица всех запросов к данным и файлам, над ней располагаются кнопки для фильтрации нужных Вам запросов, очистки таблицы или включения/отключения записи запросов, кнопки управления отображением таблицы. Также есть дополнительные переключатели: Preserve log — не очищать таблицу при перезагрузке страницы, Disable cache — отключить кэш браузера (будет работать только при открытом Dev Tools), Offline — эмулирует отсутствие интернета, также соседний переключатель позволяющий эмулировать скорость скачивания/загрузки данных и ping для различных типов сетей.

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

Ключевые возможности:

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

Панель Performance

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

Инструмент применяется для улучшение производительности работы Вашей страницы в целом.

Ключевые возможности:

Возможность сделать запись чтобы проанализировать каждое событие, которое произошло после загрузки страницы или взаимодействия с пользователем.
Возможность просмотреть FPS, загрузку CPU и сетевые запросы в области Overview.
Щелкните по событию в диаграмме, чтобы посмотреть детали об этом.
Возможность изменить масштаб таймлайн, чтобы сделать анализ проще.

Панель Memory и JavaScript Profiler

Содержит несколько различных профайлеров для отслеживания нагрузки которую оказывает выполнение кода на систему:

JavaScript CPU Profiler (был вынесен в отдельную панель JavaScript Profiler ) — позволяет узнать сколько процессорного времени занимает выполнение различных частей вашего JS кода.
Take Heap Snapshot — показывает распределение памяти среди JS объектов и связанные с ним элементы DOM.

Record Allocation Timeline — записывает и отображает распределение памяти между переменными в коде. Эффективен для устранения утечек памяти.

Record Allocation Profile — записывает и отображает распределение памяти на выполнение отдельных JS функций.

Ключевые возможности:

Панель Application

Вкладка для инспектирования и очистки всех загруженных ресурсов, включая IndexedDB или Web SQL базы данных, local и session storage, куков, кэша приложения, изображений, шрифтов и таблиц стилей.

Ключевые возможности:

Быстрая очистка хранилищ и кэша.
Инспектирование и управление хранилищами, базами данных и кэшем.
Инспектирование и удаление файлов cookie.

Панель Security

На вкладке можно ознакомится с протоколом безопасности при его наличии и просмотреть данные о сертификате безопасности, если он есть.

Инструмент используется для отладки проблем смешанного контента, проблем сертификатов и прочее.

Ключевые возможности:

Окно Security Overview быстро подскажет безопасна ли текущая страница или нет.
Возможность просмотреть отдельные источники, чтобы просмотреть соединение и детали сертификата (для безопасных источников) или узнать, какие запросы не защищены (для небезопасных источников).

Панель Audits

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

Анализируются такие параметры как: кэширование ресурсов, gzip сжатие, наличие неиспользуемых частей JS кода и CSS правил и много других параметров. Далее пользователю выводится сгруппированных список рекомендаций за счет выполнения которых можно существенно оптимизировать скорость загрузки и отзывчивости страницы.

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

Недавно я решил протестировать одно приложение и ужаснулся результатам. Сразу по нескольким разделам оценка находилась в красной зоне. Я принялся изучать что же с моим приложением не то. И нашел в результатах анализа большой список очень полезных рекомендаций, выполнил их и получил 500 баллов. В результате приложение стало запускаться значительно быстрее, а я пересмотрел несколько концепций относительно метода построения приложений. А в этой статье я хочу поделиться самыми интересными решениями к которым я пришел.

Если у вас нету возможности установить хром, то можно поставить lighthouse из npm и работать с ним из консоли.

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

Performance

Выбор сервера

Это самый банальный совет, но именно это является фундаментом для всей производительности. К счастью найти хорошее решение просто, это любой ЦОД уровня Tier 3 или Tier 4. Сам этот статус ничего не говорит о скорости, он говорит о том что владельцы позаботились о качестве.

Инициализация приложения

Когда то в браузерах был только html. Потом появился javascript и бизнес логика. Сегодня логики на клиенте стало настолько много, что html с ней не справляется и стал вовсе не нужен. Но, т.к. браузер не может начать загружаться из JavaScript файла, нам придется разместить небольшой кусок html для запуска нашего приложения.

В идеале он должен выглядеть примерно так:

В нем не должно быть никакого контента, только код необходимый для инициализации приложения, который подгрузит уже само приложение и контент.

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

Использовать сплеш скрин

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

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

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

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

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

Инициализация приложения

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

Из чего он состоит:

Подключение PWA — рассмотрим в соответствующем разделе ниже. Подключать его надо как можно раньше, потому что возможно в pwa уже будет все необходимое для работы сайта и запросов на сервер больше не будет.
Подключение стилей — по мере необходимости подключаем стили. В идеале этого кода вообще не должно быть и стили должны подключать ваши компоненты по мере необходимости.
Подключение скриптов — подключаем программу. Состоять он должен всего из двух этих скриптов. Все остальные скрипты (карты, аналитика, библиотеки) не влияющие на отображение первого экрана (не всей страницы) загружаются уже после отрисовки первого экрана приложения. Аналитику уже должен подгрузить компонент аналитики после загрузки программы. Качество аналитики от этого не пострадает, а системы аналитики поддерживают загрузку после загрузки программы. Карты должны погрузиться только после того как пользователь до них доскролит и они попадут в экран. Со сторонними библиотеками, необходимых для работы конкретных компонентов, аналогично.

Ленивая подгрузка и отрисовка

Очень важным параметром является то насколько быстро отрисуется первый экран и пользователь сможет начать взаимодействовать с этой страницей. И здесь стоит использовать следующие оптимизации:

1. Ленивая отрисовка. Необходимо отрисовывать только ту часть страницы куда смотрит пользователь, а отрисовку тяжелых компонентов или картинок уже делать когда пользователь к ним доскролился.

Хорошим решением тут может служить компоненты lazy-block и lazy-img:

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

Но не стоит забывать и о гугл боте, который видит spa, но не скролит всю страницу. Поэтому если вы не позаботитесь, то он не увидит ваш контент.

2. Если какой либо из компонентов использует внешнюю зависимость, он должен будет загрузить ее сам по мере необходимости. Например это может быть блок с картами, графиками или 3D графикой. А с недавних пор в JS появился способ сделать это очень просто:

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

Минимизация бандла

И… да, вы подумали не о том, речь не о минификации в Terser (UglifyJS), а о том что бы конкретному браузеру отдавать только то что ему нужно.

Дело в том что браузеры постоянно развиваются, у них появляется новое API, разработчики начинают использовать его, а для совместимости со старыми браузерами подключают полифиллы и транспиллеры. В итоге образуется проблема что пользователи с новейшими браузерами, которых около 80%, получают код который предназначен для пользователей IE11, транспиленный и с полифилами.

Проблема этого кода в том что он содержит много лишнего текста, а производительность его в 3 раза меньше (по моим субъективным оценкам) чем оригинала. Гораздо логичнее делать несколько бандлов для разных версий браузеров. Бандл с ES2017 кодом для Chrome 73 с минимумом полифилов, бандл с ES5 для IE11 с максимум полифилов и т.д.

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

В итоге пользователи современных браузеров получат максимально легкую и производительную программу, а пользователи IE11 получат то что они заслужили.

Очень интересная библиотека для сокращения бандла на 50%, к сожалению с непредсказуемым результатом.

Минимизация кода

Очень популярна проблема когда разработчики начинают подключать всё на что упадет их взгляд. В результате иногда можно наблюдать программы которые весят по 5-15 мб и даже больше. Поэтому к выбору библиотек надо подходить с умом.

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

Избегайте использования тяжелых библиотек. Вместо использование таких библиотек как jquery, lodash, moment, rxjs и любая другая в минифицированном размере >100кб, постарайтесь поглубже изучить алгоритмы и найти решение на нативном JS. Как правило на нативном скрипте можно написать проще, а вы избавляетесь от лишней тяжелой зависимости.

Минификация картинок

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

По этому здесь я приведу очень простой рецепт решения всех проблем с картинками. В основе этого рецепта лежит инструмент обработки и конвертирования изображений Sharp. Выделяется он очень продуманным пайплайном, за счет которого скорость обработки изображений в 30-40 раз выше чем у аналогов. А само время сборки сотен изображений из огромных исходников в разные размеры и форматы сопоставимы со скоростью сборки современного фронтенда.

Для использования Sharp необходимо написать скрипт, я использую его в связке с glob для рекурсивного поиска изображений в директории с исходными картинками, а сам скрипт прячу за утилитой запуск задач gulp. Пример моей сборки:

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

То теперь надо писать так:

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

А с учетом того что теперь можно генерировать картинки на этапе сборки приложения, получается на все картинки будет одинаковый набор форматов и разрешений, а значит мы можете унифицировать эту логику и скрыть за каким нибудь компонентом, например тем же <lazy-img src="https://habr.com/ru/post/440950/img/sample.jpg"> .

Минификация стилей

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

Минимизируйте название классов. Огромная длинна вложенных или БЭМ селекторов в стилях плохо влияют на размер вашего приложения. В настоящее время полно инструментов которые на генерируют стили с уникальными селекторами: JSS, Styled Components, CSS Modules.

Минификация дома

Все мы знакомы с html, но мало кто задумывался что это всего лишь простая абстракция над деревом очень сложных объектов. Цепочка наследования для элемента div выглядит следующим образом:

HTMLDivElement -> HTMLElement -> Element -> Node -> EventTarget

И у каждого объекта в этой цепочки от 10 до 100 свойств и методов которые потребляют много памяти. И все это богатство должен учитывать движок DOM для построения картинки которую мы видим. Поэтому старайтесь не использовать лишние элементы в доме.

Минифицируйте HTML. Удаляйте все что вы используете для форматирования html на этапе написания. Дело в том что пробелы которые используются при написании кода, в браузере также превращаются в объекты дома:

TextNode -> Node -> EventTarget

Удаляйте комментарии. Они также являются элементом дома и потребляют много ресурсов:

Comment -> CharacterData -> Node -> EventTarget

Хорошей практикой может служить использование шаблонизаторов на jsx. Дело в том что при компиляции он превращается в нативный js код, который не генерирует пробелов, комментариев и никогда не ошибается в открытии и закрытии тэгов.

Как видим используется вложенность из десяти элементов, но эта вложенность не выполняет никакой работы. Первый фрагмент всего лишь выводит текст «Напишите комментарий. » и иконки, второй «Что у вас нового?». В результате такого не рационального использования DOM вся производительность шаблонизатора React просто сводится на нет, и сайт становится одним из самых медленных что я знаю.

Progressive Web App

Файл манифеста

PWA позволяет пользоваться вашим веб приложение как нативным приложением. При включении поддержки на сайте в меню браузера появляется кнопка инсталляции вашего сайта на устройство (Windows, Android, iOS), после чего оно начинает вести себя как нативное и работать в режиме оффлайн, и всё это в обход магазинов приложений.

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

Сервис воркер

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

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

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

Accessibility

Корректность атрибутов для людей с особыми потребностями

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

Используйте достаточно контрастные цвета. По статистике Минздрава 20% людей имеют проблемы со зрением. А плохой контраст сайтов только усложняет им жизнь, а здоровым людям увеличивает утомляемость.
Расставте tabindex. Позвольте пользоваться сайтом без мышки и сенсорных устройств. Грамотное расположением переходов с помощью клавиатуры сильно упрощает процесс заполнения форм.
Атрибут aria-label на ссылках. Позволяет экранным дикторам зачитывать текст внутри атрибута.
Атрибут alt на картинках. Аналогично предыдущему. Кроме того отобразит текст в случае невозможности загрузки картинки.
Язык документа. Пометьте тег html атрибутом с языком lang=«код языка». Это поможет вспомогательным инструментам правильно настроиться на работу.

Best Practices

Отделите фронтенд приложение от серверного приложения

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

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

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

Создайте мета теги в html и используйте семантическую разметку

Конец

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

В этой статье не описывается как с оптимизировать админки, формы и прочий энтерпрайз, но об этом будет вторая часть.

Что такое Google Lighthouse?

Как использовать Google Lighthouse

Далее перейдите на определенную страницу в вашем браузере и нажмите кнопку «Generate Report» в расширении Lighthouse.

Lighthouse расскажет вам, насколько ваш веб-сайт соответствует стандартам Google. В отчете будут объяснены сильные и слабые стороны вашего сайта, а также предложены способы повысить его оценку.

Кроме того, вы можете запустить Lighthouse с помощью Node CLI. Для этого требуется Node 6 или новее, и его можно установить с помощью следующей команды:

Google Lighthouse: краткий обзор

Аудит веб-страницы с Lighthouse очень прост, если вы знакомы с Chrome DevTools. Перейдите на страницу с Chrome, откройте DevTools (Ctrl + Shift + I или ⌥ + ⌘ + i в зависимости от вашей системы), а затем перейдите в раздел Audits (Аудиты).

Перед запуском аудита с помощью кнопки «Run audit», вы можете настроить уровень аудита в соответствии с вашими интересами (Производительность (Performance), SEO, Доступность (Accessibility) и т. д.).

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

Когда Lighthouse завершит оценку вашей страницы, вы получите аудиторский отчет, который начинается с нескольких баллов (столько баллов, сколько категорий выбрано при настройке аудита).

Показатель эффективности (Performance Score) рассчитывается на основе результатов теста скорости, сравнивая скорость вашего сайта с другими. Получение 100 баллов означает, что протестированная веб-страница работает быстрее, чем 98% или более веб-страниц. Оценка 50 означает, что страница работает быстрее, чем 75% Интернета (источник).

Когда вместо оценки отображается знак вопроса, это значит что некоторые запущенные тесты не были проведены должным образом и помечены как «Ошибка!».

После scores overview вы найдете результаты по 6 метрикам:

First ContentFul Paint: измеряет время за которое, первый текст/ изображение отобразилось на экране.
First Meaningful Paint: измеряет время за которое, отобразился основной контент страницы.
Speed Index: показывает, насколько быстро содержимое страницы отображается визуально.
First CPU Idle: измеряет время, когда основной поток страницы стал ожидать обработку ввода в первый раз.
Time to Interactive: показывает время, когда страница стала полностью интерактивной.
Estimated Input Latency: является оценкой того, как долго ваше приложение реагирует на ввод пользователя в миллисекундах в течение самого загруженного 5-секундного окна загрузки страницы. Если ваша задержка превышает 50 мс, пользователи могут воспринимать ваше приложение как тормозящее.

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

После обзора производительности вам будут показаны лучшие практики для каждой категории. Большинство советов являются техническими и не очень подробно изложены в самом отчете, но вы возможно найдете полезную информацию по ссылкам «Learn more».

Обратите внимание, что некоторые рекомендации дублируются в нескольких категориях, например, элемент управления, относящийся к смешанному контенту, присутствует в категории «Progressive Web App», а также в «Best Practices».

С большой властью приходит большая ответственность

Lighthouse, безусловно, является отличным инструментом, который может легко создавать как метрики производительности, так и обеспечить контроль качества, поскольку он доступен непосредственно в Chrome. Это основное преимущество также может быть вашим злейшим врагом! Выполняя тест производительности с вашего настольного компьютера, вы полагаетесь на множество параметров из вашей локальной среды, и иногда может быть трудно получить достаточно стабильные результаты:

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

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

PERFORMANCE SCORE	FIRST CONTENTFUL PAINT	SPEED INDEX	TIME TO INTERACTIVE
85	1690	1730	5380

Те же тесты, но при интернет соединение с добавлением задержки в 500 мс (с помощью команды tc Unix):

PERFORMANCE SCORE	FIRST CONTENTFUL PAINT	SPEED INDEX	TIME TO INTERACTIVE
67	2780	3880	7320

Мы получаем изменение Performance Score на 21%, в то время как Speed Index более чем удвоился во втором тесте. Мы получили эти результаты, используя режим Lantern (эмулированное регулирование Lighthouse), который на самом деле направлен на уменьшение изменчивости локальной сети.

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

При использовании Lighthouse, если вы хотите сравнить несколько отчетов, помните о нестабильности вашего контекста и связанной с этим предвзятости!

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

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

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

Подготовимся

Ваша версия может отличаться от этого руководства, так что некоторые функции могут выглядеть иначе или быть недоступными. У нас с Тони, например, это версия 80.0, а свою вы можете узнать, набрав в адресной строке chrome://version/ . Ничего страшного – просто имейте в виду, что ваш пользовательский интерфейс может отличаться от приведённых снимков. Сама методология давно укоренилась, так что она вряд ли поменятся в один миг.

Рис. 2. Вкладка редактора

Нажмите tony . Появится меню.

Рис. 3. Меню, которое появляется после нажатия tony

Кликните Remix Project . Название проекта сменится на случайно сгенерированное имя. Создалась редактируемая копия кода, В этот код позже мы внесём изменения.

Нажмите Show , а затем – In a New Window . В новой вкладке откроется демо. Эту вкладку мы будем именовать демонстрационной. Загрузка сайта займёт некоторое время – поклонники Тони не зря жаловались.

Рис. 4. Демонстрационная вкладка

Нажмите Ctrl+ Shift+J (Windows, Linux) или Cmd+Option+J (Mac). Вместе с демо откроется Chrome DevTools.

Рис. 5. Демо-страница и открытая панель DevTools

Определим базис

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

Рис. 6. Панель Audits

Выставим настройки для аудита, как на Рис. 6.

Device. Параметр Mobile изменяет описание пользовательского агента, имитируя мобильный экран. Выбор Desktop просто отключает эти настройки.

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

Кликаем Generate report . Через 10–30 секунд на панели Audits появится отчёт о работе сайта.

Рис. 7. Отчёт по результатам аудита сайта

Если в отчёте панели Audits появится ошибка, и в кружке рядом с Performance вы видите вместо числа знак вопроса, запустите демонстрационную вкладку в новом окне в режиме инкогнито. Процессу аудита часто мешают расширения Chrome.

Разбираемся в отчёте

Число в верхней части отчёта – общий показатель эффективности сайта. Для сайта Тони у вас наверняка получилось число 0. По мере внесения улучшений это число должно расти.

Рис. 8. Общий показатель эффективности и раздел Metrics

В разделе Metrics представлены количественные показатели производительности сайта. Каждый параметр отвечает за определённый аспект производительности. Например, First Contentful Paint сообщает, через какое время контент начал отображаться на экране – важный параметр для восприятия пользователем загрузки страницы. Time to Interactive отмечает точку, когда страница стала достаточно готова, чтобы с ней можно было взаимодействовать. Развёрнутое описание каждой метрики можно получить при нажатии переключателя списков.

После метрик идёт лента скриншотов, показывающих как страница выглядела в процессе загрузки.

Рис. 9. Панель скриншотов почти пуста – большую часть времени загрузки на сайте ничего не отображалось

Раздел Opportunities (англ. «возможности») содержит советы о том, как улучшить загрузку сайта и связанный с ней код. Каждый совет можно раскрыть, нажать Learn more и прочитать документацию на web.dev о том, почему это важно.

Рис. 12. Раздел Passed audits

Как ни странно, иногда этот раздел может работать некорректно, так что и эти пункты нужно внимательно рассмотреть. Например, мы скоро увидим, что сайт Тони не сжимает текст ( enable text compression ) и использует слишком большие изображения ( properly size images )

Итак, в разделах Opportunities и Diagnostics отчёта содержатся советы о том, как повысить эффективность страницы. На этом шаге мы реализуем рекомендуемые изменения в кодовой базе, проверяя сайт после каждого изменения.

Сжатие текста

Перед отправкой по сети текстового файла, даже файла с программным кодом, полезно применить процедуру сжатия. Чтобы проверить, работает ли сжатие текстовых ресурсов, перейдём на вкладку Network .

Рис. 15. Внешний вид редактора после вставки

Некоторая время займёт перестройка структуры сайта. Перезагрузите демонстрационную страницу. В столбце Size теперь будут отображаться два различных значения для текстовых ресурсов. Например, bundle.js сжимается до 256 Кб.

Рис. 17. Показатель производительности вырос с 0 до 10 после сжатия

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

Изменение размера изображений

Изменение размера изображений помогает ускорить загрузку сайта за счет уменьшения размера файла изображений. Если ваш пользователь просматривает изображения на экране мобильного устройства шириной 500 пикселей, не имеет смысла отправлять изображение шириной 1500 пикселей.

Вернёмся на вкладку редактора, откроем src/model.js и заменим const dir = 'big' на const dir = 'small' . Этот каталог содержит копии тех же изображений, размер которых был изменен. После обновления страницы повторим процедуру аудита.

Рис. 18. Показатель производительности вырос с 10 до 12 после оптимизации изображений

Похоже, что изменение имеет незначительное влияние на общую производительность. Тем не менее вы сохраняете травфик пользователей. Общий размер старых фотографий составлял около 5,3 Мб, а сейчас всего лишь около 0,18 Мб.

Устранение ресурсов, блокирующих загрузку сайта

Среди главных замечаний в отчете значится Eliminate render-blocking resources (устранить ресурсы, блокирующие рендеринг). Таким ресурсом, могут являться внешние файлы JavaScript и CSS, которые браузер должен загрузить, проанализировать и выполнить, прежде чем отобразить страницу.

Первая задача – найти код, который не нужно выполнять при загрузке страницы. Чтобы посмотреть блокирующие ресурсы, развернём в отчёте аудита указанный совет. Среди ресурсов видим lodah.js и jquery.js .

Рис. 19. Подробная информация о блокирующих ресурсах

Нажмём сочетание клавиш Ctrl+Shift+P (Windows, Linux) или Cmd+Option+P (Mac). В открывшемся меню команд начнём печать слово Coverage и выберем Show Coverage .

Рис. 20. Открытие командного меню для поиска команды

Нажимаем кнопку для перезагрузки страницы. Вкладка Coverage обеспечивает обзор того, как выполняется код в bundle.js , jquery.js и lodash.js во время загрузки страницы. На Рис. 21 показано, что около 74% jQuery и 30% Lodash не используются.

Рис. 21. Отчёт о покрытии (англ. coverage)

Нажмём на строку jquery.js . DevTools откроет файл в панели источников. Если рядом со строкой кода есть зелёная полоска, то эта строка выполнялась. Красная полоска означает, что эти строки не были выполнены и не нужны при загрузке страницы. Если прокрутить код ниже, можно заметить, что некоторые из «исполняемых» строк представляют собой просто комментарии. Прогонка кода через минификатор, удаляющий комментарии – ещё один способ уменьшить размер файла.

Вкладка Coverage помогает анализировать код построчно и отправлять только то, что необходимо для загрузки страницы. Давайте проверим, необходимы ли вообще файлы jquery.js и lodash.js . С помощью Ctrl+Shift+P (Windows, Linux) или Cmd+Option+P (Mac) добавим вкладку Request blocking (Show Request Blocking). На открывшейся панели нажмём кнопку Add pattern . Введём строку /libs/* , чтобы блокировать ресурсы из папки libs .

Рис. 23. Панель Network показывает, что запросы были заблокированы

При этом страница загружается и является интерактивной – похоже, отключенные ресурсы вообще не нужны!

Вкладка Request blocking полезна для имитации поведения страницы, когда какой-либо ресурс недоступен.

Удалим шаблон блокировки из Request blocking . Вернёмся на вкладку редактора и откроем template.html . Удалим строки <script src="https://proglib.io/libs/lodash.js"> и <script src="https://proglib.io/libs/jquery.js"></script> . Перезагрузим страницу и вновь проведём аудит.

Рис. 24. Результаты отчёта после удаления ссылок на ресурсы, блокирующие рендеринг

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

Если вы используете фреймворк, проверьте, есть ли у него production mode. Такой режим позволяет использовать функцию tree shaking, чтобы исключить ненужный код, блокирующий рендеринг.

Минимизируем работу в основном потоке браузера

Среди пунктов, отмеченных в Diagnostics , присутствует совет Minimize main thread work . Основной поток – это то, где браузер выполняет большую часть работы, необходимой для отображения страницы – анализ и выполнение HTML, CSS и JavaScript. Для анализа основного потока используется панель Performance .

Чтобы провести испытания в «полевых условиях», полезно имитировать устройства с медленным интернетом и аппаратными ограничениями. Для этого в настройках панели выставим в выпадающем списке Network Slow 3G, а в списке CPU 6x slowdown. Перезагрузим страницу для профилирования. DevTools отобразит развёртку загрузки страницы во времени – эта визуализация в DevTools носит название trace .

Рис. 25. Панель Performance отслеживает загрузку сайта

В trace показывается активность в хронологическом порядке слева направо. Диаграммы FPS, CPU и NET в верхней части дают обзор соответствующих видов активности. Жёлтые области показывают, когда процессор был полностью занят выполнением скрипта. Изучим внимательнее выделенную область – раскроем раздел Timings :

Рис. 27. Рост производительности при переходе на production mode

Однако что-то до сих пор сильно тормозит загрузку сайта. Вернёмся к разделу Perfromance . Свернём Timings и обратимся к разделу Main (его начало видно на Рис. 25). Здесь расположен хронологический журнал активностей основного потока с указанием причинно-следственных связей: событие Evaluate Script вызвало анонимную функцию, та вызвала _webpack_require__ и т. д. Прокрутим вниз к концу раздела Main .

Рис. 28. App делает множество вызовов к функции Bitcoin

Приложение App многократно вызывает функцию mineBitcoin . Похоже, Тони не так-то прост и использовал устройства поклонников для майнинга криптовалюты.

В нижней части Performance нажмём на вкладку Bottom-Up . В этом разделе отображается информация о выделенном объекте. Например, если мы кликнем на одно из действий mineBitcoin , в разделе Bottom-Up отобразится информация для этого действия.

Рис. 29. Раздел Main и вкладка Bottom-Up в случае выбора Evaluate Script

Столбец Self Time показывает, сколько времени было потрачено непосредственно для каждого блока. Видно, что 87.4% времени уходит на работу с функцией mineBitcoin . Ох уж этот Тони!

Снизим активность JavaScript, удалив вызовы mineBitcoin . Перейдём в редакторе в src/App.jsx и закомментируем вызов this.mineBitcoin(1500) . Проведём заключительный аудит страницы.

Рис. 30. Отчёт после удаления лишних обращений JavaScript

Это последнее изменение вызвало огромный скачок в производительности!

Панель Performance – наиболее распространённый способ понять, какую активность выполняет сайт во время загрузки, и найти способы удалить ненужные действия. Если вы предпочитаете визуальному подходу логирование результатов, изучите User Timing API.

Отдельное спасибо от Тони

Поклонникам Тони нравится, как быстро сайт теперь загружается сайт, и Тони очень благодарен за вашу помощь (функцию mineBitcoin он создал для баловства и уже забыл о ней). Нажмите «Получить подарок» ниже, чтобы получить специальный подарок от Тони.

Читайте также: