Sett et ytelsesbudsjett før nettsiden blir treg
Et ytelsesbudsjett gjør hastighet til et konkret krav for bilder, kode, caching og database – ikke et oppryddingsprosjekt før lansering.
Kategori: Nettsideytelse
En nettside blir sjelden treg på grunn av én dramatisk feil. Ofte er årsaken summen av et stort toppbilde, flere sporingsskript, en tung font, lite effektiv caching og databasespørringer som vokser med innholdsmengden. Hver beslutning virker kanskje forsvarlig alene, men til sammen gir de lang ventetid og en side som reagerer sent.
Et ytelsesbudsjett setter grenser før dette skjer. Budsjettet beskriver hvor rask nettsiden skal oppleves, og hvor mye bilder, JavaScript, CSS, tredjepartskode og serverarbeid en sidetype kan bruke. Dermed får designere, utviklere, redaktører og leverandører et felles beslutningsgrunnlag.
Start med forretningskritiske sider
Det er lite nyttig å lage ett samlet hastighetskrav for hele nettstedet. En enkel kontaktside, en produktside og en innlogget kundeside har forskjellige oppgaver og tekniske forutsetninger.
Velg først noen representative sidetyper og brukeroppgaver:
- forside eller viktig landingsside
- tjeneste- eller produktside
- artikkel eller veiledning
- søk, filtrering eller produktoversikt
- skjema, bestilling eller utsjekk
Prioriter sidene som mottar mye trafikk, starter en kundereise eller ligger tett på en konvertering. Mål også viktige steg inne i siden. En produktside kan laste raskt, men likevel oppleves treg hvis valg av variant eller åpning av handlekurven reagerer sent.
Bruk Core Web Vitals som resultatkrav
Core Web Vitals gir tre nyttige mål for brukeropplevelsen. De bør inngå i budsjettet, men ikke stå alene.
- Largest Contentful Paint, LCP: Hvor raskt det viktigste synlige innholdet blir vist. Et praktisk mål er 2,5 sekunder eller raskere.
- Interaction to Next Paint, INP: Hvor raskt siden gir synlig respons etter klikk, trykk og tastaturbruk. Et praktisk mål er 200 millisekunder eller raskere.
- Cumulative Layout Shift, CLS: Hvor mye innhold flytter seg uventet mens siden lastes. Et praktisk mål er 0,1 eller lavere.
Vurder målene ved den 75. persentilen, særlig for mobiltrafikk. Det betyr at kravet skal være oppfylt for et tydelig flertall av besøkene, ikke bare på utviklerens raske maskin og nettverk.
Målinger i et testverktøy er nyttige under utvikling. Data fra faktiske besøk viser hvordan nettsiden fungerer med reelle enheter, nettverk, samtykkevalg og innhold. Budsjettet bør derfor angi både testkrav før lansering og oppfølging av reelle brukere etterpå.
Gjør resultatkravene om til tekniske grenser
Core Web Vitals forteller at noe er tregt, men ikke alltid hvorfor. Budsjettet må derfor inneholde grenser som teamet kan bruke i det daglige.
Bilder: budsjetter per plassering
Ikke bruk én maksimal filstørrelse for alle bilder. Et bredt hovedbilde har andre behov enn et lite profilbilde. Definer i stedet krav per bildeplassering:
- maksimale visningsmål på mobil og stor skjerm
- egnede filformater og komprimeringsnivå
- flere bildestørrelser slik at mobilen ikke laster skrivebordsvarianten
- faste bredde- og høydeforhold for å unngå layoutskift
- regler for hvilke bilder som kan lastes senere
Bildet som sannsynligvis blir sidens LCP-element, bør normalt ikke lazy-loades. Det må oppdages og hentes tidlig. Bilder lenger nede på siden kan lastes først når brukeren nærmer seg dem.
Sett gjerne en konkret filgrense for hver mal etter at dere har testet reelle motiver. Et detaljert produktfoto tåler ikke nødvendigvis samme komprimering som en enkel illustrasjon. Målet er lav vekt uten synlig kvalitetstap i den størrelsen bildet faktisk vises.
JavaScript: budsjetter utførelse, ikke bare kilobyte
En liten JavaScript-fil kan være dyr hvis den utfører mye arbeid i nettleseren. En større fil kan være mindre problematisk dersom den lastes ved behov og gjør lite på hovedtråden. Budsjettet bør derfor omfatte både overført datamengde og tiden koden bruker.
Skill mellom kode som er nødvendig ved første visning, kode som kan lastes etterpå, og kode som bare trengs på enkelte sidetyper. Et kart, en kalkulator eller en produktkonfigurator bør ikke følge med til alle sider dersom funksjonen bare brukes ett sted.
Tredjepartsskript må behandles som en del av budsjettet. Analyse, annonsering, chat, video og personalisering konkurrerer om de samme ressursene. Hvert skript bør ha en navngitt eier, et tydelig formål og en plan for fjerning hvis det ikke lenger gir verdi.
CSS og fonter: prioriter det som er synlig først
Store stilark kan forsinke visningen, selv om mye av innholdet gjelder komponenter som ikke finnes på siden. Fjern ubrukte regler, del opp kode der det er hensiktsmessig, og prioriter stilen som trengs for den første synlige delen.
Fonter påvirker både lastetid og layoutstabilitet. Begrens antall fontfamilier, snitt og vekter. Bruk reserverte skrifter med lignende proporsjoner, slik at tekst og knapper ikke flytter seg mye når webfonten blir tilgjengelig.
Caching: angi hva som kan gjenbrukes
Et godt cache-oppsett hindrer at serveren og nettleseren gjør det samme arbeidet på nytt. Budsjettet bør ikke bare kreve «caching», men beskrive hva som skal caches og når innholdet skal fornyes.
- Bilder, fonter, CSS og JavaScript kan ofte lagres lenge når filnavnet endres ved nye versjoner.
- Ferdig genererte sider kan mellomlagres når innholdet er likt for mange besøkende.
- Personlige sider, handlekurver og innlogget innhold krever egne regler.
- Databasekall eller beregnede resultater kan mellomlagres når dataene ikke må være helt ferske.
Test alltid at publisering, priser, lagerstatus og personlige data blir oppdatert riktig. Aggressiv caching uten klare regler kan gi raske, men feilaktige sider.
Database: sett grenser før innholdet vokser
En løsning kan være rask med ti produkter og treg med ti tusen. Databasebudsjettet bør derfor testes med realistiske datamengder, ikke bare en nesten tom utviklingsbase.
Følg med på serverens svartid, antall spørringer og de tregeste spørringene for viktige sidetyper. Søk, filtrering og sortering fortjener særlig oppmerksomhet. Unngå løsninger der hvert nytt produkt, filter eller innholdselement fører til stadig flere separate oppslag.
Opprydding er også en del av arbeidet. Ubrukte data, gamle revisjoner, utløpte mellomlagringer og tabeller etter fjernede utvidelser kan gjøre vedlikehold og feilsøking vanskeligere. Slik opprydding må planlegges og sikkerhetskopieres, ikke utføres tilfeldig i produksjon.
Ta med opplevd hastighet i budsjettet
En side kan få gode tekniske målinger og fortsatt føles treg. Brukeren trenger å forstå at noe skjer, hva som er tilgjengelig, og når oppgaven kan fortsette.
Definer derfor noen krav til opplevd hastighet:
- Vis sidens overskrift og viktigste innhold tidlig.
- Gi umiddelbar visuell respons når en knapp aktiveres.
- Behold eksisterende innhold mens nye søkeresultater hentes.
- Reserver plass til bilder, varsler og dynamiske komponenter.
- Unngå lasteskjermer som skjuler innhold som allerede kunne vært brukt.
En knapp som endrer tekst til «Legger til» oppleves bedre enn en knapp som ser ut til å være død i ett sekund. Denne typen tilbakemelding gjør ikke nødvendigvis serveren raskere, men reduserer usikkerheten.
Gjør budsjettet til en del av godkjenningen
Et dokument alene holder ikke nettsiden rask. Kravene må kontrolleres når design, funksjoner og innhold godkjennes.
- Ved oppstart: Velg sidetyper, brukeroppgaver, måleforhold og Core Web Vitals-mål.
- I designfasen: Vurder konsekvensene av store medieflater, fonter, animasjoner og komponenter.
- Under utvikling: Følg størrelse og kjøretid for bilder, kode og tredjepartsfunksjoner.
- Før lansering: Test med realistisk innhold, svakere mobilutstyr og kald cache.
- Etter lansering: Følg reelle brukerdata og undersøk endringer per sidetype og enhet.
Avtal også hva som skjer ved overskridelse. Teamet kan optimalisere funksjonen, laste den senere, begrense den til relevante sider eller fjerne noe annet. Hvis alle ønsker behandles som tillegg uten motkrav, er budsjettet bare en ønskeliste.
Et lite budsjett er bedre enn et omfattende dokument ingen bruker
Begynn med noen få krav som kan måles og knyttes til ansvar. Core Web Vitals beskriver resultatet. Grenser for bilder, JavaScript, CSS, caching og database gjør resultatet mulig å styre. Krav til opplevd hastighet sørger for at dere ikke bare optimaliserer en poengsum.
Den viktigste effekten er ikke at hver side blir teknisk perfekt. Det er at ytelse blir vurdert samtidig med design, funksjon og innhold. Da slipper dere å oppdage rett før lansering at nettsiden må bygges om for å bli rask nok.
