VG bruker det. Dagbladet gjør det ikke. NRK gjør det, TV2 gjør det ikke.
Heller ikke regjeringen.no synes det er bryet verdt.
Hva snakker jeg om? HTTP/2-protokollen så klart.
Hva er egentlig HTTP/2?
En gjennomsnittlig nettside betjener et hundretalls objekter, det være seg bilder, scripts, stilark med mere. De store nettjenestene som Facebook, Google, Amazon bruker selvfølgelig allerede HTTP/2 for å gjøre nedlastingen så effektiv som mulig.
«Mange har ikke kommet seg over ennå.»
I følge HTTP Archive bruker i dag 46.5% av alle tjenester HTTP/2 (i resten av artikkelen forkortet til H/2). Som nevnt innledningsvis bruker også mange norske nettjenester H/2, men mange har ikke kommet seg over ennå.
Hva er det som gjør at HTTP2 er raskere enn H/1, som lenge var den rådende standarden? Det er selvfølgelig flere ting, men den klart viktigste er at protokollen lar tjeneren laste ned flere ressurser samtidig.
H/1 er begrenset av noe som kalles for «head of line blocking». Tenk på det som en ketsjupflaske der du har en stor masse som skal ut av flasken, men bare et lite hull å presse det gjennom. Dersom det skulle oppstå problemer med en av nedlastingen må de andre vente til problemet er løst, hvilket altså er den nevnte blokkeringen. For å omgå dette vil dagens nettlesere åpne opptil seks tilkoblinger mot tjenesten. Det åpner for en form for parallellisme, men hver tilkobling vil fortsatt stoppe opp om det oppstår problemer med nedlastingen.
Foruten dette problemet er det en lite effektiv teknikk dersom du vil sende avgårde mange mindre filer. Det er en av årsakene til at pakking av kode i store kodefiler med verktøy som Browserify eller Webpack ble så tvingende nødvendig.
Et annet problem som kanskje virker lite i den store sammenheng, men som viser seg å virkelig monne, er tjukke headers. Headers er metadata som beskriver det som sendes. La oss anta at en gjennomsnittsheader er rundt en 450 bytes og at en vanlig nettside har omtrent 75 objekter som skal sendes til brukeren. I bare metadata tilsvarer det altså omtrent 32KB. Det er ikke mulig å komprimere headere i H/1, og ettersom header-informasjonen gjerne er større enn det som kan sendes over en TCP-spørring, så går det gjerne endel data fram og tilbake før ressursen som skal frem endelig kan sendes.
Hvordan kommer du deg over på H/2?
Alle moderne nettlesere støtter H/2 i dag.
Utfordringen er å sette opp webserveren din til å støtte protokollen, samt å skaffe og sette opp et sikkert TLS-sertifikat. H/2 krever egentlig ikke dette, men ingen nettlesere støtter tilkoblinger mot H/2 uten en kryptert tilkobling.
Hva er greia med GraphQL?
Dette skyldes prøving og feiling fra tidligere eksperimenter (med SPDY) og en voksende erkjennelse at alt innhold som sender over nettet bør krypteres av hensyn til sikkerhet og personvern.
Overgang til H/2 anses som en gyllen mulighet til å tvinge gjennom kryptert kommunikasjon over nettet.
Regn med at du må finjustere webserveren din for å ta i bruk H/2 på en effektiv måte. Det finnes en rekke ressurser som kan hjelpe deg med å analysere hvor godt du har gjort jobben din godt nok (for eksempel http2.pro og https://tools.keycdn.com/http2-test).
Kvitt deg med H/2-«optimeringer»
En rekke teknikker som du har lært er god praksis i H/1 er å regne som antimønstre i H/2.
«...god praksis i H/1 er å regne som antimønstre i H/2.»
Blant disse er en teknikk kalt Spriting, som går ut på samle en rekke mindre bilder i et større bilde og så henvise til posisjonen og størrelse for å vise dem fram på websiden. I H/2-protokollen er ikke lenger spørringer blokkerende og nedlasting foregår i parallell, så denne teknikken er unødvendig sett fra et ytelsesperspektiv.
Det samme gjelder for mindre blokker med JavaScript- og CSS-kode som det tidligere har vært anbefalt å smelte inn sammen med HTML-koden for å redusere antall nedlastinger fra serveren. Disse kan du med H/2 fint betjene som eksterne filer, og derved ikke bare dra nytte av at de kan lastes ned i parallell, men også at de kan caches i nettleseren slik at brukeren ved gjentakende besøk ikke trenger å laste dem ned overhodet.
Pakking av mange små JavaScript-filer til en større en gir fortsatt mening i H/2, fordi verktøyene som pakker koden blant annet er hjelper til med å fjerne overflødig kode, og skriver den om slik at den støttes av eldre nettlesere.
En annen teknikk kalt Sharding omgår restriksjonen hvor nettleseren bare åpner et visst antall tilkoblinger for hver tjener ved å spre ressursene over flere tjenere med ulike domenenavn. I en H/2-verden er denne teknikken også unødvendig.
Trenger du virkelig daglige standup-møter?
Domener uten cookies for betjening av ressurser som for eksempel bilder er også en vanlig teknikk i H/1-verdenen. Det skyldes at headers og cookies i H/1 ikke er komprimert og gjerne bidrar til betydelig treghet i nedlasting av ressurser bare ved å sende metadata fram og tilbake mellom klient og server. I H/2-verdenen er headers komprimert og det lagres en historikk med headers som allerede er sendt og mottatt for å unngå at unødvendig header-informasjon sendes til klienten. Det er derfor ikke lenger nødvendig å sette opp slik ressurs-tjenere.
En bonus er at når du betjener statiske ressurser over det samme domenenavnet som HTML-koden, så eliminerer du ytterligere DNS-oppslag og en potensiell treghet ved henting av disse ressursene.
Hvorfor er H/2-adopsjonen så treg i Norge?
Det er lett å finne eksempler på nettsider som ikke bruker H/2 i Norge.
Protokollen gjør nettet raskere og er bakoverkompatibel med HTTP/1, så hvorfor er adopsjonen fortsatt så treg?
«Det vil nok gå seg til.»
Det er kanskje så enkelt at ikke mange nok innser at det faktisk er mye å hente på gjøre jobben med å gå over til den nye protokollen.
Ambisiøse utviklere vil etterhvert innse at det ligger betydelig gevinst i å forstå protokollen. De vil grave seg ned i detaljene, implementere dem og gjøre nettsidene deres raskere enn konkurrentens.
Det vil nok gå seg til, og kanskje artikler som dette kan være den ekstra dytten som får nok en tjeneste til å skifte?
