Что такое First Contentful Paint

FCP — это момент, когда браузер впервые отрисовал любой «содержательный» пиксель страницы: текст, изображение (в том числе фоновое), SVG или «не-белый» <canvas>. То есть пользователь впервые что-то увидел, кроме пустого фона/«заглушки» браузера.

Время прочтения:

4 минуты

Дата публикации:

19.05.25

22

Главная

Что такое First Contentful Paint

глоссарий

a

b

c

d

e

f

g

h

i

j

l

m

o

p

r

s

t

u

v

w

y

А

Y

А

Б

В

Г

Д

Е

з

и

к

л

м

н

о

п

р

с

т

у

ф

х

ц

ч

ш

А

Я

метрика месяца

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

ROMI

Важно: FCP — не Core Web Vital. Это вспомогательная метрика «первой видимой реакции». Для ранжирования Google использует CWV: LCP, CLS, INP. Но хороший FCP помогает и CWV, и восприятию скорости.

Чем FCP отличается от соседних метрик

FP (First Paint) — «первый любой пиксель» (даже просто фон). Мало полезен;
FCP — первый содержательный пиксель (текст/картинка/SVG/не-белый canvas);
LCP — время до крупнейшего видимого элемента (обычно герой-картинка/заголовок) — ключевая метрика восприятия загрузки;
INP — отзывчивость на взаимодействия; CLS — стабильность макета;

Обычно: FCP наступает раньше LCP. Хороший FCP создаёт ощущение «страница ожила», пока догружается крупный контент (LCP).

Как Google и инструменты трактуют FCP

В PageSpeed Insights/Lighthouse FCP показывается и влияет на лабораторный скоринг. Практические ориентиры:

Good ≤ 1,8 с;
Needs improvement 1,8–3,0 с;
Poor > 3,0 с.

В полевых данных (RUM) FCP берут из Paint Timing API.

Посмотреть можно:

PageSpeed Insights (lab + field);
Chrome DevTools → Performance/Performance Insights;
Собственный RUM (через web-vitals или PerformanceObserver).

Мини-пример сбора в браузере:

const po = new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    if (e.name === 'first-contentful-paint') {
      console.log('FCP:', e.startTime); // мс от navigationStart
    }
  }
});
po.observe({ type: 'paint', buffered: true });

Что задерживает FCP

Высокий TTFB (медленный сервер/бэкенд/неиспользуемый кэш);
Блокирующие рендер ресурсы: большой CSS «в шапке», синхронные <script> без defer;
Тяжёлые шрифты с font-display: block (FOIT — текст невидим → FCP откладывается);
Героевое фоновое изображение огромного веса (оно само — «контент», значит FCP ждёт его);
Большой бандл JS: пока парсится/выполняется, браузер часто задерживает отрисовку.

Как улучшать FCP

Сократите серверную задержку

Кэш страниц/фрагментов, CDN ближе к пользователю;
Быстрая TLS-установка, HTTP/2/3;
Редьюс TTFB: оптимизация БД, n+1, холодные старты.

Ускорьте критический путь рендера

Критичный CSS инлайн, остальной — отложить/разбить. Уберите неиспользуемые стили;
Скрипты — defer/async, никаких синхронных блокировок в <head>;
Минимизируйте число шрифтов/начертаний.

Сделайте текст видимым раньше

Для веб-шрифтов: font-display: swap/optional, предзагрузка ключевых файлов:

<link rel="preload" as="font" href="/fonts/Inter-var.woff2" type="font/woff2" crossorigin>

Подберите метрики/size-adjust, чтобы переход с fallback не дёргал макет.

Дайте браузеру подсказки

preconnect к критичным источникам (CDN, шрифт-сервер):

<link rel="preconnect" href="https://cdn.example.com" crossorigin>

dns-prefetch для сторонних доменов.

Следите за «героем»

Если фон-картинка в первом экране — это и есть FCP-ресурс. Сожмите её (AVIF/WebP), задайте точные размеры, избегайте «гигантских» исходников;
Часто лучше сделать контентный <img> с preload + CSS-позиционирование, чем тяжёлый background.

Уменьшайте JS-нагрузку

Code-split, удалите неиспользуемые полиfill’ы/библиотеки;
Грузите виджеты/аналитику после первого контента.

SSR/SSG и «острова»

Серверный рендер + прогрессивная гидрация (islands/partial hydration) выводят текст сразу, а JS подтягивают позже.

Частые анти-паттерны

Lazy-loading для первого контента (герой-картинка/логотип) — FCP только ухудшится;
Большой шрифт без preload и без swap — «пустая» страница до загрузки файла;
Сторонние теги (А/В, виджеты, чаты) в <head> синхронно;
«Заглушка-скелет» как чистый фон — FCP не наступит, пока не появится реальный текст/картинка. (Скелет как SVG/изображение — уже контент, но следите за весом.)

Как мониторить и не регрессить

Полевой мониторинг (RUM): собирайте FCP по сегментам (страна, сеть, устройство, шаблон);
Ставьте алерты по 75-му перцентилю: рост > 200–300 мс — повод для тикета;
В CI используйте Lighthouse CI/WebPageTest budgets (вес CSS/JS, число блокирующих ресурсов).

Мини-чек-лист FCP

TTFB стабильно низкий (CDN/кеш/HTTP2/3);
Критичный CSS инлайн; лишний CSS удалён;
Скрипты с defer/async, нет синхронных блокировок;
Веб-шрифты: preload + font-display: swap/optional;
Первый видимый контент не «lazy», изображения оптимизированы;
Сторонние скрипты грузятся после первого контента/по событию;
Есть RUM-сбор FCP и алерты по перцентилям.

вывод

FCP — это «первая осмысленная картинка/текст на экране». Пользователь именно здесь понимает, что страница ожила. Ускоряйте серверный ответ, снимайте блокировки на критическом пути (CSS/JS/шрифты), оптимизируйте герой-контент и контролируйте FCP полевыми датчиками — и субъективная «скорость» сайта заметно вырастет (а за ней потянутся поведенческие и конверсия).