Календарь
Расписание
ноябрь 2020
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30  -  -  -  -  -  -

Ключевые показатели скорости загрузки страницы

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 и скорость работы сети мы повлиять не можем. Поэтому главными тормозящими факторами являются:

  1. скорость генерации html на стороне сервера (не должна превышать 200 ms)
  2. стили и скрипты в 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. Не бойтесь того, что размеры могут не совпадать, главное – пропорция!

Выводы и нюансы для размышления

  1. FID будет нормальным, если не начудить в javascript.
  2. Сторонние скрипты, такие как счётчики, реклама и т.п., могут ухудшить FID.
  3. FCP и CLS вступают в противоречие относительно места загрузки CSS-стилей. Поэтому, мы делим стили на критические и асинхронные.
  4. Правильные критические стили и width/height изображений приближают CLS к нулю.
  5. FCP и LCP можно улучшить за счёт новых вариантов link: preload, preconnect.
  6. Подключение нестандартных шрифтов, скорее всего, повлияет на FCP либо на CLS. Если на время загрузки к подключаемому шрифту удаётся подобрать похожий стандартный шрифт, FCP и CLS не страдают.
  7. LCP всегда зависит от конкретной ситуации. Если дизайнер поместил в шапку громадную картинку или фоновое видео, получить хороший LCP будет трудно.

Также в Lighthouse Performance можно увидеть такие метрики, как Speed Index, Time to Interactive и Total Blocking Time. Сейчас мы их не рассматривали, однако в документации есть подробное описание.

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

31.10.2020

Понравился материал? Поделись с друзьями!