Finn den første flaskehalsen: En praktisk metode for raskere nettsider
En treg nettside blir sjelden rask av tilfeldige enkelttiltak. Finn først hvor ventetiden oppstår, og prioriter tiltaket som faktisk forbedrer brukerreisen.
Kategori: Nettsideytelse
Når en nettside oppleves treg, er det fristende å komprimere noen bilder, installere en cacheløsning eller fjerne et programtillegg. Slike tiltak kan hjelpe, men de treffer ikke nødvendigvis problemet. Hvis serveren bruker lang tid på å lage siden, hjelper det lite å finjustere CSS. Hvis hovedbildet lastes for sent, løser ikke en raskere database hele brukeropplevelsen.
En bedre arbeidsmåte er å finne den første flaskehalsen i innlastingen. Det er punktet der ventetiden begynner, og som forsinker det brukeren skal se eller gjøre. Når dette punktet er identifisert, blir det enklere å velge mellom tiltak i server, database, caching, bilder, JavaScript og CSS.
Start med brukerreisen, ikke forsiden
Forsiden er ofte den mest testede siden på nettstedet, men ikke nødvendigvis den viktigste. En potensiell kunde kan komme direkte til en tjenesteside fra et søk, åpne en produktside fra en annonse eller gå rett til et skjema fra en e-post.
Velg derfor tre til fem representative sider eller handlinger før dere begynner å måle. Et bedriftsnettsted kan for eksempel teste:
- en sentral tjenesteside åpnet fra et eksternt søk
- en artikkel med flere bilder og relaterte innlegg
- et kontaktskjema med validering
- en produktside eller kategoriside i nettbutikken
- navigasjon fra én intern side til en annen
Test både første besøk og videre navigasjon. Første besøk viser hva en ny bruker møter uten lagrede ressurser. Videre navigasjon viser om caching faktisk reduserer ventetiden når brukeren beveger seg rundt på nettstedet.
Del ventetiden i fire faser
Det er lettere å finne årsaken når innlastingen deles i faser. Hver fase peker mot ulike tekniske tiltak.
1. Før nettleseren mottar innhold
Hvis det tar lang tid før nettleseren mottar det første svaret, ligger problemet ofte på serversiden. Mulige årsaker er tunge databaseforespørsler, omfattende behandling i publiseringsløsningen, eksterne integrasjoner eller manglende sidecache.
Test samme side flere ganger, både som utlogget og innlogget bruker. Hvis utloggede besøk er raske, men innloggede er trege, kan sidecachen skjule en underliggende svakhet i applikasjonen eller databasen. Det er særlig relevant for redaktører, kunder med innlogging og nettbutikker, der deler av innholdet må lages dynamisk.
2. Frem til hovedinnholdet blir synlig
Når serveren svarer raskt, men det viktigste innholdet likevel vises sent, må dere se på ressursene nettleseren trenger for å tegne siden. Core Web Vitals-målingen Largest Contentful Paint, ofte forkortet LCP, handler om når det største synlige innholdselementet blir vist.
LCP-elementet er ofte et toppbilde, en stor overskrift eller en innholdsblokk. Finn hvilket element som faktisk måles før dere optimaliserer. Et stort toppbilde kan være godt komprimert og likevel komme sent fordi nettleseren ikke oppdager det tidlig nok. Det kan også bli forsinket av CSS, skrifter eller JavaScript som blokkerer visningen.
For bilder bør dere kontrollere at riktig bildestørrelse leveres til enheten, at formatet er egnet, og at filen ikke har større dimensjoner enn den vises med. Bilder langt nede på siden kan lastes senere. Hovedbildet øverst bør derimot prioriteres og ikke behandles som om det var utenfor synsfeltet.
3. Fra synlig side til fungerende side
En side kan se ferdig ut uten å være klar til bruk. Brukeren klikker på menyen, åpner et filter eller begynner å skrive, men nettleseren reagerer sent. Da er JavaScript ofte en del av problemet.
Interaction to Next Paint, INP, måler hvor raskt siden gir synlig respons etter brukerens handlinger. Tung JavaScript-kjøring kan blokkere nettleseren mens sporingsverktøy, animasjoner, kalkulatorer, chat, samtykkeløsninger og grensesnittfunksjoner arbeider samtidig.
Lag en oversikt over hvilke skript som lastes på hver sidetype. Et bestillingsverktøy trenger kanskje ikke å lastes på alle artikler. Et produktgalleri trenger ikke å kjøre på kontaktsiden. Fjern ubrukt kode der det er mulig, og last funksjoner først når siden faktisk trenger dem.
CSS bør vurderes på samme måte. Store stilsett kan inneholde regler for komponenter som ikke finnes på den aktuelle siden. Kritiske stiler for innholdet øverst bør bli tilgjengelige tidlig, mens resten kan håndteres uten å blokkere det brukeren venter på.
4. Når innholdet flytter på seg
Cumulative Layout Shift, CLS, avdekker uventede forskyvninger i oppsettet. Et typisk eksempel er en knapp som flyttes fordi et bilde, en annonse, et skjema eller et varsel settes inn etter at resten av siden er vist.
Reserver plass til bilder, video, innebygde elementer og dynamiske meldinger. Vær også oppmerksom på skrifter som endrer tekstens bredde og linjebryting når de blir lastet. Målet er at brukeren skal kunne begynne å lese og handle uten at innholdet flyttes underveis.
Bruk caching på riktig nivå
Caching er ikke ett enkelt tiltak. Nettlesercache lagrer statiske ressurser hos brukeren. Sidecache kan levere ferdig generert HTML uten at publiseringsløsningen bygger siden på nytt. Objektcache kan redusere gjentatte databaseoperasjoner. En mellomliggende cache kan levere ressurser nærmere brukeren.
Avklar først hva som kan caches, hvor lenge det kan caches, og hva som skal føre til at cachen tømmes. For aggressiv caching kan vise gammelt innhold, feil priser eller data fra feil kontekst. For forsiktig caching gir liten ytelsesgevinst.
Kontroller også om cachen faktisk treffer. En løsning kan være aktivert uten å ha effekt fordi informasjonskapsler, forespørselsparametere eller personlige elementer gjør hver forespørsel unik. Mål derfor forskjellen mellom første og gjentatte besøk i stedet for å anta at cacheinnstillingen virker.
Undersøk databasen når serveren er flaskehalsen
Databasen bør ikke optimaliseres bare fordi nettstedet har mange innlegg eller produkter. Det avgjørende er hvilke forespørsler som kjøres, hvor ofte de kjøres, og hvor mye data som behandles per sidevisning.
Tegn på databaseproblemer kan være at enkelte sidetyper er betydelig tregere enn andre, at administrasjonen bruker lang tid på å åpne lister, eller at ytelsen faller kraftig ved mange samtidige besøk. Filtrering, søk, relaterte produkter og innhold som hentes etter omfattende kriterier, kan være mer krevende enn vanlige innholdssider.
Se etter gjentatte forespørsler, unødvendig store resultater og data som lastes selv om de ikke skal vises. Gamle revisjoner, midlertidige data og rester etter fjernede utvidelser kan ryddes, men opprydding alene erstatter ikke analyse av de tunge forespørslene. Ta sikkerhetskopi og test endringer før produksjonsdatabasen endres.
Kombiner feltdata med kontrollerte tester
Core Web Vitals bør vurderes med data fra reelle brukere når nettstedet har tilstrekkelig datagrunnlag. Slike data fanger opp variasjoner i enheter, nettverk og geografisk plassering. Ulempen er at de viser en periode som allerede har gått, og at det kan ta tid før forbedringer blir synlige.
Kontrollerte tester gir raskere tilbakemelding og gjør det mulig å gjenta samme scenario. De er nyttige for å finne konkrete årsaker, men representerer ikke alle brukere. Bruk derfor feltdata til å forstå omfanget og laboratorietester til å diagnostisere og kontrollere tiltak.
Test alltid på nytt etter en endring. En mindre JavaScript-fil kan for eksempel redusere blokkering, men samtidig introdusere feil i menyen. Et nytt bildeformat kan gi mindre filer, men skape unødvendig prosessering på serveren hvis bildene genereres ved hver forespørsel.
Opplevd hastighet er mer enn måleresultatet
Brukeren vurderer ikke nettsiden ut fra en teknisk rapport. Opplevelsen påvirkes også av om siden gir tidlig tilbakemelding, om innholdet kommer i en fornuftig rekkefølge, og om det er tydelig at en handling er registrert.
Vis det viktigste innholdet først. Gi umiddelbar visuell respons når brukeren sender inn et skjema eller legger en vare i handlekurven. Unngå tomme flater mens hele komponenter venter på data. En enkel og stabil plassholder kan gjøre ventetiden forståelig, men bør ikke brukes til å skjule at en grunnleggende prosess er for treg.
Opplevd hastighet handler også om å fjerne unødvendige steg. En teknisk rask produktside oppleves fortsatt tung hvis filteret krever flere bekreftelser, eller hvis et skjema laster inn nye felt uten tydelig respons.
Prioriter én dokumentert flaskehals om gangen
Lag en kort tiltaksliste der hvert punkt beskriver berørt sidetype, observert problem, sannsynlig årsak og forventet brukerforbedring. Prioriter problemer som rammer viktige brukerreiser og mange besøk, ikke bare tiltak som er enkle å gjennomføre.
- Velg en konkret side og handling.
- Finn om ventetiden oppstår i serveren, visningen eller interaksjonen.
- Identifiser elementet, ressursen eller forespørselen som skaper forsinkelsen.
- Gjør én avgrenset endring.
- Test funksjon, måleresultat og opplevd hastighet på nytt.
- Følg utviklingen med reelle brukerdata over tid.
Denne arbeidsformen gjør ytelsesarbeidet mindre tilfeldig. Dere unngår å bruke tid på generell opprydding når problemet egentlig er et sent hovedbilde, en tung databaseforespørsel eller JavaScript som kjører på sider der det ikke trengs. Resultatet er ikke bare bedre målinger, men en nettside som reagerer raskere der brukeren faktisk merker det.
