Как оптимизировать показатель LCP — ускоряем загрузку контента для пользователей
В статье:
В мае Google определил новый способ оценки пользовательского опыта. Показатель называется Google Core Vitals, он связан со скоростью загрузки сайта и появления на нем контента.
Google Core Vitals состоит из трех метрик:
Про CLS у нас есть подробный материал «Как оптимизировать CLS: сдвиги макета страницы, которые мешают пользователям», в этой статье поговорим о показателе LCP и способах его улучшить.
Что такое LCP — показатель Largest Contentful Paint
Largest Contentful Paint — время рендеринга самого большого элемента, видимого в области просмотра пользователем — изображения, текстового блока, видео или другого контента. Учитываются те размеры элементов, которые видны пользователю. Если элемент частично скрыт за областью просмотра, эти невидимые части не берутся в расчет.
Самый аккуратный способ определить время отображения основного содержимого страницы — использовать API Largest Contentful Paint (LCP).
Как это происходит:
При загрузке страницы контент может меняться, поэтому каждый раз, когда появляется новый большой элемент, браузер отправляет PerformanceEntry c типом largest-contentful-paint. Когда пользователь начинает взаимодействовать со страницей, отправка метрики прекращается. Нужное значение — время самого последнего отправленного события.
Отрисовка самого большого элемента может происходить и до полной загрузки страницы. К примеру, логотип Instagram — самый большой элемент, он загружается относительно рано и остается самым большим элементом, пока постепенно отображается остальной контент.
Самый большой элемент загрузился до конца загрузки остального контента
В следующем примере самый большой элемент изменяется по мере загрузки содержимого — сначала им был текст, потом самым большим объектом стала картинка.
Самый большой элемент менялся по мере загрузки
Как измерить LCP: инструменты веб-мастера
Инструменты, которые позволяют измерить показатель LCP:
Проверка скорости сайта от PR-CY бесплатно анализирует загрузку страницы по ключевым параметрам, проверяет десктопное и мобильное отображение. Сервис дает рекомендации и прикидывает, сколько можно сэкономить, если их внедрить на сайте.
Интерфейс проверки скорости сайта
Какой показатель LCP считается хорошим
Нужно стремиться, чтобы отрисовка самого большого контента происходила не дольше, чем за 2,5 секунды после начала загрузки страницы. Тогда пользователям будет удобно работать на сайте.
Инструменты для измерения показывают сводный показатель LCP для 75 % посещений URL.
Как улучшить показатель LCP
На LCP влияют четыре фактора:
Рассмотрим эти факторы, сопутствующие им проблемы и способы оптимизировать показатели.
Медленный ответ сервера
Чем быстрее браузер получает контент с сервера, тем быстрее загрузка страницы и тем лучше показатель LCP.
Вы можете улучшить TTFB — время до первого байта. Какие есть способы:
Другой вариант — dns-prefetch для ускорения поиска DNS, подходит для браузеров, которые не поддерживают preconnect.
Можно использовать оба варианта для разных браузеров.
Блокировка рендеринга JavaScript и CSS
Браузер преобразовывает разметку HTML в дерево DOM, а потом уже отображает контент. Он не сможет продолжать работу, если обнаружит ресурсы, блокирующие рендеринг: внешние таблицы стилей link rel=»stylesheet» и сценарии JavaScript script src=»https://pr-cy.ru/news/p/main.js». Чтобы ускорить загрузку содержимого страницы, нужно отложить все некритические JavaScript и CSS.
Неиспользуемый JavaScript и CSS можно найти с помощью Chrome DevTools на вкладке Coverage.
Поиск неиспользуемого CSS и JavaScript
Найденный неиспользуемый CSS можно вообще удалить или переместить в другую таблицу стилей, если он нужен на других страницах сайта.
Если CSS не нужен для начального рендеринга, можно использовать loadCSS для асинхронной загрузки файлов, который использует rel=»preload» и onload.
Как улучшилось LCP после откладывания некритического CSS
Критический CSS можно включить в head, если он нужен для верхней части страницы. Встраивание стилей таким образом позволит не делать двусторонний запрос для получения критического CSS.
Как автоматизировать добавление встроенных стилей на сайт:
Для JavaScript также можно использовать асинхронную загрузку.
Еще полезна минификация или минимизация кода CSS и JavaScript — удаление символов, которые не нужны браузеру для чтения кода. Минификаторы удаляют отступы, интервалы, разделители и комментарии, файл по сути не меняется, но становится легче.
Список бесплатных инструментов для минимизации CSS, JS, HTML-файлов есть в статье.
Как улучшилось LCP после минификации CSS
Долгая загрузка ресурсов
Время, которое требуется контенту для загрузки, влияет на LCP, так что имеет смысл поработать с элементами на странице.
Рендеринг на стороне клиента
Есть сайты, которые работают через рендеринг на стороне клиента (CSR) — то есть рендеринг страниц происходит в браузере с использованием JavaScript, все обрабатывается на стороне клиента, а не на сервере.
Основной недостаток такого подхода в том, что по мере роста сайта, добавления новых библиотек и кода начинает страдать скорость загрузки и отображения контента для пользователя.
В некоторых случаях можно использовать предварительный рендеринг. В таком способе рендер выполняется в headless браузере типа Chrome, который генерирует статические файлы HTML, а их уже подставляют в ответ сервера.
Предварительный рендеринг не нагружает реальный сервер и позволяет улучшить показатель LCP, но не подходит для страниц с изменяемым или с введенным пользователем контентом.
Как улучшилось LCP после предварительного рендеринга
Скорость загрузки ресурса на компьютере и мобильных устройствах можно проверить в Анализе сайта от PR-CY. Он проверяет сайт по 70+ параметрам, включая скорость загрузки и отображения контента, анализирует, что реализовано на сайте для ускорения, и дает советы, что еще можно улучшить.
Проверка скорости в Анализе сайта
Некоторые подробные тесты и графики, а также проверка внутренних страниц и отслеживание позиций доступны на платных тарифах. Но мы даем новым пользователям неделю на бесплатный тест сервиса — оставайтесь, если понравится!
В комментариях напишите, о чем еще вам было бы интересно почитать по теме оптимизации и работы с техническими характеристиками сайта.
Core Web Vitals: как Google решил оценивать сайты
Сегодня поговорим о важности пользовательского взаимодействия, ведь совсем скоро придется подготовить свои сайты к максимальному ускорению загрузки. Возможно, вы уже слышали про Core Web Vitals…
В прошлом году Google начал масштабный пересмотр факторов ранжирования в поисковике, чтобы улучшить качество поисковой выдачи. И в ноябре команда Google анонсировала Core Web Vitals — новые факторы оценки качества ресурсов, которые смогут влиять на индексацию и вступят в силу в мае 2021 года. Давайте разбираться.
Существуют сотни факторов ранжирования, однако Core Web Vitals будет анализировать ещё больше информации и иметь непосредственное влияние на дальнейшую индексацию. Нужно отметить, что скорость загрузки напрямую не влияет на индексацию, однако имеет значительное влияние на поведение пользователя, которое является важным сигналом для поисковых алгоритмов Google.
Чем Core Web Vitals отличается от прочих факторов ранжирования?
Положительная сторона Core Web Vitals — в прозрачности: это понятные, публично доступные критерии, которые можно отслеживать и улучшать с помощью специального набора инструментов. Кроме того, с момента анонсирования и до официального запуска есть много времени, чтобы уже начать работать над Core Web Vitals.
Андрей Липатцев, Web Partnerships Google
Core Web Vitals
Среди многих показателей ранжирования (оптимизации для мобильных устройств, безопасный просмотр, безопасность HTTPS и т.д.) Google выделил основные (core), жизненно важные для пользователя. Метрики, составляющие Core Web Vitals, со временем будут развиваться и дополняться.
Текущий набор показателей фокусируется на трех аспектах взаимодействия с пользователем: 
LCP (загрузка)
Для разработчиков всегда было непросто измерить, насколько быстро контент веб-страницы загружается и становится видимым для пользователей.
Старые метрики, такие как load или DOMContentLoaded, не подходят, так как они всегда соответствуют тому, что пользователь видит на экране. А более новые показатели производительности, такие как First Contentful Paint (FCP), отражают только самое начало процесса загрузки.
В ходе исследований обнаружилось, что более точный способ измерить загрузку основного содержимого страницы, – это посмотреть, когда был отрисован самый большой элемент.
Так появилась метрика Largest Contentful Paint (LCP), которая измеряет время рендеринга самого большого элемента на странице. 
Что считается большим элементом?
Как это работает?
Веб-страница загружается поэтапно, и в результате самый большой элемент на ней может измениться.
Чтобы справиться с таким изменением, браузер отрисовывает первый кадр и отправляет PerformanceEntry с параметром large-contentful-paint, который идентифицирует самый большой элемент. Но затем, после рендеринга последующих кадров, браузер будет отправлять PerformanceEntry при каждом изменении самого большого элемента.
Важно отметить, что элемент может считаться самым большим содержимым только после того, как он будет отрисован и виден для пользователя.
Браузер перестает сообщать о новых записях, как только пользователь начнет взаимодействовать со страницей, поскольку взаимодействие может визуально изменить страницу (прокрутка, модальное окно и т.д.).
Рис.1. Изменение самого большого элемента по мере загрузки содержимого
Как определяется размер самого большого элемента?
Размер элемента определяется в области видимости пользователя: если элемент выходит за её пределы (обрезан или имеет overflow: hidden), то эти части не учитываются.
Если у изображения видимый и исходный размеры отличаются, то будет учитываться меньший из них. Например, если изображение сжали до меньшего размера, чем его исходный, то передается видимый размер, а если растянули — исходный.
Для текстовых элементов учитывается только размер их текстовых узлов.
Для всех элементов любые margin, padding или border не рассматриваются.
FID (интерактивность)
Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и быстродействии вашего сайта.
FID измеряет время с момента, когда пользователь впервые взаимодействует со страницей, до того, как браузер действительно может начать обработку событий в ответ на это взаимодействие.
Задержка ввода возникает из-за того, что основной поток браузера занят чем-то другим (синтаксическим анализом или выполнением большого бандла), поэтому он (пока) не может ответить пользователю.
FID можно измерить только в реальных условиях.
Почему рассматривается именно первый ввод?
CLS (визуальная стабильность)
Cumulative Layout Shift — важный, ориентированный на пользователя показатель для измерения стабильности верстки и элементов, не препятствующих взаимодействию с контентом.
Например, вы переходите на сайт, почитать статью. Пока сайт прогружался, на странице появилось ещё несколько элементов и положение скролла неожиданно изменилось. Неприятно.
Рис.2. Пример Cumulative Layout Shift
Первая ассоциация при виде этого примера — реклама. Думаю, что каждый хотя бы раз сталкивался с таким неожиданным появлением элемента.
Это может происходить из-за асинхронной загрузки ресурсов или динамического добавления DOM-элементов на странице. Причиной может быть изображение или видео с неизвестными размерами, сторонняя реклама или виджет, которые динамически изменяют размер.
CLS измеряет общую сумму всех показателей визуальной стабильности верстки в течение сессии страницы.
Показатель визуальной стабильности определяет Layout Instability API, который отправляет layout-shift каждый раз, когда существующий элемент меняет свое начальное положение между двумя кадрами.
Обратите внимание, что визуальная стабильность не учитывается, когда новый элемент добавляется в DOM или существующий элемент меняет размер.
Чтобы вычислить коэффициент визуальной стабильности, браузер смотрит на размер области просмотра и перемещение нестабильных элементов между двумя визуальными кадрами. Коэффициент вычисляется двумя показателями: коэффициентом воздействия и расстояния.
Рис.3. Коэффициент воздействия
На изображении выше есть элемент, который занимает половину области просмотра в одном кадре. Затем в следующем кадре элемент смещается вниз на 25% от высоты экрана. Красный пунктирный прямоугольник указывает на объединение видимой области элемента в обоих кадрах, которая в данном случае составляет 75% от экрана.
Рис.4. Доля расстояния
Доля расстояния — это наибольшее расстояние, на которое любой нестабильный элемент переместился в кадре (по горизонтали или вертикали), деленное на размер экрана.
В приведенном примере наибольшим размером экрана является высота, а нестабильный элемент перемещается на 25%.
Коэффициент визуальной стабильности = 0.75 * 0.25 = 0.1875
Как улучшить показатели Core Web Vitals?
Если ваше приложение не дотягивает до идеальных показателей, то нужно заняться вопросом повышения скорости. Итак, что можно сделать:
Библиотеки и инструменты
Самый простой способ измерить все Core Web Vitals — использовать js-библиотеку web-vitals, которая измеряет каждую метрику в соответствии с Инструментами Google.
Или можно использовать расширение Web Vitals для Chrome.
Не забывайте периодически следить за скоростью загрузки своего приложения. Быстрая реакция на любые негативные изменения позволит минимизировать потери и вовремя внести необходимые коррективы. Core Web Vitals влияет не только на индексацию, но и главным образом на конверсию, посещаемость и в результате на прибыль. К счастью, Google предупредил заранее о запуске новых факторов ранжирования, поэтому у вас есть еще время исправить все погрешности к запуску Core Web Vitals (май 2021).
Полезные ссылки и используемые материалы:
Новый фактор ранжирования Google — Page Experience: как подготовиться и почему это важно делать уже сейчас
28 мая Google анонсировала новый алгоритм ранжирования, который начнёт действовать в 2021 году. Как и было обещано, о крупных апдейтах теперь оповещают заранее. Давайте разберёмся, что нас ждёт, к чему начинать готовиться и почему это важно начать делать уже сейчас.
Обновление Google Page Experience направлено на оценку сайтов с учётом того, как пользователи взаимодействуют с ним. Часть факторов, которые сказываются на взаимодействии пользователей со страницей и влияют на внутрисайтовые поведенческие факторы, становятся подтвержденными сигналами ранжирования.
В целом, всё это уже так или иначе работает в Google. Пожалуй, главное нововведение — CLS в составе блока Core Web Vitals (основные веб-показатели). Разберём их подробнее и рассмотрим рекомендуемые значения.
Метрика отвечает за отображение самых крупных элементов контента на странице. В отличие, например, от времени первой отрисовки контента (FCP), показатель более удобен с точки зрения понимания пользовательского опыта и отвечает за скорость загрузки именно видимой части контента.
Рекомендуемое значение: 2,5 секунды после начала загрузки страницы.
Ниже пример первой отрисовки контента (FCP) и отрисовки основного контента (LCP).
Метрика отвечает за время между первым взаимодействием со страницей и ответом сервера. Взаимодействием, как правило, считается первый клик (на ссылку, кнопку, JS-элемент и прочее).
Показатель FID непосредственно связан со временем блокировки ввода (TBT) — это время между первой отрисовкой контента (FCP) и время для готовности для взаимодействия (TTI).
Измерить можно с помощью Lighthouse от Google, а уменьшить время загрузки поможет:
Новая метрика, помогающая Google оценивать визуальную стабильность страницы, то есть буквально неожиданное изменение страницы без намеренного взаимодействия. Например, непонятное перемещение текста, исчезание или изменение элементов при попытке взаимодействия и другие раздражающие пользователей факторы.
Измеряется частота возникновения таких смещений (проверить можно также с помощью Lighthouse).
Рекомендуемое значение: менее 0,1 (относительная шкала).
Как правило, на возникновение подобных перемещений элементов влияет асинхронная загрузка DOM-элементов, когда подгрузка изображений, шрифтов, видео или рекламных баннеров влияет на отображение нужного пользователю контента, изменяя его изначальное положение.
Речь идёт только о непредсказуемых и неожиданных изменениях. Интерактивные и меняющиеся элементы, которые не мешают пользователю, а улучшают его опыт взаимодействия со страницей, Google только поощряет.
Помимо обновленного блока с основными веб-показателями (Core Web Vitals), апдейт затронет уже знакомые нам параметры, влияющие на поведение пользователей:
Список факторов, которые войдут в состав монома «Page Experience» уже сейчас сказывается на качестве взаимодействия пользователей с вашим проектом и том, как успешно сайт решает задачу пользователя.
Это значит, что улучшив «Page Experience» и факторы, которые влияют на оценку, вы сможете поднять значения как внутрисайтовых поведенческих метрик, так и кликовых. К числу наиболее важных, на которые можно влиять с помощью «Page Experience» можно отнести:
Безусловно, важно заботиться об этих показателях и в текущих реалиях.
Google обещает уведомить вебмастеров за шести месяцев до начала апдейта. Есть время начать оптимизировать скорость сайта, работать над поведенческими и совершенствовать мобильную версию. В этом помогут:
Всем готовности к апдейту и высоких скоростей!
Спасибо, полезная статья
Для владельцев площадок есть решение от смещений макета. Кто знает можно ли это реализовать самому, например, в CSS?
Информационных сайтов это тоже касается?
Как и сейчас: формулы для инфо и коммерческих проектов РАЗНЫЕ, то есть, факторы могут быть одни, а их значимость — чуть ли не противоположная.
В реальности, разделение по формулам ещё более узкое.
Причём тут Яндекс вообще?
Смысл тот же, логика работы современных поисковых систем схожая
Это неправда. Касается это всех сайтов и всех запросов.
Любые другие факторы можно делить на инфо или коммерческие. Скорость загрузки не имеет этой привязки. И касается ранжирования только на мобильном поиске. Потому что довольно сложно сделать долгую загрузку на десктопе. Хотя до сих пор умельцы находятся.
2020 год на дворе, а гугл нас заставляет делать сайты без картинок, с минимальным количеством js и ксс. Любой интерактив на странице карается вычитанием баллов производительности, банальное подключение скрипта аналитики тоже рейтинг подкашивает.
Та нет, всё не так плохо.
Картинок может быть сколько угодно. Сжимаете, откладываете загрузку и используете современные форматы и Гугл не ругается и не отнимает баллы.
Минимальное количество JS? Ну да. А вам бандл на 10 мегабайт охота пропихнуть на сотку?)
CSS минимально? Ну да. А зачем загружать CSS, который не используется на этой странице? Почему нельзя инлайн вписать те стили, которые нужны для отображения экрана?
Этот коммент звучит как:
«2020 год на дворе, а гугл нас заставляет делать качественные сайты, с соблюдением правил для высокой производительности! Вот гады блин!»
Я говорю не про сайты разработанные в сферическом вакууме, специально для прохождения требований гугла. А про реальные проекты, где есть маркетинговые команды которые вас попросят как минимум иметь gtag подключенный + возможно какой-нибудь hotjar + intercom. И вот вы уже получаете на мобиле вместо 100, что-нибудь типо 60-70. Затем вы подключаете кастомный шрифт, очень маленький только нужного вам типа. Затем у вас есть по всему сайту приятные анимации, какой-то интерактив, контактная форма, GDPR баннер. Не сильно длинная страница, с хорошей версткой, где-то инлайновыми небольшими свг иконками, где-то фото галерея возможно(все с отложенной загрузкой как надо и с вебп), но вот вы получаете около 500 Dom елементов и гугл еще вычитает вам рейтинг.
Вот посмотрите примеры реальных сайтов, за которыми стоят большие команды и которые как не крути, а пытаются заботиться о своих сайтах:
Есть и хотджар. И Метрика и гуглтэгменеджер. И в нем пиксели и всё, что надо для крутого маркетолога.
Зеленая зона.
Значит можно работать? Трелло-то зачем вы замеряли? Их когда купил атлассиан, они свой проект с реактивности на джейквери перевели. И стало всё ясно.
Алексей, у вас типичный российский бизнес расчитаный на тупых клиентов. Все бы было хорошо если бы вы не написали.
Но видите в чем дело, hotjar, gtag используют не удовлетворительную cache политику, на которую ругается Google page speed, но у вас он почему-то не ругается 🙂 Что и сразу же подтвердило мою теорию и выше сказанное, так как чтобы это обойти вы специально не подгружаете эти скрипты, когда вы видите что запрос идет от Lighthouse или page speed.
Так что идите в своей шараге дальше людей разводите, а моим проектам такая помощь не нужна.
— Заходим Chrome Inspector
— Вводим network conditions
— Назначаем Custom user agent
— Вводим «Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3694.0 Mobile Safari/537.36 Chrome-Lighthouse»
— И смотрим какие-же у нас скрипты начинают
— И ой как странно, куда-то пропал и хотжар и ga, ой да и вообще все js скрипты.
Ой разоблачил. Ой детектиииив.
И правда, они не подгружаются для лайтхаус. А кто вам мешает сделать тоже самое?
При этом, наш сайт полностью работает для лайтхаус и JS внутренний выполняется и не скрыт для ЛХ.
Итог такой. Если вы любите ныть в комментах про то, как несправедлива судьба и какой Гугл нехороший — то у вас это получается очень хорошо. Вы тот самый ёж, который ест кактус и рыдает. Выход есть, и да, он не самый изящный.
Никто не мешает, просто смысла самообманом заниматься не вижу, мухлюя и подстраивая работу сайта под прохождение теста, когда для фактического клиента разницы никакой не будет.
А вы конечно разводить можете и дальше своих клиентов.
Чувак, весь «seo бизнес» в СНГ это шарлатаны. Им бесполезно что-то доказывать, они на этом деньги делают.
