Оптимизация FCP (First Contentful Paint)
Плохой FCP — бич современных веб-проектов. Мы часто видим сайты, где пользователь ждёт 3–4 секунды перед появлением текста. Наша команда за 5 лет оптимизировала более 200 проектов, и в каждом пятом FCP был выше 2.5 секунд. Разбираемся с render-blocking ресурсами, шрифтами и серверным рендерингом. Результат — FCP < 1.2 с даже на медленных устройствах. Срок оптимизации под ключ: от 1 до 3 дней. Писать можно в телеграм — оценим ваш проект бесплатно. Входит анализ, настройка critical CSS, preload ресурсов, включение SSR если нужно.
FCP (First Contentful Paint) — это время до появления первого контента: текст, изображение, canvas. Хорошее значение ≤ 1.8 секунды. FCP напрямую влияет на восприятие скорости — пользователь видит, что что-то происходит. Плохой FCP почти всегда означает плохой LCP, поэтому с него начинаем.
Разница FCP и LCP
- FCP — первый пиксель контента (любого).
- LCP — самый крупный элемент (геройское изображение, заголовок). Часто страдает из-за медленных изображений.
Плохой FCP почти всегда означает плохой LCP. Исправляя FCP, мы автоматически улучшаем LCP на 20–40%.
Как render-blocking ресурсы убивают FCP?
Браузер останавливает рендеринг на каждый <link> CSS и <script> в <head>. Типичная ситуация: в head 5 стилей и 3 скрипта — пользователь видит белый экран >2 секунд. В крупных проектах это добавляет до 3 секунд к FCP.
<!-- Плохо — каждый ресурс блокирует рендеринг --> <head> <link rel="stylesheet" href="/css/app.css"> <link rel="stylesheet" href="/css/plugins.css"> <link rel="stylesheet" href="/css/vendor.css"> <script src="/js/jquery.js"></script> <script src="/js/plugins.js"></script> </head> Решение — инлайн critical CSS, остальные стили загружать асинхронно через preload. Скрипты — defer или async.
Почему critical CSS — основа быстрого FCP?
Critical CSS — это минимальный набор стилей для видимой части экрана. Мы генерируем его автоматически с помощью critters в Vite. Настройка:
// vite.config.ts import { defineConfig } from 'vite'; import { critters } from 'critters'; export default defineConfig({ plugins: [ critters({ preload: 'swap', pruneSource: false, }) ] }); Для Laravel используем spatie/laravel-vite-plugin и дополнительную настройку Nginx для раздачи pre-built страниц. Результат — снижение FCP на 0.5–1 секунду.
Когда без SSR не обойтись?
SPA на React или Vue имеют ужасный FCP — пользователь видит пустой экран пока не выполнится JS. Server-Side Rendering решает эту проблему. В Next.js SSR включён из коробки. Для Laravel + Inertia.js:
// vite.config.ts import { defineConfig } from 'vite'; import laravel from 'laravel-vite-plugin'; import react from '@vitejs/plugin-react'; export default defineConfig({ plugins: [ laravel({ input: 'resources/js/app.tsx', ssr: 'resources/js/ssr.tsx' }), react(), ], }); SSR улучшает FCP в 2–3 раза по сравнению с чистой SPA. Для сравнения: SPA с SSR даёт FCP ~1.2 с, без SSR — ~3.5 с на мобильном 3G.
Шрифты — скрытый убийца FCP
Кастомные шрифты добавляют задержку. Решение:
- Использовать системный стек
-apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif— нулевая задержка. - Если нужен кастомный шрифт — preload +
font-display: swap.
@font-face { font-family: 'Inter'; src: url('/fonts/inter-regular.woff2') format('woff2'); font-display: swap; /* показать fallback сразу, заменить когда загрузится */ unicode-range: U+0400-045F, U+0490-0491; /* только кириллица */ } <link rel="preload" href="/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin> Что входит в работу по оптимизации FCP?
Мы предоставляем:
- Анализ текущих метрик (Lighthouse, PageSpeed Insights, WebPageTest) — отчёт с рекомендациями.
- Генерацию critical CSS и настройку сборщика (Webpack, Vite, Laravel Mix).
- Оптимизацию шрифтов: preload, font-display, уменьшение количества глифов.
- Включение SSR для SPA (Next.js, Nuxt, Inertia).
- Проверку на реальных устройствах (iPhone 8, Android Galaxy S8).
- Документацию и обучение команды поддержке результатов.
Стоимость рассчитывается индивидуально — пишите, оценим.
Чек-лист для быстрой оптимизации FCP
| Шаг | Действие | Ожидаемый эффект |
|---|---|---|
| 1 | Инлайн critical CSS | -0.5–1 с |
| 2 | Асинхронная загрузка CSS | -0.3–0.8 с |
| 3 | Defer/async скриптов | -0.5–1 с |
| 4 | Preload шрифтов + swap | -0.2–0.5 с |
| 5 | SSR включён | -0.5–2 с |
| 6 | TTFB < 600 мс | -0.3–0.8 с |
Важно: Начинать с самой влиятельной метрики — TTFB. Если сервер отвечает 1.5 секунды, FCP никогда не будет < 1.8 с.
Типичные ошибки и их решения
| Ошибка | Решение | Эффект |
|---|---|---|
| Critical CSS >50 КБ | Инлайнить только above-the-fold | -0.3 с |
| Игнорирование мобильных устройств | Тестировать на реальных устройствах | — |
| Неиспользуемые CSS-правила | PurgeCSS/Tailwind purge | -0.2–0.5 с |
Подробнее о TTFB
TTFB (Time to First Byte) – время получения первого байта от сервера. Должен быть < 600 мс. Для его улучшения используйте кеширование на уровне Nginx, подключите CDN (Cloudflare) и оптимизируйте базу данных.Как измерить FCP?
Мониторить FCP можно через PerformanceObserver в консоли браузера. HTTP Archive показывает, что 40% сайтов имеют FCP > 2.5 с. Регулярная проверка метрики после деплоя — обязательна.
Получите консультацию — свяжитесь с нами. Оценим ваш проект и предложим решение под ключ.