TTFB оптимизация: 10 техники (2026)

Защо TTFB е метриката, от която зависи всичко останало

Time to First Byte (TTFB) е времето от момента, в който браузърът изпраща HTTP заявка, до получаването на първия байт от отговора на сървъра. Звучи като дребен детайл, нали? Но ето къде е уловката — макар TTFB да не е официална Core Web Vital метрика, тя е диагностичната основа, върху която стоят всички останали показатели: LCP, FCP, INP. Ако TTFB е бавен, всичко надолу по веригата страда.

И данните го потвърждават доста красноречиво.

Според Web Almanac 2025 (базиран на CrUX данни от юли 2025 г.), едва 44% от мобилните страници постигат „добър" TTFB резултат. За сравнение, LCP се е подобрил от 44% на 59%, а INP — от 55% на 74% за същия период. TTFB остава най-стагниращата метрика в целия уеб — и това не е случайно, а по-скоро следствие от факта, че много екипи го пренебрегват.

Ето и числото, което наистина те кара да се замислиш: сайтове с лош LCP изразходват средно 2,27 секунди само за TTFB — почти изчерпвайки целия праг от 2,5 секунди за LCP, преди браузърът изобщо да е започнал рендериране. Казано по-директно: ако не оптимизирате TTFB, всичко друго, което правите, е козметика.

Какво точно измерва TTFB и какви са праговете

TTFB обхваща няколко последователни фази и всяка от тях може да бъде тясно гърло:

Пренасочвания (redirects) — всяко 301/302 пренасочване добавя допълнителен round-trip
DNS lookup — разрешаване на домейна до IP адрес
TCP свързване — установяване на TCP връзка
TLS преговаряне — криптографско ръкостискане за HTTPS
Обработка на заявката от сървъра — изпълнение на код, заявки към бази данни, генериране на HTML

Google определя следните прагове за TTFB на 75-ия персентил:

Добър: ≤ 800 ms
Нуждае се от подобрение: 800–1800 ms
Лош: > 1800 ms

На практика обаче, ако целите конкурентна производителност, стремете се към под 200 ms на сървърно ниво. Под 100 ms е отлично (и напълно постижимо с правилния стек).

Как да измерите TTFB правилно

Лабораторни инструменти (Lab Data)

Лабораторните тестове ви дават контролирана среда — идеални за дебъгване, но не винаги представителни за реалния свят:

Chrome DevTools — в панела Network, колоната „Waiting (TTFB)" показва времето за чакане на първия байт за всяка заявка. Лесно и бързо.
Lighthouse — показва „Server Response Time" като одит. Имайте предвид, че Lighthouse не включва DNS lookup и redirect времена, така че реалният TTFB може да е по-висок.
WebPageTest — професионален инструмент с възможност за тестване от различни локации по света. Честно казано, това е любимият ми инструмент за дълбок анализ на TTFB.

Полеви данни (Field Data)

Реалните потребителски данни са по-ценни, защото отразяват действителните условия — бавни мрежи, далечни локации, претоварени устройства:

CrUX (Chrome User Experience Report) — Google събира анонимизирани TTFB данни от реални Chrome потребители. Достъпен е чрез PageSpeed Insights и BigQuery.
Navigation Timing API — позволява ви да измервате TTFB програматично директно в браузъра:

// Измерване на TTFB чрез Navigation Timing API
const [entry] = performance.getEntriesByType('navigation');
const ttfb = entry.responseStart - entry.startTime;
console.log(`TTFB: ${ttfb.toFixed(0)} ms`);

// За по-детайлно разбиване на фазите:
console.log(`DNS: ${(entry.domainLookupEnd - entry.domainLookupStart).toFixed(0)} ms`);
console.log(`TCP: ${(entry.connectEnd - entry.connectStart).toFixed(0)} ms`);
console.log(`TLS: ${(entry.connectEnd - entry.secureConnectionStart).toFixed(0)} ms`);
console.log(`Server: ${(entry.responseStart - entry.requestStart).toFixed(0)} ms`);

10 техники за намаляване на TTFB (подредени по въздействие)

1. Сървърно кеширане на пълни страници

Кеширането на ниво сървър е най-ефективната единична оптимизация за TTFB. И не, не преувеличавам — разликата е огромна. Вместо да се изпълняват PHP скриптове и SQL заявки при всяка заявка, сървърът връща предварително генериран HTML директно от паметта.

Типичен резултат: от 1–4 секунди за динамично генериране до под 50 ms за кеширан отговор. Това е 20–80 пъти по-бързо.

# Nginx FastCGI Cache конфигурация
# Добавете в nginx.conf или server block:

fastcgi_cache_path /var/cache/nginx levels=1:2 
    keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ \.php$ {
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_valid 404 1m;
        
        # Bypass cache за логнати потребители
        fastcgi_cache_bypass $no_cache;
        fastcgi_no_cache $no_cache;
        
        add_header X-Cache-Status $upstream_cache_status;
    }
}

За WordPress сайтове, LiteSpeed Cache постига TTFB под 20 ms, тъй като прихваща заявката преди изобщо да стартира PHP интерпретатора. Ако хостингът ви поддържа LiteSpeed — просто го включете, сериозно.

2. CDN с Edge Caching

Content Delivery Network разполага кеширани копия на вашите страници на стотици сървъри по целия свят. Данните от Web Almanac 2025 показват, че CDN постига 3 пъти по-бързо TLS преговаряне в сравнение с origin сървъри — 57 ms срещу 177 ms медиана на десктоп. Тази разлика сама по себе си е значителна.

Конфигурирайте правилни Cache-Control заглавки за максимална ефективност:

# Оптимални Cache-Control заглавки за статичен контент
Cache-Control: public, max-age=31536000, immutable

# За HTML страници с CDN кеширане
Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400

# За динамично съдържание, което не трябва да се кешира на CDN
Cache-Control: private, no-cache, no-store

Целете се към 90%+ cache hit rate. И ако още не използвате Origin Shielding — помислете сериозно. Това е междинен кеш слой, който предотвратява множество заявки от edge сървърите към origin при cache miss. Разликата в натоварването на origin сървъра може да е драматична.

3. HTTP/3 и QUIC протокол

HTTP/3, базиран на QUIC, елиминира TCP handshake и обединява TLS преговарянето в едно round-trip. За мобилни потребители с нестабилна връзка (а те са повече, отколкото предполагаме), това може да спести 100–200 ms от TTFB.

# Nginx: активиране на HTTP/3
server {
    listen 443 quic reuseport;
    listen 443 ssl;
    
    http2 on;
    http3 on;
    
    # Обявете поддръжката на HTTP/3 чрез Alt-Svc header
    add_header Alt-Svc 'h3=":443"; ma=86400';
    
    ssl_early_data on;  # 0-RTT за повторни връзки
}

4. 103 Early Hints

HTTP 103 Early Hints е модерният заместител на HTTP/2 Server Push (който на практика се провали). Идеята е елегантна: докато сървърът обработва заявката и генерира HTML, той изпраща предварителен 103 отговор с Link заглавки, инструктиращи браузъра да започне зареждане на критични ресурси.

Cloudflare отчита над 30% подобрение на LCP при използване на Early Hints. Защо? Защото браузърът използва „мъртвото време" на сървърната обработка за зареждане на CSS, шрифтове и LCP изображения — вместо просто да чака.

# NGINX конфигурация за 103 Early Hints (NGINX 1.29+)
server {
    location / {
        # Изпращане на Early Hints за критични ресурси
        add_header Link "; rel=preload; as=style" early;
        add_header Link "; rel=preload; as=font; crossorigin" early;
        add_header Link "; rel=preconnect" early;
        
        proxy_pass http://backend;
    }
}

Важно уточнение: 103 Early Hints работи само през HTTP/2 и HTTP/3 връзки. Ако все още сте на HTTP/1.1, първо мигрирайте.

5. Оптимизация на базата данни

При динамични сайтове (WordPress, Laravel, Django) заявките към базата данни са основен фактор за сървърното време за обработка. Типичен WordPress page load изпълнява 20–100 SQL заявки на страница — и ако дори една от тях е бавна, целият TTFB страда.

Ключови стъпки:

Добавете липсващи индекси — без индекс, MySQL сканира цялата таблица (full table scan). Това е убийствено за производителността при големи таблици.
Ограничете autoloaded данни (WordPress) — препоръчително е да са под 800 KB. Видял съм сайтове с над 5 MB autoload данни — и се чудят защо са бавни.
Използвайте обектен кеш — Redis или Memcached елиминират повтарящи се заявки

# Идентифициране на бавни MySQL заявки
# В my.cnf активирайте slow query log:
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

# След това анализирайте с:
mysqldumpslow -s t /var/log/mysql/slow.log | head -20

6. Актуализиране на технологичния стек

Това е лесна победа, която много екипи пропускат. PHP 8.3/8.4 е значително по-бърз от PHP 7.x, а PHP 8.x с JIT компилация може да ускори обработката с 20–40%. MariaDB 11.x предлага подобрени оптимизатори на заявки спрямо по-старите версии.

За Node.js приложения: преминете към Node.js 22 LTS с подобрено HTTP/2 управление и по-бърз V8 двигател. Самата миграция рядко е проблематична, а ползите са мигновени.

7. DNS оптимизация

DNS resolve е включен в TTFB измерването и бавен DNS може да добави 50–150 ms към всяка нова навигация. Звучи малко, но тези милисекунди се натрупват бързо.

Преминете към бърз DNS провайдър:

Cloudflare DNS (1.1.1.1) — средно 11 ms глобален response time
Google Public DNS (8.8.8.8) — средно 22 ms глобален response time

Намалете DNS lookups, като консолидирате ресурсите от третострани домейни. Използвайте dns-prefetch и preconnect за критични домейни:

<!-- DNS prefetch за некритични домейни -->
<link rel="dns-prefetch" href="https://analytics.example.com">

<!-- Preconnect за критични домейни (DNS + TCP + TLS) -->
<link rel="preconnect" href="https://cdn.example.com">
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>

8. Минимизиране на пренасочванията

Всяко HTTP пренасочване добавя пълен round-trip — обикновено 100–300 ms допълнително. Най-честите виновници (и решенията им):

http:// → https:// (решение: HSTS header)
example.com → www.example.com (решение: консистентни URL-и навсякъде)
Множество маркетингови redirect-и — тези понякога са невидими, но се натрупват

# HSTS header за елиминиране на HTTP→HTTPS пренасочване
# (браузърът автоматично ще използва HTTPS)
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

9. Streaming и Edge SSR

За Next.js и React Server Components, използвайте streaming SSR за да изпратите първия байт HTML веднага, докато останалата част от страницата все още се генерира. На практика това означава, че потребителят вижда нещо по-рано, дори ако цялата страница не е готова.

// Next.js 15 — streaming по подразбиране с App Router
// app/page.tsx
import { Suspense } from 'react';
import HeavyComponent from './HeavyComponent';

export default function Page() {
  return (
    <main>
      {/* Това се изпраща веднага */}
      <h1>Добре дошли</h1>
      <nav>...</nav>
      
      {/* Това се стриймва, когато е готово */}
      <Suspense fallback={<p>Зареждане...</p>}>
        <HeavyComponent />
      </Suspense>
    </main>
  );
}

За Next.js приложения, предпочитайте Static Generation (SSG) или Incremental Static Regeneration (ISR) пред SSR, когато е възможно. Кешираните статични страници постигат TTFB близък до нулата — и това не е маркетингово преувеличение.

10. Speculation Rules API — бъдещето на TTFB

И стигаме до най-вълнуващата техника. Speculation Rules API е може би най-революционната стъпка за елиминиране на TTFB при последващи навигации. Данните от Web Almanac 2025 показват, че предварително рендерирани страници чрез Speculation Rules постигат p75 TTFB от 0 милисекунди. Нула. Буквално.

<!-- Speculation Rules: prefetch + prerender -->
<script type="speculationrules">
{
  "prefetch": [{
    "where": { "selector_matches": "a[href^='/']" },
    "eagerness": "moderate"
  }],
  "prerender": [{
    "where": { "selector_matches": ".primary-nav a" },
    "eagerness": "moderate"
  }]
}
</script>

Препоръчителна стратегия за внедряване:

Започнете с prefetch за всички вътрешни линкове (moderate eagerness)
Добавете prerender за навигационни елементи с висока вероятност за кликване
Мониторирайте в Chrome DevTools → Application → Speculative Loads

Понастоящем Speculation Rules API се поддържа от Chromium-базирани браузъри (Chrome, Edge, Opera). За останалите браузъри, използвайте <link rel="prefetch"> като fallback — не е идеално, но е по-добре от нищо.

TTFB по тип навигация: какво казват данните

Различните типове навигация показват драматични разлики в TTFB (данни от Web Almanac 2025, p75):

Speculation Rules prerender: 0 ms
Reload: 82 ms (топла връзка)
Стандартна навигация: 131 ms
Back/forward навигация: 244 ms

Тези числа говорят сами за себе си. Комбинацията от сървърно кеширане (за първоначалната навигация) и Speculation Rules (за последващите) може да доведе до практически мигновено зареждане на целия потребителски път. А не е ли точно това, което искаме?

Географският фактор: защо CDN не е лукс

TTFB варира драматично в зависимост от физическото разстояние между потребителя и сървъра. Европейски потребител близо до сървъра може да вижда TTFB под 170 ms, докато потребители в Индия изпитват 3 пъти по-висок TTFB, а в Китай — почти 10 пъти по-висок (~1468 ms). Различията са шокиращи, когато ги видите за пръв път.

За сайтове с международна аудитория, CDN с глобални edge точки е абсолютна необходимост. Модерните CDN като Cloudflare, Fastly и AWS CloudFront предлагат:

300+ Points of Presence (PoP) по целия свят
Edge Functions за персонализация без връщане към origin
Smart Early Hints — машинно обучение за автоматично генериране на Early Hints (Cloudflare)
Origin Shielding — намалява натоварването на origin сървъра с 90–99%

Чеклист за TTFB оптимизация

Ето един бърз справочник, който можете да ползвате при оптимизация на вашия сайт:

Висок приоритет: Сървърно кеширане на пълни страници, CDN с edge caching, HTTP/3 + QUIC
Среден приоритет: Оптимизация на базата данни (индекси, обектен кеш), 103 Early Hints, актуализация на PHP/Node.js
Нисък приоритет (но важен): DNS оптимизация, минимизиране на redirect-и, Speculation Rules API
За Next.js/React: SSG/ISR вместо SSR, Streaming SSR с Suspense, Edge Runtime
Мониторинг: CrUX данни в PageSpeed Insights, Navigation Timing API за RUM, WebPageTest от множество локации

Често задавани въпроси

TTFB Core Web Vital метрика ли е?

Не, TTFB не е официална Core Web Vital метрика. Тя е диагностична метрика, която помага да разберете защо вашият LCP или FCP може да е бавен. Технически е възможно да преминете Core Web Vitals дори с TTFB над 800 ms, но на практика — висок TTFB почти винаги води до проблеми с LCP.

Какъв е добрият TTFB резултат?

Google препоръчва TTFB под 800 ms на 75-ия персентил. На практика обаче: под 100 ms е отличен, 100–200 ms е много добър, 200–500 ms е средно, а над 600 ms е проблем. За кеширани CDN отговори, стремете се към под 50 ms.

Как TTFB влияе на SEO класирането?

Google използва CrUX данни (включващи TTFB като компонент на LCP) като фактор за класиране. Макар TTFB да не е директен ranking signal, висок TTFB забавя LCP и FCP, което косвено влошава SEO класирането. Освен това бавните страници получават по-малко crawl budget от Googlebot — и това е по-голям проблем, отколкото повечето хора осъзнават.

Защо моят TTFB е добър в Lighthouse, но лош в CrUX?

Класически казус. Lighthouse измерва TTFB в контролирана лабораторна среда (обикновено от сървър близо до origin). CrUX обаче събира данни от реални потребители по целия свят — включително тези с бавен интернет, далечно местоположение или мобилни мрежи. За точна картина, винаги давайте приоритет на CrUX field data.

Мога ли да постигна TTFB от 0 ms?

Технически да — чрез Speculation Rules API. Предварително рендерираните страници показват 0 ms TTFB, защото цялата страница вече е заредена в скрит таб. За първоначалната навигация обаче, физически ограниченият от скоростта на светлината network round-trip означава, че винаги ще има минимален TTFB, определен от разстоянието до най-близкия CDN edge. Физиката си е физика.