Vad gör en webbplats långsam, och hur mäter du det?

Modul 6: Hastighet · Lästid: 9 minuter

Lärandemål: Efter den här lektionen kan du mäta var tiden tar vägen och känna igen skillnaden mellan fördröjning på servern och fördröjning i webbläsaren.

Nyckelbegrepp: TTFB, Core Web Vitals (LCP, INP, CLS), labbdata, fältdata, PageSpeed Insights, nätverksfliken, komprimering, externa skript, webbhotellpaketets gränser, 503

Mät först, pyssla sedan

"Webbplatsen är långsam" kan ha tio olika orsaker. Den som utan att mäta installerar ett cachetillägg, ett bildoptimeringstillägg och ett större paket samtidigt vet efteråt inte vad som hjälpte, och har tre saker till att hålla koll på. Börja därför alltid med tre frågor (samma som i din webbhotells guide):

Allt är långsamt, eller bara administrationen? En långsam administration med en snabb framsida tyder på tillägg som gör mycket i administrationen, eller på bottar som angriper inloggningssidan.
Alltid, eller vid vissa tillfällen? Bara under högtrafik eller när en schemalagd uppgift körs: då når ditt paket sina gränser.
Hos alla, eller bara hos dig? Prova på din telefon via 4G eller 5G, eller be någon annan testa. Är det bara långsamt hos dig beror det på din anslutning eller VPN.

Två halvor: server och webbläsare

Tiden en besökare väntar består av två delar (lektion 1.2):

Servern skapar HTML:en: webbserver, PHP, tillägg, databas. Det ser du som TTFB (time to first byte), tiden tills det första bytet av svaret kommer. web.dev anger som tumregel att de flesta webbplatser bör sträva efter en TTFB på 0,8 sekunder eller mindre.
Webbläsaren läser den HTML:en och hämtar sedan allt som finns i den: stilmallar, skript, teckensnitt, bilder, video, mätkoder, chattwidgetar. Först när tillräckligt mycket av det har hämtats ser besökaren något.

En hög TTFB löser du på serversidan: caching (lektion 6.2), färre eller lättare tillägg, en nyare PHP-version, en städad databas (lektion 6.3) eller mer processorkraft. En låg TTFB med ändå en långsam sida pekar mot webbläsarsidan: för stora bilder, för många skript, externa komponenter.

Core Web Vitals

Google mäter besökarupplevelsen med tre mätvärden, Core Web Vitals:

Mätvärde	Vad det mäter	Bra om
LCP (Largest Contentful Paint)	Hur snabbt den största delen av innehållet (ofta den stora bilden eller rubriken) blir synlig	2,5 sekunder eller mindre
INP (Interaction to Next Paint)	Hur snabbt sidan reagerar när du klickar, trycker eller skriver	200 millisekunder eller mindre
CLS (Cumulative Layout Shift)	Hur mycket sidan hoppar till under laddningen	0,1 eller mindre

INP ersatte i mars 2024 det äldre mätvärdet FID. Google använder dessa mätvärden bland annat vid rankning av sökresultat, men den viktigaste anledningen att förbättra dem är enkel: besökare lämnar en långsam eller hoppig sida.

Labbdata och fältdata

Det finns två typer av mätningar, och de ger olika siffror:

Labbdata: ett test vid ett tillfälle, från en plats, med en simulerad telefon och anslutning. Praktiskt för att jämföra (före och efter en ändring), men det är ingen verklig besökare.
Fältdata: mätningar hos verkliga besökare med Chrome, över de senaste 28 dagarna. Det är vad besökare verkligen upplever. Mindre webbplatser har ofta för få besökare för fältdata.

PageSpeed Insights (pagespeed.web.dev) visar båda: högst upp fältdata (om de finns), därunder ett labbtest med en poäng och konkreta råd. Titta inte blint på poängen från 0 till 100. Titta på de enskilda delarna: är LCP dåligt för att servern är långsam (TTFB) eller för att den stora bilden är 3 MB?

Testa alltid några gånger (siffrorna varierar) och testa även en vanlig sida, inte bara startsidan.

Undersök själv med webbläsaren

Din webbläsares utvecklarverktyg (F12) visar vad som verkligen händer:

Nätverksfliken: uppdatera sidan med cachen avstängd (kryssrutan "Disable cache" eller liknande). Du ser varje fil som laddas, hur stor den är och hur lång tid den tog. Sortera efter storlek: de största filerna är ofta bilder. Sortera efter domän: hur mycket kommer från andra parter (teckensnitt, mätkoder, videor)?
Den första begäran (själva HTML:en): klicka på den, fliken Timing. "Waiting for server response" är TTFB.
Headrar för den första begäran: finns det komprimering (content-encoding: br eller gzip), och kom sidan från en cache (lektion 6.2)?

De vanligaste boven

I praktiken beror fördröjning hos WordPress oftast på en av dessa:

Ingen sidcache: varje sida skapas på nytt vid varje besök (lektion 6.2).
För många eller tunga tillägg, särskilt tillägg som vid varje begäran anropar externa tjänster eller gör tunga databasfrågor (lektion 5.3).
Stora bilder: ett foto på 5 MB från en telefon på startsidan (lektion 4.4 och 6.3).
Ett tungt tema eller en sidbyggare som laddar många skript och stilmallar på varje sida (lektion 5.1).
Externa komponenter: teckensnitt, videor, chattwidgetar, mätkoder, knappar för sociala medier från andra parter. Var och en är en anslutning till en annan server som kan vara långsam.
En gammal PHP-version (lektion 8.4).
En skräpig databas: tusentals revisioner, skräppost, loggtabeller från tillägg (lektion 6.3).
Bottar: crawlrar, AI-crawlrar och inloggningsförsök upptar ditt paket (lektion 7.3).
Paketet når sina gränser: för lite processorkraft (CPU), processer eller minne för trafiken.

Ditt pakets gränser

Med delat webbhotell får varje paket en fast del av servern: processorkraft, minne, diskhastighet och ett antal processer samtidigt. Om din webbplats använder mer bromsas den, eller så får besökare ett felmeddelande 503 (Service Unavailable, hos vissa webbhotell "Resource Limit Is Reached"). Hos DirectAdmin med CloudLinux ser du det under Resource Usage (med "faults" om din webbplats bromsades) och med X-Ray ser du per sida vilket tillägg eller vilken databasfråga som tar tid. Andra webbhotell har liknande översikter, ibland bara på begäran.

Ett större paket hjälper om din webbplats verkligen behöver mer (en webbshop med mycket trafik). Det löser inte en dåligt konfigurerad webbplats: problemet kommer då tillbaka senare. Hitta orsaken först.

Sammanfattning

Mät först: allt eller bara administrationen, alltid eller ibland, alla eller bara du.
TTFB är serversidan (sträva efter 0,8 sekunder eller mindre); resten är det webbläsaren laddar.
Core Web Vitals: LCP (2,5 s), INP (200 ms) och CLS (0,1); INP ersatte FID 2024.
PageSpeed Insights visar fältdata och labbdata; nätverksfliken visar vad som verkligen laddas.
Det mesta av fördröjningen beror på avsaknad av cache, tunga tillägg, stora bilder och externa komponenter; ett större paket är först det sista steget.

Quiz

Uppgift

Uppgift A6.1: Mät din TTFB och komprimering. Ange adressen till din webbplats och, om du vill, en vanlig sida (till exempel din kontaktsida). Programmet hämtar varje sida tre gånger utan cookies och visar den mittersta TTFB-värdet, HTML:ens storlek, och om servern skickar HTML:en komprimerad (content-encoding gzip eller br). Jämför resultatet med ett test i PageSpeed Insights och notera vad du lägger märke till.

Läs mer

Dessa artiklar beskriver stegen i WebOkés paneler; i andra paneler fungerar de på liknande sätt.

Cookies på WebOké

Cookieinställningar

Nödvändiga

Marknadsföring