Оптимізація TTFB у 2026 році: як зменшити час до першого байта

Time to First Byte (TTFB) — це метрика, яку чомусь постійно недооцінюють, хоча вона напряму впливає на Largest Contentful Paint, First Contentful Paint і взагалі на те, як швидко користувач відчуває сайт. Якщо ваш сервер витрачає 1.2 секунди тільки на формування відповіді — забудьте про бюджет LCP у 2.5 секунди. Браузер ще навіть байта HTML не отримав, а ви вже не вкладаєтесь.

Чесно кажучи, я сам років зо два тому вважав TTFB чимось «суто бекендським» і не дуже звертав увагу. Поки одного разу не побачив, як проста перебудова рендерингу на edge підняла нам Lighthouse-скор з 62 до 91 — без жодних змін у фронтенді. Відтоді ставлюся до цієї цифри серйозно.

У цьому гайді розбираємо TTFB у контексті 2026 року: нові пороги, як вимірювати показник у CrUX, і дев'ять конкретних стратегій оптимізації — з робочими прикладами коду для Next.js, Nginx і Cloudflare Workers.

Що таке TTFB і чому він критичний у 2026 році

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

• Резолюція DNS — пошук IP-адреси домену
• TCP handshake або QUIC connect (для HTTP/3)
• TLS-узгодження — обмін сертифікатами та ключами
• Час очікування відповіді сервера (request → response on server)
• Час до першого байта на дроті

У 2026-му TTFB набув нової ваги через два чинники.

По-перше, Google підтвердив, що CrUX публікує TTFB як діагностичну метрику для всіх Core Web Vitals — повільний бекенд автоматично псує LCP. По-друге (і це, мабуть, головне), edge-обчислення перестали бути нішею для гіків з Vercel-аккаунтами. Тепер це стандарт. І ваші конкуренти у ніші вже спокійно тримають TTFB < 200 мс, поки ви все ще запитуєте MySQL з одного сервера в Дата-Центрі №3.

Цільові пороги TTFB у 2026

Web Vitals команда Chrome рекомендує такі значення, виміряні на 75-му перцентилі реальних користувачів:

• Добре: ≤ 800 мс
• Потребує покращення: 800–1800 мс
• Погано: > 1800 мс

Однак не варто розслаблятися на офіційних 800 мс. Для конкурентної ніші — e-commerce, медіа, SaaS-лендінги — реальна планка значно жорсткіша. Топові сайти у 2026-му тримають TTFB у межах 100–300 мс, використовуючи статичну генерацію або повне edge-кешування HTML. Якщо ви робите інтернет-магазин і у вас 900 мс — формально це «добре», а фактично ви вже програли всім, хто перейшов на edge.

Як виміряти TTFB: три способи

1. Web Vitals JavaScript-бібліотека

Найточніший спосіб — збирати реальні дані користувачів через web-vitals v4:

import { onTTFB } from 'web-vitals';

onTTFB((metric) => {
  // metric.value у мілісекундах
  // metric.rating: 'good' | 'needs-improvement' | 'poor'
  navigator.sendBeacon('/analytics', JSON.stringify({
    name: 'TTFB',
    value: metric.value,
    rating: metric.rating,
    navigationType: metric.navigationType,
    id: metric.id,
  }));
});

2. Chrome DevTools → Performance Insights

Відкрийте DevTools, перейдіть у панель Performance і запишіть навантаження сторінки. У звіті Insights блок «Document request latency» розбиває TTFB на стадії: Waiting for server response, Redirects, Connection setup. Це найшвидший спосіб локалізувати вузьке місце — буквально хвилина роботи.

3. CrUX API для реальних користувачів

curl -X POST \
  "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com",
    "metrics": ["experimental_time_to_first_byte"],
    "formFactor": "PHONE"
  }'

Відповідь міститиме розподіл TTFB у відсотках для трьох категорій якості. Це дані з реального трафіку Chrome за останні 28 днів — золотий стандарт.

Дев'ять стратегій зменшення TTFB у 2026 році

1. Edge-кешування HTML

Найбільший приріст дає переніс рендерингу або кешу повністю на CDN edge. Cloudflare Workers, Vercel Edge і Netlify Edge Functions виконують код у локації, найближчій до користувача — типово менше 50 мс мережевої затримки. Так, навіть якщо ваш користувач десь у Львові, а сервер у Сан-Франциско.

// Cloudflare Worker з кешуванням HTML на edge
export default {
  async fetch(request, env, ctx) {
    const cache = caches.default;
    const cacheKey = new Request(request.url, request);

    let response = await cache.match(cacheKey);
    if (response) return response;

    response = await fetch(request);
    response = new Response(response.body, response);
    response.headers.set('Cache-Control', 'public, s-maxage=300, stale-while-revalidate=86400');

    ctx.waitUntil(cache.put(cacheKey, response.clone()));
    return response;
  },
};

Маленький, але важливий нюанс: директива stale-while-revalidate дозволяє віддавати застарілий кеш миттєво, поки edge у фоні оновлює свіжу версію. Без неї кожне закінчення TTL = знов холодний запит до origin.

2. Перейдіть на HTTP/3 (QUIC)

HTTP/3 працює поверх UDP і усуває head-of-line blocking, який досі є в HTTP/2. Особливо вагомий ефект на мобільних з'єднаннях: 0-RTT відновлення TLS зменшує час підключення на 100–300 мс. Перевірити, чи увімкнено HTTP/3 на вашому домені:

curl -I --http3 https://example.com

У Nginx 1.25+ увімкніть HTTP/3 директивою:

listen 443 quic reuseport;
listen 443 ssl;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';

3. 103 Early Hints — недооцінений приріст

Early Hints — це проміжна відповідь сервера зі статусом 103, що дозволяє браузеру почати завантажувати критичні ресурси (CSS, шрифти, hero-зображення) ще до того, як основна відповідь HTML буде готова. Підтримується Chrome, Edge і Cloudflare з 2024 року.

// Next.js 15+ (App Router)
export async function GET(request) {
  const headers = new Headers();
  headers.append('Link', '</_next/static/css/main.css>; rel=preload; as=style');
  headers.append('Link', '</fonts/inter.woff2>; rel=preload; as=font; crossorigin');

  // Рамкова відправка 103 (підтримується Vercel автоматично за наявності Link)
  return new Response(html, { headers });
}

Реальні вимірювання Shopify показали зменшення LCP на 20–30% завдяки Early Hints для повторних візитів. Чесно — це найдешевша оптимізація, яку зазвичай ніхто не робить.

4. Виключіть редіректи з критичного шляху

Кожен редірект (HTTP → HTTPS, www → non-www, або застарілий URL → новий) додає повний раундтріп до сервера: DNS, TCP, TLS, потім сам редірект. Швидкий аудит:

curl -sIL https://example.com -o /dev/null -w "%{num_redirects} redirects, total %{time_total}s\n"

Налаштуйте HSTS preload, щоб браузер ніколи не робив запит на HTTP-версію:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

5. Перейдіть з SSR на ISR або статичну генерацію

Якщо контент не персоналізований — повний SSR на кожен запит це просто марнування ресурсів. Incremental Static Regeneration (ISR) у Next.js дозволяє генерувати сторінку один раз і регенерувати її у фоні за розкладом:

// app/blog/[slug]/page.tsx
export const revalidate = 3600; // регенерація раз на годину

export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Це переводить TTFB з 600+ мс (повний SSR) у діапазон 50–150 мс (статичний файл з edge). Тобто ефект негайно видно у CrUX вже через тиждень-два.

6. Оптимізуйте запити до бази даних

Якщо ваш TTFB повзе вище 500 мс, у 80% випадків винна база даних. Я це казав десяткам команд, і щоразу — ну, майже щоразу — виявлялась саме вона. Найчастіші проблеми:

• N+1 запити — використовуйте JOIN, IN або DataLoader
• Відсутні індекси на колонках у WHERE та ORDER BY
• Холодні з'єднання — підіймайте connection pool на edge через PgBouncer або Prisma Accelerate

Аналіз повільних запитів у PostgreSQL:

SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

7. Кешуйте API-відповіді на рівні застосунку

Для динамічних сторінок з частково статичним контентом використовуйте unstable_cache у Next.js або Redis:

import { unstable_cache } from 'next/cache';

const getProducts = unstable_cache(
  async (categoryId) => {
    return db.product.findMany({ where: { categoryId } });
  },
  ['products-by-category'],
  { revalidate: 60, tags: ['products'] }
);

8. Зменшіть розмір першого байта

TTFB вимірюється від запиту до першого байта, але якщо сервер генерує велику відповідь і не використовує streaming — браузер чекатиме повний HTML. Увімкніть streaming SSR (React 18+, Remix, Next.js App Router):

// Suspense дозволяє надсилати HTML частинами
export default function Page() {
  return (
    <>
      <Header />
      <Suspense fallback={<Skeleton />}>
        <SlowProductList />
      </Suspense>
    </>
  );
}

Перший байт приходить миттєво з шапкою сайту, а повільні секції догружаються асинхронно. Користувач бачить прогрес — не пустий екран.

9. Brotli-стиснення на рівні CDN

Brotli стискає HTML на 20–25% краще ніж gzip. Cloudflare, Fastly і Vercel вмикають його автоматично. Для self-hosted Nginx:

brotli on;
brotli_comp_level 5;
brotli_types text/html text/css application/javascript application/json image/svg+xml;

Динамічний контент стискайте на рівні 4–5 (баланс CPU vs розмір), статичний — на рівні 11 під час білда. На рівні 11 у динаміці CPU просто згорить, перевірено.

Чек-ліст моніторингу TTFB

1. Підключіть web-vitals v4 і відправляйте TTFB у вашу аналітику
2. Перевіряйте CrUX щотижня для p75 на мобільних
3. Налаштуйте алерт у Grafana / Datadog при TTFB > 800 мс
4. Запускайте Lighthouse CI на кожен PR
5. Тестуйте з різних географічних точок (WebPageTest, Calibre)

Часті запитання (FAQ)

Чи входить TTFB у Core Web Vitals у 2026 році?

Ні, TTFB офіційно залишається діагностичною, не оцінюваною метрикою. Але Google враховує його для розрахунку LCP, тож повільний TTFB напряму псує оцінку Core Web Vitals. У 2026 році Chrome продовжує публікувати TTFB у CrUX звітах поряд з LCP, INP і CLS.

Який TTFB вважається добрим у 2026 році?

Офіційний поріг від Google — ≤ 800 мс на 75-му перцентилі реальних користувачів. Однак для конкурентних ніш цільове значення нижче: 200–400 мс. Топові сайти на edge-інфраструктурі досягають 50–150 мс.

Чи зменшує HTTP/3 значно TTFB?

Так, особливо на мобільних і нестабільних з'єднаннях. HTTP/3 використовує QUIC поверх UDP і дозволяє 0-RTT відновлення з'єднання, що економить 100–300 мс на повторних запитах. На стабільному дротовому з'єднанні різниця менш помітна (10–30 мс).

Чому мій TTFB високий лише на першому візиті?

Найімовірніше, у вас холодний старт серверлес-функції або порожній кеш CDN. Другий запит уже потрапляє в кеш і повертається миттєво. Виправлення: увімкніть stale-while-revalidate, переходьте на edge-функції з мінімальним cold start (Cloudflare Workers, Vercel Edge), або тримайте «прогрівні» крон-таски, які раз на 5 хвилин стукають у функцію.

Як виправити високий TTFB на WordPress?

Три кроки за пріоритетом: (1) увімкніть повносторінкове кешування через WP Rocket, LiteSpeed Cache або плагін рівня сервера; (2) перенесіть статичні ресурси та HTML-кеш на CDN з підтримкою edge (Cloudflare APO); (3) перейдіть на PHP 8.3+ і MariaDB 11+ — лише оновлення стека дає 30–40% приріст TTFB. Так, я знаю, що оновлення PHP у легасі WP-проєкті — це окреме пекло, але воно того варте.

Висновок

TTFB — це фундамент швидкості сайту. Без оптимізованого часу до першого байта решта зусиль із покращення Core Web Vitals просто впирається у стелю. У 2026-му виграють ті команди, які перенесли HTML-рендеринг на edge, увімкнули HTTP/3 та Early Hints, і налаштували інкрементальне кешування для динамічного контенту.

Почніть з вимірювання: підключіть web-vitals, подивіться у CrUX, виявіть найгіршу сторінку. Потім застосуйте 2–3 стратегії з цього списку — найчастіше це edge-кешування + HTTP/3 + видалення редіректів. Цього достатньо, щоб TTFB опустився нижче 300 мс на 75-му перцентилі. А це вже зовсім інша гра.