Ключевые показатели скорости загрузки страницы
Core Web Vitals – (с англ. ключевые интернет показатели) метрики, которые Google считает главными при анализе скорости загрузки страницы.
В документации к Core Web Vitals отнесены три метрики: First Input Delay, Largest Contentful Paint и Cumulative Layout Shift.
Однако Page Speed Insights в разделе «данные наблюдений за страницей за последние 28 дней» добавляет четвёртую метрику First Contentful Paint. Поэтому мы будем считать, что главных метрик четыре.
First Contentful Paint (FCP)
«Первая отрисовка контента – показатель, который определяет интервал времени между началом загрузки страницы и появлением первого изображения или блока текста»
На 30.10.2020, согласно данному калькулятору, Google считает идеальным время <= 1340 миллисекунд.
Важно понимать, что в это время включены затраты на запрос к DNS, запросы к серверу, работа серверной части и первичный рендеринг DOM.
На DNS и скорость работы сети мы повлиять не можем. Поэтому главными тормозящими факторами являются:
- скорость генерации html на стороне сервера (не должна превышать 200 ms)
- стили и скрипты в head
Именно поэтому Google рекомендует подключать в head только критические стили, и даже не тегом link, а тегом style, для уничтожения лишнего запроса к серверу.
First Input Delay (FID)
«Время от первого взаимодействия пользователя со страницей до момента, когда браузер начал обработку данного действия»
Нормальным значением считается показатель ниже 100 миллисекунд.
В подавляющем большинстве случаев большой FID появляется из-за тяжёлого синхронного javascript-кода, тормозящего браузер.
Если вы пишите адекватный javascript и не подключаете подозрительные сторонние скрипты, FID будет нормальным.
Largest Contentful Paint (LCP)
«Отрисовка крупного контента – показатель, который определяет время, требуемое на полную отрисовку крупного текста или изображения в зоне показа (первого экрана)»
Google считает, что самый крупный элемент привлекает наибольшее внимание пользователя, поэтому важно быстро его отобразить.
Если таким элементом окажется большой текстовый блок, а мы правильно выделили критические стили, то LCP будет незначительно больше FCP.
Если таким элементом оказывается картинка, разумеется, потребуется время на её скачивание. Поэтому нужно постараться реализовать данную картинку в webp-формате для уменьшения её веса.
Cumulative Layout Shift (CLS)
«Совокупное смещение макета – это процентная величина, на которую смещаются видимые элементы области просмотра при загрузке»
Google считает, что скачки макета в процессе загрузки страницы сильно бесят пользователей, которые могут совершить ошибочные клики. Думаю, все встречали такие сайты. Хочешь нажать на ссылку, а в момент клика где-то вверху изменился или добавился элемент, макет поехал вниз, клик в лучшем случае ушёл в пустоту, в худшем – на другой элемент.
Когда страница загрузилась, такие скачки являются редкостью, как правило, связанной с рекламными баннерами. А вот в процессе загрузки страницы они случаются на огромном количестве сайтов.
CLS будет равен нулю, если мы загрузим все стили в head. Однако, тогда пострадает FCP. Поэтому мы выносим критические стили в head, а остальные подключаем асинхронно. CLS растёт, если мы неправильно выделили критические стили. Элементы сначала отображаются, а затем прыгают, когда применится асинхронный CSS.
Решение – правильно выделять критические стили, связанные с размерами элементов. Например, цвет ссылки в меню можно и асинхронно установить, а вот размер шрифта, отступы и рамки нужны для CLS, стремящегося к нулю.
Чем выше расположен элемент из-за которого происходит скачок, тем больше CLS он добавляет, ведь сдвигается не только он, но и все соседи снизу. Напротив, элементы, расположенные внизу первого экрана, даже дёргаясь, лишь незначительно увеличивают CLS.
Ещё одним фактором роста CLS являются изображения без html-атрибутов width и height. Такие картинки до момента загрузки занимают высоту, равную нулю, а затем резко отображаются, сдвигая макет вниз.
Решение – получить пропорции картинки, прописать width=Npx, height=Mpx в html. В CSS важно указать width в любой единице измерения, обязательно поставив height auto!
В таком случае браузер до загрузки изображения зарезервирует под неё прямоугольник со сторонами, сохраняющими пропорцию N / M. Не бойтесь того, что размеры могут не совпадать, главное – пропорция!
Выводы и нюансы для размышления
- FID будет нормальным, если не начудить в javascript.
- Сторонние скрипты, такие как счётчики, реклама и т.п., могут ухудшить FID.
- FCP и CLS вступают в противоречие относительно места загрузки CSS-стилей. Поэтому, мы делим стили на критические и асинхронные.
- Правильные критические стили и width/height изображений приближают CLS к нулю.
- FCP и LCP можно улучшить за счёт новых вариантов link: preload, preconnect.
- Подключение нестандартных шрифтов, скорее всего, повлияет на FCP либо на CLS. Если на время загрузки к подключаемому шрифту удаётся подобрать похожий стандартный шрифт, FCP и CLS не страдают.
- LCP всегда зависит от конкретной ситуации. Если дизайнер поместил в шапку громадную картинку или фоновое видео, получить хороший LCP будет трудно.
Также в Lighthouse Performance можно увидеть такие метрики, как Speed Index, Time to Interactive и Total Blocking Time. Сейчас мы их не рассматривали, однако в документации есть подробное описание.
В большинстве ситуаций, если у вас всё в порядке с Core Web Vitals, дополнительные метрики также покажут хороший результат.
31.10.2020
Понравился материал? Поделись с друзьями!