Last det viktigste først: En prioriteringsplan for raskere nettsider
En rask nettside handler ikke bare om færre kilobyte. Med riktig lastrekkefølge blir viktig innhold synlig og brukbart før resten av siden er ferdig.
Kategori: Nettsideytelse
En nettside kan være teknisk optimalisert og likevel oppleves treg. Problemet er ofte ikke bare hvor mye som lastes, men rekkefølgen nettleseren får arbeidet i. Hvis et stort toppbilde, flere skrifttyper, analyseverktøy og omfattende JavaScript konkurrerer om kapasiteten, må brukeren vente på innholdet som faktisk betyr noe.
En bedre strategi er å dele siden i to: det som må være klart for at brukeren skal forstå og bruke siden, og det som kan komme etterpå. Denne prioriteringen gir et praktisk grunnlag for å forbedre Core Web Vitals, bildebruk, caching, kode og database uten å starte med en tilfeldig liste over tekniske tiltak.
Definer hva som skal være klart først
Begynn med den første skjermflaten på mobil. Hva trenger en besøkende for å forstå hvor de har kommet, hva virksomheten tilbyr og hva neste steg er? På en typisk tjenesteside kan svaret være:
- logo og enkel navigasjon
- overskrift og kort forklaring
- en tydelig handlingsknapp
- det viktigste bildet eller den viktigste illustrasjonen
Dette er sidens prioriterte innhold. Cookieverktøy, chat, karuseller, videospillere, kart, anbefalinger og innhold lenger ned er normalt ikke like kritisk. De kan være nyttige, men de bør ikke forsinke sidens hovedoppgave.
Prioriteringen bør gjøres per sidetype. En produktside trenger produktnavn, pris, hovedbilde og kjøpsmulighet tidlig. En artikkel trenger tittel, ingress og lesbar tekst. En kontaktside trenger kontaktinformasjon og skjema. Én felles lastestrategi for hele nettstedet treffer sjelden godt.
Bruk Core Web Vitals som rollefordeling
Core Web Vitals kan brukes som tre ulike spørsmål om brukeropplevelsen, ikke bare som en samlet poengsum.
Hvor raskt kommer hovedinnholdet?
Largest Contentful Paint måler når det største synlige innholdselementet blir vist. På mange bedriftsnettsteder er dette et toppbilde eller en stor tekstblokk. Hvis elementet oppdages sent, har for stor fil eller venter på blokkerende stilark, oppleves åpningen treg.
Finn først ut hvilket element som faktisk blir målt. Det hjelper lite å komprimere små ikoner dersom hovedbildet fortsatt er for stort eller lastes via et skript som nettleseren oppdager sent.
Reagerer siden når brukeren gjør noe?
Interaction to Next Paint handler om respons ved klikk, trykk og tastaturbruk. Tung JavaScript-kjøring kan gjøre at en synlig knapp virker død selv om siden ser ferdig ut. Del derfor opp omfattende arbeid, fjern kode som ikke brukes, og unngå å starte alle sporings- og grensesnittfunksjoner samtidig.
Holder innholdet seg på plass?
Cumulative Layout Shift måler uventede forskyvninger. Bilder uten avsatt plass, bannere som skyves inn øverst og skrifttyper som endrer tekstens størrelse etter lasting, er vanlige årsaker. Angi dimensjoner for medier og reserver plass til elementer som kommer senere.
Gi hovedbildet særbehandling
Ikke behandle alle bilder likt. Hovedbildet i den første skjermflaten skal oppdages og lastes tidlig. Bilder lenger ned kan normalt vente til brukeren nærmer seg dem.
En praktisk bildestrategi består av fire valg:
- Riktig utsnitt: Mobilbrukere bør ikke laste et bredt skrivebordsbilde som deretter beskjæres kraftig.
- Riktig dimensjon: Lever en fil som passer omtrent til plassen den skal fylle, gjerne med flere størrelser som nettleseren kan velge mellom.
- Effektivt format: Bruk moderne bildeformater når publiseringsløsningen og nettleserstøtten gjør det forsvarlig.
- Riktig tidspunkt: Ikke bruk utsatt lasting på bildet som sannsynligvis er sidens største synlige element.
Vurder også om bildet trenger å være der. Et dekorativt toppbilde kan koste mye lastetid uten å hjelpe brukeren. God typografi, en presis overskrift og et rolig fargefelt kan gi en raskere og tydeligere åpning.
Skill kritisk CSS fra resten
Nettleseren trenger CSS for å tegne siden riktig. Store stilark med regler for alle maler, komponenter og kampanjer kan derfor forsinke første visning, selv om den aktuelle siden bare bruker en liten del.
Rydd først bort stilregler som ikke lenger brukes. Del deretter kode etter behov, slik at en enkel artikkelside ikke må hente all styling for nettbutikk, skjemaer og karuseller. Den viktigste stylingen for første skjermflate må være tilgjengelig tidlig, mens mindre viktig styling kan komme etterpå.
Vær forsiktig med automatiske verktøy som flytter eller kombinerer CSS uten kontroll. De kan gi gode testresultater på én side og samtidig skape korte glimt av ustylet innhold eller feil på andre sidetyper. Test representative maler og ulike skjermbredder.
Utsett JavaScript som ikke hjelper første oppgave
JavaScript påvirker både nedlasting, behandling og interaksjon. Hver funksjon bør derfor få et tydelig svar på to spørsmål: Må den finnes på denne siden, og må den starte før brukeren kan gjøre det viktigste?
Et kontaktskjema trenger kanskje validering når brukeren begynner å fylle det ut. En kartmodul kan vente til kartet nærmer seg skjermen eller brukeren ber om å åpne det. En chat kan starte etter at hovedinnholdet er klart. Et skript for en karusell bør ikke lastes på sider uten karusell.
Tredjepartsskript krever særlig oppmerksomhet fordi virksomheten ikke kontrollerer størrelsen eller kjøringen fullt ut. Lag en oversikt over analyse, markedsføring, video, chat, skjema og andre innbygginger. Registrer hvem som eier behovet, hvilke sider skriptet brukes på, og om det kan aktiveres senere eller etter samtykke.
Sørg for at serveren leverer første svar raskt
God prioritering i nettleseren hjelper mindre dersom serveren bruker lang tid på å produsere HTML-dokumentet. Her møtes caching, applikasjonskode og database.
Sidecache kan la serveren levere ferdig genererte sider uten å bygge dem på nytt for hvert besøk. Dette passer godt for offentlig innhold som er likt for de fleste brukere. Personlige sider, handlekurv og innloggede områder trenger mer presise regler slik at feil innhold ikke mellomlagres.
Objektcache kan redusere gjentatte databaseoppslag, mens nettlesercache gjør at statiske filer ikke må lastes ned på nytt ved hvert sidebesøk. Filnavn eller versjonering må endres når innholdet endres, slik at brukerne ikke blir sittende med gamle filer.
Hvis databasen fortsatt er flaskehalsen, bør dere undersøke hvilke spørringer som tar tid og hvorfor. Vanlige årsaker er omfattende filtrering, store tabeller med oppsamlede data, manglende indekser eller utvidelser som gjør de samme oppslagene flere ganger. Ikke start med generell databaserydding uten å vite hva som faktisk forsinker sidene.
Gjør opplevd hastighet til et godkjenningskrav
En side bør ikke bare vurderes etter når alt er ferdig lastet. Det avgjørende er når den blir forståelig, stabil og brukbar. Lag derfor en enkel kontroll for hver viktig sidetype:
- Overskrift og hovedbudskap vises uten unødig venting.
- Det viktigste bildet kommer tidlig og har reservert plass.
- Primærknappen reagerer med en gang den brukes.
- Innholdet flytter seg ikke når skrifter, bilder eller bannere lastes.
- Funksjoner lenger ned forsinker ikke første skjermflate.
- Gjentatte besøk drar nytte av riktig caching.
Test på en vanlig mobiltelefon og en forbindelse som ikke skjuler problemer med høy kapasitet. Gjennomfør både førstegangsbesøk uten cache og nye besøk med cache. En rask kontormaskin på stabilt nett gir et ufullstendig bilde av kundeopplevelsen.
En praktisk rekkefølge for arbeidet
Start med én viktig sidetype, men vurder hele lastrekkefølgen fremfor enkelttiltak. Arbeidet kan gjennomføres slik:
- Definer hva brukeren må se og kunne gjøre først.
- Identifiser elementet som styrer Largest Contentful Paint.
- Optimaliser hovedbildet, skrifttypene og kritisk CSS.
- Fjern eller utsett JavaScript som ikke støtter første oppgave.
- Reserver plass til medier og dynamiske komponenter.
- Kontroller serverens responstid, cache og databasearbeid.
- Test siden på mobil og gjennomfør de viktigste handlingene.
Målet er ikke at minst mulig skal lastes uansett. Målet er at nettsiden bruker kapasiteten på riktig tidspunkt. Når hovedinnhold og handlinger får forkjørsrett, blir siden raskere å forstå og bruke, også før den siste filen er ferdig lastet.
