Du klickar på en länk, och webbläsaren bara sitter där. Ingen sidladdning, ingen förloppsindikator, bara en vit skärm och väntan. Det här handlar inte om din internethastighet eller långsam JavaScript. Det här är TTFB: tiden det tar för servern att svara på den allra första förfrågan.

TTFB avgör när användare överhuvudtaget får se något på sin skärm. Med långsam TTFB lämnar besökare innan din webbplats ens har börjat renderas. Och från och med 2025 inkluderar Google serverns svarstid i sina rankningssignaler Core Web Vitals.

Här nedan får du veta vad TTFB egentligen är, vilka fyra komponenter det består av och hur du får ner det till en nivå där din webbplats levererar den första byten snabbare än en användare hinner blinka.

💡 Snabb översikt:

• Förstå vad TTFB är och varför varje sekund av denna fördröjning multipliceras över varje besökarinteraktion.
• Gå igenom kedjan av fyra faktorer: DNS, server, WordPress-tillägg och HTML-cachning.
• Jämför fyra scenarier med verkliga Pingdom-mätningar, från 150 ms till katastrofala 4,2 sekunder.
• Aktivera HTML-cachning och se hur ett enda tillägg minskar TTFB dramatiskt utan att byta webbhotell.

Vad är TTFB och varför påverkar det allt

Den formella definitionen från Wikipedia: TTFB är tiden från att en HTTP-förfrågan skickas tills den första byten av svaret tas emot i klientens webbläsare. Det inkluderar latens för socket-anslutning, tid för överföring av förfrågan och serverns bearbetningstid.

Enklare uttryckt: TTFB är pausen mellan "att klicka på en länk" och "något börjar hända på webbplatsen". I speltermer är det latens, ping, fördröjningen före det första svaret. Användare ser ingen sidhuvud, ingen meny, ingen laddningssnurra, bara en tom flik. Ju längre denna paus är, desto större är chansen att de stänger fliken.

En viktig nyans: TTFB påverkar mer än bara den första sidladdningen. Varje intern navigering, varje klick på en menylänk, varje klick på en bild i ett inlägg, är var och en en separat HTTP-förfrågan med sin egen TTFB. Ett dåligt värde multipliceras över varje läsarinteraktion.

Fyra faktorer som bygger upp TTFB

TTFB är inte ett enskilt mätvärde utan en summa av fördröjningar i varje steg av kedjan "användare → webbplats". Alla fyra länkar arbetar sekventiellt: om en saktar ner, saktar slutresultatet också ner. Låt oss granska var och en.

DNS: den första kontrollpunkten

Webbläsaren vet inte var din server fysiskt finns förrän DNS omvandlar domänen till en IP-adress. Bra DNS-servrar med ett distribuerat nätverk av noder gör detta på millisekunder, medan dåliga lägger till tiotals eller hundratals millisekunder på varje sidladdning.

Praktiskt minimum: använd Cloudflare eller en liknande tjänst med global DNS-cachning. Efter den första förfrågan ligger adressen kvar i cachen, och DNS-latensen försvinner helt för efterföljande förfrågningar.

Server och PHP: vad som händer hos webbhotellet

Varje förfrågan till en icke-cachad WordPress-sida startar PHP-tolken. Servern laddar kärnan, temat och aktiva tillägg, kör deras kod och levererar först därefter HTML-koden. Moderna PHP-versioner hanterar denna cykel mycket snabbare än versioner från för tio år sedan, för att inte tala om helt föråldrade grenar.

Två webbhotellsparametrar avgör hastigheten: PHP-version och den CPU-tid som tilldelas din plan. Billig delad hosting med dussintals webbplatser på en server och föråldrad PHP är en garanterad väg till TTFB > 1 sekund. Specialiserad WordPress-hosting med PHP 8.2+ och inbyggd cachning på servernivå levererar fundamentalt andra siffror.

WordPress-tillägg och tema

WordPress sätter ihop sidor från dussintals PHP-filer, och varje aktivt tillägg lägger till sin kod i denna process. Tio kvalitetstillägg från ansedda utvecklare kan knappt påverka TTFB. Ett enda dåligt skrivet tillägg som gör tre extra databasfrågor vid varje förfrågan kan sänka hela din webbplats hastighet.

Här är ett exempel på en vettig tilläggsuppsättning, allt som behövs, inget överflödigt:

Och detta är redan en potentiellt problematisk konfiguration. Flera dussin aktiva tillägg, och servern måste bearbeta vart och ett när sidan genereras:

I praktiken innebär fler än 30 aktiva tillägg nästan garanterat hög TTFB, även på bra hosting. Regeln är enkel: varje tillägg ska utföra en specifik uppgift som inte kan lösas på annat sätt. Allt som finns där "för säkerhets skull" ska tas bort.

HTML-cachning: den viktigaste hävstången

Den mest kraftfulla faktorn av alla. Ett cachningstillägg som Cache Enabler sparar färdiga HTML-kopior av sidor på serverns disk. När en förfrågan kommer in levererar webbservern en statisk fil, och går förbi hela PHP- och WordPress-stacken.

Resultatet: servern behöver inte längre ladda kärnan, temat och tilläggen för varje besökare. Bara själva webbservern (nginx eller Apache) levererar innehåll direkt. Det är därför cachning ger den mest betydande minskningen av TTFB, i faktorer snarare än procent. Vi gick igenom varför nginx är effektivare än Apache för den här uppgiften i en separat artikel.

TTFB i praktiken: fyra scenarier

Låt oss gå över till verkliga mätningar. Nedan finns testresultat för olika kombinationer av webbplats och server, hämtade via Pingdom Tools. Varje scenario visar TTFB för både ocachad och cachad version.

Långsam webbplats på en långsam server

Den sämsta tänkbara kombinationen: en webbplats med dussintals tillägg och ingen cachning på ett gammalt delat webbhotell med PHP 5.4.

Låt oss expandera detaljerna för den första förfrågan, där du kan se servern tänka i en evighet:

TTFB är 4,2 sekunder. Fyra sekunder där användaren stirrar på en tom skärm innan webbläsaren får någon data alls. Lägg till sidrenderingstid ovanpå det, så når den totala väntetiden tills webbplatsen är klar lätt sju sekunder. Cloudflare framför hjälper inte här: problemet ligger djupare, på webbhotells- och webbplatskodnivå.

Snabb webbplats på en medelsnabb server

Ändrade förutsättningar: en webbplats med minimalt antal tillägg, server på Apache med en standardversion av PHP, ingen cachning.

Resultat: 521 ms. Redan 8 gånger bättre än det första scenariot. En halv sekund till första byte, acceptabelt för de flesta webbplatser. Låt oss nu aktivera cachning:

TTFB sjunker till 152 ms. Även medelbra webbhotell med korrekt konfigurerad cachning levererar utmärkta resultat.

Långsam webbplats på en snabb server

Den omvända situationen: en optimerad server på Plesk med nginx och en standardversion av PHP, men en tilläggstung webbplats.

Utan cache spenderar den snabba servern ändå 1,29 sekunder på att bearbeta den tunga webbplatsen. Bra webbhotell mildrar men löser inte problemet med dåligt optimerad WordPress.

Aktivera cachning, så sjunker TTFB till 400 ms. Mer än tre gångers skillnad.

Snabb webbplats på en snabb server

Det optimala scenariot: en lättviktig webbplats på bra webbhotell.

Utan cache levererar servern den första byten på under 500 ms. Lägg till cachning:

Resultat: under 150 ms. Praktiskt taget omedelbar respons.

Resultatsammanfattning

Alla fyra scenarier i ett enda diagram:

Slutsatsen från dessa mätningar är enkel: hosting spelar roll, men vad du gör med själva sajten påverkar TTFB mer. En snabb server med cache kan dra ner även en problematisk sajt till acceptabla 400 ms, medan en långsam server utan cache sänker även en lättviktig WordPress.

Så förbättrar du TTFB: steg-för-steg-plan

Optimering går från enkelt till komplext, från det som tar fem minuter och ger maximal effekt till finare justeringar.

Steg 1: aktivera HTML-cachning. Installera det kostnadsfria Cache Enabler eller ett liknande cachningstillägg. Denna enda åtgärd minskar TTFB dramatiskt på vilket webbhotell som helst. Utan överdrift, den högsta avkastningen per ansträngd minut inom all WordPress-optimering.

Steg 2: kontrollera din PHP-version. I ditt webbhotells adminpanel eller cPanel, leta reda på inställningen för PHP-version. Om en aktuell version finns tillgänglig (8.2 eller nyare), byt till den. Att gå från en föråldrad gren till en modern snabbar märkbart upp bearbetningen av varje förfrågan. Innan du byter, försäkra dig om att ditt tema och alla tillägg är kompatibla med den valda versionen.

Steg 3: granska dina tillägg. Inaktivera allt som inte används aktivt just nu. Behåll bara tillägg som löser en specifik uppgift. Allt annat bör raderas, inte bara avaktiveras. Tillägg som sparas "för framtida bruk" eller "kan vara bra att ha" lägger till kod i varje förfrågan oavsett om du använder dem eller inte.

Steg 4: välj ett snabbt tema. Temat avgör hur mycket PHP-kod som körs vid varje sidladdning. Tunga teman med visuella sidbyggare genererar betydligt mer serverarbete än minimalistiska lösningar. Om ett TTFB-test på en ren WordPress-installation (inga tillägg, standardtema) visar ett bra resultat, men värdet sjunker kraftigt efter att du aktiverat ditt tema, ligger problemet i själva temat.

Steg 5: utvärdera ditt webbhotell. Om TTFB fortfarande överstiger 500-800 ms efter de första fyra stegen, ligger begränsningen på webbhotellets sida. Specialiserad WordPress-hosting med nginx, PHP 8.2+ och cachning på serversidan ger en fundamentalt annan svarsnivå. När du väljer, leta efter inbyggd objektcachning (Redis eller Memcached), vilket är nästa nivå efter HTML-cachning.

Video: TTFB från teori till resultat

Se en visuell genomgång av TTFB med live-mätningar före och efter optimering:

⁉️🤔 Vanliga frågor

Vilken TTFB anses vara bra för WordPress?

Använd Google Core Web Vitals målvärden som riktlinje: upp till 800 ms är acceptabelt, upp till 500 ms är bra, upp till 200 ms är utmärkt. I praktiken, för en WordPress-sajt med cachning, är det uppnåbara intervallet 100-400 ms. Utan cachning går även en snabb sajt sällan under 400-500 ms.

Är det obligatoriskt att byta webbhotell för att förbättra TTFB?

Inte alltid. HTML-cachning minskar TTFB dramatiskt även på medelmåttiga webbhotell. Innan du migrerar, aktivera cachning, uppdatera PHP till en aktuell version och rensa upp bland tillägg. Om TTFB fortfarande ligger över 800 ms efter det, då är det verkligen dags att byta webbhotell.

Varför varierar TTFB från mätning till mätning?

TTFB påverkas av serverns CPU-belastning vid mättillfället, nätverkslatens och testserverns geografiska plats. Gör en serie på 5-7 mätningar och använd medianvärdet, inte det första slumpmässiga värdet. Testa från flera platser: en server i Europa kan visa utmärkt TTFB från Frankfurt men dålig från Tokyo.

Påverkar TTFB Googles rankning?

Ja, från och med 2025 är serversvarstid en del av Core Web Vitals som en rankningssignal. Den direkta påverkan är måttlig, men den indirekta påverkan är betydande: hög TTFB ökar avvisningsfrekvensen, och hög avvisningsfrekvens skadar rankningen direkt.

Kan jag mäta TTFB gratis?

Ja. Använd Pingdom Tools, GTmetrix, PageSpeed Insights eller WebPageTest. Viktig nyans: mät specifikt TTFB (time to first byte), inte total sidladdningstid. I Pingdom behöver du expandera detaljerna för den första förfrågan till sajten för detta.

Vad du ska göra åt TTFB just nu

Den viktigaste slutsatsen från mätningarna ovan: HTML-cachning är den mest kraftfulla och enklaste hävstången. Ett enda tillägg minskar TTFB dramatiskt på vilket webbhotell som helst, och det tar exakt fem minuter.

Åtgärdsordningen är som följer:

• Om TTFB > 1 sekund, börja med cachning och uppdatering av PHP. Dessa två steg står för det mesta av den möjliga förbättringen.
• Om TTFB ligger mellan 400 och 800 ms, eliminerar en tilläggs- och temagenomgång vanligtvis den återstående fördröjningen.
• Om TTFB konsekvent ligger under 200 ms, befinner du dig i den optimala zonen; bibehåll den nuvarande nivån.

Börja med ett kostnadsfritt cachningstillägg: installera, aktivera och kör ett test via Pingdom Tools. Du kommer att se skillnaden omedelbart. Vad är din nuvarande TTFB? Dela dina siffror i kommentarerna.