Hvorfor er nettsiden treg? Det meste av ventetiden skjer før siden vises

Klokka er 07.40, og det drypper fra taket på badet. Hun søker «rørlegger Tromsø» på telefonen, trykker på det andre treffet og ser på en hvit skjerm.

Tre sekunder senere er hun tilbake i søkeresultatet. Hun ringer nummer tre.

Rørleggeren med den hvite skjermen får aldri vite at han mistet en jobb. Nettsiden hans var ikke nede. Den var bare treg, og det meste av ventetiden gikk med til ting som skjedde før et eneste bilde var på vei.

Hva som skjer mens skjermen er hvit

Når noen åpner en nettside, skjer det i tre etapper:

1. Forespørselen reiser fra telefonen til serveren der nettsiden ligger.
2. Serveren lager siden og sender den tilbake.
3. Nettleseren henter det siden trenger: bilder, skrifter og skript.

De fleste råd om treg nettside handler om den tredje etappen. Komprimer bildene, fjern tillegg. Det er gode råd. Men på en vanlig bedriftsnettside er det ofte de to første etappene som spiser tiden, og der hjelper ikke et mindre bilde.

Tiden de to første etappene tar, har et navn: tid til første byte, eller TTFB. Google regner 0,8 sekunder eller mindre som bra. Bruker serveren lenger enn det, har den besøkende ventet før noe som helst har begynt å vises.

Siden bygges på nytt for hver besøkende

Her er det få som vet hvordan det henger sammen. En typisk WordPress-side ligger ikke ferdig noe sted. Hver gang noen åpner den, starter serveren et program som henter teksten fra en database, setter den inn i en mal, legger på meny og bunntekst og sender resultatet.

Femti besøkende på forsiden i dag betyr femti like forsider, bygget fra bunnen femti ganger.

Det fungerer. Det er bare tregt, særlig på billige servere der nettsiden din deler maskinkraften med hundrevis av andre. Det finnes tillegg som lagrer en ferdig kopi, såkalt hurtigbuffer eller cache, men noen må sette dem opp. Og de må vite når kopien er utdatert. Det er derfor så mange nettsider enten er trege eller viser åpningstidene fra i fjor.

Avstanden teller også

Lys i fiberkabel går omtrent 200 000 kilometer i sekundet. Det høres raskt ut helt til du regner på det.

Står serveren i USA, tar en tur fram og tilbake fra Norge rundt en tiendedel av et sekund. En ny side trenger gjerne tre eller fire slike turer før den første byten kommer: et oppslag for å finne serveren, en sikker tilkobling og så selve forespørselen. Da har den besøkende ventet nesten et halvt sekund på reiseveien alene, før serveren i det hele tatt har begynt å jobbe.

Billig hosting står ikke alltid der du tror. Spør leverandøren før du antar at nettsiden ligger i Norge, og husk at hostingen er den minste posten i hva en nettside faktisk koster.

Hva et CDN gjør

Tenk på to bakerier. Det ene baker hvert brød når kunden står i døra. Det andre har ferske brød i disken fra klokka sju og baker et nytt brett når noe er utsolgt eller oppskriften endres.

Et CDN, et innholdsleveringsnettverk, er bakeriet med full disk. Det er et nett av datasentre rundt om i verden, og hvert av dem har en ferdig kopi av nettsiden din. Den besøkende får siden fra datasenteret nærmest seg, og ingen bygger den på nytt.

Det løser begge problemene på én gang. Siden er ferdig, og den står nær.

Den vanskelige delen er ikke å lagre kopien. Det er å vite når den må kastes. Endrer du åpningstidene, må kopien i hvert eneste datasenter byttes ut, ellers ser halve landet de gamle. Derfor bruker mange nettsider CDN bare til bilder og lar selve sidene ta den lange veien.

Det et CDN ikke kan fikse

Vi skal være ærlige her: et CDN gjør ikke en tung side lett.

• Bilder rett fra kameraet. Et mobilbilde på 6 MB er like tungt uansett hvor nær det står. På nett trenger det sjelden å være over 300 KB.
• Skript fra andre selskaper. Chatbobler, annonsepiksler og bookingløsninger lastes fra hver sin server, og den farten styrer du ikke. Mange av dem krever dessuten samtykke, noe vi har skrevet om i innlegget om cookie-banner og personvernerklæring.
• Skrifter fra Google Fonts. Enda en tur til en annen server før teksten kan vises riktig.

Et CDN tar seg av veien til den besøkende. Det du har lagt på siden, må fortsatt fraktes.

Slik sjekker du din egen side

Åpne PageSpeed Insights, lim inn adressen din og velg mobil. Det er mobiltallet som teller, for det er der kundene dine er. Se etter to tall:

Er TTFB høy, ligger problemet i de to første etappene: serveren og avstanden. Det fikser du sjelden selv. Enten må leverandøren endre oppsettet, eller så må du bytte leverandør, og det kan du gjøre uten å miste plassen på Google. Er TTFB lav og LCP høy, er det bildene og skriptene.

LCP er en av de tre Core Web Vitals, målingene Google bruker når den vurderer hvordan en side oppleves. Den avgjør sjelden en plassering alene. Mellom to like gode sider vinner likevel den raske, og kunden som trykket seg tilbake til søkeresultatet, kommer uansett ikke igjen. Fart er bare én av seks vanlige grunner til at en bedrift blir borte i søk.

Slik gjør vi det i Sitekit

Hver side på en Sitekit-nettside lages én gang, første gang noen besøker den. Deretter ligger den ferdig i et CDN og leveres fra datasenteret nærmest den besøkende. For de fleste i Norge er det Stockholm.

Når du publiserer en endring, kastes de gamle kopiene med en gang. Den første som åpner siden etterpå, venter et øyeblikk mens den nye versjonen lages. Alle etter det får den ferdig.

Resten av listen over er også ordnet:

• Bildene krympes når du laster dem opp, og hver besøkende får en versjon i riktig bredde for skjermen sin.
• Skriftene ligger på samme sted som nettsiden, ikke hos Google.
• Statistikken bruker ingen skript fra andre selskaper.
• Kart, video og booking fra andre tjenester lastes først når den besøkende har sagt ja.

Det siste har en bakside vi ikke kan gjøre noe med. Legger du inn en bookingløsning fra en annen leverandør, er den delen av siden nøyaktig så rask som leverandøren er. Resten av driften, fra servere til sertifikater, står på siden om hosting og domene.

Kunden i Tromsø vet ikke hva TTFB er. Hun vet bare hvilken rørlegger som tok telefonen.