First contentful paint fcp что это

Первая отрисовка контента (FCP)

Метрика FCP (Первая отрисовка контента) измеряет время с момента начала загрузки страницы до момента, когда какая-либо часть содержимого страницы отобразится на экране. Под «содержимым» в этой метрике понимается текст, изображения (включая фоновые изображения), &LTsvg> или небелые элементы &LTcanvas> .

На приведенной выше временной шкале загрузки FCP происходит во втором фрейме, так как именно тогда первые элементы изображения и текст отображаются на экране.

Заметно, что хотя некоторая часть контента была отрисована, но не вся. Это важное различие между Первой отрисовкой контента(FCP) и Скоростью загрузки основного контента (LCP), цель метрики LCPизмерить время загрузки основного контента.

Какое значение показателя FCP можно считать хорошим? #

Для обеспечения удобства работы пользователей сайты должны стремиться к тому, чтобы время до первой отрисовки контента составляло 1,8 секунды или меньше. Чтобы убедиться, что вы достигли этой цели для большинства пользователей, рекомендуется в качестве порогового значения использовать 75-й процентиль загрузки страниц, сегментированный по мобильным и настольным устройствам.

Как измерить FCP #

FCP можно измерить в лабораторных или полевых условиях с помощью следующих инструментов:

Инструменты для измерения в полевых условиях #

• Отчет Chrome User Experience Report

Инструменты для измерения в лабораторных условиях #

Измерение FCP в JavaScript #

• Chrome 60, Supported 60
• Firefox 84, Supported 84
• Edge 79, Supported 79
• Safari 14.1, Supported 14.1

Чтобы измерить FCP в JavaScript, можно воспользоваться Paint Timing API. В следующем примере показано, как создать PerformanceObserver , который прослушивает записи paint с именем first-contentful-paint и регистрирует их в консоли.

Предупреждение

В приведенном выше примере зарегистрированная запись first-contentful-paint сообщит, когда был отрисован первый элемент контента. Однако в некоторых случаях эта запись недействительна для измерения FCP.

Далее приведем различия между тем, что сообщает API, и тем, как рассчитывается метрика.

Различия между метрикой и API #

• API отправит запись first-contentful-paint для страниц, загруженных в фоновых вкладках, но эти страницы следует игнорировать при вычислении FCP (время первой отрисовки нужно учитывать только в том случае, если страница всё время находилась на переднем плане).
• API не сообщает о записях first-contentful-paint , когда страницы восстанавливаются функцией back/forward cache, но в данных случаях следует измерять FCP, поскольку пользователи воспринимают такие посещения страниц как отдельные.
• API может не сообщать о времени отрисовки из iframe с перекрестным происхождением, но для правильного измерения FCP следует учитывать все фреймы. Подфреймы могут использовать API, чтобы сообщать о времени отрисовки в родительский фрейм для агрегирования.

Чтобы не запоминать все эти тонкости, разработчики могут использовать для измерения FCP JavaScript-библиотеку web-vitals , которая обрабатывает эти случаи (где это возможно):

Полный пример измерения FCP в JavaScript приводится в исходном коде onFCP() .

Как улучшить показатель FCP #

Чтобы узнать, как улучшить FCP для конкретного сайта, можно запустить проверку производительности с помощью Lighthouse и обратить внимание на любые конкретные возможности улучшения или диагностики, предлагаемые проверкой.

Чтобы узнать, как улучшить FCP в целом (для любого сайта), обратитесь к следующим руководствам по производительности:

CHANGELOG #

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.

If you have feedback for these metrics, you can provide it in the web-vitals-feedback Google group.

Using First Contentful Paint — FCP

First Contentful Paint, or FCP, measures the time take to render the first element of a webpage. It’s a modern, user-centric measurement of how fast users see a response from your website. Here’s everything you need to know about the metric and how to use it.

FCP is one of the Core Web Vital performance metrics that measure user’s perceived performance of websites. These metrics are incredibly important to delivering fast user experiences, and avoiding SEO performance penalties. Check out how FCP compares with other performance metrics in The Definitive Guide to Measuring Web Performance.

First Contentful Paint Metric

The First Contentful Paint metric considers all the steps required to show the user the first bit of requested content. This includes the time for your servers to respond, network transfer time, HTML size and complexity, and required CSS assets.

In this case, Contentful refers to any text or image elements, but not the background color of the document.

Check out this example waterfall chart, and where FCP is marked.

Loading webpage images is not needed for FCP, but the browser does need to download all the CSS styles, including styles chained with @import statements. Nesting multiple levels of styles can dramatically slow down your FCP performance.

Google defines the acceptable ranges for FCP to be less than 1.0 seconds. Anything over that risks a negative user experience and a possible ranking penalty. FCP scores larger than 3.0 seconds indicate a serious performance problem for your website.

Measuring FCP with PerformanceObserver

First Contentful Paint is measured using the PerformanceObserver API and is supported in Blink-based browsers, such as Chrome, Edge, Android, and Opera. Other browsers, including Chrome on iOS, Safari, and Firefox, cannot report FCP metrics.

Here’s a little code to illustrate the API:

Unlike the Largest Contentful Paint metric, there is not a dedicated type for FCP. You must listen to all paint events and filter them by name. The buffered option allows you to gather data after it has happened. Paste in that code into DevTools on any page and you'll see something like this:

Note that the measurement value is startTime , not duration . startTime is when the FCP event started, while duration is how long the event lasted, which is usually 0.

Quirks, Gotchas, and Unexpected Behavior

Likely, you won’t be measuring FCP yourself. You’ll rely on a library like web-vitals or a service like Request Metrics to gather the data for you. But if you do want to measure FCP yourself, there are a few unexpected things you should look out for.

1. Don’t Measure Background Pages

Pages that are loaded in the background, such as opened in another tab or while minimized, will not have accurate FCP measurements. The first-contentful-paint performance entry is fired once the page is viewed, which will be significantly slower than the actual loading time of the page.

You can detect whether a page is in the background and filter out metrics:

2. Always Use Feature Detection

Many (most) browser do not support PerformanceObserver or the paint type. Some browsers, the object is not defined, while others will throw an error if you attempt to use it. Try/catch is the most reliable way to detect browser compatibility.

3. Styles to the Document Don’t Count

Some pages will apply inline styles to their html or body elements, such as background-color, borders, or outlines. While these styles do paint to the screen, they are not considered for the first-contentful-paint metric.

Improving Your FCP Scores

FCP includes all the time waiting and fetching the document, CSS files, and synchronous scripts. You can improve your FCP scores by making your servers quick, your resources small and few, and the network hops short. Here are some common tactics that can help:

• Reduce server work and cache expensive actions
• Use compression on your HTML, CSS, and other resources
• Reduce the critical CSS required to render the page
• Use fewer and more efficient fonts
• Serve content through a CDN
• Use efficient http caching settings

All the improvements that you make to FCP will also help your Largest Contentful Paint scores.

Conclusion

The First Contentful Paint metric is an important part of the web performance story, but it’s not the only one! Learn more about the other web performance metrics and how to measure them in the Definitive Guide to Measuring Web Performance.

First contentful paint fcp что это

Первая отрисовка контента (FCP)

Published on четверг, 2 мая 2019 г. • Updated on пятница, 4 июня 2021 г.

FCP (Первая отрисовка контента) — одна из метрик, отслеживаемых в разделе Performance (Производительность) отчета Lighthouse. Каждая метрика отражает определенный аспект скорости загрузки страницы.

Lighthouse показывает FCP в секундах:

# Что измеряет FCP

FCP измеряет, сколько времени требуется браузеру для отрисовки первой части контента DOM после перехода пользователя на страницу. Изображения, небелые элементы <canvas> и SVG на странице считаются содержимым DOM; всё, что находится внутри iframe, не включается.

# Как Lighthouse определяет FCP

Оценка FCP — это сравнение времени FCP вашей страницы и времени FCP реальных веб-сайтов на основе данных из Интернет-архива. Например, у сайтов, входящих в 99-й процентиль, FCP составляет примерно 1,5 секунды. Если FCP вашего сайта составляет 1,5 секунды, то оценка FCP равна 99.

В этой таблице показано, как интерпретировать оценку FCP:

Время FCP (в секундах)	Цветовой код
0–1,8	Зеленый (быстро)
1,8–3	Оранжевый (средне)
Более 3	Красный (медленно)

See the Lighthouse performance scoring post to learn how your page’s overall performance score is calculated.

# Как улучшить оценку FCP

Для FCP особенно важно время загрузки шрифтов. Ознакомьтесь со статьей «Убедитесь, что текст остается видимым во время загрузки веб-шрифта», чтобы узнать, как ускорить загрузку шрифтов.

# Отслеживайте FCP на устройствах реальных пользователей

Чтобы узнать, как измерять FCP на реальных устройствах пользователей, см. статью Google «Ориентированные на пользователя показатели производительности». В разделе «Отслеживание FP/FCP» описывается, как программно получить доступ к данным FCP и отправить их в Google Analytics.

# How to improve your overall Performance score

Unless you have a specific reason for focusing on a particular metric, it’s usually better to focus on improving your overall Performance score.

Use the Opportunities section of your Lighthouse report to determine which improvements will have the most value for your page. The more significant the opportunity, the greater the effect it will have on your Performance score. For example, the Lighthouse screenshot below shows that eliminating render-blocking resources will yield the biggest improvement:

See the Performance audits landing page to learn how to address the opportunities identified in your Lighthouse report.

Скорость загрузки сайта: основные термины

Ни для кого не секрет, что медленная работа сайта — это плохо. Если сайт периодически «тормозит», то посетителю становится сложно решить на нем свои задачи. Кроме этого, не стоит исключать и простые человеческие эмоции, когда ожидание загрузки просто раздражает.

Оптимизация скорости загрузки страницы — это один из самых важных этапов для успешности сайта, ведь этот показатель является одним из факторов ранжирования. Большое время загрузки негативно влияет на позиции в выдаче. При этом и Яндекс, и 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 определяет некоторые из таких элементов по умолчанию:

• H1 — самый большой элемент <h1>, видимый в области просмотра. Если его не видно, то вместо него будет использован самый большой <h2>.
• Самое большое изображение — это самый большой элемент <img />, видимый в области просмотра.
• Самое большое фоновое изображение — это самый большой элемент любого типа, который имеет фоновое изображение и который видим в области просмотра.

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 уже ясно, что самый большой элемент отображен на странице.

On Load — в промежутке длительностью 0.014s (с 6.794s по 6.808s) документ почти готов. При этом в течение этого события возникает Document Complete на показателе 6.808s, т.е .документ считается полностью готовым к дальнейшему использованию, хоть некоторые файлы могут все еще подгружаться.

Пять основных этапов загрузки

Любой запрос пользователя к странице состоит из пяти основных этапов. Рассмотрим их подробнее, проанализировав график «Waterfall View»:

На графике и в легенде графика «Waterfall View» этапы Time to First Byte и Content download для каждого типа файлов занимают персональные участки и отображаются различной насыщенностью цвета.

DNS (DNS Lookup) — поиск адреса сайта. При попытке загрузки страницы происходит запрос к DNS серверу, имеющему информацию о запрашиваемом домене. Этот запрос перенаправляется в нужном направлении. На время выполнения данного этапа могут влиять большое число цепей сертификатов или высокая задержка на самом DNS сервере.

Сonnect (Initial Connection) — инициализация соединения, т.е .подключения браузера клиента к серверу запрашиваемого сайта.

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.
На основании полученных при подобном анализе данных можно сделать вывод о возможных проблемах при загрузке сайта и принять решение о наиболее приемлемых способах их устранения.