Treghet kommer litt etter litt: Slik styrer dere ytelse i publiseringshverdagen
En praktisk metode for å hindre at bilder, videoinnbygginger, sporingsskript og nye innholdsblokker gradvis gjør nettsiden tregere.
Kategori: Nettsideytelse
En nettside blir sjelden treg på én dag. Forfallet skjer gjerne gjennom mange små endringer: et stort toppbilde, en ny videoinnbygging, enda et sporingsskript eller en innholdsblokk som henter data flere steder. Hver endring virker uskyldig alene, men summen merkes av brukerne.
Derfor bør ytelse være en del av den løpende publiseringsprosessen, ikke bare et teknisk prosjekt ved lansering. Et redaksjonelt ytelsesbudsjett setter tydelige grenser for hva sidene kan belastes med, og beskriver hva som skal kontrolleres før og etter publisering.
Hva et ytelsesbudsjett skal løse
Et ytelsesbudsjett er et sett med praktiske rammer for lastetid, filstørrelser, skript og stabilitet. Budsjettet bør gjelde noen utvalgte sidetyper som representerer de viktigste brukerreisene.
For et vanlig bedriftsnettsted kan dette være:
- Forsiden
- En viktig tjenesteside
- En artikkel med bilder og videoinnhold
- En landingsside for kampanjer
- Kontaktsiden eller et skjema
For en nettbutikk bør dere i tillegg følge kategorisider, produktsider, handlekurv og utsjekk. Poenget er ikke å teste alt hele tiden. Poenget er å oppdage om vanlige endringer gjør sentrale sidemaler gradvis tyngre.
Bruk Core Web Vitals som brukerrettede varsellamper
Core Web Vitals gjør ytelse mer konkret ved å måle sentrale deler av brukeropplevelsen. Tre målinger er særlig relevante.
LCP: Når hovedinnholdet blir synlig
Largest Contentful Paint måler hvor raskt det største synlige innholdselementet lastes. På mange nettsider er dette toppbildet, en stor overskrift eller en innholdsseksjon øverst på siden.
Dårlig LCP skyldes ofte tunge bilder, treg serverrespons, blokkerende stilark eller at nettleseren oppdager det viktigste elementet for sent. Redaksjonen kan påvirke dette direkte gjennom valg av bilde, format og innholdsblokk.
INP: Hvor raskt siden reagerer
Interaction to Next Paint måler responsen når brukeren klikker, trykker eller skriver. Tunge JavaScript-oppgaver kan gjøre at menyen, skjemaet eller produktfilteret føles tregt, selv om siden allerede ser ferdig ut.
Nye sporingsverktøy, chatløsninger, kart, filtre og interaktive moduler bør derfor vurderes ut fra mer enn funksjon. Dere må også kontrollere hvordan de påvirker responsen på reelle enheter.
CLS: Om innholdet flytter på seg
Cumulative Layout Shift måler uventede bevegelser i siden. Et typisk eksempel er at en knapp flyttes idet et bilde, et samtykkefelt eller en annonse lastes inn.
Angitte bildedimensjoner, reserverte områder for dynamisk innhold og kontrollert lasting av skrifttyper bidrar til et mer stabilt oppsett. Dette er særlig viktig på mobil, der små forskyvninger lettere fører til feiltrykk.
Lag regler som redaksjonen faktisk kan følge
Et ytelsesbudsjett fungerer dårlig hvis det bare består av tekniske måleverdier. Oversett derfor målene til konkrete publiseringsregler.
Sett grenser for bilder
Bilder er ofte den største datamengden på en innholdsside. Fastsett anbefalte dimensjoner og maksimal filstørrelse for toppbilder, kortbilder, portretter og illustrasjoner. Publiseringsløsningen bør lage tilpassede varianter slik at en mobiltelefon ikke laster ned et bilde beregnet for en stor skjerm.
Bruk moderne bildeformater når løsningen støtter det. Komprimer bilder før publisering, og unngå å bruke et stort originalfoto bare fordi det senere skaleres visuelt med CSS.
Vanlig lat lasting passer for bilder lenger ned på siden. Hovedbildet øverst bør derimot normalt prioriteres, fordi utsatt lasting kan gjøre LCP dårligere.
Begrens eksternt innhold
Videoer, kart, sosiale medier og andre innbygginger kan laste mange eksterne ressurser. Bruk et forhåndsbilde med aktivering ved klikk når det er mulig. Da slipper alle besøkende å laste hele videospilleren eller kartløsningen før de faktisk trenger den.
Lag også en regel om at nye tredjepartstjenester må ha en navngitt eier. Hvis ingen bruker dataene eller følger opp funksjonen, bør skriptet fjernes.
Gjenbruk etablerte innholdsblokker
Spesialbygde kampanjeseksjoner kan gi ekstra CSS, JavaScript og skrifttyper som bare brukes på én side. Gjenbruk av gjennomprøvde komponenter gir som regel mindre kode, færre feil og mer forutsigbar ytelse.
Det betyr ikke at alle sider skal se like ut. Det betyr at variasjon bør skapes innenfor et kontrollert designsystem, fremfor å bygge en ny teknisk løsning for hver kampanje.
Skill mellom innholdsvekt og teknisk grunnmur
Redaksjonen kan redusere store bilder og unødvendige innbygginger, men enkelte problemer må løses i kode, serveroppsett eller database. Ytelsesbudsjettet bør derfor ha to nivåer.
Innholdsnivået omfatter bilder, video, dokumenter, innbygginger, antall komponenter og bruk av tredjepartstjenester.
Teknisk nivå omfatter serverrespons, caching, JavaScript, CSS, skrifttyper, databasekall og integrasjoner.
Når serverresponsen blir tregere, bør dere undersøke cachetreff, eksterne API-kall og databasens arbeid før dere begynner å komprimere flere bilder. En fullsidecache kan levere ferdigbygde sider raskt, mens objektcache kan redusere gjentatte databaseoppslag. Begge deler krever tydelige regler for når innholdet skal tømmes og bygges på nytt.
Databasen bør følges over tid. Uindekserte søk, store tabeller, utdaterte midlertidige data og utvidelser som henter mer informasjon enn nødvendig, kan gi langsom respons. Det merkes særlig på sider som ikke kan mellomlagres fullt ut, som søk, innloggede områder og utsjekk.
Ikke vurder JavaScript og CSS etter filstørrelse alene
En liten JavaScript-fil kan gjøre mye arbeid og blokkere nettleseren lenge. En større fil kan være mindre problematisk hvis den lastes på riktig tidspunkt og bare inneholder nødvendig funksjonalitet.
Se derfor etter om koden:
- lastes på sider der den faktisk brukes
- blokkerer visning av innhold øverst på siden
- starter lange oppgaver når brukeren forsøker å klikke
- dupliserer funksjoner som allerede finnes
- kommer fra tredjepart og endres utenfor deres kontroll
Det samme gjelder CSS. Store globale stilark oppstår ofte når gamle komponenter beholdes etter at de er tatt ut av bruk. Regelmessig opprydding er bedre enn å prøve å komprimere et stadig voksende stilark.
Mål både teknisk og opplevd hastighet
Laboratorietester er nyttige fordi de kan gjentas under like forhold. De viser om en bestemt endring forbedrer eller forverrer siden. Data fra faktiske besøk gir et annet bilde, fordi brukerne har ulike telefoner, nettverk og geografisk avstand til serveren.
Suppler målingene med en enkel manuell kontroll. Åpne siden på en vanlig mobil, bruk mobilnett og gjennomfør den viktigste oppgaven. Legg merke til om hovedinnholdet kommer raskt, om knapper reagerer med én gang, og om elementer flytter seg.
Opplevd hastighet handler også om tilbakemelding. En knapp som viser at noe behandles, føles tryggere enn en knapp som ser ut til å ha sluttet å virke. Et skjema kan svare raskt visuelt selv om den underliggende prosessen tar litt tid.
En enkel kontroll før publisering
Kontrollen bør være kort nok til å bli brukt. For større landingssider, kampanjer og nye maler kan dere følge denne rekkefølgen:
- Kontroller bildeformat, dimensjoner og filstørrelser.
- Tell nye videoer, kart og andre eksterne innbygginger.
- Avklar om nye sporingsskript eller interaktive funksjoner er nødvendige.
- Test siden på mobil med begrenset nettverk.
- Kontroller LCP, INP og CLS mot en tidligere måling av samme sidetype.
- Sjekk serverrespons og databasearbeid dersom hele siden starter sent.
- Dokumenter eventuelle unntak og hvem som skal følge dem opp.
Unntak vil forekomme. En kampanje kan trenge video, kart og avansert sporing. Da bør beslutningen være bevisst, tidsavgrenset og mulig å reversere etter kampanjen.
Gjør ytelse til et delt ansvar
Redaksjonen eier ikke serveren, og utviklerne velger ikke alle bildene. God nettsideytelse krever derfor tydelig ansvarsdeling.
- Redaksjonen følger regler for bilder, innbygginger og innholdsblokker.
- Markedsansvarlig godkjenner nye sporings- og annonsetjenester.
- Utvikler eller leverandør følger kode, caching, database og tekniske målinger.
- Nettsideeier avgjør hvilke avvik som kan aksepteres av forretningsmessige grunner.
Start med tre representative sider og registrer dagens nivå. Sett noen få, forståelige grenser og legg kontrollen inn i den eksisterende publiseringsflyten. Da blir ytelse en løpende kvalitetsoppgave, ikke en opprydding dere må kjøpe på nytt hver gang nettsiden har blitt merkbart treg.
