Optimalisere sidehastighet: en praktisk arbeidsrekkefølge
Hastighetsarbeid har en markant skjev form: en håndfull tiltak forklarer størstedelen av forbedringen på de fleste sider, og det er nesten alltid bilder, serversvar og tredjepartsskript.
Denne guiden går gjennom i hvilken rekkefølge du arbeider, hvordan du måler om en endring hjalp, og hvilke optimaliseringer som som regel ikke er bryet verdt.
Mål før du endrer noe#
Å optimalisere uten å måle betyr å rette det som er lettest, i stedet for det som er tregt. To målinger, så arbeid.
- Hent feltdata fra ekte besøkende — Core Web Vitals-rapporten, eller din egen overvåking.
- Kjør en labtest på de tre viktigste malene, begrenset til en mellomklassemobil på 4G.
- Noter tallene før du begynner. Uten utgangspunkt kan du ikke si om en endring hjalp.
- Finn per mal den største enkeltfilen og den største blokkerende forespørselen.
- Noter Time to First Byte separat: ligger den over 800 ms, redder intet frontendarbeid deg.
Rekkefølgen som lønner seg#
Grovt sett etter forbedring per times innsats, for en typisk bedrifts- eller innholdsside.
| Arbeid | Typisk gevinst | Innsats |
|---|---|---|
| Optimalisere og skalere bilder | Stor | Lav |
| Fjerne ubrukte tredjepartsskript | Stor | Lav — mest politisk |
| Slå på cache og CDN | Stor | Lav |
| Løse blokkerende CSS og JS | Middels til stor | Middels |
| Redusere JavaScript-pakken | Middels til stor | Middels til høy |
| Rette trege databasespørringer | Stor der relevant | Middels |
| Optimalisere lasting av skrifttyper | Middels | Lav |
| Minifisere og komprimere tekst | Liten | Lav — som regel allerede på |
| Mikrooptimalisere CSS-selektorer | Ubetydelig | Ikke bryet verdt |
Bilder: som regel den største gevinsten#
På de fleste sider utgjør bilder størstedelen av sidevekten, og de fleste serveres flere ganger større enn de vises. Det er den billigste store forbedringen som finnes.
- Server WebP eller AVIF; begge har bred støtte og er typisk 25 til 50 % mindre enn JPEG ved samme kvalitet.
- Generer flere størrelser og bruk srcset med sizes, så mobiler henter filer i mobilstørrelse.
- Server aldri et bilde på 2000 px i en boks på 400 px — nettopp denne ene feilen er usedvanlig vanlig.
- Utsett lasting av alt under bretten, og ingenting over.
- Automatiser det i byggingen eller i CMS-et. Håndoptimaliserte bilder slutter å være optimaliserte så snart en annen laster opp et.
- Fjern metadata; kameraets EXIF kan være titusenvis av byte per fil.
Automatiseringen er kjernen. En engangsrunde med optimalisering går ut på dato innen måneder etter hvert som innhold kommer til, og ingen merker det før sidevekten er doblet.
Tredjepartsskript og serveren#
De to områdene der problemet som regel er organisatorisk snarere enn teknisk: ingen eier tag manageren, og ingen eier valget av drift.
| Problem | Hva du gjør |
|---|---|
| Tag manager med ukjente merker | Gå gjennom hvert; fjern alt ingen kan begrunne |
| Chatwidget som lastes på hver side | Last ved interaksjon, eller kun der støtte trengs |
| Flere analyseverktøy | Behold ett; hvert er et helt skript og en forbindelse |
| A/B-testskript som blokkerer gjengivelse | Flytt til serveren, eller aksepter et glimt og last async |
| Treg TTFB på delt drift | Legg til fullsidecache; oppgrader om det vedvarer |
| Ucachede databasespørringer | Cache de dyre; legg til indekser for de hyppige |
| Ingen CDN | Legg til ett — den billigste globale forsinkelsesrettelsen som finnes |
Tredjepartsskript er den mest pålitelige kilden til uforklart treghet, fordi de endrer seg uten varsel og ligger utenfor utrullingsprosessen din.
Ofte stilte spørsmål
Hva er en god lastetid?
De brukbare målene er Core Web Vitals-tersklene snarere enn ett tall: LCP under 2,5 sekunder og Time to First Byte under 800 ms. Samlet lastetid er et dårlig mål, fordi en side kan være brukbar lenge før hver fil er ferdig — og på en treg enhet ubrukelig lenge før det.
Øker en raskere side konverteringen?
Som regel ja, og effekten er størst der sidene er trege nå, og de besøkende er på mobilnett. Gevinsten fra tre sekunder til to er langt større enn fra halvannet til ett. Er siden allerede rask, så legg innsatsen i innhold og klarhet — avkastningen er bedre.
Løser cache-utvidelser alt?
De løser én reell ting godt — gjentatt serverarbeid for samme side — og de kan skape nye problemer, særlig med innloggede brukere, handlekurver og skjemaer. De gjør heller ingenting med for store bilder eller tredjepartsskript, som typisk er de større problemene. Nyttige, ikke tilstrekkelige.
Er servergjengivelse verdt det for hastigheten?
Om sidene dine i dag kun gjengis i nettleseren, ja: servergjengivelse eller statisk generering fjerner en hel tur frem og tilbake før innholdet vises, og hjelper samtidig indekseringen. Er sidene allerede servergenerert HTML, oppstår ikke spørsmålet — du har fordelen allerede.
optimalisere sidehastighetsidehastighetwebytelsebildeoptimaliseringcachecdn
