Forsiden er rask, men kundereisen er treg: Feilsøk ytelse per sidetype

Kategori: Nettsideytelse

En rask forside betyr ikke at nettsiden er rask. Kunden kan møte helt andre ytelsesproblemer på produktsiden, i artikkelarkivet, i kontaktskjemaet eller i handlekurven. Likevel er det ofte forsiden som måles, fordi den er synlig, enkel å finne og viktig internt.

En bedre tilnærming er å undersøke nettsiden per sidetype og brukeroppgave. Da blir det mulig å skille mellom problemer i malverk, bilder, JavaScript, caching, database og eksterne tjenester. Dere får også et mer presist grunnlag for å prioritere tiltak.

Start med sidene som inngår i en reell brukerreise

Ikke velg testsider tilfeldig. Ta utgangspunkt i de viktigste oppgavene nettsiden skal støtte. For en tjenestebedrift kan reisen gå fra en landingsside til en tjenesteside og videre til et kontaktskjema. For en nettbutikk kan den gå fra en kategoriside til en produktside, handlekurven og kassen.

Lag et lite testutvalg som dekker ulike tekniske egenskaper:

• En viktig landingsside med stort toppbilde og tydelig handling.
• En innholdsrik side med flere moduler, bilder eller videoer.
• En arkiv-, kategori- eller søkeresultatside med mange databaseoppslag.
• En side med skjema, produktvalg eller annen interaktiv funksjonalitet.
• En personlig eller dynamisk side som ikke kan mellomlagres på vanlig måte.

Testutvalget trenger ikke være stort. Poenget er at det skal representere forskjellige maler og belastningsmønstre. Dersom alle testsidene bruker samme sidemal, risikerer dere å overse problemer som bare finnes andre steder.

Skill mellom ventetid, visningstid og reaksjonstid

«Siden er treg» er ikke en presis feilbeskrivelse. Brukeren kan vente lenge før noe vises, oppleve at hovedinnholdet kommer sent, eller møte en side som ser ferdig ut, men ikke reagerer på klikk.

Core Web Vitals gir et nyttig språk for tre sentrale deler av opplevelsen:

• Largest Contentful Paint, LCP: Hvor raskt det største synlige innholdselementet blir vist. Dette er ofte et hovedbilde, en overskrift eller en større innholdsblokk.
• Interaction to Next Paint, INP: Hvor raskt siden gir synlig respons når brukeren klikker, trykker eller skriver.
• Cumulative Layout Shift, CLS: Hvor mye innholdet flytter seg uventet mens siden lastes og brukes.

Disse målene forteller at det finnes et problem, men ikke nødvendigvis hvorfor. En svak LCP kan skyldes et for stort bilde, treg serverrespons, blokkerende CSS eller at hovedinnholdet opprettes av JavaScript. Derfor må målingen kobles til sidetype og teknisk årsak.

Bruk både feltdata og kontrollerte tester

Feltdata viser hvordan ekte besøkende opplever nettsiden på ulike enheter, nettverk og tidspunkter. Kontrollerte tester gjør det enklere å gjenta samme situasjon og undersøke detaljene i lasting og kjøring.

Hvis feltdata viser et problem som ikke kan gjenskapes internt, betyr ikke det at problemet er borte. Besøkende kan bruke svakere telefoner, tregere nettverk eller nettlesere med andre forutsetninger. Samtidig kan en enkelt kontrollert test gi et unødvendig dramatisk eller positivt bilde.

Sammenlign derfor flere kjøringer, både med tom cache og ved gjentatte besøk. Test også mobilvisning og de sidene som faktisk mottar trafikk. Noter tidspunkt, testforhold og hvilken sideversjon som ble undersøkt, slik at resultatene kan sammenlignes etter et tiltak.

Les lastingen i riktig rekkefølge

Når en side har svak LCP, bør dere begynne tidlig i leveransekjeden. Hvis det tar lang tid før serveren sender det første svaret, vil bildekomprimering alene ha begrenset effekt. Undersøk derfor årsakene i en fast rekkefølge.

1. Kontroller serverrespons og database

En treg start kan komme av tunge databasespørringer, mange kall mellom systemer, kompliserte sidemaler eller manglende mellomlagring. Arkivsider, filtrering, søk og nettbutikksider er ofte mer databaseavhengige enn en enkel informasjonsside.

Se etter mønstre. Er alle sider trege, eller bare sider med et bestemt filter, språk eller innholdstype? Blir responstiden dårligere for innloggede brukere? Øker den når en side viser mange produkter eller relaterte artikler?

Tiltak kan være å redusere unødvendige spørringer, forbedre spørringslogikken, begrense datamengden som hentes, rydde opp i foreldede data eller mellomlagre resultater som ikke må beregnes på nytt for hvert besøk. Databasearbeid bør styres av målinger, ikke generell rydding uten kjent effekt.

2. Kontroller caching på flere nivåer

Caching er ikke ett enkelt tiltak. Hele HTML-svar kan mellomlagres for sider som er like for alle. Bilder, CSS og JavaScript kan lagres i nettleseren. Beregnede resultater kan mellomlagres nær applikasjonen eller databasen.

Kontroller både om caching finnes, og om den faktisk brukes. En side kan hoppe over cache på grunn av informasjonskapsler, innlogging, sporingsparametere eller feil regler. For nettbutikker må handlekurv, lagerstatus og personlige opplysninger behandles annerledes enn statiske innholdssider.

Test alltid hva som skjer etter publisering og tømming av cache. Det hjelper lite med rask mellomlagring hvis de første besøkende etter hver endring får en betydelig tregere side.

3. Finn elementet som styrer LCP

Identifiser hvilket element som faktisk er sidens største synlige innhold. Det er ikke alltid toppbildet. På mobil kan overskriften eller en produktinformasjon bli det viktigste elementet.

Hvis LCP-elementet er et bilde, bør filen ha riktige dimensjoner, effektivt format og en størrelse tilpasset visningsflaten. Nettleseren bør få velge mellom flere bildestørrelser, slik at en mobiltelefon ikke laster ned en fil beregnet for en bred skrivebordsskjerm.

Hovedbildet bør normalt ikke behandles som innhold langt nede på siden. Forsinket lasting er nyttig for bilder utenfor skjermbildet, men kan gjøre hovedinnholdet tregere dersom det brukes ukritisk. Unngå også at samme motiv lastes flere ganger gjennom både HTML, CSS og ulike mobilvarianter.

4. Undersøk CSS og JavaScript

Store kodefiler er ikke bare et nedlastingsproblem. JavaScript må også tolkes og kjøres. På svakere enheter kan dette blokkere hovedtråden og gi dårlig reaksjonstid selv etter at siden ser ferdig ut.

Finn ut hvilke skript som brukes på den aktuelle sidetypen. Et kart, en chat, en karusell eller et analyseverktøy trenger kanskje ikke lastes på alle sider. Del kode etter funksjon, fjern ubrukt kode og utsett funksjoner som ikke er nødvendige for den første oppgaven.

CSS kan forsinke den første visningen hvis nettleseren må laste og behandle store stilsett før innholdet tegnes. Prioriter stilene som trengs i det første skjermbildet, og unngå at alle komponentvarianter sendes til alle sider.

Ved svak INP bør dere undersøke lange JavaScript-oppgaver og hendelser som gjør for mye arbeid ved ett klikk. Et filter bør for eksempel ikke bygge opp hele resultatlisten på nytt hvis bare en liten del må oppdateres.

5. Stabiliser layouten

Layoutforskyvning oppstår ofte fordi plass ikke er reservert før et element lastes. Angi dimensjoner eller sideforhold for bilder, videoer og innebygde elementer. Sørg for at samtykkebokser, varsler og personaliserte felt ikke skyver hovedinnholdet ned etter at brukeren har begynt å lese.

Skriftfiler kan også endre tekstens bredde og høyde når de blir tilgjengelige. Begrens antall varianter, velg gode reserveskrifter og test hvordan overskrifter og knapper oppfører seg før og etter at skrifttypen er lastet.

Forbedre opplevd hastighet, ikke bare målt hastighet

Brukeren vurderer hastighet ut fra fremdrift og kontroll. En handling føles tregere når ingenting skjer etter et klikk. Gi derfor umiddelbar visuell respons, for eksempel en tydelig lastetilstand eller en deaktivert knapp mens skjemaet sendes.

Vis nyttig innhold før funksjoner som kan vente. På en produktside er navn, pris, bilde og kjøpsvalg viktigere enn anbefalinger og omfattende omtaler. På en tjenesteside bør hovedbudskapet og neste steg komme før kart, video og sekundære moduler.

Unngå samtidig falsk fremdrift. En lasteindikator løser ikke lang serverventetid eller tung kode. Den gjør bare ventingen mer forståelig mens den tekniske årsaken utbedres.

Lag en tiltaksliste per sidetype

Samle funnene i en enkel prioritering. Hvert punkt bør beskrive sidetype, symptom, sannsynlig årsak, foreslått tiltak og hvordan effekten skal kontrolleres.

Et konkret punkt kan være: Produktsider har svak LCP på mobil fordi hovedbildet lastes sent og i for stor størrelse. Tiltaket er å prioritere riktig bildevariant og kontrollere at mindre filer velges på smale skjermer. Effekten måles på de samme produktsidene før og etter endringen.

Prioriter tiltak som påvirker viktige brukerreiser og flere sider samtidig. En forbedring i en sentral sidemal gir ofte større nytte enn finjustering av én enkelt kampanjeside. Gjenta testene etter hver vesentlig endring. Da vet dere hva som faktisk virket, og unngår at flere samtidige tiltak skjuler årsak og effekt.

En rask nettside krever presis feilsøking

Ytelsesarbeid blir mer håndterbart når dere slutter å behandle hele nettsiden som én måling. Test representative sidetyper, skill mellom serverventing, visning og interaksjon, og følg leveransekjeden fra database til nettleser.

Da kan teamet rette innsatsen mot den faktiske flaskehalsen: caching når siden beregnes unødvendig ofte, bildeoptimalisering når hovedmotivet er tungt, kodearbeid når interaksjoner blokkeres, og layoutforbedringer når innhold flytter på seg. Resultatet er ikke bare bedre måleverdier, men en kundereise som føles raskere og mer forutsigbar.