TTFB w PageSpeed Insights jest dobry, ale realni użytkownicy doświadczają wolniejszego — dlaczego?

PSI testuje z lokalizacji zwykle bliskiej serwerowi. CrUX pokazuje field data — Twoich realnych użytkowników w różnych geolokalizacjach. Różnica może wynosić sekundy, jeśli serwer jest np. w US, a użytkownicy w Polsce. Patrz na field, nie na lab.

Czy SSL/HTTPS spowalnia TTFB?

Tak, o ~100–300 ms (TLS handshake). Ale z HTTP/2, TLS 1.3 i session resumption to akceptowalny narzut. Korzyści (bezpieczeństwo, sygnał rankingowy, HTTP/2 multipleksowanie) zdecydowanie przewyższają koszt.

Jaki TTFB jest realistyczny dla WordPressa?

Bez cache: 800 ms–2 s. Z cache (np. WP Rocket, Cloudflare APO, Hummingbird): 100–300 ms. Cache na poziomie page'a transformuje WP z wolnego CMS w stronę statyczną pod kątem TTFB — i to bez ingerencji w kod.

Czy ISR w Next.js daje dobry TTFB?

Tak, bardzo dobry. Strony są wstępnie wygenerowane jako HTML i serwowane z edge cache (Vercel) — TTFB schodzi do 50–100 ms. Pierwszy request po revalidate jest wolniejszy (regeneracja), ale kolejne są błyskawiczne. Optymalne dla blogów i stron firmowych.

TTFB (Time to First Byte)

TTFB (Time to First Byte) to czas od wysłania żądania HTTP do otrzymania pierwszego bajta odpowiedzi z serwera. Mierzy wszystko, co dzieje się po stronie backendu — DNS, TCP, TLS, processing serwerowy, sieć. Bez dobrego TTFB nie ma dobrego LCP.

Cel

Google nie traktuje TTFB jako oddzielnego ranking signala, ale rekomenduje próg ≤ 800 ms. Dla dynamicznych stron 200–600 ms to dobry przedział, dla statycznych z CDN — 50–200 ms. Powyżej 1 sekundy zaczyna się problem dla LCP, bo cały budżet czasu zjada backend.

Co składa się na TTFB

DNS lookup (50–200 ms przy zimnym cache, < 1 ms przy ciepłym).
TCP handshake (~jeden round-trip).
TLS handshake (~dwa round-tripy bez TLS 1.3, jeden z TLS 1.3).
Server processing — generowanie HTML (queries do DB, renderowanie templatek, integracje API).
Network transit — odległość użytkownika od serwera (Polska → Frankfurt to ~20 ms, → US to ~150 ms).

Co najczęściej psuje TTFB

Dynamiczne strony bez cache (każdy request odpala SQL i renderowanie templatek). Backend w PHP z setkami queries N+1. Hosting daleko od użytkowników (US server, polski ruch). Brak CDN. Cold starty serverless (1–3 sekundy na bootowanie funkcji). Wolne API third-party w trakcie SSR. Blokujące middleware w Next.js / Express.

Jak poprawić

Włącz cache (Redis, in-memory, full-page cache na poziomie reverse proxy). Optymalizuj queries — indexy, eliminacja N+1, prepared statements. Wstaw CDN (Cloudflare, Vercel Edge, AWS CloudFront). Dla Next.js: ISR z odpowiednim revalidate. HTTP/2 i HTTP/3 (mniej round-tripów). HSTS preload (eliminacja redirectu http → https). Connection: keep-alive.

Cel