Kort svar: TTFB (Time To First Byte) er tiden fra browseren beder om en side, til den første byte af svaret ankommer – summen af DNS-opslag, forbindelse, TLS og frem for alt serverens tænketid. Den er gulvet under alle andre hastighedstal: intet kan vises, før første byte er fremme. Tommelfingerregler: under 200 ms er stærkt, 200-500 ms fint, over 800 ms et problem, der skal findes. For WordPress er høj TTFB næsten altid manglende servercache eller en overbelastet server – ikke temaet.
Fire poster lægges sammen: DNS-opslaget (hvor bor serveren?), TCP-forbindelsen, TLS-håndtrykket (krypteringen) – og så serverens egen behandlingstid, som for WordPress vil sige PHP og database, medmindre en cache svarer i stedet. De tre første er typisk 50-150 ms tilsammen og svære at flytte ret meget; den fjerde kan svinge mellem 10 ms (cache-hit) og flere sekunder (tung, ucachet side på presset server). Derfor er TTFB-optimering i praksis næsten altid server- og cachearbejde.
Mål altid FLERE sider, ikke kun forsiden: forsiden ligger stort set altid varm i cachen, mens den dybe produktside, en kunde lander på fra Google, kan være kold. Og mål både første og andet kald på samme URL – falder tiden markant på kald to, virker cachen, men for få sider ligger i den. I browseren finder du samme tal i PageSpeed Insights („serverens svartid“) og i Netværk-fanen; feltdata i Search Console viser, hvad rigtige besøgende oplever over tid.
TTFB sætter loftet for Core Web Vitals (LCP kan aldrig blive bedre end TTFB + rendering), påvirker crawl-budget – og er blevet dobbelt vigtig, fordi AI-søgetjenesters hentere opgiver langsomme sider. Rangordenen, når tallet er for højt: 1) få servercache til at dække de offentlige sider, 2) tjek om serveren har luft (CPU/RAM – eller om du er vokset ud af planen), 3) jagt langsomme databasekald med Query Monitor. Hosting med LiteSpeed og NVMe-diske – som hos Hostious – flytter grundniveauet for alle tre.
Nej – det er starttiden. Derefter kommer download, rendering, billeder og scripts. Men fordi alt andet venter på første byte, mærkes høj TTFB på ALT – og lav TTFB gør resten af optimeringen synlig.
Fordi test rammer varme, cachede sider, mens rigtige besøgende også rammer kolde. Feltdata er gennemsnittet af begge – løsningen er højere cache-dækning og længere levetider, ikke flere tests af forsiden.
På statiske filer og kant-cachet HTML, ja – især for fjerne besøgende. På dynamiske sider, der stadig skal bygges på origin, flytter det lidt eller intet: dér er servercache og serverkraft svaret.
