TTFB: når problemet er serveren

Der er én skillelinje der afgør hvor du skal lede: er tiden brugt på serveren, eller er den brugt i browseren?

Og så er der en skillelinje mere, som er lige så vigtig og som langt de fleste springer over: tiden på serveren er ikke nødvendigvis hostens skyld. Dit tema, dine plugins og dine databaseforespørgsler kører på den server, og de tæller med i det samme tal. Jeg har mange gange fået TTFB ned alene ved at rydde op i tema og plugins, uden at hosten blev rørt.

TTFB er tallet der svarer på det. Time to First Byte måler tiden fra browseren beder om siden, til det første byte af svaret kommer tilbage. Der er ikke tegnet en eneste pixel endnu — det er ren ventetid, og den ligger foran alt andet du måler.

Vurdering	TTFB
God	0,8 sekund eller under
Kan forbedres	0,8–1,8 sekunder
Dårlig	Over 1,8 sekunder

Det vigtige ved TTFB er ikke tallet i sig selv. Det er at hvert eneste andet tal starter bagefter. Bruger du 1,5 sekund på at vente, kan du ikke få en LCP på 2,5 sekunder uden at tegne hele siden på ét sekund.

Hvad ventetiden består af

TTFB er ikke ét tal, men en stak:

Redirects. Hver 301 undervejs er en hel ekstra rundtur. En URL der først går fra http til https og derefter fra uden www til med, har brugt to — før serveren har lavet noget som helst.

DNS-opslag. Første gang browseren skal finde ud af hvilken server domænet peger på.

Forbindelse og TLS. At åbne forbindelsen og forhandle certifikatet.

Serverens egen arbejdstid. WordPress starter PHP, spørger databasen, kører temaets funktioner og hvert aktivt plugin igennem, og sætter HTML’en sammen.

Det sidste punkt er næsten altid det største — og det er dét der gør, at TTFB ikke er et tal du bare kan sende videre til din udbyder. Det meste af den tid er din egen kode. Et tungt tema med en indbygget sidebygger skal sætte layoutet sammen ved hver sidevisning. Et plugin med dyre forespørgsler kan alene lægge hundreder af millisekunder på. Det er arbejde der foregår på serveren, men det er ikke serverens skyld.

Sådan afgør du hvor problemet sidder

Her er testen. Den tager to minutter, og den afgør resten.

Trin 1: mål TTFB på en side der er i cachen. Besøg forsiden to gange, og mål anden gang. Er der sidecache på, får du en cachet version.

Trin 2: mål TTFB på en side der ikke kan være i cachen. Læg en tilfældig parameter på URL’en — ?nocache=1 eller ?12345 — så cachen ikke rammer, og siden bliver bygget forfra.

Sammenlign de to tal:

• Begge er lave (under 300 ms). Serveren er fin. Din langsomhed sidder i browseren — billeder, JavaScript, render-blocking ressourcer. Læs Hvorfor er min WordPress-hjemmeside langsom?
• Cachet er lav, ucachet er høj. Det almindelige billede. Cachen dækker over en langsom side. Læs videre — afsnittet om hvorfor det skal rettes alligevel er til dig.
• Begge er høje. Der er ingen sidecache, eller den virker ikke. Det er første opgave.
• Cachet er høj, ucachet er lav. Sjældent, men det sker: cachen ligger et sted der er langsommere end serveren selv, typisk et forkert opsat CDN.

Cachen dækker over problemet — ryd det alligevel

Med HTML-cache på falder TTFB til under 80–150 millisekunder i de fleste tilfælde. Det gælder også på sider hvor den samme URL uden cache tager flere sekunder. Arbejdet bliver ikke gjort hurtigere — det bliver ikke gjort.

Og her kommer en holdning, som ikke alle deler: du skal have TTFB uden cache ned omkring de 800 millisekunder, helst lavere — også når cachen dækker over det.

Grunden er at cachen ikke altid er der:

• Den første besøgende efter en tømning betaler den fulde pris. Det sker hver gang du opdaterer et indlæg eller retter et produkt.
• Sider der aldrig må caches har intet at falde tilbage på. På en webshop er det kurv, kasse og Min konto — præcis de sider hvor kunden er tættest på at betale.
• Indloggede brugere får som regel siden serveret udenom cachen.
• Google crawler også de sider ingen har besøgt. En URL langt nede i arkivet ligger sjældent i cachen når crawleren rammer den.
• Din egen administration kører altid uden sidecache. En langsom side bagved er langsom hver eneste gang du selv arbejder i den.

En side der er hurtig både med og uden cache er robust. En side der kun er hurtig med cache ser fin ud i en test og falder sammen præcis når det gør ondt.

Det du selv kan rette

Rækkefølgen er den samme hver gang:

1. Slå sidecache til. Ét plugin, ikke to. Se To cache-plugins er værre end ét.
2. Fjern unødige redirects. Læg dem i ét hop frem for to. Tjek særligt om dit domæne redirecter to gange på vej til den kanoniske adresse.
3. Ryd op i plugins. Hvert aktivt plugin kører ved hver sidevisning, også på sider hvor det ikke bruges. Se Hvad koster hvert plugin dig i hastighed?
4. Kig på temaet. Det er den del folk oftest overser, fordi temaet mest opfattes som design. Men temaets PHP kører ved hver sideopbygning, og et tungt multipurpose-tema med indbygget bygger koster reel tid her — ikke kun i browseren. Se Skal du skifte tema for at få fart på?
5. Læg objektcache på — Redis eller Memcached — hvis siden er stor eller har mange indloggede. Det er den der hjælper dér hvor sidecache ikke kan.
6. Ryd op i databasen. Gamle revisioner, udløbne transients og logtabeller der er vokset i årevis. På en webshop er det ofte ordrer og sessioner.
7. Sæt et CDN foran, hvis du har besøgende uden for landet.

Hvornår det er hosten

Her er pointen: du kan først sige at det er hosten, når du har prøvet det ovenstående. Går man den anden vej og skifter udbyder først, flytter man ofte den samme langsomme opsætning over på en hurtigere maskine og bliver skuffet over hvor lidt der skete.

Når du har gjort alt ovenstående og ucachet TTFB stadig ligger over halvandet sekund, er det maskinen. Så er der to spørgsmål værd at stille din udbyder:

Hvor mange sider deler den server jeg ligger på? På et billigt delt webhotel kan der ligge hundredvis. Din side kæmper om CPU’en med naboer du ikke kender, og du kan ikke optimere dig ud af det.

Hvilken PHP-version kører jeg? Springet fra PHP 7.4 til 8.x er mærkbart på WordPress, og gamle versioner får hverken sikkerhedsrettelser eller hastighedsforbedringer.

Ligger din server desuden fysisk langt fra dine besøgende, betaler du afstanden ved hver rundtur, uanset hvor hurtig maskinen er. En dansk målgruppe hører hjemme på en server i Danmark eller Nordeuropa.

Vil du vide hvor din side ligger, før du taler med hosten, så kør en hastighedsanalyse. Så står tallene sort på hvidt.

Ofte stillede spørgsmål

Er TTFB en rankingfaktor?

Ikke direkte. TTFB er ikke et Core Web Vital, og Google måler det ikke som selvstændigt signal. Men fordi TTFB ligger foran LCP, som er et Core Web Vital, kan en høj TTFB koste dig på et tal der tæller.

Kan jeg selv gøre noget ved TTFB, eller er det hostens bord?

Du kan gøre en hel del. Sidecache, oprydning i plugins, et lettere tema, objektcache og en ryddet database flytter alt sammen TTFB, og de har intet med din udbyder at gøre. Først når du har gjort det og stadig ligger højt, er det maskinen der er flaskehalsen.

Hvad er en normal TTFB for WordPress?

Med sidecache på en fornuftig dansk host er 200–400 millisekunder helt almindeligt, og under 150 ms er opnåeligt. Uden cache afhænger det af hvor mange plugins der skal køres igennem — jeg ser alt fra 400 ms til over fem sekunder.

Kan et CDN redde en langsom server?

Delvist. Et CDN kan cache HTML’en på kanten og svare uden at spørge din server overhovedet — så er TTFB lav for de besøgende der rammer cachen. Men de sider der ikke må caches går stadig hele vejen hjem, og der er du tilbage ved serverens egen svartid.