Treg for hvem? Slik feilsøker dere nettsideytelse uten å gjette

Kategori: Nettsideytelse

En nettside kan være rask på forsiden og treg i nettbutikken. Den kan fungere godt på kontorets nettverk, men dårlig på mobil. Den kan også få en akseptabel samlet poengsum samtidig som kontaktskjemaet reagerer sent eller innholdet flytter seg mens kunden prøver å klikke.

Derfor bør arbeidet med nettsideytelse starte med et mer presist spørsmål enn om nettsiden er rask: Hvilke sider er trege, for hvilke brukere og i hvilken del av besøket?

En systematisk feilsøking gjør det lettere å velge riktig tiltak. Den hindrer også at utviklere bruker tid på å komprimere bilder når problemet egentlig er tunge skript, dårlig caching eller langsomme databasekall.

Ikke mål hele nettstedet som én side

Bedriftsnettsteder består vanligvis av flere sidetyper med ulike tekniske egenskaper. En artikkelside kan være enkel og godt bufret, mens produktsøk, innlogging eller kasse krever flere databaseoperasjoner og mer JavaScript.

Start derfor med å dele nettstedet inn i representative sidetyper:

• Forside og landingssider
• Artikler og faginnhold
• Produkt- og kategorisider
• Søk og filtrering
• Skjemaer og bestillingsløp
• Innloggede eller personaliserte sider

Velg deretter én eller to viktige sider fra hver gruppe. Da blir det mulig å se mønstre. Hvis alle produktsidene er trege, er det sannsynligvis et mal-, data- eller komponentproblem. Hvis bare én produktside er treg, kan årsaken være et spesielt bilde, en video, en integrasjon eller uvanlig mye innhold.

Bruk Core Web Vitals som symptomer, ikke fasit

Core Web Vitals beskriver sentrale deler av brukeropplevelsen. Målingene er nyttige, men de forteller først og fremst hva brukeren opplever. De peker ikke alltid direkte på den tekniske årsaken.

Sent hovedinnhold peker mot LCP

LCP handler om hvor raskt det største synlige innholdselementet blir vist. Det er ofte et toppbilde, en stor overskrift eller en fremhevet innholdsblokk.

Dårlig LCP kan skyldes et for stort bilde, men også treg serverrespons, blokkerende CSS, sen lasting av skrifter eller at nettleseren oppdager hovedelementet for sent. Kontroller derfor hvilket element som faktisk måles før dere begynner å optimalisere.

Trege klikk og tastetrykk peker mot INP

INP sier noe om hvor raskt siden reagerer når brukeren klikker, trykker eller skriver. En side kan se ferdig lastet ut og likevel reagere tregt fordi nettleseren er opptatt med JavaScript.

Dette merkes ofte i menyer, filtre, datovelgere, skjemaer og handlekurver. Typiske årsaker er store skriptpakker, mange samtidige sporingsskript eller komponenter som gjør unødvendig mye arbeid for hver handling.

Innhold som flytter seg peker mot CLS

CLS måler visuell ustabilitet. Problemet oppstår når elementer endrer plassering etter at siden er vist. Brukeren kan ende med å klikke på feil knapp fordi et bilde, et varsel eller et skjema plutselig skyver innholdet nedover.

Manglende plassreservasjon for bilder og annonser er vanlige årsaker. Det samme gjelder skrifter som endrer tekstens størrelse, informasjonsfelt som settes inn øverst på siden og komponenter som først får riktig høyde etter at JavaScript er kjørt.

Skille mellom laboratorietest og faktisk bruk

En kontrollert test er god til å gjenskape feil og sammenligne før og etter en endring. Data fra faktiske besøk viser hvordan nettstedet fungerer på brukernes telefoner, nettverk og nettlesere.

Begge deler er nødvendig. En laboratorietest kan vise nøyaktig hvilket skript som blokkerer nettleseren, men den sier ikke alene hvor mange kunder som rammes. Bruksdata kan vise at en sidetype har et problem, men gir ikke alltid en tydelig teknisk forklaring.

Vær også oppmerksom på forskjellen mellom første og senere besøk. Ved første besøk er nettleserbufferen tom. Ved senere besøk kan bilder, skrifter, CSS og JavaScript allerede være lagret lokalt. Tester dere bare med varm cache, kan førstegangsbesøket fremstå bedre enn det er.

En feilsøkingsrekkefølge som reduserer gjetting

1. Finn den berørte sidetypen. Avklar om problemet gjelder hele nettstedet, bestemte maler eller én enkelt side.
2. Beskriv symptomet. Er det ventetid før noe vises, et sent hovedbilde, treg respons etter klikk eller innhold som flytter seg?
3. Test med riktig tilstand. Sammenlign mobil og datamaskin, tom og varm cache, samt innlogget og utlogget bruker der det er relevant.
4. Isoler teknisk lag. Undersøk serverrespons, database, bilder, CSS og JavaScript hver for seg.
5. Endre én hovedting om gangen. Ellers blir det vanskelig å vite hvilket tiltak som ga effekt.
6. Kontroller hele kundereisen. En rask landingsside hjelper lite dersom skjemaet eller betalingen fortsatt er treg.

Slik kjenner dere igjen de vanligste årsakene

Bilder som er større enn visningen krever

Bildeoptimalisering handler ikke bare om komprimering. Nettleseren bør få et bilde med dimensjoner som passer til plassen og en filtype som egner seg for motivet. Et stort originalbilde bør ikke sendes til en liten kortvisning på mobil.

Prioriter bildet som er synlig først. Bilder lenger nede på siden kan normalt lastes senere. Unngå derimot å utsette lastingen av hovedbildet dersom det er sentralt for første skjermbilde. Angi også bredde og høyde slik at nettleseren kan reservere riktig plass før filen er ferdig lastet.

JavaScript som holder nettleseren opptatt

Mye JavaScript er ikke automatisk et problem. Det avgjørende er hvor mye som må lastes, tolkes og kjøres før siden kan brukes.

Se spesielt etter funksjoner som lastes på alle sider, selv om de bare brukes enkelte steder. Et avansert kart trenger ikke å belaste artikkelsider uten kart. Det samme gjelder kalkulatorer, karuseller, chat, analyseverktøy og funksjoner for nettbutikk.

Del opp store oppgaver, last funksjoner når de trengs, og fjern skript som ikke lenger har en dokumentert oppgave. Test alltid viktige interaksjoner etterpå. Aggressiv utsettelse kan gjøre siden raskere på papiret, men ødelegge menyer, skjemaer eller sporing.

CSS som forsinker eller skjuler innhold

Store stilark kan inneholde regler fra gamle maler og komponenter som ikke lenger brukes. Nettleseren må likevel hente og behandle filene.

Rydding bør gjøres kontrollert. Det er lett å fjerne en regel som bare brukes i en sjelden sidetype eller feilmelding. Skill mellom stilene som er nødvendige for første visning, og stilene som tilhører funksjoner lenger nede på siden. Samtidig bør antallet små filer holdes på et fornuftig nivå, slik at løsningen ikke blir unødvendig kompleks.

Caching som mangler eller skjuler problemet

God caching reduserer gjentatt arbeid. Ferdige sider, databaseforespørsler og statiske filer kan ofte gjenbrukes i stedet for å bygges eller hentes på nytt for hvert besøk.

Kontroller hva som faktisk bufres, hvor lenge det lagres og hva som tømmer bufferen. Hvis hele bufferen slettes hver gang en redaktør oppdaterer en liten tekst, kan mange brukere møte en treg, kald side samtidig.

Husk at sidecache ikke løser alt. Søk, handlekurv, kasse og innloggede områder inneholder ofte dynamiske data. Dersom disse delene er trege, må dere undersøke applikasjonen og databasen i stedet for å legge enda et cachelag over problemet.

Databasen som gjør dynamiske sider trege

Databaseproblemer viser seg ofte som lang ventetid før nettleseren mottar innholdet. Vanlige tegn er at søk, filtrering, administrasjon eller produktsider blir gradvis tregere etter hvert som datamengden øker.

Undersøk hvilke spørringer som tar tid, hvor ofte de kjøres og om samme informasjon hentes flere ganger i én sidevisning. Gamle data, unødvendige felter og ineffektive oppslag kan gi merkbar ventetid. Opprydding må planlegges med sikkerhetskopi og testing, ikke utføres direkte i produksjon som et hastetiltak.

Opplevd hastighet må vurderes separat

Brukeren vurderer ikke nettsiden med et måleverktøy. En kort ventetid kan oppleves akseptabel dersom siden gir tydelig respons. En tilsvarende ventetid føles lengre når ingenting skjer.

Gi derfor umiddelbar tilbakemelding etter viktige handlinger. En knapp kan vise at innsending pågår. Et søk kan vise en enkel status. Innholdsområdet kan reservere plass mens data lastes, slik at resten av siden ikke hopper.

Dette erstatter ikke teknisk optimalisering. En lasteindikator gjør ikke en langsom database rask. Den reduserer imidlertid usikkerheten og hindrer at brukeren klikker flere ganger fordi det ser ut som handlingen ikke ble registrert.

Avslutt med en dokumentert diagnose

En nyttig ytelsesrapport bør være kort og beslutningsklar. Noter hvilken sidetype som er berørt, hvilket symptom brukeren møter, sannsynlig årsak, foreslått tiltak og hvordan forbedringen skal kontrolleres.

Eksempel: Produktsider på mobil viser hovedbildet sent ved første besøk. Bildet er større enn visningen krever og prioriteres for sent. Tiltaket er å levere riktige bildestørrelser og prioritere det første produktbildet. Effekten kontrolleres med samme testoppsett og deretter mot data fra faktiske besøk.

Denne arbeidsformen gjør nettsideytelse håndterbart. Dere går fra en generell beskjed om at nettstedet er tregt til en konkret feil på en bestemt sidetype, med et tiltak som kan testes. Det gir bedre prioriteringer og reduserer risikoen for kostbare endringer som ikke løser brukerens problem.