TTFB optimizacija u 2026: Kako smanjiti Time to First Byte ispod 200 ms

Ažurirano: 10. lipnja 2026.

TTFB (Time to First Byte) je vrijeme od trenutka kada preglednik pošalje HTTP zahtjev do trenutka kada primi prvi bajt odgovora. Da biste prošli Core Web Vitals u 2026., treba ga držati ispod 800 ms na 75. percentilu, a idealno ispod 200 ms za stvarno brz dojam. U ovom vodiču pokazat ću točno gdje se ti milisekundi gube (DNS lookup, TLS handshake, čekanje na bazu, render-blocking SSR), pa kako ih vratiti. Svaki primjer dolazi s tragom iz Chrome DevToolsa i mjerljivim rezultatom.

• "Dobar" TTFB prema Google Core Web Vitals pragu je ispod 800 ms na p75; "loš" je iznad 1800 ms i blokira prolaz na LCP-u.
• TTFB se sastoji od pet faza: DNS, TCP, TLS, server processing i čekanje na prvi bajt. Svaku mjerite zasebno kroz Server-Timing zaglavlja.
• HTTP/3 (QUIC) eliminira head-of-line blocking i reže TCP+TLS fazu s 2–3 RTT-a na 1 RTT, što u stvarnim mrežama vrijedi 100–300 ms.
• CDN edge caching uz stale-while-revalidate direktivu pretvara TTFB iz "ovisi o originu" u "ovisi o najbližoj edge lokaciji", često ispod 50 ms.
• SSR i Edge funkcije moraju streamati odgovor (Transfer-Encoding: chunked) jer prvi bajt mora otići PRIJE nego baza vrati sve podatke.
• Mjerite TTFB kroz PerformanceNavigationTiming.responseStart - requestStart, ne kroz Lighthouse, koji simulira mrežu i ne odražava stvarne korisnike.

Što je TTFB i koja je dobra vrijednost u 2026.?

TTFB mjeri vrijeme od početka navigacije (kad korisnik klikne link ili upiše URL) do dolaska prvog bajta HTTP odgovora natrag u preglednik. Google ga koristi kao dijagnostičku metriku za Core Web Vitals. Nije sam direktan rangirajući signal, ali je tehnički preduvjet za dobar LCP. Ako TTFB iznosi 1500 ms, fizički je nemoguće postići LCP ispod 2.5 sekunde na bilo kojem realnom uređaju.

Pragovi koje Google koristi u službenom web.dev vodiču za TTFB za 75. percentil stvarnih korisnika su sljedeći:

Rang	TTFB (p75)	Što to znači
Dobar	≤ 800 ms	Server brzo odgovara; ostatak proračuna za LCP je realan
Treba poboljšati	800–1800 ms	Sumnja na probleme u backendu, DNS-u ili odsutnost CDN-a
Loš	> 1800 ms	LCP je gotovo zajamčeno loš; korisnici vide praznu stranicu

Pragmatičan cilj nije 800 ms, nego 200 ms na p75. Razlog je jednostavan: vrijeme do prvog bajta troši se na "ništa za korisnika", još uvijek nema piksela na ekranu. Svaka milisekunda ovdje je čisti gubitak proračuna LCP-a. U mojim profilima site-ova s dobro postavljenim Vercel ili Cloudflare CDN-om, p75 TTFB pada na 80–150 ms. Iskreno, kad jednom vidite tu brojku u proizvodnji, ne želite se vratiti.

Pet faza koje čine TTFB

Glavna greška inženjera je tretirati TTFB kao "vrijeme servera". TTFB je zapravo pet odvojenih faza, od kojih su tri prije nego što vaš server uopće vidi zahtjev:

1. DNS Lookup. Preglednik mora pretvoriti vasdomena.com u IP adresu. Cold lookup: 20–120 ms.
2. TCP Handshake. Tri paketa (SYN, SYN-ACK, ACK). Jedan RTT, tipično 30–80 ms.
3. TLS Handshake. Pregovaranje šifre i certifikata. TLS 1.3 = 1 RTT; TLS 1.2 = 2 RTT-a.
4. Server processing. Vaš backend obrađuje zahtjev: routing, autentikacija, query baze, render.
5. Wait time. Vrijeme dok prvi bajt putuje natrag kroz mrežu do preglednika.

Mjerenje samo "trajanja servera" promaši onih 200–400 ms u fazama 1–3. Zato uvijek mjerimo cijelih pet faza kroz Server-Timing zaglavlja i PerformanceNavigationTiming API.

Kako pravilno mjeriti TTFB

Postoje tri legitimna izvora za TTFB podatke, i samo jedan od njih odražava stvarne korisnike. Lighthouse vam neće reći istinu jer simulira mrežu s fiksnim throttlingom. To sam naučio na teži način kad sam mjesec dana "popravljao" TTFB koji je u Lighthouseu pao s 1.2 s na 400 ms, a CrUX podaci se nisu pomaknuli ni za milisekundu.

1. PerformanceNavigationTiming API (RUM)

Ovo je jedini pravi izvor istine. Mjeri ono što stvarni korisnici stvarno doživljavaju:

// Mjerenje TTFB-a u browseru
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'navigation') {
      const ttfb = entry.responseStart - entry.requestStart;
      const dns = entry.domainLookupEnd - entry.domainLookupStart;
      const tcp = entry.connectEnd - entry.connectStart;
      const tls = entry.connectEnd - entry.secureConnectionStart;
      const serverTime = entry.responseStart - entry.requestStart;

      // Šalji u svoj analytics
      navigator.sendBeacon('/rum', JSON.stringify({
        ttfb, dns, tcp, tls, serverTime,
        url: location.pathname,
      }));
    }
  }
}).observe({ type: 'navigation', buffered: true });

Za širu sliku kako TTFB utječe na druge metrike i kako agregirati p75 podatke, pogledajte naš vodič za INP optimizaciju i odzivnost weba, koji pokriva sličnu RUM pipeline logiku.

2. Server-Timing zaglavlja

Da biste znali ŠTO je unutar faze 4 (server processing) sporo, vratite Server-Timing iz backenda:

// Node.js / Express primjer
app.get('/api/post/:id', async (req, res) => {
  const t0 = performance.now();
  const post = await db.query('SELECT * FROM posts WHERE id=$1', [req.params.id]);
  const t1 = performance.now();
  const rendered = await renderTemplate('post', post);
  const t2 = performance.now();

  res.setHeader('Server-Timing',
    `db;dur=${(t1 - t0).toFixed(1)},` +
    `render;dur=${(t2 - t1).toFixed(1)},` +
    `total;dur=${(t2 - t0).toFixed(1)}`
  );
  res.send(rendered);
});

Ova zaglavlja vidite u Chrome DevTools → Network → vaš dokument → Timing tab. Pokazuju točno gdje milisekunde nestaju unutar servera. Specifikacija je definirana u W3C Server-Timing dokumentu, što je korisno ako gradite vlastiti monitoring sustav.

3. CrUX (Chrome User Experience Report)

Google objavljuje agregirane TTFB podatke za sve site-ove s dovoljno prometa. Za vlastiti site:

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

Što uzrokuje visok TTFB?

U mojim profilima posljednjih dvanaest mjeseci, evo distribucije uzroka kad TTFB pređe 1 s:

• Nepostojeći ili pogrešno konfiguriran CDN (≈35%). Svi zahtjevi idu na origin u jednoj regiji. Korisnik iz Sydneya čeka 250 ms RTT-a do Frankfurta.
• Neoptimizirani query baze (≈25%). N+1 query u SSR-u, missing index, ili sinkroni fetch eksternog API-ja prije render-a.
• Cold start serverless funkcije (≈15%). Lambda u VPC-u s cold startom od 800 ms+ jer čeka ENI.
• Render-blocking SSR (≈10%). Server čeka da se cijela stranica izrenderira prije nego pošalje prvi bajt, umjesto da streama.
• Loš TLS ili stari HTTP/1.1 (≈8%). TLS 1.2 s 2 RTT-a, ili origin koji ne podržava HTTP/2.
• Geografski daleki origin (≈7%). Server u us-east-1, korisnici u Aziji.

Kako smanjiti TTFB ispod 200 ms

Konkretan playbook, redoslijedom utjecaja u stvarnim site-ovima koje sam profilirao:

1. Stavite CDN ispred origin servera

Ne samo za statiku. Za HTML. Cloudflare, Vercel Edge, Fastly i Bunny svi cachiraju HTML s pravilnim Cache-Control direktivama. Detalji u sekciji CDN edge caching ispod.

2. Aktivirajte HTTP/3

QUIC eliminira head-of-line blocking i radi handshake u 1 RTT umjesto 2–3. Na Cloudflareu: dashboard → Network → HTTP/3 = ON. Na nginxu treba 1.25+ s --with-http_v3_module.

3. Eliminirajte DB waterfall

Pretvorite sekvencijalne pozive u paralelne:

// LOŠE — 4 sekvencijalna querya, ≈120 ms
const user = await db.getUser(userId);
const perms = await db.getPermissions(user.id);
const posts = await db.getPosts(user.id);
const related = await db.getRelated(posts[0].id);

// DOBRO, paraleliziraj što god se može, ≈40 ms
const [user, perms] = await Promise.all([
  db.getUser(userId),
  db.getPermissions(userId), // ne ovisi o useru
]);
const [posts, profile] = await Promise.all([
  db.getPosts(user.id),
  db.getProfile(user.id),
]);

4. Koristite resource hints na prvi paint

<!-- DNS lookup počinje prije nego što parser vidi resurs -->
<link rel="dns-prefetch" href="https://cdn.vasdomena.com">

<!-- DNS + TCP + TLS handshake unaprijed -->
<link rel="preconnect" href="https://cdn.vasdomena.com" crossorigin>

Ovo ne smanjuje TTFB samog dokumenta, ali smanjuje TTFB subresurse koji utječu na LCP. Za dublji uvid u to kako se TTFB povezuje s glavnom vizualnom metrikom, pogledajte naš vodič za LCP optimizaciju u 4 faze.

5. Predzagrijte serverless funkcije

Vercel Edge funkcije nemaju cold start. AWS Lambda da. Ako morate koristiti Lambdu, koristite Provisioned Concurrency za rute kritične za SSR, ili migrirajte na Cloudflare Workers (cold start < 5 ms).

CDN edge caching i stale-while-revalidate

Najveći pojedinačni dobitak za TTFB. Cilj: HTML se servira s edge lokacije udaljene 10 ms od korisnika, a ne s origin servera udaljenog 200 ms. Ključ je Cache-Control zaglavlje na HTML odgovoru:

Cache-Control: public, s-maxage=60, stale-while-revalidate=86400

Što ovo znači:

• s-maxage=60: CDN cachira 60 sekundi (browser ignorira; max-age bi cachirao u browseru, što ne želimo za dinamičan sadržaj).
• stale-while-revalidate=86400: sljedećih 24 sata, CDN služi stari sadržaj odmah, a u pozadini revalidira s origin servera. Korisnik nikad ne čeka origin.

Rezultat: 99%+ zahtjeva servira se s edgea u 30–80 ms, a 1% (revalidation) plaća punu cijenu odlaska na origin. Ali korisnik tog 1% ne čeka. Detaljan opis ovih direktiva nalazi se u RFC 5861.

HTTP/3, QUIC i 0-RTT

HTTP/3 koristi QUIC umjesto TCP+TLS, što rješava dva problema istovremeno:

• 1 RTT handshake umjesto 2–3 RTT-a (TCP SYN + TLS). Na 100 ms RTT vezi, ušteda od 100–200 ms.
• Nema head-of-line blockinga. Gubitak jednog paketa ne blokira ostale tokove. Bitno za mobilne mreže s 1–3% loss rate.
• 0-RTT resumption. Vraćajući korisnici šalju zahtjev u prvom paketu, bez handshake-a.

U praksi, prelazak s HTTP/2 na HTTP/3 daje 50–150 ms ušteđenog TTFB-a za p75 mobilne korisnike, prema podacima koje Cloudflare objavljuje o HTTP/3 performansama. Provjerite je li aktivan kroz Chrome DevTools → Network → Protocol stupac (treba pisati "h3"). Ako piše "h2", server šalje krivi Alt-Svc ili klijent ne podržava QUIC.

SSR streaming i edge funkcije

Klasični SSR sastavi cijeli HTML pa pošalje. Streaming SSR šalje <head> i početak <body> ČIM su gotovi, pa server piše dalje kako podaci stižu. TTFB pada s "vrijeme cijelog rendera" na "vrijeme do prvih bajtova HTML-a", često 10× brže.

U React 19 + Next.js 15:

// app/posts/[id]/page.tsx
import { Suspense } from 'react';

export default function PostPage({ params }) {
  return (
    <article>
      {/* Header se renderira odmah i šalje se u prvom chunku */}
      <Header />
      <Suspense fallback={<Skeleton />}>
        {/* Spori dio se streama kasnije */}
        <PostContent id={params.id} />
      </Suspense>
    </article>
  );
}

Sa streaming SSR-om, prvi bajt ide van čim Next.js izrenderira layout shell, često za 30–50 ms, a spori dijelovi se hidriraju iz Suspense streama. TTFB metrika pada s 800 ms na 80 ms iako server radi isti posao. I usput, ako vas zanima kako se ovo veže na vizualnu stabilnost stranice, pogledajte naš vodič za CLS optimizaciju, jer streaming bez stabilnog layouta zna pogoršati layout shift.

TTFB vs LCP vs FCP: razlike i veze

Tri metrike često se brkaju jer mjere uzastopne događaje:

Metrika	Mjeri	Tipičan udio TTFB-a
TTFB	Prvi bajt HTML-a stigne u preglednik	100%
FCP	Prvi piksel (bilo koji) renderiran	TTFB + 100–400 ms
LCP	Najveći vidljivi element renderiran	TTFB + 400–2000 ms

Matematički: LCP >= FCP >= TTFB. Uvijek. Ako vam je TTFB 1.2 s, ne možete imati LCP od 2 s, fizički je nemoguće. Zato je TTFB "donja granica" svih ostalih vizualnih metrika i prva stvar koju gledamo prije optimizacije bilo čega drugog.

Često postavljana pitanja

Koja je dobra TTFB vrijednost za Core Web Vitals?

Google smatra TTFB "dobrim" ako je ispod 800 ms na 75. percentilu stvarnih korisnika. U praksi, da biste imali "dobar" LCP (ispod 2.5 s), trebate TTFB ispod 200–400 ms, jer LCP uključuje TTFB plus vrijeme rendera resursa.

Utječe li TTFB direktno na SEO?

TTFB nije direktan rangirajući signal, ali je dijagnostička metrika za LCP, koji JEST signal Core Web Vitalsa. Visok TTFB matematički garantira loš LCP, što šteti vašem rangu. Drugim riječima: indirektno, ali snažno.

Razlikuje li se TTFB između desktop i mobile korisnika?

Da, značajno. Mobile korisnici imaju veće RTT-ove (50–200 ms na 4G/5G u odnosu na 10–30 ms na fiksnom) i češći gubitak paketa. TTFB na mobile p75 tipično je 1.5–2× veći nego na desktopu. Zato HTTP/3 najviše pomaže baš mobilnim korisnicima.

Mogu li popraviti TTFB bez mijenjanja backenda?

Često da. Postavljanjem CDN-a ispred origin servera (Cloudflare, Vercel, Fastly) i postavljanjem Cache-Control: s-maxage=60, stale-while-revalidate=86400 na HTML odgovor. CDN preuzima TTFB i servira keširani HTML s edgea u 30–80 ms bez ikakvih izmjena na vašem serveru.

Zašto Lighthouse pokazuje drugačiji TTFB od mojih RUM podataka?

Lighthouse simulira mrežu s fiksnim throttlingom (150 ms RTT, 1.6 Mbps download) i pokreće test iz jedne lokacije. Stvarni korisnici imaju različite mreže, lokacije i caching stanja. Uvijek vjerujte RUM podacima i CrUX-u, ne Lighthouseu, za stvarnu sliku TTFB performansi.