Soms denk ik dat mijn interesse in optimalisatie wat doorslaat. Regelmatig zit ik 
urenlang online te lezen over Service Workers met Read-through caching, de nieuwste npm build tools voor het maken van een productieversie van je javascript en sinds een paar maanden zit ik te kijken naar http/2.
Http is iets wat de meesten alleen kennen van de URLs, "haa-tee-tee-pee-dubbelepunt-slash-slash-wee-wee-wee...", je kent het wel. Wat minder mensen weten is dat HTTP het protocol is wat het internet van vandaag mogelijk maakt. Als je kijkt naar de spec van HTTP 1.0 uit 1996, zie je dat er ondertussen veel is veranderd. Hoog tijd voor HTTP om mee te groeien, en een half jaar geleden is eindelijk de specificatie RFC7540 goedgekeurd: HTTP 2.0 komt er aan!
Nieuws?
Natuurlijk, als er na 18 jaar een update voor een protocol uitkomt, zit er een hoop nieuws in. Toch is het voor de geïnteresseerde webdeveloper een feest van herkenning. Onze grote vriend Google heeft namelijk fanatiek meegewerkt aan http/2. Zo fanatiek zelfs, dat ze hun eigen bèta versie hebben gemaakt, SPDY.
Om maar meteen met de deur in huis te vallen: De interactie tussen websitebezoeker en server is compleet anders in http/2. Gelukkig merkt de bezoeker daar vrij weinig van, behalve dat alles een heel stuk sneller is! Http/2 maakt het namelijk mogelijk om de server de controle te geven. Dit is het beste uit te leggen met een voorbeeld:
Stel, je bezoekt het blog van Seo Online Marketing. Dan vraagt je browser een url op met de inhoud van de laatste blogpost. Daarbij willen we je natuurlijk ook een gezellige ervaring geven door de pagina mooi op te maken met CSS. In HTTP 1.1 (de "huidige" versie uit 1997), de browser krijgt eerst de tekst binnen en daarin staat een linkje waarmee de opmaak van de pagina ook opgevraagd kan worden. Handig, behalve dat de browser nu weer naar de server moet om het volgende bestand te downloaden. In http/2 kan de server meteen een "push-promise" meegeven. Dit moet je zien als de server die zegt "Zodra ik alle tekst heb gestuurd, stuur ik je ook meteen de CSS code, geen zorgen!". En beloofd is beloofd, dus de server levert ook meteen de opmaak af. Super handig!
Optimaliseren in http/2
Webdevelopers zijn over het algemeen hetzelfde als ik, verslaafd aan snelheid. Daarom hebben we over de jaren heen heel wat trucjes bedacht om die pagina weer net iets sneller in je browser te krijgen. Maar webdevelopers, pas op! Je slimmigheidjes werken niet altijd meer in http/2. Soms werken ze zelfs averechts!
Wat hetzelfde is gebleven
Geen zorgen, niet alles is anders. De volgende tips&tricks werken nog altijd:
- Reduceer DNS lookups: Iedere keer dat iets van een domeinnaam geladen moet worden, moet eerst de server gevonden worden. Dat proces heeft een zware stap: het opzoeken van het IP. Daar is niets veranderd, nog steeds op letten! (Tip: firefox doet nog steeds iets met een dns-prefetch in de HEAD)
- Hergebruik TCP verbindingen: Deze kom je niet eens veel tegen als normale web developer, dus als je niet weet hoe dit zit, geen probleem!
- CDN: simpelweg: Als je content om de hoek op een server staat gaat het een stuk sneller dan wanneer het uit de VS moet komen!
- Minimaliseer HTTP redirects: Iedere keer als iets doorgestuurd moet worden herstart de verbinding, niet handig!
- Elimineer onnodige request bytes: Een gevorderde optimalisatiestap, maar voor wie er mee bezig is: geen paniek, het helpt nog steeds!
- Compress tijdens overdracht: Zet die mod_deflate aan! Het helpt enorm in de bestandsgrootte.
- Client-side caching: Ook gewoon blijven doen. Als de browser een bestand al lokaal heeft is het natuurlijk sneller dan wanneer het van een server moet komen.
- Elimineer onnodige bestanden/code: Spreekt voor zich, minder versturen = eerder klaar.
Maar wat is er anders?
Waar je wel even op moet letten:
- "Domain sharding". Misschien zegt het je iets. Ooit naar de URL van een plaatje op facebook gekeken? Die URLs zijn onleesbaar, maar je ziet dat alles van honderden subdomains geladen wordt. Dit werd tot nu toe gedaan omdat browsers in HTTP 1.1 maar enkele verbindingen tegelijk open mochten hebben per domein. Met de nieuwe manier van optimaliseren aan de server kant gaat het fout als alles verdeeld wordt over servers. Lekker weer naar 1 domein, super!
- Concateneren van resources. Wij doen het voorlopig nog even, maar op den duur moet je er wel echt vanaf. Http/2 kan veel beter omgaan met meerdere kleine scriptfiles, waarbij de kritieke scripts eerst worden verzonden. Dit omdat alles nu via 1 verbinding gaat. Het grote probleem dat het concateneren van files oploste was dat er te veel transacties opgezet moesten worden. Nu worden alle overdrachten via 1 transactie gestuurd, dus probleem opgelost!
- Inline resources: Google is onlangs meer gaan voorstellen om kritieke javascript en css inline in de html bestanden mee te sturen, om die paar extra requests te vermijden. Door het eerder genoemde "server push"-concept worden deze files toch direct achter de content aan gestuurd. Doe jezelf een plezier en scheidt de content en opmaak weer van elkaar, dat valt veel beter te onderhouden.
Dat waren ze, de grote dingen die je technisch aan moet passen. Valt best mee toch? Zodra meer hostingpartijen http/2 gaan aanbieden (ik voorspel dat dat nog een paar maanden duurt), check je site(s) even en geniet van een heerlijk snelle website!
Wil je nou meer weten over hoe HTTP/2 en specifiek deze optimalisaties onder de motorkap werken? Bekijk hier de presentatie van Ilya Grigorik, en hier vind je de slides terug! Natuurlijk mag je mij ook altijd emailen op g.weterings@seoonlinemarketing.nl als je nog verdere vragen hebt. Succes!
