Optimere sidehastighed: en praktisk arbejdsrækkefølge
Hastighedsarbejde har en markant skæv form: en håndfuld indgreb forklarer størstedelen af forbedringen på de fleste sider, og det er næsten altid billeder, serversvar og tredjepartsscripts.
Denne guide gennemgår, i hvilken rækkefølge du arbejder, hvordan du måler om en ændring hjalp, og hvilke optimeringer der som regel ikke er besværet værd.
Mål før du ændrer noget#
At optimere uden at måle betyder at rette det, der er lettest, i stedet for det der er langsomt. To målinger, så arbejde.
- Hent feltdata fra rigtige besøgende — Core Web Vitals-rapporten, eller din egen overvågning.
- Kør en labtest på de tre vigtigste skabeloner, begrænset til en mellemklassemobil på 4G.
- Notér tallene, før du begynder. Uden udgangspunkt kan du ikke sige, om en ændring hjalp.
- Find pr. skabelon den største enkeltfil og den største blokerende forespørgsel.
- Notér Time to First Byte separat: ligger den over 800 ms, redder intet frontendarbejde dig.
Rækkefølgen der betaler sig#
Groft sagt efter forbedring pr. times indsats, for en typisk virksomheds- eller indholdsside.
| Arbejde | Typisk gevinst | Indsats |
|---|---|---|
| Optimere og skalere billeder | Stor | Lav |
| Fjerne ubrugte tredjepartsscripts | Stor | Lav — mest politisk |
| Slå cache og CDN til | Stor | Lav |
| Løse blokerende CSS og JS | Middel til stor | Middel |
| Reducere JavaScript-pakken | Middel til stor | Middel til høj |
| Rette langsomme databaseforespørgsler | Stor hvor relevant | Middel |
| Optimere indlæsning af skrifttyper | Middel | Lav |
| Minificere og komprimere tekst | Lille | Lav — som regel allerede slået til |
| Mikrooptimere CSS-selektorer | Ubetydelig | Ikke besværet værd |
Billeder: som regel den største gevinst#
På de fleste sider udgør billeder størstedelen af sidevægten, og de fleste serveres flere gange større, end de vises. Det er den billigste store forbedring, der findes.
- Servér WebP eller AVIF; begge har bred understøttelse og er typisk 25 til 50 % mindre end JPEG ved samme kvalitet.
- Generér flere størrelser og brug srcset med sizes, så mobiler henter filer i mobilstørrelse.
- Servér aldrig et billede på 2000 px i en boks på 400 px — netop denne ene fejl er usædvanligt almindelig.
- Udskyd indlæsning af alt under folden, og intet ovenover.
- Automatisér det i bygget eller i CMS'et. Håndoptimerede billeder holder op med at være optimerede, så snart en anden uploader et.
- Fjern metadata; kameraets EXIF kan være titusindvis af bytes pr. fil.
Automatiseringen er kernen. En engangsrunde af optimering udløber inden for måneder, efterhånden som indhold kommer til, og ingen bemærker det, før sidevægten er fordoblet.
Tredjepartsscripts og serveren#
De to områder hvor problemet som regel er organisatorisk frem for teknisk: ingen ejer tag manageren, og ingen ejer valget af hosting.
| Problem | Hvad du gør |
|---|---|
| Tag manager med ukendte tags | Gennemgå hvert; fjern alt ingen kan begrunde |
| Chatwidget der indlæses på hver side | Indlæs ved interaktion, eller kun hvor support er nødvendig |
| Flere analyseværktøjer | Behold ét; hvert er et helt script og en forbindelse |
| A/B-testscript der blokerer rendering | Flyt til serveren, eller accepter et glimt og indlæs async |
| Langsom TTFB på delt hosting | Tilføj fuldsidecache; opgradér hvis det holder ved |
| Ucachede databaseforespørgsler | Cache de dyre; tilføj indekser til de hyppige |
| Intet CDN | Tilføj et — den billigste globale latensrettelse der findes |
Tredjepartsscripts er den mest pålidelige kilde til uforklaret langsommelighed, fordi de ændrer sig uden varsel og ligger uden for din udrulningsproces.
Ofte stillede spørgsmål
Hvad er en god indlæsningstid?
De brugbare mål er Core Web Vitals-tærsklerne frem for ét tal: LCP under 2,5 sekunder og Time to First Byte under 800 ms. Samlet indlæsningstid er et dårligt mål, fordi en side kan være brugbar længe før hver fil er færdig — og på en langsom enhed ubrugelig længe før det.
Øger en hurtigere side konverteringen?
Som regel ja, og effekten er størst, hvor siderne er langsomme nu, og de besøgende er på mobilnet. Gevinsten fra tre sekunder til to er langt større end fra halvanden til et. Er siden allerede hurtig, så læg indsatsen i indhold og klarhed — afkastet er bedre.
Løser cache-udvidelser alt?
De løser én reel ting godt — gentaget serverarbejde for samme side — og de kan skabe nye problemer, især med indloggede brugere, kurve og formularer. De gør heller intet ved for store billeder eller tredjepartsscripts, som typisk er de større problemer. Nyttige, ikke tilstrækkelige.
Er serverrendering det værd for hastigheden?
Hvis dine sider i dag kun renderes i browseren, ja: serverrendering eller statisk generering fjerner en hel tur frem og tilbage, før indholdet vises, og hjælper samtidig indekseringen. Er siderne allerede serverrenderet HTML, opstår spørgsmålet ikke — du har fordelen allerede.
optimere sidehastighedsidehastighedwebydeevnebilledoptimeringcachecdn
