Новый Google PageSpeed Insights на движке Lighthouse 6 (beta): проверьте, какие показатели будут у вашего сайта
16 марта в Google Chrome выпустили бета-версию Lighthouse 6. Финальная версия ляжет в основу замеров в новом PageSpeed Insights и консоли разработчика браузера Chrome. Подробности и тест движка внутри.
Привет, Хабр. Я Алексей из Loading.express.
На прошлом саммите разработчиков Chrome Developer Summit рассказали, что к январю 2020 выпустят обновление для PageSpeed Insights.
Как только пришло оповещение, мы развернули beta-релиз Lighthouse 6 на своих серверах и подробно изучили нововведения. Вот основные:
Три новые метрики в новом отчете PageSpeed (lighthouse 6)
TBT — Total Blocking Time. Это время блокировки ввода в миллисекундах, когда посетитель не может ничего делать на сайте. Он загружается. Ждём. Даже если вы попробуете свайпнуть, скролить, кликать — вы получите эффект зависания или движения с прерываниями.
Показатели TBT для главной страницы Habr
Что считается быстрым или медленным:
Что хорошо и плохо:
Значения от 0 до 1. До 0,5 хорошо, ближе к 1 плохо.
Параметр FID убрали из отчета. Его частично взял на себя TBT и отчеты по замерам JS.
Новое устройство для открытия сайта Moto G4
Имитация устройства, на котором Гугл открывал ваш сайт равнялась на экран Nexus 5 из 2013 года. И многие Performance консультанты недоумевали, доколе это будет считаться образцовым устройством. И вот, в 2020 — новое устройство — Moto G4 (emulated) из 2016 года. А это значит, что в среднем по миру, люди обновили устройства, с которых заходят на сайты.
Новые аудиты в Lighthouse 6
JS — теперь, если при загрузке вашего сайта выполняется слишком много джаваскрипта, то GPSI сообщит об этом отдельно.
Accessibility — новые пункты аудита касаются отображения элементов сайта для читалок текстов в аудио формате, для слабовидящих. Есть мнение, что этой разметкой будут пользоваться и голосовые помощники.
Аудит кодировки символов — кодировка должна быть объявлена.
PWA maskable icon audit — аудит, который проверит есть ли векторная иконка для маски. Если нет, то будет рекомендовать сделать векторный формат.
Выводы про новый аудит скорости загрузки сайтов Lighthouse 6
Последний раз такое глобальное обновление у PageSpeed Insights было в ноябре 2018 года. Тогда многие сайты попали в красную зону, потому что до обновления PageSpeed не измерял скорость загрузки сайтов, а показывал рекомендации для оптимизации разных параметров, которые могли влиять на скорость загрузки.
Те, кто пропустил то обновление, до сих пор может заблуждаться и уверять всех, что GPSI не измеряет скорость загрузки сайтов.
С новым Lighthouse 6 замер скорости станет более понятным для разработчиков и владельцев сайтов.
Синтетический мониторинг производительности
Благодаря внедрению клиентского мониторинга производительности, мы с полной уверенностью можем диагностировать проблемные места проекта и составить план для дальнейшей оптимизации.
Однако было бы неплохо иметь инструмент, который еще на этапе разработки позволял бы выявлять возможные регрессы производительности. Именно так родилась идея о создании синтетического мониторинга.
Содержание
Мониторинг
Perfectum Synthetic — это инструмент для измерения синтетических показателей производительности. Рассмотрим основные требования, которые мы предъявляли к будущему мониторингу.
Гибкая конфигурация
С самого начали разработки мы понимали, что вариантов и условий использования мониторинга может быть много, а значит, от проекта потребуется возможность максимальной конфигурации.
Для удобства работа с инструментом мы разработали утилиту Perfectum CLI и добавили файл конфигурации perfectum.json.
Сочетание возможностей утилиты командной строки и файла конфигурации дает существенную гибкость в использовании мониторинга, начиная от определения бюджетов производительности, заканчивая динамической подменой аудируемых страниц.
Сборка и запуск проекта
Для нас было важно, чтобы инструмент, помимо выполнения основных функций, обеспечивал удобную работу с проектом на всех этапах разработки.
Поэтому возможность автоматической сборки и запуска проекта при внесении изменений избавляет от ручных пересборок, что значительно упрощает локальное использование мониторинга.
Возможность аутентификации
Некоторые наши проекты недоступны для публичного использования и требуют предварительной аутентификации. Поэтому такая возможность доступна через указание пути к файлу auth-скрипта, который выполнится непосредственно перед началом мониторинга.
В процессе аутентификации используется Puppeteer, поэтому содержимое скрипта должно соответствовать правилам использования данного инструмента.
Воспроизводимость результатов
Одним из основных требований, которые предъявляются к подобному виду мониторинга, является воспроизводимость и точность результатов.
Для аудита производительности используется Lighthouse, который в условиях изолированной среды показывает стабильные результаты между запусками.
Также наш мониторинг дополнительно определяет медианный результат среди всех запусков аудита, что позволяет получить наиболее стабильный отчет о производительности.
Метрики
Как упоминалось ранее, Perfectum Synthetic использует Lighthouse. Поэтому рассмотрим, как в этом инструменте происходит общая оценка производительности проекта.
Lighthouse использует значения шести метрик. Каждая метрика отражает состояние разных стадий загрузки страницы и имеет собственный вес, который показывает степень влияния метрики на общий результат.
Ниже приведена соответствующая таблица:
| Название метрики | Вес |
|---|---|
| First Contentful Paint (FCP) | 15% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 5% |
| Speed Index (SI) | 15% |
| Time to Interactive (TTI) | 15% |
| Total Blocking Time (TBT) | 25% |
Метрики FCP, LCP и CLS подробно рассматривались в статье о клиентском мониторинге производительности, поэтому в этой мы рассмотрим остальные — SI, TTI и TBT.
Speed Index
Speed Index (SI) показывает, насколько быстро отображается содержимое страницы в процессе загрузки приложения.
Принцип работы
В основе работы SI лежит понятие визуального завершения (Visually Complete, VC):
Рассмотрим два возможных варианта загрузки страницы:
Оба варианта начинают загрузку и становятся визуально завершенными (VC) за одно и тоже время (5 секунд). Но очевидно, что вариант А гораздо предпочтительнее с точки зрения пользователя. И чтобы увидеть количественную разницу между подобными вариантами загрузки, используется показатель SI.
SI оценивает процент визуального завершения в разные моменты времени:
Стандартный механизм определения VC, используемый, к примеру, в WebPageTest, основывается на анализе оттенков цветовой палитры страницы. Каждые 100 мс происходит сравнение количества оттенков между двумя соседними фреймами:
Однако следует отметить, что в Lighthouse применяется другая модель определения визуальной завершенности. Вместо сравнения количества оттенков цветовой палитры используется индекс структурного сходства (SSIM), который основывается на оценке воспринимаемого качества изображения, включая информацию об изменениях яркости и контраста.
Разобравшись с тем, как происходит расчет показателя VC, представим графически рассмотренные варианты загрузки страницы:
Графики отображают отношение времени загрузки и процента визуальной завершенности.
Область графика под кривой можно представить как отрендеренную часть страницы в определенный момент времени:
Для вычисления SI мы могли бы использовать площадь данной области, однако есть важный нюанс. Напомню, что 5 секунд загрузки которыми мы оперируем, являются временем визуальной завершенности (VC), но они не являются показателем полной загрузки страницы. Это значит, что область под кривой будет увеличиваться пропорционально времени загрузки, при этом увеличивая результат показателя SI.
В то же время использование области графика над кривой будет лишено подобных недостатков, поскольку она всегда ограничена наступлением события VC:
Именно поэтому алгоритм работы SI использует данную область при вычислении результата.
Разумеется, для нахождения площади указанной области (плоской криволинейной фигуры) формула расчета использует определенный интеграл и выглядит следующим образом:
Поэтому чем меньше площадь данной области, а соответственно, и значение SI — тем лучше:
Оценка результатов
При оценке результатов показателя рекомендуется использовать следующие градации:
Способы оптимизации
Как правило, любые оптимизации, направленные на увеличение скорости загрузки страницы, положительно скажутся на показателе SI.
Список данных оптимизаций я приводил в статье о клиентском мониторинге производительности.
Дополнительной рекомендацией будет проверка на отсутствие явления FOIT (Flash Of Invisible Text).
Time To Interactive
Time To Interactive (TTI) измеряет время с момента начала загрузки страницы до момента стабильного реагирования на ввод пользователя.
Принцип работы
В основе работы TTI лежат три понятия: время первой отрисовки контента (First Contentful Paint, FCP), продолжительные задачи (Long Tasks) и временной интервал с отсутствием продолжительных задач и сетевых запросов (Quiet Window).
Для начала посмотрим на временную шкалу, представляющую типичную загрузку страницы:
Кроме выполнения сетевых запросов на ней также отмечено событие FCP и продолжительные задачи основного потока рассматривавшиеся в предыдущей статье.
Для полноты картины осталось определить, что такое Quiet Window.
Quiet Window — это временной интервал (5 секунд), на протяжении которого отсутствуют продолжительные задачи и выполняется не более двух сетевых запросов (GET). Отметим его на временной шкале загрузки:
Значением TTI будет время окончания последней продолжительной задачи перед наступлением Quiet Window.
При отсутствии продолжительных задач значение TTI будет равняться значению FCP.
Оценка результатов
При оценке результатов показателя рекомендуется использовать следующие градации:
Способы оптимизации
Основным улучшением, которое может оказать влияние на показатель TTI, является уменьшение количества JS-ресурсов на странице. Соответствующие рекомендации я приводил в предыдущей статье.
Дополнительные улучшения, направленные на увеличение скорости загрузки страницы, такие как минификация, компрессия, предварительные соединения и прелоадинг ресурсов, также положительно скажутся на значении показателя.
Total Blocking Time
Total Blocking Time (TBT) измеряет общее количество времени, в течение которого страница была недоступна для пользовательского ввода.
Принцип работы
Рассмотрим уже знакомую нам временную шкалу загрузки страницы:
Алгоритм работы TBT использует информацию о задачах основного потока, которые выполнялись между событиями FCP и TTI.
Поэтому оставим на шкале только нужную нам информацию:
и обозначим время выполнения каждой задачи:
Показатель TBT оперирует понятием времени блокировки пользовательского ввода.
Из спецификации продолжительных задач и модели производительности RAIL, мы знаем, что любая задача, выполняющаяся больше 50 мс, будет заметным образом блокировать взаимодействие со страницей. Поэтому время, оставшееся после первых 50 мс выполнения задачи, будет являться временем блокировки пользовательского ввода.
Отметим данное время на шкале загрузки:
Значением TBT будет сумма всех периодов блокировки, которая в нашем случае составляет 310 мс (200 + 70 + 40).
TBT является отличным дополнением к показателю TTI. Поскольку последний, в силу эвристики алгоритма (Quiet Window), не способен отобразить разницу между следующими сценариями.
Представим, что на протяжении 10 секунд загрузки приложения в основном потоке браузера возникли три продолжительные задачи длительностью 51 мс:
При таком варианте загрузки значение TTI составит около 9 секунд, а TBT — 3 миллисекунды.
Теперь рассмотрим второй вариант загрузки, который вместо трех продолжительных задач, будет иметь одну длительностью 8 секунд:
При таком сценарии значение TTI будет тем же, однако значение TBT заметно увеличится и составит 7950 миллисекунд.
Оба варианта загрузки имеют одинаковое значение TTI, но с точки зрения пользователя, это абсолютно разные сценарии взаимодействия со страницей. И показатель TBT способен такую разницу отобразить.
Оценка результатов
При оценке результатов показателя рекомендуется использовать следующие градации:
Способы оптимизации
Рекомендации по оптимизации TBT те же, что и для показателя First Input Delay.
Анализ данных
Результат работы синтетического мониторинга отображается в виде двух отчетов Lighthouse. Один отчет генерируется для десктопной версии страницы, другой — для мобильной:
Определить собственные характеристики среды можно через настройки аудита.
Для мониторинга сразу нескольких страниц приложения достаточно перечислить необходимые адреса в файле конфигурации.
Для предварительной аутентификации, необходимо указать путь к файлу auth-скрипта.
Бюджеты производительности
О том, что такое бюджеты производительности, я рассказывал в предыдущей статье.
Для работы с бюджетами в Perfectum Synthetic используется соответствующий раздел конфигурации мониторинга. Можно установить бюджет как для временных, так и для ресурсных показателей проекта.
Для отдельных страниц приложения могут устанавливаться собственные бюджеты. А каждый показатель может иметь бюджет как для десктопной, так и для мобильной версии страницы.
Вся информация о превышении бюджетов будет отображаться в соответствующем разделе отчета производительности:
Заключение
Хорошая производительность проекта не является приложением к экспертизе отдельного человека или целой команды — это всегда результат целенаправленной работы.
И если вы заботитесь не только о скорости разработки, но и о качестве продукта, то внедрение подобных инструментов этому только поспособствует.
Общее время блокировки
Что делаете вы, когда переходите на сайт и он, по вашему мнению, долго загружается. Уходите с него и идёте на другую, более быструю страницу. Пользователи вашего сайта поступают точно также. Поэтому, чем быстрее вы дадите им возможность эффективно взаимодействовать с ресурсом, тем больше выгод это принесёт в результате.
Многие думают, что могут самостоятельно провести все необходимые настройки. Но, оптимизация сайта веб-разработчиками потому и выполняется, что любые действия человеком, который не досконально разбирается в JavaScript, построении DOM, CSS и другой внутренней начинке, в лучшем случае не принесут результата. В худшем — придётся проводить «реанимационные мероприятия» и буквально переделывать всё заново. Профессиональная настройка сайта позволяет сделать его действительно быстрым и функциональным.
Одним из показателей, которые можно отследить в аудите Lighthouse — Общее время блокировки. В отчёте он располагается в разделе «Производительность». И каждый из показателей отображает отдельный аспект скорости загрузки страницы. Главное — не получить результаты с помощью проведения тестирования. Первоочередная задача — провести анализ, выявить закономерности и на их основании провести оптимизацию сайта по всем параметрам.
Что такое общее время блокировки
Общее время блокировки (TBT) — это метрика, основанная на времени, которая описывает активность основного потока JavaScript. Эти данные необходимы для понимания того, как долго страница не может ответить на ввод пользователя. ТВТ является более показательным нежели Time to Interactive на который могут оказывать влияние различные процессы в JavaScript.
Другими словами, показатель общего времени блокировки измеряет общее количество времени между первой содержательной краской (FCP) и временем до интерактивности (TTI). В данный период основной поток блокируется, предотвращая реакцию ввода и не реагирует на действия пользователя, такие как щелчки мыши, нажатия на экран или нажатия клавиш клавиатуры.
Вполне логично, что чем дольше пользователь не имеет возможности осуществлять взаимодействие со страницей, тем меньше ему это нравится. Необходимо определить факторы, которые кроются внутри скриптов и кодов, оказывая негативное воздействие. Но прежде чем их исправить, требуется точно знать с чем именно придётся работать.
Как рассчитывается общее время блокировки
Общее время блокировки рассчитывается путём сложения всех блокирующих частей длинных задач, которые находятся в интервалемежду First Contentful Paint и Time to Interactive. Если на выполнение задачи требуется более 50 миллисекунд, то она будет длинной. И не стоит обращать внимание на тот факт, что зачастую рекомендованным временем называют 100 миллисекунд. Это не совсем достоверная информация, так как 100 миллисекунд включают в себя общее время. Которое требуется браузеру для выполнения полностью всех работ.
Время, которое начинается после вожделенных 50 миллисекунд и является частью блокировки. К примеру, если Lighthouse обнаруживает задачу длительностью 70 миллисекунд, то её блокирующая часть будет составлять 20 миллисекунд.
Если говорить простыми словами, то заблокированным основной поток называется потому, что браузер не может прервать текущую задачу, которая ему уже была поставлен и переключиться на другую. Когда пользователь взаимодействует со страницей и хочет, чтобы она выполнила иное действие в середине длинной задачи (к примеру, переход к товару или услуге), то браузер должен дождаться завершения текущей задачи. И только после этого он сможет ответить. Если задание достаточно длинное, превышающее 50 миллисекунд, то в большинстве случаев пользователь заметит задержку и воспримет страницу как подвисающую или дерганную.
Рассмотрим на примере. Предположим, что в процессе загрузки данных, основной поток должен выполнить 5 задач. На работу с каждой из них, браузеру требуется своё время.
• Задача 1 — 250 миллисекунд
• Задача 2 — 90 миллисекунд
• Задача 3 — 35 миллисекунд
• Задача 4 — 30 миллисекунд
• Задача 5 — 155 миллисекунд
Таким образом, мы получаем общее время работы затраченное в основном потоке, равное 560 миллисекунд. Но общим временем блокировки будут являться 345 миллисекунд — превышение лимита в первой, второй и пятой задачах.
Почему ТВТ эффективнее ТТI
Говорить о том, что Total Blocking Time эффективнее Time to Interactive — не совсем корректно. TBT является отличным сопутствующим показателем для TTI, поскольку помогает количественно оценить степень неинтерактивности страницы до того момента, когда она станет надежно интерактивной.
TTI считает страницу «надежно интерактивной», если в основном потоке не было долгих задач в течении минимум 5 секунд кряду. Это означает, что три задачи продолжительностью 51 мс, распределенные в течение 10 секунд, TTI может пропустить. Или наоборот, посчитать превышением 10секундную задачу в рамках различных сценариев. При этом, для пользователя это будет иметь существенную разницу в восприятии.
Как улучшить показатель TBT
Чтобы сократить показатель ТВТ, необходимо провести детальный анализ всех компонентов и выявить, где кроются длинные задачи, которые превышают рекомендованные 50 миллисекунд. Среди наиболее частых причин следующие:
• Ненужная загрузка, анализ или выполнение JavaScript. Это происходит когда основной поток выполняет работу, которая на самом деле не нужна для загрузки страницы. Сокращение полезной нагрузки JavaScript с помощью разделения кода, удаления неиспользуемого кода или эффективной загрузки стороннего JavaScript должно улучшить ваш показатель TBT.
• Неэффективные операторы JavaScript. Например, после анализа вашего кода можете увидеть вызов document.querySelectorAll(‘a’), который возвращает 2000 узлов. В данном случае требуется провести рефакторинг кода для использования более конкретного селектора, который возвращает только 10 узлов и это также улучшит показатель TBT.
Приведённые примеры — наиболее часто встречающиеся ошибки, но далеко не все. В процессе оптимизации сайта, наша команда зачастую встречает ошибки там, где их не может быть по определению. Зачастую это связанно с тем, что для наполнения сайта он отдаётся удалённым маркетологам, копирайтерам или специалистам по продвижению, веб-разработчикам, которые не особо разбираясь в структуре, случайно влезают в коды. Поэтому, если уж вы передаёте «ключи» от сайта — убедитесь в квалификации компании или человека. Ключи от квартиры вы же не отдадите первому встречному.
Lighthouse. Руководство по оптимизации сайтов для начинающих
Быстрые сайты любят и пользователи, и поисковики.
С первыми всё просто: если страница долго грузится, пользователь её закроет и перейдёт на другой сайт. С поисковиками похожая история: скорость загрузки влияет на ранжирование сайта в поисковой выдаче.
Проверить производительность сайта можно с помощью разных инструментов. Один из наиболее известных — Lighthouse от компании Google. Он не только тестирует сайт и показывает оценку производительности, но и даёт конкретные рекомендации: что можно улучшить, чтобы сделать сайт быстрее.
Давайте разберём, как с помощью Lighthouse проверить качество сайта и повысить его производительность. Мы не будем углубляться в алгоритмы работы инструмента и принципы подсчёта внутренних метрик: начинающим веб-разработчикам это и не нужно. Однако знать, как работает инструмент, и уметь использовать его в своих проектах — очень важный навык.
Как запустить Lighthouse
Запустить инструмент можно тремя способами:
Через расширение для браузера Chrome или Firefox. Установите расширение, затем откройте свой сайт и запустите проверку с помощью кнопки Generate report.
Пример запуска Lighthouse из браузера Firefox
С помощью инструментов разработчика — Chrome DevTools. Чтобы запустить проверку, откройте инструменты разработчика, переключитесь на вкладку Lighthouse и нажмите на кнопку Generate report.
Мы разберем основы работы с Lighthouse на примере Chrome DevTools. Этого вполне достаточно, чтобы понять возможности инструмента. Для продвинутого использования можно установить npm-пакет и работать с Lighthouse через консоль. Этот способ позволяет более гибко настраивать инструмент и запускать его в автоматическом режиме.
Какие параметры оценивает Lighthouse
Lighthouse анализирует четыре показателя: производительность, доступность, SEO и лучшие практики. Для прогрессивных веб-приложений добавляется пятый параметр — PWA.
Performance — производительность. Анализирует скорость загрузки сайта. На эту оценку влияет время блокировки, отрисовки стилей, загрузки интерактивных элементов, шрифтов и контента.
Progressive Web App — Прогрессивные web-приложения. Проверяет, регистрирует ли сайт Service Workers, работает ли офлайн, возвращает ошибку 200.
Best Practices — лучшие практики. Проверяет безопасность сайта и использование современных стандартов веб-разработки. Оценка зависит от того, используется ли на сайте HTTPS, устаревшие API, правильная кодировка и другие параметры.
Accessibility — доступность. Проверяет, могут ли все пользователи получать доступ к контенту и эффективно перемещаться по сайту. Эта оценка зависит от понятности и воспринимаемости контента, возможности управлять интерфейсом и передвигаться по содержимому без помощи мыши.
SEO — оценивает соответствие страницы советам Google по поисковой оптимизации. Здесь проверяется использование метатегов, доступ к индексации и переобходу роботами, наличие атрибутов alt у изображений, адаптированность к мобильным экранам и другие характеристики.
Каждый параметр оценивается по 100-балльной шкале: чем выше, тем лучше. У каждой группы оценок также есть свой цвет. Зелёный выставляется при 90-100 баллах, он показывает, что с сайтом всё хорошо. Оранжевый можно получить при 50-89 баллах. То есть с сайтом всё хорошо, но можно сделать ещё лучше. Если оценка ниже 49 баллов, она становится красной. Это означает, что над производительностью стоит поработать.
Большой плюс Lighthouse в том, что проверять качество сайта можно как на десктопной, так и на мобильной версии.
Оценки при этом будут отличаться. Порой они различаются и при запуске нескольких тестов для одной версии сайта. В этом случае колебания возможны при:
использовании на сайте анимаций, которые отображаются рандомным образом;
использовании расширений для браузера;
запуске антивирусных программ;
использовании устройств с разной производительностью.
Чтобы оценка была максимально приближена к реальной, рекомендуется запускать проверку в режиме инкогнито. Тестируйте сайт при стабильном интернет-соединении и отключите программы, которые могут повлиять на результаты.
Результаты проверки десктопной версии сайта
Как улучшить производительность сайта с помощью Lighthouse
Lighthouse не только показывает оценку по каждому из четырёх критериев, но и даёт конкретные рекомендации: что можно улучшить.
Например, оценка производительности складывается из шести метрик:
First Contentful Paint — измеряет время, которое понадобится браузеру для отображения первой части содержимого DOM.
Speed Index — проверяет скорость визуального отображения контента во время загрузки страницы.
Largest Contentful Paint — измеряет время загрузки самого большого элемента в области просмотра.
Time to Interactive — проверяет, за какое время страница станет полностью интерактивной.
Total Blocking Time — смотрит, в течение какого времени происходит блокировка страницы в ответ на действия пользователя: клики мышью или нажатия клавиш.
Cumulative Layout Shift — проверяет визуальную стабильность: смещение макета из-за асинхронной загрузки ресурсов.
Показатели метрик — на этом сайте всё хорошо
Ниже под метриками Lighthouse описывает возможности и предложения, которые помогут улучшить показатели.
Давайте разберём, как можно повысить оценки Lighthouse на конкретном примере. Для этого возьмём стандартный сайт, размещённый на бесплатном хостинге, и проверим его производительность. Тестировать будем мобильную версию, так как Google преимущественно использует мобильную версию контента для индексации и ранжирования.
Как видно на скриншоте, у сайта средние показатели производительности: 69 баллов из 100. Это неплохо, но давайте их улучшим. Для этого используем рекомендации, которые даёт Lighthouse. Каждую из них можно раскрыть и посмотреть подробнее, что предлагается изменить:
Если такого описания недостаточно и вы всё равно не понимаете, что нужно делать — нажимайте на ссылку Learn more. В открывшемся окне появится более подробная информация и руководство для разработчиков. Вся информация на английском языке, но даже если вы его не знаете, Google Переводчик поможет вам разобраться.
В нашем случае Lighthouse предлагает использовать современные форматы изображений: WebP и AVIF, так как они весят меньше, чем PNG и JPEG. Мы также можем уменьшить размер изображения с 567 Кб до 500 Кб. На первый взгляд может показаться, что это мелочи. Но если мы оптимизируем изображения на сайте, то браузерам понадобится меньше времени на их загрузку.
Также важно помнить про блокирующие рендеринг ресурсы, такие как стили и скрипты. Lighthouse предупреждает нас о том, что мы можем уменьшить их влияние на скорость, если минифицируем код или встроим критические ресурсы инлайн.
Если соблюдать хотя бы эти рекомендации, мы повысим оценку Lighthouse. Пусть не до 100 баллов, но это уже будет значительный вклад в производительность сайта.
Среди разработчиков нет единого мнения о том, когда лучше проверять производительность сайта. Кто-то этим занимается в процессе разработки, кто-то — в самом конце. Неважно, какой способ выберете вы. Главное не забывайте тестировать свой продукт и работать над его качеством.
Базовые рекомендации для повышения производительности:
Подключайте к документу минифицированные стили и скрипты.
Подумайте, что можно сделать с неиспользуемым кодом. Возможно, его стоит переписать или удалить.
Оптимизируйте изображения. Используйте для этого специальные программы или пакеты npm.
Используйте современные форматы графики, собирайте SVG в спрайты.
По возможности уменьшайте количество подключенных ресурсов;
Подсказывайте браузеру, какие ресурсы самые важные: включайте предзагрузку или наоборот — ленивую загрузку.
Можно ли получить 100 баллов в Lighthouse?
Максимальная оценка вполне достижима. В сети есть проект Зака Лезермана — рейтинг сайтов с максимальными баллами Lighthouse. На момент подготовки этой статьи в нем было 133 ресурса, набравших сто баллов по каждому из четырёх критериев.
Нужно ли вам добиваться таких показателей — решайте сами. Но помните: главное не сама оценка. Главное — сделать сайт достаточно быстрым, безопасным и удобным для пользователей.
Какие еще есть инструменты для проверки производительности?
Lighthouse далеко не единственный инструмент для оптимизации скорости сайтов. Есть и другие, не менее популярные сервисы. Например, WebPageTest, GTmetrix и Pingdom Tools. Или даже PageSpeed Insights, который использует для проверки алгоритмы Lighthouse, но работает только с сайтами, размещенными в Интернете. Протестировать сайты на локальном сервере с его помощью не получится.
У каждого из таких инструментов есть свои особенности. Например, GTmetrix и Pingdom Tools дают более развёрнутые результаты проверки.
Так выглядят оценки и результаты проверки в WebPageTest
Они также показывают последовательность загрузки ресурсов и учитывают во время проверки местонахождение сервера — параметр, который тоже может влиять на производительность. А в GTmertix можно не только получить результаты тестирования, но и отслеживать их в дальнейшей работе.
Если по какой-то причине вам не подходит Lighthouse, можете остановиться на любом другом инструменте. Ведь главный принцип получения высокой оценки в любом из сервисов — это хороший, качественный код. А научиться его писать вы можете на профессиональных курсах «HTML и CSS. Профессиональная вёрстка сайтов» и «HTML и CSS. Адаптивная вёрстка и автоматизация».