Forsiden er rask, men kundereisen er treg: Test ytelse per sidetype

Kategori: Nettsideytelse

Mange ytelseskontroller starter og slutter på forsiden. Det gir et ryddig måleresultat, men kan skjule problemene som faktisk rammer kundene. Produktsider kan hente mer data, landingssider kan være fulle av bilder og sporingsskript, og skjemaer kan reagere tregt når brukeren begynner å skrive.

Nettsideytelse bør derfor vurderes per sidetype og brukeroppgave, ikke som én samlet egenskap ved nettstedet. Målet er å finne ut hvor ventetiden oppstår i den virkelige kundereisen, og velge tiltak som passer akkurat den sidemalen.

Start med sidene som har en oppgave

En teknisk test av forsiden er nyttig, men den bør bare være ett punkt i kontrollen. Velg et lite utvalg sider som representerer ulike maler, funksjoner og belastninger.

• En viktig landingsside fra søk eller annonsering
• En artikkel eller faglig innholdsside
• En kategori-, arkiv- eller søkeresultatside
• En produktside eller tjenesteside
• Et kontaktskjema, bestillingsløp eller annen konverteringsside
• Handlekurv og kasse dersom nettstedet er en nettbutikk

Prioriter sider som har mye trafikk, støtter viktige forretningsmål eller inneholder funksjonalitet som skiller seg fra resten av nettstedet. Da undersøker dere både det brukerne ser mest, og det som teknisk sett har størst risiko for å være tregt.

Core Web Vitals må tolkes i riktig sammenheng

Core Web Vitals beskriver tre sentrale deler av brukeropplevelsen. LCP handler om hvor raskt det største synlige innholdselementet lastes. INP måler hvor responsiv siden er når brukeren klikker, trykker eller skriver. CLS sier noe om hvor mye innholdet flytter seg mens siden lastes.

Verdiene bør ikke behandles som én karakter for hele nettstedet. En landingsside kan ha svak LCP fordi toppbildet er for stort. Et avansert skjema kan ha svak INP fordi JavaScript gjør for mye arbeid ved hvert tastetrykk. En produktside kan ha svak CLS fordi bildegalleriet eller lagerinformasjonen ikke får reservert plass.

Skill også mellom laboratorietester og data fra reelle besøk. En kontrollert test er god til å gjenskape problemer og sammenligne endringer. Feltdata viser hvordan nettstedet fungerer på faktiske enheter, nettverk og nettlesere. Bruk begge deler: Feltdata peker ut utsatte sidetyper, mens laboratorietesten hjelper utvikleren med å forstå årsaken.

Test kald og varm lasting

Caching kan få den samme siden til å oppføre seg svært forskjellig fra besøk til besøk. Test derfor minst to situasjoner:

1. Kald lasting: Siden åpnes uten at nettleseren eller serverens mellomlager allerede har nødvendige ressurser klare.
2. Varm lasting: Brukeren går videre på nettstedet eller besøker en side på nytt, slik at flere ressurser kan hentes fra cache.

Hvis varm lasting er rask, men kald lasting er treg, bør dere undersøke bilder, skrifter, eksterne skript og serverens responstid. Hvis begge er trege, kan årsaken ligge i sidens kode, databasetilgang eller store mengder arbeid i nettleseren.

Gjennomfør også testen på en vanlig mobiltelefon og et realistisk mobilnett. En kraftig arbeidsmaskin på raskt bedriftsnett kan skjule både tunge skript og unødvendig store filer.

Bilder må optimaliseres for plasseringen de har

Bildeoptimalisering handler ikke bare om filformat og komprimering. Det vanligste praktiske problemet er at nettstedet leverer et langt større bilde enn visningen krever.

Kontroller først elementet som påvirker LCP. På mange sider er dette et toppbilde, produktbilde eller stort innholdsbilde. Nettleseren bør få en fil som passer til skjermstørrelsen, og det viktigste bildet må ikke forsinkes av unødvendig lat lasting.

• Lag flere bildestørrelser og la nettleseren velge riktig variant.
• Komprimer originalene før de legges i publiseringsløsningen.
• Bruk moderne formater når løsningen og arbeidsflyten støtter det.
• Oppgi bredde og høyde slik at plassen reserveres før bildet er ferdig lastet.
• Bruk lat lasting på bilder lenger ned på siden, ikke ukritisk på innhold øverst.
• Unngå store bakgrunnsbilder når et vanlig responsivt bilde løser oppgaven bedre.

En artikkelmal og en produktmal kan trenge ulike regler. Produktbilder må kanskje støtte zoom, mens et illustrasjonsbilde i en artikkel kan leveres betydelig mindre. Felles opplastingsrutiner er nyttige, men de må ta hensyn til bruken.

Caching må følge innholdets levetid

God caching reduserer både serverarbeid og nedlasting, men den må settes opp etter hva slags side og data det gjelder. Statiske ressurser som bilder, skrifter, CSS og JavaScript kan ofte lagres lenge i nettleseren når filnavnet endres ved oppdateringer.

Ferdig genererte sider kan også mellomlagres, men ikke alle sider bør behandles likt. En offentlig artikkel er enkel å cache. En handlekurv, brukerkonto eller side med personlig innhold krever tydelige unntak. Feil oppsett kan ellers vise gammelt eller feil innhold til brukeren.

For WordPress og andre datadrevne løsninger kan objektcache redusere gjentatte databaseoppslag. Dette hjelper særlig på sidetyper som bygger mange menyer, filtre, produktdata eller relasjoner. Effekten bør måles på de aktuelle malene, ikke bare antas.

JavaScript og CSS bør lastes etter behov

En vanlig årsak til treghet er at alle sider laster kode for alle funksjoner. En enkel artikkel kan få JavaScript og CSS for skjemaer, karuseller, nettbutikk, chat og analyseverktøy selv om bare en liten del brukes.

Kartlegg hvilke filer hver sidetype faktisk trenger. Fjern kode som ikke er i bruk, og unngå å laste funksjonsspesifikke ressurser globalt. Ikke alt JavaScript må kjøres før siden kan vises. Skript som ikke er kritiske for første visning, kan ofte utsettes til innholdet er tilgjengelig eller brukeren trenger funksjonen.

Vær særlig oppmerksom på tredjepartsskript. Chat, videoinnbygging, kart, annonsemåling og samtykkeløsninger kan påvirke både lasting og respons. Det betyr ikke at alt skal fjernes, men hvert skript bør ha en tydelig forretningsmessig oppgave og bare lastes der det er nødvendig.

For CSS er målet å gi nettleseren nok stilinformasjon til å vise første skjermbilde raskt, uten å sende store mengder ubrukt kode. Samtidig må optimaliseringen testes visuelt. Aggressiv splitting eller forsinkelse av stilark kan gi korte glimt av uformatert innhold og flere layoutforskyvninger.

Når databasen gjør enkelte maler trege

Hvis serveren bruker lang tid før den begynner å sende siden, er ikke større bilder eller mer komprimering nødvendigvis riktig medisin. Da bør dere undersøke hva publiseringsløsningen gjør før HTML-en leveres.

Produktsøk, avanserte filtre, relaterte innlegg og store arkivsider kan utløse mange eller tunge databaseforespørsler. I WordPress kan også oppblåste innstillinger som lastes automatisk, gamle midlertidige data, unødvendige revisjoner og dårlig vedlikeholdte utvidelser bidra til forsinkelsen.

Logg hvilke databasekall som tar tid på den aktuelle sidetypen. Se deretter om data kan hentes enklere, mellomlagres eller begrenses. Det er ofte bedre å forbedre én kostbar spørring enn å legge mer maskinkraft over et uklart problem.

Opplevd hastighet begynner før alt er ferdig

En side kan føles rask selv om enkelte ressurser fortsatt lastes, så lenge viktig innhold blir synlig tidlig og siden reagerer når brukeren gjør noe. Vis overskrift, hovedbudskap og neste handling før mindre viktige elementer. Reserver plass til bilder, skjemaelementer og meldinger slik at siden ikke hopper.

Gi også umiddelbar respons på handlinger. Når brukeren sender et skjema, legger et produkt i handlekurven eller åpner et filter, bør grensesnittet vise at handlingen er registrert. Tilbakemeldingen må være reell og forståelig, ikke en animasjon som skjuler at prosessen har stoppet.

Unngå å gjøre første skjermbilde avhengig av dekorative videoer, store karuseller eller eksterne komponenter. Hvis en ekstern tjeneste er treg, bør det viktigste innholdet fortsatt være tilgjengelig.

Lag et enkelt ytelseskart

Samle kontrollen i en tabell eller arbeidsliste med én rad per sidetype. Noter hvilken brukeroppgave siden støtter, hvilket element som er LCP, hvilke interaksjoner som er viktige, hvilke eksterne tjenester som lastes, og om siden kan caches fullt.

Registrer deretter det viktigste problemet og hvem som eier tiltaket. Et bildeproblem kan ligge hos innholdsansvarlig og utvikler i fellesskap. En treg databaseforespørsel krever utvikling. Et unødvendig markedsføringsskript må avklares med den som bestilte verktøyet.

Test samme sidetype på nytt etter endringen, under de samme forholdene. Kontroller samtidig at skjemaer, sporing, innlogging og kjøpsløp fortsatt fungerer. Ytelsesarbeid er først vellykket når forbedringen både kan måles og brukes uten nye feil.

Den viktigste lærdommen er enkel: Nettsiden er ikke rask fordi forsiden er rask. Den er rask når kunden kan finne, forstå og handle uten unødvendig venting gjennom hele reisen.