First Contentful Paint (FCP)
First Contentful Paint (FCP) измеряет, сколько времени требуется, чтобы первый фрагмент контента - текст, изображение, SVG или незакрашенный белым холст - отрисовался на экране после того, как пользователь запросил страницу. Это момент, когда пользователи видят первый признак того, что «страница отвечает».
First Contentful Paint (FCP) измеряет, сколько времени требуется, чтобы первый фрагмент контента - текст, изображение, SVG или незакрашенный белым холст - отрисовался на экране после того, как пользователь запросил страницу. Это момент, когда пользователи видят первый признак того, что «страница отвечает».
Почему это важно
Пользователи, смотрящие на пустой экран, быстро уходят. Исследование Nielsen Norman Group показывает, что внимание резко падает, как только первый визуальный отклик превышает 1 секунду. Сегодня FCP не является официальным Core Web Vital, но это ключевой компонент оценки производительности в Lighthouse и опережающий индикатор для LCP. Если FCP медленный, LCP никогда не будет хорошим.
Пороги
| Оценка | FCP |
|---|---|
| Хорошо | <= 1,8 с |
| Требует улучшения | 1,8-3,0 с |
| Плохо | > 3,0 с |
Измеряется по 75-му процентилю (p75) данных реальных пользователей из отчёта Chrome User Experience Report.
TTFB -> FCP -> LCP -> INP
Загрузка страницы - это временна́я шкала последовательных метрик.
- TTFB: время до того, как сервер отправит первый байт
- FCP: время до отрисовки первого контента
- LCP: время до отрисовки самого большого элемента контента
- INP: время до визуального отклика на взаимодействие пользователя
Порядок имеет значение: если TTFB медленный, FCP не может быть быстрым, и LCP тоже не может быть быстрым. Работу над производительностью нужно начинать «сверху».
Что замедляет FCP
Медленный TTFB: медленный сервер замедляет FCP на ту же величину.
Ресурсы, блокирующие отрисовку: внешний CSS и синхронный JS в <head> должны загрузиться и выполниться до того, как браузер сможет отрисовать страницу. Их слишком много или они слишком велики - и FCP стопорится.
Большой размер DOM: тысячи элементов в исходном HTML требуют времени на парсинг и компоновку.
Загрузка веб-шрифтов: пока кастомные шрифты не загружены, возникает FOIT (мелькание невидимого текста), из-за чего FCP кажется задержанным.
Клиентский рендеринг (CSR): приложения на React и Vue, которые отрисовывают контент только после загрузки и выполнения JS-бандла, существенно отодвигают FCP.
Как оптимизировать
Улучшите TTFB: CDN, серверное кеширование и оптимизация БД - это фундамент.
Устраните блокирующие отрисовку ресурсы: используйте async и defer для отсрочки JS. Встраивайте критический CSS и загружайте остальное асинхронно.
Серверный рендеринг (SSR): используйте фреймворки вроде Next.js, Astro или Remix для предварительной генерации HTML на сервере.
Оптимизация шрифтов: font-display: swap сразу показывает запасной текст, пока загружаются кастомные шрифты. Используйте preload только для критически важных шрифтов.
Уменьшите JS-бандлы: tree shaking, разделение кода и удаление неиспользуемых библиотек снижают исходный бандл.
Оптимизация изображений: используйте <link rel="preload"> для главного изображения и отдавайте WebP или AVIF.
Инструменты измерения
- PageSpeed Insights: полевые данные CrUX + лабораторные данные
- Lighthouse: диагностика на уровне страницы
- Chrome DevTools -> Performance: FCP на временно́й шкале
- JS-библиотека web-vitals: сбор данных реальных пользователей на собственном сайте
Источники: