Hastighet er en del av kundeopplevelsen.
Se for deg en kunde som åpner en produktside på mobilen. Bildet lar vente på seg. Kunden trykker på størrelsesvelgeren, men ingenting skjer. Så flytter kjøpsknappen seg akkurat idet fingeren treffer skjermen.
Dette er også design. Det kunden opplever mellom klikkene, er like mye en del av butikken som bildene, fargene og teksten. En rask, stabil side gjør det enklere å finne et produkt, lese om det og komme videre.
Derfor mener vi at page speed hører hjemme i de første valgene du tar om en nettside. Hver funksjon må fortjene både plassen sin og tiden den bruker.
Hva må nettleseren gjennom?
Spill av illustrasjonen
All kode bør ha en jobb å gjøre.
En stor standardmal kan være laget for hundre forskjellige butikker. Den kan tilby bildegallerier, videobakgrunner, mange menyvarianter og animasjoner. Problemet oppstår når kunden må laste ned funksjoner din butikk aldri bruker.
Nettleseren må hente og behandle ressursene. Mye JavaScript kan dessuten bruke tid på å kjøre, slik at siden reagerer tregere. Å redusere ubrukt CSS og JavaScript kan redusere både nedlasting og arbeid i nettleseren. Les Googles veiledning om ressurslasting.
En mal er ikke automatisk treg, og skreddersydd kode er ikke automatisk rask. Det avgjørende er hva siden faktisk sender til nettleseren, når det lastes, og hva det gjør.
Bygg det siden trenger.
La resten bli igjen.
Fra «kjekt å ha»
til det kunden trenger.
Slik tenker vi om kode i Holio Studio.
Utgangspunktet vårt er enkelt: Vi vil lage akkurat det du trenger for oppgaven. En landingsside skal ikke arve funksjonslisten til en hel temabutikk. Et kontaktskjema skal løse kontaktbehovet. En produktside skal hjelpe kunden å velge.
Studio bygger på Holio-plattformen, med produkter, kunder og ordre som en del av grunnlaget. Det gir oss en tydelig retning: velge innhold og funksjoner ut fra bedriften din, og holde unødvendig kompleksitet ute.
- Innhold først. Tekst og viktig produktinformasjon skal få prioritet.
- Interaktivitet med hensikt. Vi ønsker å bruke kode der den løser et konkret behov.
- Ytelse som en del av leveransen. Den ferdige siden må vurderes med sine faktiske bilder, skrifter og integrasjoner.
Dette er et byggeprinsipp, ikke et løfte om en bestemt lastetid eller en perfekt PageSpeed-score. AI-generert kode trenger også gjennomgang. Resultatet må måles.
Tre ting kunden faktisk merker.
Core Web Vitals beskriver lasting, respons og stabilitet. Googles grenser for «god» opplevelse er:
Når det største synlige innholdselementet vises.
Hvor raskt siden gir en visuell respons på interaksjoner.
Hvor mye innholdet uventet flytter seg. En poengverdi, ikke tid.
Grensene vurderes ved 75-persentilen, separat for mobil og desktop. Alle tre må være gode. Tallene over er anbefalte terskler, ikke målinger av Holio. Kilde: Google, Web Vitals.
Bedre flyt. Et bedre utgangspunkt for salg.
For en nettbutikk er det naturlige målet at kunden kommer frem til riktig produkt og får gjennomført kjøpet. Venting og knapper som ikke reagerer, legger friksjon i den reisen. Hvor mye en forbedring påvirker salget, må du undersøke i din egen butikk.
Google bruker Core Web Vitals i rangeringssystemene sine. Gode resultater er likevel ingen garanti for høy plassering. Relevant, nyttig innhold og andre signaler teller også. Les Google Search Centrals forklaring.
Vi vil derfor se ytelse sammen med det siden skal oppnå: Kan kunden finne informasjonen? Fungerer valgene? Er veien til neste steg enkel?
Start med siden kunden bruker.
- Velg en viktig side. Start gjerne med en mye brukt produkt- eller kategoriside.
- Undersøk den i PageSpeed Insights. Se etter både feltdata og laboratorietester. En test er ikke det samme som alle kundenes opplevelser.
- Se etter unødvendig last. Gjennomgå store bilder, skrifter, ubrukt kode og tredjepartsskript. Behold det som gir verdi.
- Mål igjen etter endringen. Bruk sammenlignbare testforhold og følg med på reelle brukere over tid.
Laboratorietester hjelper under utvikling. Feltdata viser opplevelser på brukernes faktiske enheter og nettverk. Begge er nyttige, men de svarer på ulike spørsmål. Mer om måling hos web.dev.
En rask nettside er resultatet av mange bevisste valg. Vi vil starte med det viktigste: bygge for behovet ditt, og gi hver del av koden en grunn til å være der.