Websites bliver ofte gjort hurtigere i den forkerte rækkefølge: Nogen installerer et optimeringsplugin, aktiverer alle indstillinger og leder derefter efter årsagen til, at formularen ikke længere virker. Den rigtige rækkefølge er måling, en hypotese, én ændring, en funktionskontrol og en ny måling.
I en ældre version beskrev jeg også metoder, som jeg ikke længere anbefaler, såsom at proxye andres scripts lokalt eller anvende generel AMP- og PWA-udrulning. De gav delvise forbedringer i laboratoriet, men medførte risiko ved forældet kode, ødelagte opdateringer og mere kompliceret vedligeholdelse. Et moderne website bør være hurtigt i sin primære version.
Hvad skal du måle i dag
Til Core Web Vitals bruger Google tre stabile målinger:
- LCP: indlæsning af hovedindholdet; en god værdi er op til 2.5 sekunder.
- INP: reaktion på interaktioner; en god værdi er under 200 millisekunder.
- CLS: uventede layoutforskydninger; en god værdi er højst 0.1.
Grænseværdierne gælder for den 75. percentil og opsummeres i den officielle Core Web Vitals for Google Search-oversigt. Resultater fra rigtige besøgende i Search Console eller CrUX har prioritet over én laboratorietest på min bærbare computer.
Laboratorieværktøjer er stadig vigtige: De viser vandfaldet, hovedtråden, ubrugt kode og konkrete kandidater til reparation. Feltdata fortæller, at der findes et problem; laboratoriet hjælper med at forklare hvorfor.
Afgræns først problemets omfang
- Sammenlign mobil og desktop.
- Adskil skabeloner: forside, artikel, ydelse, oversigt, formular og webshop.
- Kontrollér hurtige og langsomme lande, enheder og trafikkilder.
- Find URL-grupper med dårlige feltdata.
- Optag et reproducerbart laboratorietrace for en repræsentativ side.
Én hurtig forside betyder ikke, at hele websitet er hurtigt. Ét langsomt besøg på en gammel telefon betyder ikke, at hele systemet skal skrives om.
Tiltag med den mest almindelige effekt
1. Server og HTML
Mål tiden til den første byte, og opdel den i DNS, forbindelse, ventetid på serveren og omdirigeringer. Lange ventetider kan skyldes hosting, databasen, en side uden cache, en langsom API eller omdirigeringskæder. Aktivér passende sidecache for offentligt indhold og objektcache, hvor det giver mening. Undtag loggede brugere, indkøbskurve og personalisering korrekt fra cachen.
2. Hovedbillede
LCP er ofte hero-billedet. Lever en størrelse, der passer til visningen, og brug srcset, komprimering samt moderne WebP eller AVIF med en fornuftig fallback. Lazy-load ikke hovedbilledet; lazy-load billeder under den første viewport. Angiv billedets bredde og højde, så browseren reserverer plads, og CLS forbliver lav.
3. CSS og skrifttyper
Fjern ubrugte styles forsigtigt, og hold kritisk CSS lille. Begræns skrifttyper til de nødvendige vægte og tegnsæt, cache lokale filer længe, og preload kun en skrifttype, der reelt skal bruges tidligt. Preload af ti skrifttyper skaber blot endnu en kø.
4. JavaScript og interaktion
Opdel store bundles, udskyd ikke-kritisk kode, og indlæs kun tredjeparter, når det er nødvendigt og samtykke tillader det. async og defer er ikke magi; test script-rækkefølge og afhængigheder. Opdel lange opgaver på hovedtråden, og lad ikke et klik vente på analytics.
5. Tredjeparter
Chats, heatmaps, annonceringspixels, videoer og A/B-værktøjer tilføjer netværksanmodninger og processorarbejde. Hvert script skal have en ejer og en forretningsmæssig begrundelse. Indlæs det ikke synkront i headeren, blot fordi installationsvejledningen er kortest. Analytics kan håndteres via Google Tag Manager, men containeren kan ikke i sig selv redde performance.
WordPress: færre lag, mere kontrol
WordPress-dokumentationen anbefaler at arbejde med performance gennem hosting, antal og kvalitet af plugins, billeder, cache og et leveringsnetværk. Læs deres optimeringsoversigt og separate forklaring af cache.
- Opdatér WordPress, PHP, temaet og plugins på staging først.
- Fjern ubrugte plugins og overlappende cache- eller minificeringsværktøjer.
- Profilér databaseforespørgsler og langsomme eksterne kald.
- Planlæg databasevedligeholdelse, men slet ikke revisioner eller metadata blindt.
- Test formularer, søgning, login og købsflowet efter hver optimering.
Jeg gennemgår et fornuftigt valg af tilføjelser i de bedste WordPress-plugins.
Hvad skal du ikke gøre
- Download ikke andres analytics- eller annonceringsscripts til din server kun for en score; du kan miste sikkerheds- og funktionsopdateringer.
- Indstil ikke et års cache for en fil, der ændrer sig, uden at versionsindstille dens navn.
- Fjern ikke CSS eller JavaScript fra en automatiseret rapport uden at teste alle skabeloner.
- Vurder ikke kun succes ud fra Lighthouse. Google siger udtrykkeligt, at gode Core Web Vitals alene ikke garanterer høje placeringer eller en god brugeroplevelse.
- Gør ikke et website hurtigere ved at skjule indhold eller en funktion, kunden har brug for.
En plan over fire uger
- Uge 1: baseline for feltdata, laboratoriemålinger og skabelonliste.
- Uge 2: server, cache, omdirigeringer og de største LCP-ressourcer.
- Uge 3: billeder, skrifttyper, CSS, JavaScript og tredjeparter.
- Uge 4: regressionstest, nye målinger, overvågning og dokumentation.
Registrér dato, URL, måling før og efter, funktionel effekt og mulighed for rollback for hver ændring. Følg også konverteringsrate, formularfuldførelse og fejl; en hurtigere side, der sælger mindre, er ikke en færdig optimering.
Start med at kontrollere websitets tekniske fundament og analytics i et teknisk audit og GA4. Hvis du skal prioritere reparationer efter effekt og pris, kan du kontakte mig via kontakt.