Оптимізація Largest Contentful Paint (LCP) сайту

Ваш інтернет-магазин втрачає до 20% конверсії через повільне завантаження головного зображення. Відвідувач бачить білий екран замість банера — і йде до конкурентів. Винуватець — LCP (Largest Contentful Paint), час появи найбільшого елемента у viewport. Google вимагає LCP менше 2,5 секунди, але 60% сайтів не проходять цей поріг. Ми оптимізуємо LCP понад 5 років і виконали більше 200 проєктів, накопичивши практичні рішення для будь-яких кейсів. Сертифіковані фахівці з Core Web Vitals гарантують результат: якщо LCP не покращиться, ми повертаємо кошти. У результаті ви отримуєте швидкий сайт, високі позиції в пошуку та зростання конверсії. Фінансовий ефект: зниження витрат на серверні ресурси до 5000 грн на місяць та збільшення виручки. Спираємося на багаторічний досвід і використовуємо найкращі практики індустрії.

Чому LCP критичний для конверсії?

LCP безпосередньо впливає на Core Web Vitals — фактор ранжування Google. Затримка в 1 секунду знижує конверсію на 7%. Повільне завантаження hero-зображення або заголовка відштовхує користувача. Наші клієнти після оптимізації фіксують покращення LCP в середньому на 40% і зростання органічного трафіку на 15%. Preload зображень у 3 рази ефективніший для LCP, ніж відкладене завантаження. Серверний кеш знижує TTFB у 5-10 разів порівняно з відсутністю кешування.

Як швидко діагностувати LCP?

Використовуйте DevTools → Performance → запис завантаження. Знайдіть позначку LCP. Або через консоль:

new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const last = entries[entries.length - 1];
    console.log('LCP element:', last.element);
    console.log('LCP time:', last.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Також можна використовувати PerformanceObserver через JavaScript для точної діагностики. LCP діагностика за допомогою CrUX та Lighthouse дає повну картину. Докладніше про метрику читайте в документації LCP.

Preload зображень та оптимізація контенту

Preload критичних зображень

<link rel="preload" as="image"
      href="/images/hero.webp"
      imagesrcset="/images/hero-640.webp 640w,
                   /images/hero-1280.webp 1280w,
                   /images/hero-1920.webp 1920w"
      imagesizes="100vw"
      fetchpriority="high">

<img src="/images/hero.webp"
     srcset="/images/hero-640.webp 640w,
             /images/hero-1280.webp 1280w,
             /images/hero-1920.webp 1920w"
     sizes="100vw"
     width="1920" height="1080"
     alt="Оптимізація LCP: preload герой-зображення"
     fetchpriority="high"
     loading="eager"
     decoding="async">

loading="lazy" на LCP-зображенні — часта помилка. Lazy loading відкладає завантаження, збільшуючи LCP. Завжди використовуйте fetchpriority="high" та loading="eager" для головного зображення.

Коректна обробка фонового зображення

Якщо LCP-елемент — CSS background-image, браузер не може preload його автоматично. Найкраще рішення — замінити на <img>. Якщо заміна неможлива, додайте preload через JavaScript.

Прискорення TTFB та усунення render-blocking

Серверний кеш

LCP = TTFB + час завантаження ресурсу. Повільний TTFB робить хороший LCP неможливим. Використовуйте серверний кеш — Full Page Cache або fastcgi_cache.

// Laravel: Full Page Cache для публічних сторінок
// Пакет spatie/laravel-responsecache або nginx fastcgi_cache

class CacheResponse
{
    public function handle(Request $request, Closure $next): Response
    {
        if (!$request->isMethod('GET') || auth()->check()) {
            return $next($request);
        }

        $key = 'fpc:' . md5($request->fullUrl());
        $cached = Cache::get($key);

        if ($cached) {
            return response($cached['body'], 200, $cached['headers'])
                ->header('X-Cache', 'HIT');
        }

        $response = $next($request);

        if ($response->isOk()) {
            Cache::put($key, [
                'body'    => $response->getContent(),
                'headers' => ['Content-Type' => 'text/html; charset=UTF-8'],
            ], now()->addMinutes(5));
        }

        return $response;
    }
}

# nginx fastcgi_cache
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=FCGI:10m inactive=60m;

location ~ \.php$ {
    fastcgi_cache FCGI;
    fastcgi_cache_valid 200 5m;
    fastcgi_cache_bypass $cookie_session $http_authorization;
    fastcgi_no_cache $cookie_session $http_authorization;
    add_header X-Cache $upstream_cache_status;
}

Ці конфіги забезпечують кешування сторінок для неавторизованих користувачів, скорочуючи TTFB до 30–50 мс.

Critical CSS

Критичний CSS вбудовується в <head> для миттєвого рендерингу above-the-fold. Решта CSS завантажується асинхронно.

// vite.config.ts
import { critters } from 'critters';

export default defineConfig({
    plugins: [
        critters({ preload: 'swap', pruneSource: false })
    ]
});

Плагін Critters автоматично виділяє критичний CSS і вбудовує його, решту завантажує з preload.

Цільові показники LCP для різних сторінок

Порівняння методів оптимізації LCP

Процес оптимізації LCP під ключ

1. Аудит — діагностика поточного LCP, TTFB, ресурсів. Використовуємо Lighthouse, WebPageTest, CrUX.
2. Аналіз — виявлення вузьких місць (lazy loading на LCP, повільний сервер, render-blocking).
3. Оптимізація — preload, серверний кеш (Varnish, Redis), critical CSS, WebP/AVIF.
4. Тестування — заміри до/після, перевірка на мобільних пристроях.
5. Моніторинг та звіт — налаштування Long Tasks API, регулярні звіти.

Термін: 3–5 днів з урахуванням налаштування збірки, кешу та тестування. Вартість базової оптимізації LCP — від 5000 грн.

Що входить в роботу

• Повний аудит Core Web Vitals зі звітом.
• Налаштування preload та оптимізація зображень (WebP, AVIF, responsive).
• Впровадження серверного кешування (Varnish, Redis, nginx).
• Inline critical CSS з усуненням render-blocking.
• Моніторинг LCP через Long Tasks API та CrUX.
• Документація щодо впроваджених змін та рекомендації з підтримки.

Як замовити оптимізацію LCP

Отримайте консультацію щодо вашого проєкту — оцінимо поточний LCP і запропонуємо план дій. Замовте аудит LCP, щоб дізнатися точні покращення. Зв'яжіться з нами для обговорення вашого кейсу.

Чому 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 на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі 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 з потрібними розмірами.

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) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.