Частые заблуждения про оптимизацию LCP
Если вы работаете с оптимизацией перфоманса страниц, то метрика LCP (Largest Contentful Paint) точно попадалась вам на глаза. Это время от начала загрузки страницы до отрисовки самого большого блока во вьюпорте. Таким блоком может быть и текст, но часто это какая-то картинка, привлекающая внимание. И так как LCP является важной составляющей Core Web Vitals, приходится эту метрику оптимизировать.
В статье Брендана Кенни разбирается миф о том, что для оптимизации LCP достаточно сделать картинки меньше по размеру: использовать современные форматы изображений, сжимать картинки.
На самом деле до отрисовки картинки есть ещё несколько этапов, которые можно посчитать в секундах: время до первого байта, время на задержку запроса за ресурсом, время загрузки ресурса и время рендеринга. И, как показывает статистика, на 75-м перцентиле исследованных сайтов с высокими значениями LCP время на загрузку составляет меньше 10% от всего времени LCP. Да, эти 10% тоже важно оптимизировать, но как будто стоит обратить внимание на остальные этапы.
Брендан советует обращать внимание на следующие этапы:
- Оптимизировать TTFB, время до первого байта. Если у вас нет CDN, а у пользователя слабая сеть, то на TTFB может уходить около 2.5 секунд (на исследованных сайтах), а это очень много.
- Сделать так, чтобы важный ресурс запрашивался заранее. Подсказать браузеру через
- Исследовать задержки рендеринга. Возможно, где-то у вас есть кусок JS, который тормозит запрос за картинкой или отрисовку во вьюпорте. Этот совет в том числе и другие метрики улучшит.
Больше полезных чисел — по ссылке.
https://web.dev/blog/common-misconceptions-lcp
Если вы работаете с оптимизацией перфоманса страниц, то метрика LCP (Largest Contentful Paint) точно попадалась вам на глаза. Это время от начала загрузки страницы до отрисовки самого большого блока во вьюпорте. Таким блоком может быть и текст, но часто это какая-то картинка, привлекающая внимание. И так как LCP является важной составляющей Core Web Vitals, приходится эту метрику оптимизировать.
В статье Брендана Кенни разбирается миф о том, что для оптимизации LCP достаточно сделать картинки меньше по размеру: использовать современные форматы изображений, сжимать картинки.
На самом деле до отрисовки картинки есть ещё несколько этапов, которые можно посчитать в секундах: время до первого байта, время на задержку запроса за ресурсом, время загрузки ресурса и время рендеринга. И, как показывает статистика, на 75-м перцентиле исследованных сайтов с высокими значениями LCP время на загрузку составляет меньше 10% от всего времени LCP. Да, эти 10% тоже важно оптимизировать, но как будто стоит обратить внимание на остальные этапы.
Брендан советует обращать внимание на следующие этапы:
- Оптимизировать TTFB, время до первого байта. Если у вас нет CDN, а у пользователя слабая сеть, то на TTFB может уходить около 2.5 секунд (на исследованных сайтах), а это очень много.
- Сделать так, чтобы важный ресурс запрашивался заранее. Подсказать браузеру через
<link rel="preload">, например. И пока парсер реально дойдёт до картинки в коде и дождётся выполнения всех синхронных JS-операций, за это время часть полезной работы уже будет проделана.- Исследовать задержки рендеринга. Возможно, где-то у вас есть кусок JS, который тормозит запрос за картинкой или отрисовку во вьюпорте. Этот совет в том числе и другие метрики улучшит.
Больше полезных чисел — по ссылке.
https://web.dev/blog/common-misconceptions-lcp