Wat HTTP/2 verandert voor webontwikkeling

De nieuwe standaard HTTP/2 moet websites sneller en veiliger maken. De opvolger van het uit 1999 afkomstige HTTP 1.1 protocol zorgt ervoor dat browsers en servers efficiënter en sneller gegevens uitwisselen. Maar waar houd je rekening mee in de ontwikkeling van websites?

De HTML-code van een beetje website is vandaag de dag vele malen zwaarder dan eind vorige eeuw het geval was. De content wordt steeds rijker en voor het laden van iedere pagina worden tientallen bronnen geraadpleegd – van afbeelding tot JavaScript of CSS.

Sander Kwint van Traffic4u schreef onlangs al over onderzoek waaruit blijkt dat 80 procent van de onderzochte websites sneller laadt met het vlak voor de zomer gelanceerde HTTP/2. Ook de veiligheid van websites neemt er door toe. Chrome, Firefox en Opera ondersteunen deze nieuwe standaard bijvoorbeeld alleen in combinatie met een versleutelde – HTTPS – verbinding. Sneller, veiliger en goed voor de conversie schrijft hij. Hoe korter de laadtijd, hoe langer het boucepercentage. ‘Het resultaat: een hoger conversiepercentage en een stijging in de omzet.’

Vasthouden aan de ‘best practices’ van nu is mogelijk, maar kan nadelig uitpakken, schrijft webontwikkelaar Rachel Andrew. Zodra meer en meer servers zijn geüpgraded en browsers overstappen op de standaard, zullen zelfs de best geoptimaliseerde sites op den duur relatief langzamer worden. En dat is niet alles: zodra meer browsers een versleutelde verbinding eisen kan dat tot serieuze problemen leiden. Voor Google is de encryptie namelijk al een factor in de rangschikking van zoekresultaten. En moderne mogelijkheden van HTML – zoals het gebruik van ‘geolocation’ – zijn onbruikbaar over een HTTP-lijn.

Wil je ervoor zorgen dat de website al is voorbereid, houd dan in de bouw rekening met het volgende.

Sprites

Omdat je als webontwikkelaar wil voorkomen dat bij het aanroepen van een pagina te veel afzonderlijke verbindingen worden gelegd, is het lange tijd de standaard geweest te werken met ‘sprites’. Diverse kleine afbeeldingen worden zo samengevoegd in één groter afbeeldingsbestand. Stel dat zo’n sprite alle iconen uit een design bevat. Opent iemand de homepage dan hoeft er maar één bestand te worden geladen. Door middel van code wordt vervolgens bepaald welk deel van die afbeelding de bezoeker in die specifieke situatie krijgt te zien. Dat is een voordeel, er hoeft maar één bestand te worden geladen. Anderzijds worden al die iconen gedownload, ook wanneer iemand maar een fractie ‘gebruikt’. Zoiets geldt weer als onnodig dataverkeer.

Met de nieuwe standaard is dit geen issue meer. HTTP/2 is multiplex, verbindingen worden niet alleen achter elkaar in de wachtrij geplaatst, maar ook naast elkaar. Zo kun je meerdere van die kleine iconen tegelijkertijd downloaden. Sprites zijn hiermee overigens niet volledig overbodig gemaakt. Soms zorgt de samenvoeging van afbeeldingen ook voor betere compressie waardoor het bestand in zijn totaliteit kleiner is. Onderaan de streep bieden sprites dan nog steeds voordeel. Bekijk het dus per situatie.

Inline afbeeldingen

Als oplossing voor hetzelfde probleem is er de truc van inline afbeeldingen. In plaats van een afbeelding op te halen van een externe locatie wordt deze – gecodeerd – opgenomen in het HTML- of stijlbestand zelf. Het resultaat: minder verbindingen, maar bijvoorbeeld een groter bestand voor de stijl, de CSS. Ook de bezoekers die de betreffende afbeelding nooit zullen inladen downloaden wel dit bestand van formaat. HTTP/2 biedt een beter alternatief.

Aaneengeschakelde hulpbronnen

In een later stadium van de bouw besluiten ontwikkelaars vaak om de CSS- en JavasScript-bestanden aaneen te schakelen. Ook hiervoor geldt dat een bezoeker veel code downloadt die hij mogelijk nooit zal gebruiken. Natuurlijk zijn er wel wat slimmigheden te bedenken om dit te omzeilen, maar HTTP/2 neemt het probleem in principe weg. Een bijkomend probleem van de samengevoegde bestanden is dat caching er niet makkelijker op wordt. Om de performance te verbeteren worden veel hulpbronnen – zoals deze stijlbestanden – vanuit een tijdelijk geheugen opgehaald. Bestanden die vaak wijzigen geef je een korte houdbaarheidsdatum mee, bestanden die statisch zijn, worden bijvoorbeeld pas na een aantal maanden ververst. Hoe meer je als ontwikkelaar aaneenschakelt, hoe minder nauwkeurig de caching. Ook die nauwkeurigheid neemt door HTTP/2 dus toe.

Of overstappen nu al mogelijk is, hangt voor een belangrijk deel af van de server waarop de website of webwinkel draait. Of overstappen nu al een must is, hangt weer af van het percentage bezoekers dat al gebruikmaakt van modernere browsers. Onderstaand overzicht toont welke browsers op dit moment het protocol hebben omarmd. Houd de webanalytics daarom goed in de gaten. Trekt een website vooral ‘moderne’ gebruikers, dan is het de investering mogelijk al waard.