Google хочет, чтобы у людей был хороший опыт работы в Интернете, поэтому он ранжирует быстрые сайты выше в результатах поиска. Конечно, это грубое упрощение, но, если предположить, что вы сравниваете два сайта с похожим контентом и аудиторией, более быстрый сайт должен оказаться выше в результатах. Но то, как Google измеряет это, всегда было
К сожалению, «производительность» — это всеобъемлющий термин для десятков показателей... время до первого байта, начало рендеринга, загрузка ЦП, размер кучи JavaScript, первая содержательная отрисовка, первая осмысленная отрисовка, первый простой ЦП, загруженная DOM, полностью загруженная страница, время до интерактивности, пересчет стилей в секунду и многое другое.
Различные инструменты возвращают разные наборы результатов, и может быть трудно понять, с чего начать.
Инициатива Google Web Vitals направлена на то, чтобы упростить оценку производительности и помочь вам сосредоточиться на наиболее важных улучшениях. Core Web Vitals — это критически важные показатели производительности, отражающие реальный опыт пользователей. О некоторых сообщает панель Lighthouse в Chrome DevTools, PageSpeed Insights и Google Search Console.
Библиотека JavaScript
Google советует использовать
Текущие Core Web Vitals — это Largest Contentful Paint, First Input Delay и Cumulative Layout Shift, которые соответственно оценивают загрузку, интерактивность и визуальную стабильность.
Самая большая содержательная краска (LCP)
LCP измеряет производительность загрузки — насколько быстро появляется контент.
Исторические метрики, такие как загрузка страницы и DOMContentLoaded, в этом отношении боролись, потому что они не всегда свидетельствуют о пользовательском опыте. Например,
Отрисовка самого большого содержимого (LCP) сообщает о времени рендеринга самого большого изображения или текстового блока, видимого в окне просмотра. Время менее 2,5 секунд считается хорошим, а все, что превышает 4,0 секунды, считается плохим.
Типы элементов, рассматриваемые в LCP:
элементы
элементы внутри
плакатное изображение
элемент с фоновым изображением, загруженным с помощью url () свойства CSS
блочные элементы, содержащие текстовые узлы.
Самый большой элемент определяется по мере загрузки содержимого, а размер рассчитывается как его видимые размеры в области просмотра браузера.
На ЛКП могут влиять:
время ответа сервера
время загрузки ресурсов
блокирующий рендеринг CSS или JavaScript
время обработки размера клиента
Улучшения LCP могут быть возможны за счет:
использование сети доставки контента (CDN) для маршрутизации запросов на более близкие серверы
оптимизация ответа сервера за счет минимизации количества дорогостоящих процессов рендеринга
минимизация размера файла активов
локальное кэширование ресурсов и, возможно, использование работника службы, чтобы сначала вернуть локальную версию.
Задержка первого ввода (FID)
FID измеряет отзывчивость — насколько быстро страница реагирует на действия пользователя.
Эта метрика фиксирует время с момента, когда пользователь взаимодействует со страницей (клики, касания, нажатия клавиш и т. д.), до момента, когда браузер начинает обработку этого обработчика событий. Задержка менее 100 мс считается хорошей, а задержка более 300 мс считается плохой.
FID можно точно измерить только тогда, когда приложение обслуживается реальным пользователем. Кроме того, он измеряет только задержку обработки события, а не время, необходимое для запуска обработчика или обновления пользовательского интерфейса.
Поэтому Google и различные инструменты используют общее время блокировки (TBT) в качестве альтернативного показателя, который можно рассчитать без реального участия пользователя. TBT измеряет общее время между:
первая отрисовка содержимого (FCP) — время, когда любая часть контента страницы была отрисована, и
Время до интерактивности (TTI) — время, когда страница способна надежно реагировать на пользовательский ввод (длительные задачи не запущены и не более двух
Улучшения FID/TBT могут быть возможны за счет:
сокращение времени выполнения JavaScript, как правило, за счет откладывания некритического кода
разбивка длительных задач
использование
загрузка стороннего JavaScript по требованию.
Совокупный сдвиг макета (CLS)
CLS измеряет визуальную стабильность — неожиданное движение контента при просмотре страницы.
CLS оценивает раздражающие ситуации, когда содержимое перемещается без предупреждения — обычно это происходит, когда DOM изменяется после завершения загрузки рекламы или изображения над текущей позицией прокрутки. Проблема особенно заметна на мобильных устройствах и может привести к тому, что вы потеряете свое место или нажмете не на ту ссылку.
CLS рассчитывается путем умножения:
Доля удара: общая площадь нестабильных элементов в окне просмотра (тех, которые будут двигаться). Доля воздействия, равная 0,5, указывает, что элементы, занимающие половину области просмотра, будут смещены.
Доля расстояния: наибольшее расстояние, перемещаемое любым отдельным элементом в окне просмотра. Доля расстояния 0,25 означает, что хотя бы один элемент сместился на четверть области просмотра (по горизонтали или по вертикали).
Рассмотрим следующий пример, который загружает рекламу вскоре после отображения логотипа, меню и основного изображения:
Пример CLS
Логотип и меню не двигаются — это стабильные элементы. Объявление добавляется в DOM, и его начальная позиция не меняется, поэтому оно также стабильно. Однако изображение героя будет двигаться:
Размер героя 360×510 пикселей в окне просмотра 360×720. Следовательно, его ударная доля составляет (360×510) / (360×720) = 0,71.
Он перемещается на 90 пикселей по вертикали при высоте окна просмотра 720 пикселей, поэтому его доля расстояния составляет 90/720 = 0,125.
Таким образом, CLS составляет 0,71×0,125 = 0,089.
Оценка CLS ниже 0,1 считается хорошей, а все, что выше 0,25, считается плохой. В этом случае CLS находится как раз в пределах допустимого диапазона, потому что, хотя затрагивается большая площадь, он перемещается на относительно небольшое расстояние. Однако более крупная реклама потребует дополнительного внимания.
Алгоритм CLS не записывает изменение макета в течение 500 мс после любого взаимодействия с пользователем, которое может вызвать изменение пользовательского интерфейса или изменение размера области просмотра. Таким образом, ваша страница не будет наказана за обновления интерфейса, переходы и анимацию, которые необходимы для работы, например, открытие полноэкранного меню из значка гамбургера.
Панель «Рендеринг «в Chrome DevTools (меню > Дополнительные инструменты > Рендеринг) предоставляет параметр «Области смещения макета «. Поставьте галочку и обновите страницу — изменения раскладки подсвечиваются синим цветом. Вы также можете изменить скорость сети на панели «Сеть «, чтобы замедлить загрузку.
Улучшения FID/TBT могут быть возможны за счет:
резервирование места для изображений, видео и элементов iframe путем добавления размеров с помощью атрибутов widthи, свойства CSS или старого трюка с отступами по мере необходимости.
избегать FOUT (вспышка нестилизованного текста) и FOIT (вспышка невидимого текста) при загрузке
не вставлять элементы DOM над существующим содержимым во время начальной загрузки страницы, например, при подписке на новостную рассылку и подобных окнах уведомлений.
с использованием CSS transformи opacityменее затратной анимации.
Приоритеты производительности
Core Web Vitals со временем будет развиваться, но оценка показателей LCP, FID и CLS может помочь выявить наиболее важные проблемы. Решайте сначала быстрые и простые проблемы — они часто приносят наибольшую отдачу от инвестиций:
активировать сжатие сервера и HTTP/2 или HTTP/3
убедитесь, что кеширование браузера используется, установив заголовки срока действия HTTP
предварительная загрузка активов раньше
объединить и минимизировать CSS и JavaScript
удалить неиспользуемые активы
рассмотрите возможность использования CDN или лучшего хостинга
используйте подходящие размеры и форматы изображений
оптимизировать размеры файлов изображений и видео (может помочь специализированный CDN)
Книга SitePoint Jump Start Web Performance содержит десятки советов по повышению скорости сайта, снижению затрат и удовлетворению пользователей.
