Slik gjør du nettsiden raskere – i riktig rekkefølge

Ikke start med å installere en «speed plugin». Start med å finne hva som faktisk er tregt for reelle brukere: serverresponsen, hovedinnholdet, JavaScript, bilder, fonter eller en tredjepartstjeneste.

Den riktige rekkefølgen er mål → finn flaskehals → endre én ting → mål igjen.

1. Skill feltdata fra laboratorietest

Feltdata viser hva virkelige brukere opplever på ulike enheter og nettverk. Laboratorietester kjører en kontrollert sideinnlasting og er gode til å finne årsaken.

Bruk:

• Core Web Vitals-rapporten i Search Console for grupper av sider
• PageSpeed Insights for CrUX-feltdata og en Lighthouse-test av én URL
• nettleserens Network- og Performance-panel for requestrekkefølge og hovedtrådarbeid
• egen real-user monitoring hvis dere trenger URL-, enhets- og interaksjonsdetaljer

Lite trafikk kan bety at CrUX ikke viser URL-data. Da er en labtest et utgangspunkt, ikke et bevis på hvordan alle brukere opplever siden.

Core Web Vitals-guiden forklarer terskler, 75-persentil og forskjellen på felt og lab.

2. Finn LCP-elementet og del tiden opp

Largest Contentful Paint kan brytes i fire deler:

1. TTFB: tid til første byte av HTML-svaret
2. load delay: ventetid før nettleseren oppdager og starter LCP-ressursen
3. load duration: tid til å overføre ressursen
4. render delay: ventetid fra ressursen er klar til elementet vises

Tiltaket avhenger av hvilken del som er stor.

Google anbefaler at LCP-ressursen oppdages tidlig og advarer uttrykkelig mot å lazy-loade LCP-bildet. Se Googles oppdaterte LCP-metode .

3. Prioriter hovedinnholdet

Hvis et bilde er LCP-elementet:

• legg src eller srcset i første HTML, ikke først i JavaScript
• bruk fetchpriority="high" bare på det sannsynlige LCP-bildet
• ikke bruk loading="lazy" på bildet over folden
• lever en fil som er tilpasset visningsstørrelsen
• unngå en ekstra tredjepartsorigin for kritiske ressurser når det ikke gir verdi

Preload kan hjelpe når en kritisk ressurs ellers oppdages sent, for eksempel et CSS-bakgrunnsbilde. Preload er ikke en generell fartsinnstilling; for mange preloads konkurrerer med ressursene dere egentlig vil prioritere.

Hvis en stor tekstblokk er LCP, kontroller fontlastingen og blokkerende stilark. En systemfont eller en liten lokalt hostet font kan være raskere og mer robust enn flere eksterne fontfamilier og vekter.

4. Lever riktige bilder

Gjør følgende for hvert større bilde:

• velg format og kvalitet etter motivet
• generer flere bredder og bruk srcset og sizes
• behold høy nok oppløsning for skjermen, men ikke send originalfilen ukritisk
• sett width og height for å reservere riktig sideforhold
• lazy-load bare bilder som starter utenfor visningsområdet
• mål dekoding og rendering, ikke bare filstørrelse

WebP og AVIF støttes bredt i moderne nettlesere, men format alene garanterer ikke en liten fil. Sammenlign visuelt resultat og byte for det aktuelle bildet.

5. Fjern unødvendig JavaScript

JavaScript koster mer enn nedlasting. Nettleseren skal også parse, kompilere og kjøre koden på brukerens enhet. Tredjepartsskript kan i tillegg endres uten at dere deployer noe selv.

Start med:

• chat, annonser, heatmaps og flere analyseverktøy
• plugins som legger kode på alle sider
• komponentbiblioteker brukt til én enkel funksjon
• klientrendering av innhold som kunne vært HTML
• lange event handlers og store oppgaver på hovedtråden

For dårlig INP må dere finne den konkrete trege interaksjonen. Reduser arbeidet i callbacken, oppdater grensesnittet tidlig og del lange oppgaver slik at nettleseren kan tegne og ta imot input. Google beskriver hvordan feltdata og hovedtrådarbeid brukes til å forbedre INP .

Ikke slå sammen alle JavaScript- og CSS-filer mekanisk. Med HTTP/2 og HTTP/3 kan flere forespørsler håndteres effektivt; riktig oppdeling, caching og bare nødvendig kode er viktigere enn lavest mulig antall filer.

6. Stopp layoutskift

Dårlig CLS skyldes ofte at nettleseren ikke vet hvor mye plass et element trenger.

• sett width og height på bilder og video
• reserver plass for iframe, annonser og embeds
• legg ikke et sent banner over eksisterende innhold
• test samtykkeløsningen på små skjermer
• begrens fontbytte og uforutsigbare størrelsesendringer
• animer med transform når det passer, ikke egenskaper som flytter layouten

Google anbefaler eksplisitte bildedimensjoner eller CSS aspect-ratio og beskriver flere vanlige årsaker til CLS .

7. Bruk cache etter innholdstype

Cache er flere forskjellige ting:

• nettlesercache for gjenbruk på samme enhet
• CDN- eller proxycache nær brukeren
• fullsidecache for ferdig HTML
• objektcache for gjentatte applikasjons- eller databaseoperasjoner

Fingeravtrykte CSS-, JavaScript- og bildefiler kan normalt caches lenge fordi URL-en endres når innholdet endres. HTML trenger ofte kortere levetid eller revalidering. Personlige eller sensitive responser må ikke legges i delt cache uten riktig cache key og personvernvurdering.

Test at en publisering faktisk invaliderer eller bytter URL for gamle ressurser. «Cache alt» kan ellers vise gammelt innhold eller lekke personaliserte svar.

8. Vurder server og CDN etter måling

Bytt eller oppgrader hosting når målingen viser vedvarende høy TTFB, ressurskø, CPU-begrensning, databaseventing eller ustabilitet som dere ikke kan rette i applikasjonen.

Serverplassering alene avgjør ikke farten. Ruting, cachetreff, TLS-oppsett, brukerens nettverk og selve siden påvirker resultatet. Et CDN kan hjelpe for cachebart innhold og geografisk spredte brukere, men kan også legge til kompleksitet og en ekstra forbindelse ved feil oppsett. Les hva et CDN gjør og ikke gjør før dere legger det til.

HTTP/2 eller HTTP/3 kan forbedre transporten, men kompenserer ikke for flere megabyte bilder eller lang JavaScript-kjøring. Sammenlign HTTP/2 og HTTP/3 hvis protokollen faktisk er flaskehalsen.

9. Sett et ytelsesbudsjett

Et nettsted blir ofte tregt litt etter litt. Sett grenser som kan testes før publisering, for eksempel:

• maksimal vekt for bilder og fonter over folden
• maksimal JavaScript-mengde per sidetype
• ingen tredjepartsskript uten navngitt eier
• mål for LCP, INP og CLS ved 75-persentilen
• varsling når feltdata eller syntetiske tester forverres

Test viktige maler, ikke bare forsiden. En rask artikkel beviser ikke at produktsiden, skjemaet eller utsjekken fungerer godt.

Prioriteringsliste

1. Rett ødelagte brukerflyter og alvorlige layoutskift.
2. Finn LCP-elementet og den største LCP-delen.
3. Fjern eller utsett unødvendig tredjepartskode.
4. Tilpass bilder og kritiske fonter.
5. Rett treg servergenerering og cache.
6. Vurder CDN, protokoll og hosting ut fra nye målinger.
7. Legg resultatet inn i et varig ytelsesbudsjett.

Hastighet i Vymos standardtilbud

Vymos gratis standardnettside er en enkel side som vi setter opp og publiserer; den er ikke et selvbetjent webhotell med WordPress-plugins eller egne cacheinnstillinger. Vymo lover foreløpig ikke en bestemt Core Web Vitals-score eller serverplassering som del av standardtilbudet.

Hvis en enkel, mobiltilpasset presentasjonsside dekker behovet, kan dere se hva gratistilbudet inkluderer . Har dere ytelseskrav, eksisterende applikasjon eller mange tredjepartsintegrasjoner, send representative URL-er og mål så kan omfanget vurderes før bestilling.