Nettsteder gjøres ofte raskere i feil rekkefølge: Noen installerer en optimaliseringsutvidelse, aktiverer alle brytere og leter deretter etter årsaken til at skjemaet ikke lenger fungerer. Riktig rekkefølge er måling, en hypotese, én endring, kontroll av funksjonen og ny måling.
I en eldre versjon beskrev jeg også metoder jeg ikke lenger anbefaler, for eksempel å kjøre andres skript lokalt via en proxy eller generell utrulling av AMP og PWA. De ga delvise forbedringer i laboratoriet, men førte med seg risiko knyttet til utdatert kode, ødelagte oppdateringer og mer komplisert vedlikehold. Et moderne nettsted bør være raskt i hovedversjonen sin.
Hva bør måles i dag
For Core Web Vitals bruker Google tre stabile måleverdier:
- LCP: lasting av hovedinnholdet; en god verdi er opptil 2.5 sekunder.
- INP: respons på interaksjoner; en god verdi er under 200 millisekunder.
- CLS: uventede layoutforskyvninger; en god verdi er høyst 0.1.
Grenseverdiene gjelder 75-persentilen og er oppsummert i den offisielle oversikten Core Web Vitals for Google Søk. Resultater fra reelle besøkende i Search Console eller CrUX har høyere prioritet enn én laboratorietest på den bærbare datamaskinen min.
Laboratorieverktøy er fortsatt viktige: De viser vannfallsdiagrammet, hovedtråden, ubrukt kode og konkrete kandidater for utbedring. Feltdata sier at det finnes et problem; laboratoriet bidrar til å forklare hvorfor.
Definer først problemets omfang
- Sammenlign mobil og datamaskin.
- Skill mellom maler: startside, artikkel, tjeneste, oversikt, skjema og nettbutikk.
- Kontroller raske og langsomme land, enheter og trafikkilder.
- Finn URL-grupper med dårlige feltdata.
- Ta opp en reproduserbar laboratoriemåling for en representativ side.
Én rask startside betyr ikke at nettstedet er raskt. Ett tregt besøk på en gammel telefon betyr ikke at hele systemet må skrives om.
Tiltakene som oftest gir størst effekt
1. Server og HTML
Mål tiden til første byte og del den opp i DNS, tilkobling, ventetid på serveren og omdirigeringer. Lange ventetider kan skyldes webhotellet, databasen, en side uten hurtigbuffer, et tregt API eller kjeder av omdirigeringer. Aktiver passende sidebuffer for offentlig innhold og objektbuffer der det gir mening. Ekskluder innloggede brukere, handlekurver og personalisering korrekt fra hurtigbufferen.
2. Hovedbilde
LCP er ofte heltebildet. Lever en størrelse som samsvarer med visningen, bruk srcset, komprimering og moderne WebP eller AVIF med et fornuftig reserveformat. Ikke bruk lazy loading på hovedbildet; bruk lazy loading på bilder under den første visningen. Angi bildets bredde og høyde slik at nettleseren reserverer plass og CLS holder seg lav.
3. CSS og skrifter
Fjern ubrukte stiler forsiktig og hold kritisk CSS liten. Begrens skrifter til nødvendige tykkelser og tegnsett, hurtigbufre lokale filer lenge og forhåndslast bare en skrift som faktisk trengs tidlig. Å forhåndslaste ti skrifter skaper bare enda en kø.
4. JavaScript og interaksjon
Del opp store pakker, utsett ikke-kritisk kode og last inn tredjeparter bare når det trengs og samtykket tillater det. async og defer er ingen magi; test rekkefølgen på skriptene og avhengighetene. Del opp lange oppgaver i hovedtråden og ikke la et klikk vente på analyseverktøy.
5. Tredjeparter
Chatter, varmekart, reklamepiksler, videoer og A/B-verktøy legger til nettverksforespørsler og prosessorarbeid. Hvert skript trenger en eier og en forretningsmessig begrunnelse. Ikke last det inn synkront i toppteksten bare fordi installasjonsveiledningen er kortest. Analyse kan håndteres gjennom Google Tag Manager, men selve beholderen kan ikke redde ytelsen.
WordPress: færre lag, mer kontroll
WordPress-dokumentasjonen anbefaler å håndtere ytelse gjennom webhotell, antall og kvalitet på utvidelser, bilder, hurtigbuffer og et leveringsnettverk. Les deres optimaliseringsoversikt og separate forklaring av hurtigbuffer.
- Oppdater WordPress, PHP, temaet og utvidelsene på staging først.
- Fjern ubrukte utvidelser og overlappende verktøy for hurtigbufring eller minifisering.
- Profiler databasespørringer og langsomme eksterne kall.
- Planlegg databasevedlikehold, men ikke slett revisjoner eller metadata blindt.
- Test skjemaer, søk, innlogging og kjøpsflyten etter hver optimalisering.
Jeg diskuterer fornuftig valg av tillegg i de beste WordPress-utvidelsene.
Hva du ikke bør gjøre
- Ikke last ned andres analyse- eller reklameskript til serveren din bare for å få bedre poengsum; du kan miste sikkerhets- og funksjonsoppdateringer.
- Ikke sett ett års hurtigbuffer for en fil som endres, uten å versjonere navnet.
- Ikke fjern CSS eller JavaScript fra en automatisert rapport uten å teste hver mal.
- Ikke vurder suksess bare ut fra Lighthouse. Google sier uttrykkelig at gode Core Web Vitals alene ikke garanterer høy rangering eller en god brukeropplevelse.
- Ikke gjør et nettsted raskere ved å skjule innhold eller en funksjon kunden trenger.
En plan for fire uker
- Uke 1: grunnlinje for feltdata, laboratoriemålinger og maloversikt.
- Uke 2: server, hurtigbuffer, omdirigeringer og de største LCP-ressursene.
- Uke 3: bilder, skrifter, CSS, JavaScript og tredjeparter.
- Uke 4: regresjonstest, nye målinger, overvåking og dokumentasjon.
For hver endring bør du registrere dato, URL, måleverdi før og etter, funksjonell påvirkning og mulighet for tilbakeføring. Følg også med på konverteringsgrad, skjemautfylling og feil; en raskere side som selger mindre, er ikke en ferdig optimalisering.
Start med å kontrollere nettstedets tekniske grunnlag og analyse i en teknisk revisjon og GA4. Hvis du trenger å prioritere utbedringer etter effekt og kostnad, kan du kontakte meg via kontakt.