Знижуємо TTFB до 200 мс — кейси та інструменти

Оптимізація TTFB: від 1.2 с до 150 мс за тиждень

Нещодавно до нас звернувся власник інтернет-магазину зі скаргою на повільне завантаження — TTFB становив 1.2 секунди на головній сторінці. Після комплексного аудиту ми впровадили full page cache, налаштували Nginx FastCGI кеш, оптимізували запити до БД та підключили Redis. Результат: TTFB впав до 150 мс, LCP покращився на 40%, а конверсія зросла на 12%. У цій статті розбираємо, які саме кроки призвели до такого ефекту.

TTFB (Time to First Byte) — час від відправки запиту до отримання першого байта відповіді. Він складається з DNS-резолву, встановлення з'єднання (TCP+TLS), відправки запиту, обробки на сервері та генерації відповіді. Найкерованіша частина — серверна обробка. Саме її ми й оптимізуємо. Згідно з документацією Google по Web Vitals, TTFB безпосередньо впливає на LCP та INP.

Чому TTFB критичний для Core Web Vitals?

Google використовує TTFB як показник першого відгуку. Якщо сервер думає довше 600 мс, навіть ідеальний фронтенд не врятує LCP. Ми це бачили на десятках проєктів: зниження TTFB з 1 с до 200 мс покращувало LCP на 40%. Крім того, повільний сервер затримує обробку користувацьких запитів, погіршуючи INP (Interaction to Next Paint).

Як діагностувати TTFB за допомогою Chrome DevTools та WebPageTest?

• Chrome DevTools (вкладка Network): заміряємо Waiting (TTFB) для кожного запиту. Фільтруємо за типом document.
• WebPageTest: дає детальний waterfall, що показує DNS, TCP, TLS, перший байт. Вказує, скільки часу зайняв сервер.
• Lighthouse: загальна оцінка з рекомендаціями.
• RUM-рішення (Яндекс.Метрика, Google Analytics): показують реальні значення TTFB для користувачів.

Ми завжди починаємо з RUM-даних, щоб отримати об'єктивну картину.

Кешування — головний інструмент

Full Page Cache на рівні застосунку

Найефективніший спосіб — кешувати готовий HTML для всіх неавторизованих користувачів. Ось middleware для Laravel:

class FullPageCache
{
    private const TTL = 300; // 5 хвилин

    public function handle(Request $request, Closure $next): Response
    {
        if (!$this->isCacheable($request)) {
            return $next($request);
        }

        $key = $this->cacheKey($request);

        if (Cache::has($key)) {
            return response(Cache::get($key))
                ->header('X-Cache', 'HIT')
                ->header('Content-Type', 'text/html; charset=UTF-8');
        }

        $response = $next($request);

        if ($response->getStatusCode() === 200) {
            Cache::put($key, $response->getContent(), self::TTL);
        }

        return $response->header('X-Cache', 'MISS');
    }

    private function isCacheable(Request $request): bool
    {
        return $request->isMethod('GET')
            && !auth()->check()
            && !$request->hasCookie(session()->getName());
    }

    private function cacheKey(Request $request): string
    {
        return 'fpc:' . sha1($request->fullUrl());
    }
}

Такий підхід дає TTFB < 50 мс для закешованих сторінок. Головне — правильно налаштувати інвалідацію при зміні контенту. Ми використовуємо події (Model events) для очищення кешу відповідних URL.

Nginx FastCGI Cache — швидше, ніж PHP+Redis

Кеш на рівні nginx працює до генерації PHP, що дає виграш ще в 10-20 мс:

fastcgi_cache_path /var/cache/nginx/fcgi
    levels=1:2
    keys_zone=LARAVEL:10m
    inactive=60m
    max_size=1g;

fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ \.php$ {
        fastcgi_cache LARAVEL;
        fastcgi_cache_valid 200 5m;
        fastcgi_cache_valid 404 1m;

        fastcgi_cache_bypass $cookie_laravel_session $http_authorization;
        fastcgi_no_cache     $cookie_laravel_session $http_authorization;

        add_header X-Fastcgi-Cache $upstream_cache_status;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Для інвалідації використовуємо модуль ngx_cache_purge — надсилаємо PURGE-запит на URL.

Оптимізація запитів до бази даних

Повільні запити — друга за частотою причина високого TTFB. Типова помилка — N+1 problem:

// Повільно
$products = Product::all();
foreach ($products as $product) {
    echo $product->category->name;
}

// Швидко
$products = Product::with(['category', 'images', 'brand'])->get();

Ми профілюємо всі запити через DB::listen і логуємо ті, що виконуються довше 100 мс. Додаємо індекси, замінюємо вкладені цикли на єдині запити з JOIN.

Redis для кешування даних

Кешуємо результати частих запитів — дерево категорій, топ товарів, лічильники:

$categories = Cache::remember('categories:tree', 3600, function () {
    return Category::with('children')->whereNull('parent_id')->orderBy('sort_order')->get();
});

$stats = Cache::remember('product:stats:' . $productId, 300, function () use ($productId) {
    return [
        'views'    => ProductView::where('product_id', $productId)->count(),
        'sales'    => OrderItem::where('product_id', $productId)->sum('quantity'),
        'wishlist' => WishlistItem::where('product_id', $productId)->count(),
    ];
});

Інші оптимізації

DNS і мережа

Використовуємо <link rel="preconnect"> для сторонніх ресурсів, щоб скоротити DNS+TCP час. Підключаємо CDN (Cloudflare, Vercel) — вони зменшують затримку за рахунок географічно розподілених серверів.

OPcache для PHP

Налаштування для продакшену:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.jit=tracing
opcache.jit_buffer_size=64M

JIT-компіляція прискорює виконання PHP-скриптів на 20-50%, що безпосередньо знижує TTFB.

Порівняння методів кешування

Що входить у нашу роботу

1. Аудит — замір TTFB на всіх типах сторінок, аналіз структури кешування, профілювання БД.
2. Проєктування — вибір стратегії кешування під конкретний стек.
3. Реалізація — впровадження full page cache, nginx-кешу, оптимізація запитів, налаштування Redis.
4. Тестування — A/B-тести до/після, перевірка коректної інвалідації.
5. Документація — схема кешування для команди розробки.
6. Аудит через півроку — контроль деградації.

Цільові значення TTFB за типами сторінок

Ми гарантуємо зниження TTFB до 500 мс на всіх сторінках і покращення LCP на 30-50%. Клієнти економлять до 40% на хостингу за рахунок кешування, а інвестиції в оптимізацію окупаються за 3-6 місяців. Зв'яжіться з нами для безкоштовного аудиту вашого сайту. Отримайте консультацію з оптимізації TTFB — розберемо ваш проєкт і запропонуємо конкретні кроки.

Чому 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 пунктів.