Modul 6 · 6.1
Hva gjør et nettsted tregt, og hvordan måler du det?
Modul 6: Hastighet · Lesetid: 9 minutter
Læringsmål: Etter denne leksjonen kan du måle hvor tiden går med, og kjenne igjen forskjellen mellom treghet på serveren og treghet i nettleseren.
Nøkkelbegreper: TTFB, Core Web Vitals (LCP, INP, CLS), labdata, felтdata, PageSpeed Insights, nettverksfanen, komprimering, eksterne skript, grenser i webhotellpakken, 503
Først måle, så justere
"Nettstedet er tregt" kan ha ti forskjellige årsaker. Den som uten å måle tar i bruk en cacheutvidelse, en bildeoptimaliseringsutvidelse og en større pakke samtidig, vet etterpå ikke hva som hjalp, og har fått tre nye ting å holde styr på. Begynn derfor alltid med tre spørsmål (de samme som i veiledningen fra webhotellet ditt):
- Er alt tregt, eller bare kontrollpanelet? Et tregt kontrollpanel med en rask forside peker på utvidelser som gjør mye i kontrollpanelet, eller på bots som angriper innloggingssiden.
- Alltid, eller på bestemte tidspunkt? Bare i travle perioder eller når en planlagt oppgave kjører: da når pakken din grensene sine.
- Hos alle, eller bare hos deg? Prøv på telefonen via 4G eller 5G, eller spør noen andre. Er det bare tregt hos deg, ligger det hos forbindelsen din eller VPN-en din.
To halvdeler: server og nettleser
Tiden en besøkende venter, består av to deler (leksjon 1.2):
- Serveren lager HTML-en: webserver, PHP, utvidelser, database. Dette ser du som TTFB (time to first byte), tiden til den første byten av svaret kommer. web.dev nevner som tommelfingerregel at de fleste nettsteder bør sikte mot en TTFB på 0,8 sekund eller mindre.
- Nettleseren leser denne HTML-en og henter deretter alt som står i den: stilark, skript, skrifttyper, bilder, video, målekoder, chat-widgeter. Først når nok av dette er lastet inn, ser den besøkende noe.
En høy TTFB løser du på serversiden: caching (leksjon 6.2), færre eller lettere utvidelser, en nyere PHP-versjon, en ryddet database (leksjon 6.3) eller mer regnekraft. En lav TTFB med en likevel treg side peker mot nettleser siden: for store bilder, for mange skript, eksterne komponenter.
Core Web Vitals
Google måler opplevelsen til besøkende med tre tall, Core Web Vitals:
| Måling | Hva den måler | Bra når |
|---|---|---|
| LCP (Largest Contentful Paint) | Hvor raskt den største delen av innholdet (ofte det store bildet eller overskriften) blir synlig | 2,5 sekunder eller mindre |
| INP (Interaction to Next Paint) | Hvor raskt siden reagerer når du klikker, trykker eller skriver | 200 millisekunder eller mindre |
| CLS (Cumulative Layout Shift) | Hvor mye siden hopper rundt mens den lastes | 0,1 eller mindre |
INP erstattet den eldre målingen FID i mars 2024. Google bruker disse tallene blant annet ved rangering av søkeresultater, men den viktigste grunnen til å forbedre dem er enkel: besøkende forsvinner ved en treg eller hoppende side.
Labdata og felтdata
Det finnes to typer målinger, og de gir forskjellige tall:
- Labdata: en test på ett tidspunkt, fra ett sted, med en simulert telefon og forbindelse. Nyttig for å sammenligne (før og etter en endring), men det er ikke en virkelig besøkende.
- Felтdata: målinger hos ekte besøkende med Chrome, over de siste 28 dagene. Det er det besøkende faktisk opplever. Små nettsteder har ofte for få besøkende til felтdata.
PageSpeed Insights (pagespeed.web.dev) viser begge deler: øverst felтdataene (hvis de finnes), under det en labtest med en poengsum og konkrete råd. Ikke se blindt på poengsummen fra 0 til 100. Se på komponentene: er LCP dårlig fordi serveren er treg (TTFB), eller fordi det store bildet er 3 MB?
Test alltid noen ganger (tallene varierer), og test også en vanlig side, ikke bare forsiden.
Se selv med nettleseren
Utviklerverktøyene i nettleseren din (F12) viser hva som faktisk skjer:
- Nettverksfanen: oppdater siden med cachen slått av (haken "Disable cache"). Du ser hver fil som blir lastet, hvor stor den er og hvor lang tid den tok. Sorter etter størrelse: de største filene er ofte bilder. Sorter etter domene: hvor mye kommer fra andre parter (skrifttyper, målekoder, videoer)?
- Den første forespørselen (selve HTML-en): klikk på den, fanen Timing. "Waiting for server response" er TTFB.
- Headere til denne første forespørselen: er det komprimering (
content-encoding: brellergzip), og kom siden fra en cache (leksjon 6.2)?
De vanlige synderne
I praksis skyldes treghet i WordPress som regel en av disse:
- Ingen sidecache: hver side blir laget på nytt ved hvert besøk (leksjon 6.2).
- For mange eller tunge utvidelser, spesielt utvidelser som ved hver forespørsel kaller opp eksterne tjenester eller gjør tunge databasespørringer (leksjon 5.3).
- Store bilder: et bilde på 5 MB fra en telefon på forsiden (leksjon 4.4 og 6.3).
- Et tungt tema eller en sidebygger som laster mange skript og stilark på hver side (leksjon 5.1).
- Eksterne komponenter: skrifttyper, videoer, chat-widgeter, målekoder, knapper for sosiale medier fra andre parter. Hver av dem er en forbindelse til en annen server som kan være treg.
- En gammel PHP-versjon (leksjon 8.4).
- En rotete database: tusenvis av revisjoner, spam, loggtabeller fra utvidelser (leksjon 6.3).
- Bots: krypere, KI-krypere og innloggingsforsøk opptar pakken din (leksjon 7.3).
- Pakken når sine grenser: for lite regnekraft (CPU), prosesser eller minne for trafikken.
Grensene i pakken din
Med delt webhotell får hver pakke en fast del av serveren: regnekraft, minne, diskhastighet og et antall samtidige prosesser. Bruker nettstedet ditt mer, blir det bremset ned, eller får besøkende en feilmelding 503 (Service Unavailable, hos enkelte webhotell "Resource Limit Is Reached"). Med DirectAdmin og CloudLinux ser du dette under Resource Usage (med "faults" hvis nettstedet ditt ble bremset ned), og med X-Ray ser du per side hvilken utvidelse eller spørring som koster tid. Andre webhotell har tilsvarende oversikter, noen ganger bare på forespørsel.
En større pakke hjelper hvis nettstedet ditt faktisk trenger mer (en travel nettbutikk). Det løser ikke et dårlig innrettet nettsted: problemet kommer da tilbake senere. Finn først årsaken.
Oppsummering
- Mål først: alt eller bare kontrollpanelet, alltid eller noen ganger, alle eller bare deg.
- TTFB er serversiden (sikt mot 0,8 sekund eller mindre); resten er det nettleseren laster.
- Core Web Vitals: LCP (2,5 s), INP (200 ms) og CLS (0,1); INP erstattet FID i 2024.
- PageSpeed Insights viser felтdata og labdata; nettverksfanen viser hva som faktisk lastes.
- Det meste av tregheten skyldes manglende cache, tunge utvidelser, store bilder og eksterne komponenter; en større pakke er først det siste steget.
Quiz
Oppgave
Oppgave A6.1: Mål TTFB og komprimering. Fyll inn adressen til nettstedet ditt, og hvis du vil, én vanlig side (for eksempel kontaktsiden din). Programmet henter hver side tre ganger uten informasjonskapsler og viser den midterste TTFB-en, størrelsen på HTML-en, og om serveren sender HTML-en komprimert (content-encoding gzip eller br). Sammenlign resultatet med en test i PageSpeed Insights og noter deg hva du legger merke til.
Les mer
Disse artiklene beskriver stegene i kontrollpanelene til WebOké; i andre kontrollpaneler fungerer de på lignende måte.
- DirectAdmin-veiledning 18.3: Nettstedet mitt er tregt
- DirectAdmin-veiledning 17.3: Resource Usage: CPU, minne og prosesser
- DirectAdmin-veiledning 17.4: X-Ray: finn trege sider
- DirectAdmin-veiledning 17.5: 503 eller «Resource Limit Is Reached»: hva nå?
- Nettstedet mitt er tregt eller bruker for mye CPU: slik gjør du det raskere
- Core Web Vitals (web.dev, engelsk): https://web.dev/articles/vitals
- PageSpeed Insights: https://pagespeed.web.dev/
