Оптимізація 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 с. Регулярна перевірка метрики після деплою — обов'язкова.
Отримайте консультацію — зв'яжіться з нами. Оцінимо ваш проєкт та запропонуємо рішення під ключ.
Чому Core Web Vitals критичні для технічного SEO
PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.
Як досягти хороших показників Core Web Vitals?
Core Web Vitals: що реально впливає на позиції
Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).
LCP: чому 8 секунд — це не проблема зображення
LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.
Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.
Рішення по кроках:
- Переносимо hero з CSS background в
<img> з fetchpriority="high" та loading="eager"
- Конвертуємо в WebP, додаємо
srcset: 800w для мобільних, 1400w для десктопа
-
<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
- Прибираємо всі render-blocking скрипти вище hero через
defer
Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.
Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.
CLS: зсуви, які дратують користувача і Google
CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.
Джерела CLS:
- Зображення без заданих розмірів.
<img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
- Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через
min-height або завантажувати до рендеру основного контенту.
- Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування.
font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
- Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
| Типовий сценарій |
CLS до |
CLS після |
Основний фікс |
Банер знижок без min-height |
0.42 |
0.02 |
min-height: 300px |
| Картинки в статтях без атрибутів |
0.18 |
0.01 |
width/height + aspect-ratio |
| Віджет чату, що завантажується через 3с |
0.35 |
0.05 |
position: fixed із зарезервованим відступом |
INP: чому інтерфейс «зависає» на 500ms
INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.
Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.
Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:
- Безперервна обробка великого списку без
requestIdleCallback або requestAnimationFrame
- Важкі event listeners без
debounce/throttle
- Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
- Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread
Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.
Schema.org: розмітка, яку читають роботи
Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.
Типи розмітки за сценаріями:
-
E-commerce:
Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
-
Статті та блог:
Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
-
Локальний бізнес:
LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
-
FAQ:
FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.
Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.
Як проводити технічний SEO-аудит
Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.
Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.
JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.
Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.
Типові помилки при впровадженні Schema.org
- Вказано
price без priceCurrency — розмітка ігнорується.
-
ratingValue без reviewCount — у видачі не показується.
- Кілька
Product на одній сторінці без @type: ItemList — Google бере тільки перший.
- JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
| Етап роботи |
Що входить |
Термін |
| Аудит |
Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами |
1–2 тижні |
| Оптимізація одного шаблону |
LCP, CLS, INP, впровадження SSR/SSG, налаштування preload |
2–4 тижні |
| Повна технічна оптимізація |
Всі шаблони, code splitting, Web Workers, моніторинг в CI |
4–10 тижнів |
| Впровадження Schema.org |
JSON-LD генерація, валідація, тестування rich snippets |
1–3 тижні |
Що входить в роботу
- Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
- Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
- Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
- Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.
Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.
