Hastighedsoptimering virker bedst som fejlfinding: mål en rigtig side, find den ressource eller opgave, der forsinker oplevelsen, ændr én gruppe ad gangen og mål igen. En enkelt samlet score kan pege i en retning, men fortæller ikke alene, om kunden så overskriften, kunne trykke på menuen eller oplevede, at layoutet flyttede sig.
1. Vælg de rigtige sider og en fast baseline
Test mindst forsiden, den vigtigste landingsside og en tung template som artikel, case eller produkt. Brug samme URL, viewport og testmetode før og efter. Notér dato, miljø, enhedsemulering og om resultatet er laboratoriedata eller data fra rigtige brugere. Feltdata kræver nok trafik og repræsenterer en periode; laboratoriedata kan køres nu, men varierer mellem målinger.
Åbn også siden på en almindelig telefon over et realistisk netværk. Se efter tomme områder, blinkende fonte, billeder der kommer sent, knapper der flytter sig, og om første tryk reagerer. Det kvalitative notat gør målingen handlingsorienteret.
2. Find LCP-elementet
LCP er det største synlige indholdselement i viewporten under indlæsningen. Det er ofte et hero-billede eller en stor overskrift. web.dev opdeler arbejdet i tid til første byte, forsinkelse før ressourcen opdages, downloadtid og forsinkelse før rendering. Hvis billedets URL først findes efter JavaScript eller i en sen CSS-fil, hjælper komprimering kun på én del af problemet.
Et kritisk hero-billede bør være i den oprindelige HTML, have korrekt størrelse og normalt ikke lazy-loades. Brug responsive kilder, så en mobil ikke henter desktopfilen. Angiv bredde og højde. En preload eller høj fetch-prioritet kan hjælpe, men bør kun bruges til den faktiske LCP-ressource; for mange prioriterede filer konkurrerer indbyrdes.
3. Gør billedpipeline konkret
- Eksportér i den største størrelse, placeringen realistisk viser – ikke kamerafilen.
- Lav en mindre variant til cards og mobil, og brug
srcsetogsizes. - Vælg WebP eller AVIF, når browserstøtte og workflow passer; behold JPEG/PNG hvor det er nødvendigt.
- Lazy-load billeder under første viewport, men ikke hovedbilledet.
- Kontrollér beskæring og læsbarhed efter komprimering.
MDN beskriver responsive billeder som en måde at lade browseren vælge en passende fil. Det sparer kun data, hvis varianterne faktisk findes, og sizes svarer til layoutet.
4. Reducér JavaScript og tredjepartskode
Lav en liste over chat, tracking, videoembeds, heatmaps, A/B-tests og widgets. For hver ressource: hvem ejer den, hvilket formål har den, hvornår behøves den, kræver den samtykke, og hvad sker der, hvis den ikke indlæses? Fjern forældede tags frem for blot at udskyde dem.
Store JavaScript-opgaver kan forsinke interaktion. Del kode efter rute eller funktion, undgå at initialisere skjulte komponenter, og brug en facade til tunge embeds, så videoafspilleren først hentes ved handling. Kontrollér efter ændringen, at analytics ikke sender dobbelt, og at consent stadig fungerer.
5. Stabiliser layout og fonte
CLS opstår, når synligt indhold flytter sig uden brugerens forventning. web.dev anbefaler blandt andet at reservere plads til billeder, annoncer og embeds. Sæt dimensioner eller et aspect ratio, giv dynamiske beskeder en planlagt plads, og undgå at indsætte bannere over eksisterende indhold efter load.
Brug få nødvendige fontfiler og vægte. Preload kun den font, der er kritisk for første visning, og vælg en fallback med lignende proportioner. Test både første besøg uden cache og gentagne besøg.
6. Prioritér efter effekt og risiko
| Fund | Første handling | Kontrol |
|---|---|---|
| Hero er LCP og meget stor | Lav korrekte varianter og fjern lazy loading | LCP-URL og visuel kvalitet |
| Tredjepart blokerer main thread | Fjern, forsink eller indlæs efter handling/samtykke | Funktion og dataflow |
| Billeder flytter layout | Angiv dimensioner eller aspect ratio | CLS og mobilscroll |
| Mange fontfiler | Reducer familier/vægte og subset | Tekstvisning og brand |
| Langsom backend | Mål TTFB og cachelag | Friske data og cache-hit |
7. Gentest hele brugerrejsen
Kør samme måling flere gange og sammenlign medianen, men stop ikke ved tallet. Brug menu, formular, checkout eller booking. Test afvisning og accept af statistik. Kontrollér console-fejl, manglende billeder og responsivt layout. Performanceforbedringen er ikke godkendt, hvis den har fjernet en vigtig funktion eller gjort teksten svær at læse.
Gem et kort før/efter-notat med URL, hypotese, ændring, måling og sideeffekt. Det gør næste runde lettere og forhindrer, at en senere integration genindfører samme problem uden at nogen opdager det.