Оптимізація FCP (First Contentful Paint)
Поганий FCP — бич сучасних веб-проєктів. Ми часто бачимо сайти, де користувач чекає 3–4 секунди перед появою тексту. Наша команда з 10+ сертифікованих спеціалістів за 5 років оптимізувала понад 200 проєктів, і в кожному п'ятому FCP був вище 2.5 секунд. Розбираємося з render-blocking ресурсами, шрифтами та серверним рендерингом. Результат — FCP < 1.2 с навіть на повільних пристроях. Термін оптимізації під ключ: від 1 до 3 днів. Вартість базової оптимізації від 200$ (економія до 30% часу завантаження). Писати можна в телеграм — оцінимо ваш проєкт безкоштовно. Входить аналіз, налаштування critical CSS, preload ресурсів, включення SSR якщо потрібно. Надаємо гарантію результату — 30 днів після здачі.
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. Це блокуючі ресурси (blocking resources), які перешкоджають швидкому відображенню контенту.
<!-- Погано — кожен ресурс блокує рендеринг --> <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 секунду. Інлайн critical CSS у 2 рази швидше, ніж завантаження зовнішнього файлу.
Коли без 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(щоб показати fallback одразу, замінити коли завантажиться).
@font-face { font-family: 'Inter'; src: url('/fonts/inter-regular.woff2') format('woff2'); font-display: swap; 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).
- Документацію та навчання команди підтримці результатів.
Ми спеціалізуємося на оптимізації продуктивності сайту, фокусуючись на Core Web Vitals та швидкості завантаження сайту. Вартість розраховується індивідуально — пишіть, оцінимо.
Чек-лист для швидкої оптимізації 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 с. Для покращення TTFB використовуйте кешування Nginx, підключіть CDN (Cloudflare) та оптимізуйте базу даних. Детальніше про TTFB читайте в окремій статті.
Типові помилки та їх рішення
| Помилка | Рішення | Ефект |
|---|---|---|
| Critical CSS >50 КБ | Інлайнити тільки above-the-fold | -0.3 с |
| Ігнорування мобільних пристроїв | Тестувати на реальних пристроях | — |
| Невикористовувані CSS-правила | PurgeCSS/Tailwind purge | -0.2–0.5 с |
Як виміряти FCP?
Моніторити FCP можна через PerformanceObserver у консолі браузера. HTTP Archive показує, що 40% сайтів мають FCP > 2.5 с. Регулярна перевірка метрики після деплою — обов'язкова.
Отримайте консультацію — зв'яжіться з нами. Оцінимо ваш проєкт та запропонуємо рішення під ключ.