First contentful paint fcp что это
Как оптимизировать показатель 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+ параметрам, включая скорость загрузки и отображения контента, анализирует, что реализовано на сайте для ускорения, и дает советы, что еще можно улучшить.
Проверка скорости в Анализе сайта
Некоторые подробные тесты и графики, а также проверка внутренних страниц и отслеживание позиций доступны на платных тарифах. Но мы даем новым пользователям неделю на бесплатный тест сервиса — оставайтесь, если понравится!
В комментариях напишите, о чем еще вам было бы интересно почитать по теме оптимизации и работы с техническими характеристиками сайта.
Скорость загрузки сайта: основные термины
Скорость загрузки сайта: основные термины
Ни для кого не секрет, что медленная работа сайта — это плохо. Если сайт периодически «тормозит», то посетителю становится сложно решить на нем свои задачи. Кроме этого, не стоит исключать и простые человеческие эмоции, когда ожидание загрузки просто раздражает.
Оптимизация скорости загрузки страницы — это один из самых важных этапов для успешности сайта, ведь этот показатель является одним из факторов ранжирования. Большое время загрузки негативно влияет на позиции в выдаче. При этом и Яндекс, и Google отдают предпочтение быстрым ресурсам.
Специалисты Amazon выяснили, что при падении скорости загрузки на 100 мс, у них на 1% снижаются продажи.
Один из самых главных вопросов, связанных с измерением скорости работы сайта — что измерять? В этой статье мы поговорим об основных метриках, используемых при анализе скорости загрузки.
Для рассмотрения возьмем общепринятые параметры из инструмента webpagetest.org.
Основные метрики, используемые при анализе скорости загрузки
Сводная таблица инструмента содержит ряд значений:
Навигация по основным терминам:
First Byte — время, которое требуется для загрузки первого байта информации с сервера, на котором расположен сайт. Это время начинается с нажатия клавиши Enter после ввода пользователем адреса сайта в браузере и заканчивается формированием страницы на сервере и получением этим браузером первого байта информации. Хорошо, что этот параметр достаточно легко измерить и исправить. Поэтому стоит в первую очередь сравнить его с конкурентами и, если мы проигрываем, оперативно решать проблемы на стороне сервера.
Если сервер находится физически очень далеко или сервер слишком слабый и не справляется полностью с текущей нагрузкой, то он слишком долго обрабатывает полученный от клиента запрос, формирует и отправляет данные клиенту. На это наслаиваются проблемы на следующих этапах загрузки, и мы имеем низкую скорость получения контента.
Но сегодня данный параметр уже не является критичным и практически не участвует в формуле ранжирования.
Start Render — Время, необходимое для того, чтобы на странице появилось визуальное отображение контента, т.е. время до появления на мониторе первого «не белого» изображения. Другими словами, это время, через которое на экране пользователя начинает появляться первая отрисовка контента. Start Render является реальным изменением на экране, которое увидит пользователь, определяется путем захвата видео загрузки страницы.
В ситуации, когда параметр First Byte имеет небольшое значение, но при этом показатель Start Render достаточно высок, т.е. вы переходите на страницу, но она остается «пустой» в течение 3-5 секунд и лишь после этого начинают подгружаться контент и графика, основные проблемы следует искать не в работе сервера, а в сайте:
Скрипты подгружаются не вовремя.
Сначала загружаются невидимые глазу элементы или неиспользуемые скрипты.
Сначала загружаются тяжелые элементы и файлы.
Код написан с ошибками.
Чтобы выявить проблемы по пунктам 1-3 можно было бы использовать параметр First Paint. Плюсом данного показателя является его точность и простота определения. Но его минус достаточно серьезный, чтобы отказаться от его использования. Параметр First Paint не гарантирует, что пользователь сможет увидеть изменения на странице. Данный показатель выдает значения с точки зрения браузера, а не пользователя. Например, он может отрисовать белый фон.
Также для корректного определения можно попробовать использовать показатель FCP.
First Contentful Paint (FCP) — первое существенное отображение, т.е. время, за которое пользователь увидит какое-то значительное изменение на странице. Обычно это отображение текста, SVG или картинки. При этом требуется учитывать, что показатель FCP имеет ряд проблем с определением точности результата:
Не учитывает iframe — тег, который позволяет внутри одного HTML-документа отображать другой.
Показатель может увеличиваться из-за ожидания дополнительных погрузок. Так, например, для загрузки текста, ожидается загрузка шрифтов.
Метрика FCP не привязана к области просмотра. То есть где бы ни отображался контент, его загрузка будет зафиксирована, а если он не отображается на первом экране, то пользователь не увидит изменений.
Обратите внимание, что значение Start Render 2100ms, а значение FCP 2134ms
В итоге показатели First Paint, Start Render и First Contentful Paint отличаются моментом, который они фиксирует как загрузку первого элемента:
Start Render — время, в течение которого у пользователя в браузере фактически начинается отрисовка.
First Paint — время, когда браузер «думает», что начал что-то рисовать. Но по факту экран все еще может быть пустым.
First Contentful Paint — время, в течение которого будет отрисован какой-то значительный элемент страницы. Не просто первая точка на экране, а крупный элемент.
Соответственно, чтобы отследить время, в течение которого что-то будет отображено для пользователя, рекомендуем ориентироваться на показатель Start Render, т.к. он основан на видеоанализе загрузки страницы с поиском первого измененного пикселя в области просмотра.
При этом Start Render доступен только через инструменты синтетического мониторинга, тогда как First Paint и First Contentful Paint могут быть запущены из браузера, что делает их пригодными для использования в Real User Monitoring (RUM).
На изображении ниже можно увидеть отличия в фиксировании параметров FCP и Start Render.
В данном случае фактическое значение FCP составляет примерно 2134ms, но мы видим, что первый контент отобразился еще на отметке 2100ms, что и зафиксировал параметр Start Render.
Speed Index — один из самых интересных относительных показателей скорости страницы. Он показывает среднее время, в течение которого отображается все визуальное содержимое страницы. Чем меньше значение индекса скорости — тем лучше. Особенно полезен показатель для сравнения работы нескольких страниц: до/после оптимизации, одного/второго сайта и т.д.
Чтобы значение Speed Index было максимально низким, необходимо в первую очередь загружать элементы, имеющие значения для пользователя и минимальный вес. В последнюю очередь загружаются элементы второстепенной важности и с большим весом. Подробнее вы можете ознакомиться по ссылке https://web.dev/speed-index/.
Last Painted Hero — параметр, который показывает, когда критические элементы (самые большие) отображаются на экране.
Инструмент Webpagetest определяет некоторые из таких элементов по умолчанию:
, видимый в области просмотра. Если его не видно, то вместо него будет использован самый большой
First Painted Hero — время, когда первый элемент виден в окне просмотра.
Last Painted Hero — время, когда последний элемент виден в окне просмотра.
В Google Page Speed также есть параметр Time to Interactive — показатель приблизительного времени, которое требуется странице, чтобы стать полностью интерактивной. Чем меньше этот показатель, тем быстрее страница реагирует на действия пользователя.
Web Vitals — набор показателей, которые показывают степень удовлетворения пользователей сайтом. Это самые важные показатели для оценки качества сайта. Они были анонсированы Google 5 мая, а уже 28 мая Google указал, что они становятся факторами ранжирования: webmasters.googleblog.com/2020/05/evaluating-page-experience.html
Largest Contentful Paint — время, за которое загружается и становится полностью видимой самая большая часть контента: изображение, текст, заголовок.
Cumulative Layout Shift — показывает уровень визуальной стабильности контента на сайте. Например, если кнопка, на которую пользователь хочет нажать, при загрузке сдвигается в сторону из-за рекламных блоков (см. пример в видео ниже), то Cumulative Layout Shift покажет, насколько это для него критично. Чем этот показатель меньше, тем лучше.
Оба эти параметра так или иначе связаны со скоростью работы сайта.
Document Complete — параметр, задачей которого является отражение результата загрузки статического (HTML) кода, которая не гарантирует, что загрузился весь сайт. Условно, Document Complete показывает за какое время загрузился каркас страницы.
Включает в себя 3 показателя:
Time — значение «Load Time». Это общее время загрузки страницы, при котором все ее элементы полностью загружаются на экране пользователя. Это как раз та самая главная величина, которую мы имеем в виду, говоря о времени загрузки сайта. Чем ниже показатель, тем быстрее скорость загрузки в браузере.
Requests — число запросов, которые браузер должен был сделать для отображения фрагментов контента на странице (изображения, javascript, css и т. д).
Bytes In — общий объем загруженных данных для текущего показателя, т.е. размер загрузки. Этот показатель отражает только вес HTML страницы. В это значение не входит размер изображений, JS скриптов и прочих элементов не входящих в изначальный HTML код.
Fully Loaded — группа колонок, предназначенная для отображения максимально полного времени загрузки с учетом картинок, JS-скриптов и прочих элементов.
Здесь также присутствует ряд показателей:
Time — этот параметр отражает сумму времени загрузки HTML документа (Document Complete) и времени загрузки элементов, которые были загружены позже. Есть мнение, что именно этот показатель является основным и конечным, но все же значение Time (Load Time) показателя Document Complete принимается за окончательное значение скорости загрузки страницы.
Requests — необходимое число запросов к серверу для полной загрузки всей информации с сайта.
Bytes In — суммарный вес всех элементов необходимых для отображения всей информации на странице.
Последовательность событий загрузки страницы в «Waterfall View»
Всего есть 6 этапов загрузки страницы, которые на данном графике расположены в определенной последовательности:
Start Render — предназначена для отслеживания визуальных изменений на странице и указания времени, когда появляются первые изменения отражаемые на экране.
RUM First Paint — время, в течение которого содержимое страницы начинает отображаться на экране пользователя.
DOM Interactive — промежуток времени, в течение которого браузер завершает анализ документа и создает модель DOM — объектную модель документа в виде дерева тегов. (Когда браузер запрашивает страницу, в ответ от сервера он получает ее исходный HTML-код. После его анализа и разбора браузер строит на основе этого кода DOM — дерево и использует его для дальнейшей отрисовки страниц).
DOM Content Loaded — создание модели визуализации. Начинается сразу же после завершения DOM Interactive, когда модели DOM и CSSOM уже готовы. На этом этапе создается древо рендеринга (прорисовки) и все готово к визуализации в браузере пользователя, однако в данном событии изображения и CSS могут быть еще не загружены.
On Load — на данном этапе постепенно завершается загрузка основных элементов, т.е. она еще не завершена, но вот-вот это случится.
Document Complete — документ загружен и готов к использованию, т.е. его обработка полностью завершена.
Чтобы все вышеописанное вы могли применить на практике, опишем, что за события происходят на графике. Для детального понимания понадобится и второстепенная таблица, которая располагается сразу под основной:
При загрузке страницы события происходят в следующей последовательности:
Start Render — на показателе 2.100s фиксируется визуальное изменение при загрузке страницы.
RUM First Paint — на показателе 2.131s начинается прорисовка обработанного содержимого.
DOM Interactive — на показателе 3.542s браузер создал модель DOM.
DOM Content Loaded — подготавливается модель визуализации для отображения на экране пользователя. Событие длится 0.794s (с 3.542s — 4.336s).
Speed Index — показатель на 6.044s говорит о том, что страница готова к просмотру пользователем и его взаимодействию с контентом.
Last Painted Hero — на 6.800s уже ясно, что самый большой элемент отображен на странице.
Пять основных этапов загрузки
Любой запрос пользователя к странице состоит из пяти основных этапов. Рассмотрим их подробнее, проанализировав график «Waterfall View»:
На графике и в легенде графика «Waterfall View» этапы Time to First Byte и Content download для каждого типа файлов занимают персональные участки и отображаются различной насыщенностью цвета.
DNS (DNS Lookup) — поиск адреса сайта. При попытке загрузки страницы происходит запрос к DNS серверу, имеющему информацию о запрашиваемом домене. Этот запрос перенаправляется в нужном направлении. На время выполнения данного этапа могут влиять большое число цепей сертификатов или высокая задержка на самом DNS сервере.
SSL (SSL Negotiation) — промежуток времени, в течение которого клиент и сервер согласовывают безопасный способ передачи данных. Этот этап исключается для источников, использующих протокол HTTP и проводится только если сайт использует протоколы HTTPS или SPDY.
Time to First Byte (TTFB) — время до начала загрузки. Важный этап, в ходе анализа которого можно не только найти, но и исправить основные проблемы обработки запросов сервером. На графике отображается время, необходимое серверу для подготовки ответа на полученный запрос. Этот этап актуален для запросов каждого ресурса на странице: таблицы стилей, скрипты, изображения и т.д. Слишком высокая продолжительность Time to First Byte сигнализирует о том, что необходимо оптимизировать исполняемые скрипты на сервере, подключение к БД, скорость запросов и т.п.
Content download — непосредственная загрузка контента, т.е. последний этап запроса, в ходе которого сервер в ответ на поступивший от клиента запрос возвращает содержимое ответа. Затраченное время представляет собой сумму скорости соединения и размера ответа.
На графике «Waterfall View» этапы Time to First Byte и Content download для каждого типа файлов отображаются различной насыщенностью цвета.
На изображении выделен js-файл, окрашенный в светло-оранжевый и оранжевый цвета.
На графике «Waterfall View» для файла этого типа можно увидеть следующую ситуацию:
На этом изображении светло-оранжевая полоса — это Time to First Byte, а просто оранжевая — Content download. Исходя из увиденного, можно сделать вывод о необходимой оптимизации, как работы сервера, так и самой работы скрипта. По возможности рекомендуется минимизировать обращения скрипта к серверу.
Определив файл, требующий оптимизации, можно более точно узнать, сколько времени затрачивается на каждый этап. Для этого необходимо кликнуть по строке с файлом на графике, после чего откроется окно с детализацией:
Получается, что время запроса и обработки файла — 336 ms (Time to First Byte + Content download = 336 ms + 932ms), а сам скачиваемый файл весит 118.4 KB.
На основании полученных при подобном анализе данных можно сделать вывод о возможных проблемах при загрузке сайта и принять решение о наиболее приемлемых способах их устранения.
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).
Полезные ссылки и используемые материалы: