Definisjon
Å få en raskere nettside handler om å redusere tiden en side bruker på å laste og bli brukbar, og å holde den visuelt stabil mens det skjer. Moderne ytelse måles med Core Web Vitals: lastefart (LCP), hvor raskt siden svarer på det du gjør (INP) og hvor rolig den ligger (CLS). Bedre tall gjør at besøkende blir værende, og gir søkemotorene en grunn til å rangere deg høyere.
Fart er ikke et tall for syns skyld. På mobilnett og rimeligere telefoner kan en side som føles kjapp på din egen maskin bruke flere lange sekunder for en ekte kunde, og de fleste venter ikke. Raskere sider holder på flere besøkende, får flere til å handle, og gir både søkemotorer og AI-verktøy en lettere og kjappere side å stole på. Det er en av få forbedringer som hjelper både brukerne og rangeringen samtidig.
01 / Hvorfor det betyr noeFolk, søk og AI
Hvert ekstra sekund med lasting er en grunn til å forlate siden. Besøkende danner seg et inntrykk i løpet av de første øyeblikkene, og en treg side virker slurvete før noen har sett arbeidet ditt. Utover følelsen er fart målbart, og det teller på tre måter. For folk betyr raskere at flere blir værende og gjør noe. For søk er Core Web Vitals et bekreftet rangeringssignal hos Google, en del av faktorene rundt sideopplevelse som avgjør jevne oppgjør. For AI-verktøy er en lett, rask og ryddig side rett og slett enklere å lese og sitere. Fart er der god brukeropplevelse og god SEO slutter å konkurrere og begynner å dra i samme retning.
02 / De tre verdieneHva Core Web Vitals måler
Googles Core Web Vitals koker noe komplisert ned til tre menneskelige spørsmål. Largest Contentful Paint (LCP) spør: hvor lang tid tar det før hovedinnholdet dukker opp? Interaction to Next Paint (INP) spør: når jeg trykker eller klikker, hvor raskt svarer siden? Cumulative Layout Shift (CLS) spør: ligger layouten i ro, eller hopper ting rundt mens siden lastes? Ifølge Googles web.dev regnes en side som god når LCP er 2,5 sekunder eller mindre, INP er 200 millisekunder eller mindre, og CLS er 0,1 eller mindre, målt på 75-prosentilen av ekte besøk. Disse tre tallene er tavlen alt annet måles mot.
03 / Mål førstTest før du rører noe
Optimaliser aldri i blinde. Start med PageSpeed Insights, som setter en lab-test ved siden av data fra ekte besøk, altså de Core Web Vitals som besøkende faktisk har opplevd den siste måneden, hentet fra Chrome User Experience Report. Lab-tall er nyttige for å finne feil, men dataene fra ekte besøk er fasiten. De speiler ekte telefoner, ekte nett og ekte avstander. Test på mobil først, for det er der folk flest og problemene bor. Noter dagens LCP, INP og CLS, finn den ene største synderen, og rett den før du går videre. Å måle først hindrer deg i å pusse på ting ingen legger merke til mens den egentlige flaskehalsen får stå i fred.
04 / De største gevinsteneEn trinnvis vei til en raskere side
De fleste sider henter det meste av farten tilbake fra en håndfull grep. Jobb deg gjennom dem i denne rekkefølgen, og test på nytt underveis:
- Mål først. Test siden i PageSpeed Insights og se på data fra ekte besøk før du endrer noe, slik at du retter det som faktisk sinker folk i stedet for å gjette.
- Optimaliser bildene. Bruk moderne formater som WebP eller AVIF, tilpass hvert bilde til størrelsen det vises i, komprimer det, og sett fast bredde og høyde så ingenting hopper mens siden lastes.
- Last inn skjult medieinnhold ved behov. Last inn bilder og innebygd innhold under skjermkanten først når den besøkende blar seg ned mot det, mens hovedbildet lastes med en gang så det største elementet tegnes raskt.
- Trim og utsett kode. Fjern ubrukt CSS og JavaScript, legg den kritiske CSS-en for første skjerm rett inn i siden, og utsett resten så skriptene slutter å blokkere visningen.
- Bruk hurtigbuffer og CDN. Sett lang levetid på statiske filer og server dem fra et CDN, slik at gjengangere og besøkende langt unna henter filene fra en node i nærheten.
- Velg solid drift. Kjør på en løsning med rask svartid fra serveren, gjerne levert fra kanten av nettet eller som statiske filer, så første byte kommer fort i stedet for å vente på en treg database.
- Tem skrifter og tredjepartsskript. Legg skriftene på egen server, forhåndslast de viktigste og bruk font-display swap. Gå deretter gjennom hver tredjepartstagg og fjern eller utsett de som ikke bærer sin egen vekt.
05 / Bilder og skrifterDer mesteparten av vekten ligger
På de fleste sider er bildene det tyngste du sender, og dermed det raskeste stedet å hente gevinst. Gjør om fotografier til WebP eller AVIF, eksporter dem ikke større enn de noen gang vises, og sett alltid bredde og høyde så nettleseren reserverer plass og ingenting hopper. Det alene beskytter CLS-en din. Skrifter er den stille toeren: en egen skrifttype som blokkerer visningen kan la teksten være usynlig et lite øyeblikk. Legg skriftene på egen server, forhåndslast den ene eller to som første skjerm trenger, og bruk font-display: swap så teksten vises med en gang i en reserveskrift og byttes inn uten glimt. Små, disiplinerte valg om filer flytter mer enn nesten noe annet.
06 / Kode, hurtigbuffer og driftMotoren under panseret
Når filene er slanke, er det leveringen som teller. Trim ubrukt CSS og JavaScript, legg den kritiske CSS-en for første skjerm rett inn i siden, og utsett resten så skriptene ikke lenger blokkerer visningen. Sett romslig levetid på statiske filer og sett et CDN foran, slik at gjengangere og folk langt fra serveren din henter filer fra en node i nærheten i stedet for fra origin hver gang. Under alt dette setter driften taket: rask svartid fra serveren, altså lav tid til første byte, betyr at siden kan begynne å tegne seg tidligere. Levering fra kanten av nettet eller som statiske filer, der siden serveres ferdigbygd nær brukeren, er det tryggeste fundamentet for fart som finnes.
07 / TredjeparterSkriptene du ikke skrev selv
Den tyngste delen av mange sider er kode eieren aldri skrev selv: chat, statistikk, annonsetagger, testverktøy, innebygd video og delingsknapper. Hver av dem kan dra inn flere skript, blokkere hovedtråden og skade INP lenge etter at din egen kode er finpusset. Se på hver tredjepartstagg som en kostnad som må forsvares. Fjern alt som ikke er i bruk, last resten så sent som mulig, og velg gjerne en lett innebygging eller et statisk bilde fremfor et fullt verktøy der du kan. En enkelt glemt markedsføringspiksel har mer enn én gang gjort en hel runde med optimalisering til intet.
08 / Slik gjør vi detRask fra bunnen av
Hos Elevate Labs bygger vi heller en side som er rask fra første linje enn å skru fart på i etterkant. Byggene våre lages internt i Oslo og hviler på moderne formater, minimalt med JavaScript og levering fra kanten av nettet, så Core Web Vitals som regel består på grunn av hvordan siden er laget, ikke til tross for det. Ytelse er en del av håndverket, ved siden av strukturen som hjelper deg å rangere. Se guiden vår om teknisk SEO for det store bildet, og hva en nettside koster når den bygges skikkelig. Vil du ha en side som er kjapp rett ut av boksen, ta en titt på webdesignet vårt i Oslo, eller bla gjennom alle guidene våre.
09 / SpørsmålOfte stilte spørsmål
Hva er en god Core Web Vitals-score?
Påvirker fart på nettsiden rangeringen i søk?
Hvorfor er nettsiden min treg selv med rask drift?
Hvor lang tid tar det å gjøre nettsiden raskere?
Vil du ha en side som er rask fra start?
Elevate Labs bygger ytelsesbevisste nettsider i Oslo, raske og stabile og laget for å bestå Core Web Vitals.
Se webdesign i Oslo →