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
- Підключіть
web-vitals v4 і відправляйте TTFB у вашу аналітику
- Перевіряйте CrUX щотижня для p75 на мобільних
- Налаштуйте алерт у Grafana / Datadog при TTFB > 800 мс
- Запускайте Lighthouse CI на кожен PR
- Тестуйте з різних географічних точок (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-му перцентилі. А це вже зовсім інша гра.
