TL:DR: Googlebot begynte i november 2020 med å crawle ved bruk av HTTP/2. Nettsteder på HTTP/1.1 vil ikke ha noen direkte ulemper i starten, men vi ser at Google har et økt fokus på hastighet og effektiviteten av innlastingen til nettsider.
Hvorfor er dette viktig for deg som har et nettsted?
Uten et optimalisert nettsted vil du kunne gå glipp av sjansen for fornøyde brukere og økt omsetning. Utviklingen innen data går i et forrykende tempo, og ved å benytte teknologi fra 1900-tallet er det tydelig at du bør ta en helsesjekk av nettstedet ditt.
Bruker du HTTP/1.1?
Dette vil kunne redusere ditt potensiale for gode rangeringer, økt trafikk og konvertering.
For å forstå litt av omfanget og viktigheten av det vi skal snakke om i dette innlegget er det greit å ha litt grunnleggende kunnskap om hva disse forkortelsene står for og prosessene bak.
Når en bedrift livnærer seg av et nettsted sier det seg selv at alle elementer ved dette er viktig å ta tak i. Se for deg at nettstedet er en av dine fysiske butikker. Ville du vært fornøyd som butikkeier dersom:
- Produkter lå slengt på gulvet?
- Det er lys i taket som ikke fungerte?
- Temperaturen var ukomfortabel?
- Noe luktet vondt?
- Kun én kasse fungerer når du burde ha hatt fire, og køen hoper seg opp?
Nei. Dette vil etterlate et dårlig inntrykk av butikken og merkevaren. Enda verre er det hvis dere er underbemannet og man må vente altfor lenge på hjelp.
I en fysisk butikk kan disse tingene være ganske åpenbare å fikse raskt. På samme måte består et nettsted av mange deler som påvirker brukernes opplevelse av turen innom. Et nettsted er et komplisert maskineri som består av mange tannhjul som skal passe sammen og smøres over tid.
Vi begynner å se på det helt grunnleggende for hvordan internett fungerer.
Hva er HTTP?
HTTP står for Hypertext Transfer Protocol. Denne delen av måten internett fungerer for den vanlige bruker kan vi dele dette opp i 3 deler:
- Hypertext er dokumenter som kobles sammen via lenker. Ett typisk dokument er HTML-dokument. Det som gjør internett mulig er måten flere HTML-dokumenter lenkes til hverandre. I tillegg lenkes disse gjerne til andre filer som CSS og JavaScript som til sammen skaper en mer visuelt tiltalende nettside med funksjoner.
- Transfer er prosessen hvor disse filene faktisk sendes mellom klient (din enhet) og tjener (f.eks. webserver)
- Protocol er et sett med regler som bestemmer hvilke tilkoblinger som skal benyttes ved overføringen.
Dette er bare én av protokollene som gjør internett mulig, men da vi snakker om HTTP/2 er det naturlig at vi dekker dette området i dette innlegget.
Hva med HTTPS?
HTTPS betyr HyperText Transfer Protocol Secure. Dette er en kryptert versjon som krypterer informasjonen som sendes mellom klient og tjener. I et SEO-perspektiv er dette svært viktig da HTTP blir merket som usikkert, og Google kan velge å redusere nettstedets verdi i en rangeringsprosess dersom det ikke finnes en HTTPS-versjon tilgjengelig.
Litt mer info: HTTP har kommet i flere versjoner. IETF (Internet Engineering Task Force) er en gruppe frivillige fagpersoner som går gjennom og bestemmer hvilke sett med regler som skal brukes i forbindelse med prosesser på internett. Det er disse som dokumenterer protokoller som HTTP, og er et godt sted for kildeinformasjon.
Hva er HTTP/1.1?
HTTP/1.1 er versjonen som er mest brukt i dag. Denne ble lansert i 1997 og er en relativ (i dataverden) gammel teknologi.
HTTP/1.1 kom med flere nye funksjoner med metoder som kunne brukes i forhold til sine forgjengere. Det ligger flere gode artikler ute på forskjeller på HTTP-versjoner og jeg anbefaler å lese seg litt opp, dersom man finner det interessant.
Det vi skal fokusere på her er svakheten opp mot den største styrken til HTTP/2, og det er TCP: Transmission Control Protocol. Dette er kort fortalt en protokoll som sørger for at datapakker kommer fullstendig frem i dataflyten mellom server og klient. Dersom man mister en del i overføringen, sørger TCP på å sende over dataen som ble tapt.
For at dette skal fungere, må man i HTTP/1.1 åpen en TCP-tilkobling for hver datapakke som skal sendes frem og tilbake. Det vil si at man må åpne en ny kobling hver kan en klient skal etterspørre en ressurs (fil) fra server og når server skal sende etterspurte ressurs tilbake.
En nettside kan bestå av mangfoldige ressurser for å fungere og laste inn de filene som er ønsket fra nettstedseier. Og med en fare for at data kan bli tapt på veien, slik at enkelte ressurser trenger flere overføringer, sider det seg selv at dette både er ressurskrevende og lite effektivt. Det var noe av grunnlaget for videreutviklingen av HTTP/2.
Hva er HTTP/2?
HTTP/2 er den nye versjonen av HTTP man tenker vil ta over majoriteten av brukere.
Mange bruker dette allerede i dag, og spesielt nye nettsteder tar dette i bruk fra start.
HTTP/2 har utbedret mange av ulempene ved HTTP/1.x. Foruten økt sikkerhet og kvalitet på overføringer, mener vi at disse er noen av de viktigste funksjonene i forbindelse med f.eks. SEO:
- Pipelining
- Server push
- Head-of-line blocking
- Header compression
I det store og hele vil HTTP/2 kunne sikre en mer effektiv og raskere overføring mellom klient og tjener. Dette vil blant annet i et SEO-perspektiv kunne påvirke hastighet positivt og redusere last på servere.
Videre vil vi kunne se at spesielt store nettsteder og JavaScript-tunge nettsteder vil kunne dra nytte av å få et bedre crawling- og renderingbudsjett.
Pipelining
I HTTP/1.1 fungerte spørring og levering etter ressurser slik:
Klient etterspurte ressurs nr. 1 – Tjener serverte ressurs nr. 1,
Klient etterspurte ressurs nr. 2 – Tjener serverte ressurs nr. 2,
Etc. Klient måtte her vente til riktig ressurs ble servert før den kunne etterspørre ny ressurs
Dersom ressurs nr. 2 bruker lang tid, vil alle etterfulgte ressurser måtte vente på dette.
I HTTP/2 kan man aktivere pipeline, noe som vil si at klienten kan etterspørre flere ressurser samtidig, uten å måtte vente på at forrige ressurs er blir servert. Ressurs 2 og 3 kan etterspørres før serveren har levert ressurs 1 tilbake til klienten.
Det vil sikre en mye mer effektiv innlasting av siden, hvor man ikke vil måtte vente på en slik stegvis innlasting av filer slik det er ved HTTP/1.x.
Server push
Server push vil si at serveren vil sende filer før de blir etterspurt av klienten.
Hvis man åpner en HTML-side som etter hvert vil kreve en CSS- og en JS-fil, kan serveren begynne å sende disse til klienten før de blir etterspurt.
Slik kan man redusere tiden som brukes på renderingsprosessen, ved at klient ikke trenger å etterspørre filene som trengs. Disse blir sendt på initiativ fra server i forkant.
Dette er per i dag ikke aktivert, men dersom (mest sannsynlig) det blir aktivert og brukt av Googlebot kan dette kunne øke rendering-budsjettet, noe som igjen vil kunne øke potensialet til JavaScript-tunge nettsteder i forbindelse med crawling, indeksering og rangering.
Head-of-line blocking
Kanskje den største påvirkningen på hastighet er head-of-line blocking. Det vil si at i HTTP/1.x så oppstår det en kø av sendte og etterspurte ressurser. Ressurs nr. 2 kan ikke sendes før linjen/koblingen er ledig. Altså store filer som sendes før små filer vil utsette overføringen den tiden det tar før filen i forveien er komplett overført.
I HTTP/2 har man lagt opp til overføringen kan skje parallelt i samme kobling.
Se for deg at HTTP/1.x er en smal bro med kun plass til en bil. I tillegg har broen en maksvekt som kun tillater et kjøretøy om gangen. Man vil da oppleve kø i endene av broen hvor biler venter på å få kjøre over.
I HTTP/2 har man utvidet denne smale broen til en motorvei med flere filer. Flere biler kan kjøre over samtidig, og man vil fjerne flaskehalsen i starten og slutten.
Dette vil ha stor påvirkning på hastigheten på nettstedet, da overføring mellom klient og tjener vil være parallelt over én TCP-tilkobling og derfor mer effektivt.
Header compression
Når filer etterspørres og sendes mellom klient og tjener følger det alltid med en HTTP Header. Dette er informasjon om metode f.eks GET eller POST som sier noe om en fil og hva som skal skje med denne filen.
En typisk GET er hvor en klient etterspør en spesifikk fil. Serveren vil deretter finne denne filen og sende tilbake med en POST. Inne i disse HTTP Headerne er det også mer kode, og når mange av disse sendes frem og tilbake blir det mye duplisert data som ikke behøver å sendes flere ganger.
Her ser dere et eksempel på en GET-HTTP-Header:
HTTP/2 har muligheten til å korte ned dataene ved å fjerne unødvendige punkter ved repeterende handlinger.
Dette vil spare størrelse på filer og effektivisere «samtalen» mellom klient og server.
Hvordan crawler Googlebot?
Googlebot fungerer i stor grad som en nettleser som fungerer automatisk. Kall den gjerne headless. Det er et verktøy som simulerer en klient hvor crawleren følger linker på nett for å lese HTML-dokumenter og CSS-filer for å lese innholdet og «se» hvordan det ser ut for brukerne. Denne prosessen bruker noe vi kaller for et crawling budget. Dette vil si antallet sider Googlebot vil gå gjennom på ditt nettsted før den forlater siten.
Neste steg er å laste ned JS-filer for å rendre siden. Dette skjer ikke alltid umiddelbart, da dette er en veldig ressurskrevende prosess, og Googlebot har her et rendering budget.
Du har helt rett! Dette er antall sider Googlebot vil rendre hver gang den er innom siten. Dette tallet er gjerne lavere enn ditt crawling budget grunnet ressursbruk, og for store JS-tunge nettsteder er dette svært viktig. Derfor vil Googlebot komme tilbake til siden når den har allokert ressursene til dette.
Videre, innhentingen av disse filene skjer på samme måte som med en nettleser. Googlebot følger en lenke, etterspør ressursene fra servere, og mottar disse.
Denne prosessen måler Googlebot hele tiden for å se effektiviteten. Hastighet og ressursbruk er svært viktig for brukere, spesielt i dag hvor mesteparten sitter på mobil og gjerne over mobilnett. Google fokuserer på å levere gode sider til sine brukere, og er derfor opptatt av å premiere sider som gir god brukeropplevelse og brukervennlighet.
Googlebot begynte å crawle ved bruk av HTTP/2 i november
Google kom ut med informasjon om at Googlebot vil i november i år, 2020, begynne å bruke HTTP/2.
Det vil i første omgang kun dreie seg av et fåtall nettsteder, men Googlebot vil over tid ekspandere bruken med tiden som kommer.
Vi ser i våre datakilder at det fortsatt er stor variasjon over hvilke nettsteder Googlebot velger å benytte seg av HTTP/2 vs. HTTP/1.1.
Hvilken påvirkning vil dette ha for deg?
Dersom du har HTTP/2 allerede er det ikke noe du må gjøre. Du kan ikke forvente at Googlebot crawler over HTTP/2 fra og med november, men jo «viktigere» side du har i Googles øyne, jo raskere vil du nok bli prioritert.
Hvordan kan du se om Googlebot crawler via HTTP/2?
Dette kan man se i serverens loggfiler. Her vil man se HTTP Headerne som benyttes ved en gjennomgang av crawleren.
Dersom du ikke har HTTP/2 og fortsatt benytter deg av HTTP/1.1, så må du heller ikke gjøre noe. Googlebot vil fungere på både HTTP/1.1 og HTTP/2.
Google sier selv at HTTP/2 ikke vil ha noen direkte påvirkning på indeksering og rangering.
Altså vil du ifølge den offisielle dokumentasjonen ikke få økt rangering bare av å bytte over til HTTP/2.
Indirekte vil dette ha påvirkning. Har du i utgangspunktet et nettsted som har såpass lav hastighet at det negativt påvirker rangering og brukeropplevelsen, vil en overgang kunne øke rangeringen ved at du får hastigheten opp på en «godkjent» nivå.
I tillegg vil du kunne sørge for at brukerne dine når sidene innenfor rimelig tid. Dette reduserer sjansen for at de forlater nettstedet og gjør handelen et annet sted.
Hva om du ikke har HTTP/2?
Google sier i dag at du ikke trenger å gå over for indekseringens og rangeringens skyld. Dette kan endre seg etter hvert, noe vi har opplevd flere ganger tidligere. Nye ting som blir standardisert blir først nice-to-have, også blir det need-to-have hvor det kan ha en direkte påvirkning.
Dersom du vurderer å gå over til HTTP/2, ikke gjør det først og fremst for søkemotorer, gjør det for brukerne dine. Dette vil påvirke brukeropplevelsen positivt.
Søkemotorer setter pris på gode brukeropplevelser, og det du gjør positivt for brukere, vil spille positivt inn for søkemotorene.
Hvordan gå over til HTTP/2?
Det er i all hovedsak serveren din som bestemmer om den er HTTP/2-kompatibel.
Jeg vil ikke ramse opp alle servertyper her, men ved å sjekke i dokumentasjonen til din server eller snakke med dine utviklere vil du kunne få svar på dette.
De mest brukte servertypene som har HTTP/2 er:
- Apache
- Microsoft IIS
- Nginx
De mest brukte CDN som har HTTP/2 er:
- Cloudflare
- Fastly
- Akamai
- Microsoft Azure
Bruker nettstedet HTTP/2?
Det er flere metoder på å finne ut om ditt nettsted bruker HTTP/2. Den enkleste måten er å benytte en HTTP/2-test som denne.
Du kan også bruke curl-funksjonen via terminal ved å benytte deg av denne kommandoen:
«Curl -I https://www.eksempel.com»
Dette er spesielt nyttig dersom du skal gjøre en omfattende test av flere nettsider/nettsteder samtidig.
Dette blir viktigere fremover
Vi kan ut ifra dette tolke dette som at Google vil ha mer fokus på effektivitet og hastighet fremover. Dette står i tråd med Core Web Vitals som er kommunisert vil bli nye rangeringsfaktorer i løpet av 2021. Her er det også fokus på hastighet og innlasting av nettsiden og dens elementer.
Oppdatering: Utrullingen av Core Web Vitals som en del av rangeringsalgoritmen til Google startet 15. juni 2021 og forventes å være fullstendig i utgangen av august samme år.
Vi vil derfor på generell basis be alle sjekke ut om dere i dag kjører på HTTP/2 eller om serveren deres er kompatibel. Dere bør oppdatere, og jo fortere dette skjer, jo fortere kan dere slippe dette punktet ut av hjernebarken. Det er kjedelig å se at dette blir en rangeringsfaktor før dere oppdager at dere må bytte serverløsningen deres.
For dere som vurderer å opprette nye nettsteder, sjekk dette punktet før dere velger serverløsning.
Dersom dere ønsker å vite mer om dette, eller andre ting tilknyttet nettsteder og Google, send oss gjerne en melding!