De complete gids voor een snelle website - 3: waarom http requests verminderen?

Is het niet vreemd dat nu het internet steeds sneller wordt we opeens met snelheid optimalisatie bezig moeten? Nederland heeft een van de snelste internetverbindingen ter wereld en nu zitten we hier te zeuren om een kleine website, die maar een minuscule bestandsgrootte heeft. Dan is snelheid optimalisatie toch helemaal niet meer nodig? Tja.. de situatie ligt wat ingewikkelder. Het klinkt misschien raar, maar als je een supersnelle verbinding hebt betekent dat niet dat je ook direct supersnel over het web kan surfen. Lees verder om erachter te komen waarom..

Hoe het internet in elkaar steekt

Dit artikel wordt best technisch. Laat je er niet door afschrikken! Ik zal mijn best doen om het zo simpel mogelijk uit te leggen. Laat ik beginnen met een korte achtergrond over hoe het internet in elkaar steekt. Zoals je natuurlijk weet bestaat het internet uit een netwerk van computernetwerken. Ergens op dit grote netwerk bevindt zich de computer van de bezoeker van de website (de client) en ergens op dit netwerk staat een grote computer waar de website staat opgeslagen (de server). Deze twee communiceren met elkaar. Ze doen dit met het HTTP protocol: een set van regels en afspraken zodat beide weten waar ze aan toe zijn.

Op het moment dat de bezoeker (client) een webpagina opvraagt doet hij of zij een aanvraag bij de server. Als alles goed is geeft de server antwoord: als reactie stuurt de server een html bestand waarin instructies staan over hoe de browser (het programma op de computer van de client om webpagina's te bekijken, zoals Internet Explorer) de pagina moet gaan maken. De browser ontvangt het bestand en gaat ermee aan de slag. Maar hier stopt het niet. In feite begint het eigenlijk pas.In het html bestand wordt verwezen naar de inhoud van de pagina, maar de inhoud (behalve de tekst en wat andere data) wordt niet gelijktijdig met het html bestand ingeladen. In tegendeel, als de browser bezig is met het maken van de pagina zal hij aanvragen gaan doen bij de server voor de inhoud: een nieuwe aanvraag voor elk bestand dat het nodig heeft. Afbeeldingen, scripts, informatie over de lay-out etc. zijn allemaal aparte bestanden en worden dus ook apart geladen.

Het HTTP protocol

Om het nog beter uit te leggen zal ik wat dieper ingaan op het HTTP protocol dat gebruikt wordt. Op de volgende afbeelding kun je het goed zien. De tijd gaat van boven naar beneden en lange diagonale pijlen geven de aanvragen en antwoorden over en weer aan. Ik heb de communicatie, die niet direct de vertraging beïnvloedt, weggelaten.

Zoals je kunt zien op de afbeelding zijn er twee standaarden in gebruik vandaag de dag: HTTP/1.0 en HTTP/1.1.Ik begin bij HTTP/1.0. Dit zijn de stappen die nodig zijn om de communicatie tot stand te brengen:

1. De communicatie begint met een DNS lookup: als er een verbinding gemaakt wordt, dan zal er gematcht moeten worden met de server waar de opgevraagde inhoud staat. Net zoals je met een telefoonboek een nummer van een persoon kan opzoeken. Het juiste adres (bijv. IP-adres 91.198.174.232) moet gezocht worden bij de locatie (bijv. nl.wikipedia.org) die opgegeven wordt. Dit gebeurt bij de ISP (de internetprovider) en moet elke keer als er naar een nieuwe locatie wordt verwezen gedaan worden.
2. Dan moet er een verbinding tot stand worden gebracht met de server. De term die hiervoor gebruikt wordt is TCP's three-way handshake: zie het als een soort handen schudden. Er wordt nog geen data verzonden op dit moment. Dit moet elke keer gebeuren als er een verbinding wordt opgezet.
3. De client verstuurt een HTTP request naar de server. De server zal voldoen aan de aanvraag door het bestand (in dit geval het html bestand) terug te sturen. De verbinding wordt daarna afgesloten.
4. Omdat de verbinding afgesloten is zal er opnieuw moeten worden handengeschud.
5. Stel dat er nu een afbeelding volgt. De client doet weer een aanvraag. De server zoekt het bestand op en stuurt het op. Daarna sluit de verbinding weer.Wat ik ook nog even moet vermelden is dat als het bestand te groot is het in kleinere pakketjes verstuurd moet worden. Dit zorgt voor extra vertraging.

En zo gaat het verder. Een aparte verbinding voor elk object op de pagina. Het werkte toen het internet nog bestond uit simpele tekstpagina's maar vandaag de dag is het duidelijk niet zo efficiënt. Ik vertel het je hier expliciet omdat alhoewel HTTP/1.0 oud is (ik geloof uit 1990) het soms nog wel gebruikt wordt. HTTP/1.1 is de opvolger. Al is deze ook best oud (uit 1999). Ach, als het werkt werkt het.In HTTP/1.1 hebben ze daarom iets nieuws aan het protocol toegevoegd: Keep-Alive. Dit zorgt ervoor dat de server de verbinding niet meer sluit. In ieder geval niet tot de client daar opdracht toe geeft of als de server voor een x aantal seconden niets meer van de client hoort (een timeout). De functionaliteit is bekend als ‘persistent connection', en staat standaard als 'aan' ingesteld. Nu kan de client meerdere aanvragen doen en kunnen er meerdere antwoorden binnen komen in één enkele verbinding. Echter, dat betekent niet dat nu deze functionaliteit bestaat alle bestanden van de website met 1 enkele verbinding worden ingeladen. De browser sluit en opent nog steeds een veelvoud aan verbindingen.Zoals je kunt zien in de afbeelding een goede verbetering dus ten opzichte van HTTP/1.0! In sommige gevallen kan het wel tot een 50% verbetering leiden!De stappen zijn nu:

1. Een DNS lookup.
2. Verbinding openen.
3. HTTP request voor HTML bestand.
4. HTTP request voor bijvoorbeeld een afbeelding.

En dan moeten natuurlijk nog alle andere bestanden worden ingeladen. De moraal van het verhaal is dat er veel communicatie is tussen de client en de server en dat dit veel tijd kost. Elke aanvraag moet beantwoord worden en de verbinding vrijgemaakt voordat een nieuwe aanvraag verzonden kan worden.

Drie factoren die ik wil uitlichten

Deze 3 factoren wil ik speciaal belichten. Ze zorgen voor vertraging en zijn misschien enigszins verrassend:

1. De bestanden staan te wachten in de wachtrij

Je zou verwachten dat alle bestanden tegelijkertijd of bijna tegelijkertijd worden opgevraagd. Dat zou natuurlijk het snelste zijn. Maar niets is minder waar. Er worden slechts een beperkt aantal aanvragen per keer gedaan wat ervoor zorgt dat bestanden volgens een soort trappatroon worden ingeladen:

Hoeveel verbindingen precies, hangt af van de instellingen die de browser gebruikt: zie onderstaande tabel. Het is geen compleet overzicht, maar het helpt om mijn punt te maken. Ik heb gekozen voor de verschillende versies van de populaire browsers Internet Explorer en Mozilla Firefox. Aangevuld met de laatste versies van de andere meest gebruikte browsers. Ik neem alleen een tabel op voor HTTP/1.1. HTTP/1.0 is een beetje achterhaald en ik wil je niet belasten met teveel data.Verbindingen per server | HTTP/1.1BrowserVerbindingen per serverMax verbindingenIE9635IE8635IE7255IE6234Firefox 5630Firefox 4630Firefox 3630Firefox 2224Firefox 1224Safari 5.0630Opera 11832Chrome 12635In de specificatie van HTTP/1.1 staat dat een client niet meer dan 2 connecties zou moeten hebben met een server (de middelste kolom). Met de browseroorlogen (die erg op snelheid gefocust zijn) die aan de gang zijn tussen Internet Explorer, Firefox, Chrome en dergelijke wordt deze regel echter tegenwoordig aan ieders laars getrapt. Vandaar dat je in de tabel kunt zien dat de nieuwere browsers steeds meer connecties gaan toestaan. Het is ook maar een richtlijn, ze zijn niet verplicht om zich er aan te houden. En daarbij komt dat het internet natuurlijk erg is veranderd sinds 1999 en dat de richtlijn daarom misschien ook wel aan vervanging toe is.Belangrijk hierbij is we het hier hebben over verbindingen per server. Als je de inhoud inlaadt van verschillende locaties (zoals verwijzen naar img.karelgeenen.nl/plaatje.jpg, video.karelgeenen.nl/video.avi of www.anderewebsite.nl/icon.png) kan je veel meer verbindingen openen. De limiet voor het maximale aantal connecties dat de browser opent is daarom ook veel groter (rechterkolom). In realiteit echter zie ik dat de meeste webpagina's het meeste van 1 tot 3 serverlocaties inladen.Ze hebben zelfs toen ze de richtlijn voor HTTP/1.1 maakten het aantal verbindingen per server naar beneden bijgesteld. De theorie hierachter was dat nu HTTP/1.1 persistent connecties gekregen had (waar ik het net over had) er daarom minder verbindingen per server nodig waren. Ik zal je niet alle data laten zien voor alle browsers maar dit stukje geeft het goed aan:Verbindingen per serverBrowserHTTP/1.0HTTP/1.1IE866IE742IE642Firefox 366Firefox 282Dit beperkt inladen van bestanden werkt vertragend en is enigszins inefficiënt. De bestanden staan gewoon te wachten in de wachtrij. Maar een beperkt aantal mogen naar de site toe. En de rest staat te wachten voor een gesloten hek totdat de bestanden die voor hen aan de beurt zijn zichzelf helemaal hebben uitgepakt en gedaan hebben waar ze voor kwamen. Dan pas komt het volgende (beperkte) aantal aan de beurt. En zo verder. Hier is wel een goede reden voor: Als de browser teveel verbindingen opent kan het de server overbelasten of juist het tegenovergestelde effect bewerkstelligen bij de client.Omdat je maar een beperkt aantal bestanden tegelijk kunt downloaden maak je dus helemaal niet gebruik van de volledige capaciteit van de verbinding.

2. De upload snelheid kan de beperkende factor zijn

De snelheid van de meeste internet verbindingen heeft een asymmetrische bandbreedte. Dit betekent dat de snelheid van het inkomende (downloaden) en uitgaande (uploaden) verkeer niet aan elkaar gelijk is: bijvoorbeeld 1.5Mbit down/128Kbit up, 6Mbit down/512Kbit up, etc. De verhouding is meestal in de range van 5:1 tot 20:1. Dit betekent dat een aanvraag evenveel tijd in beslag neemt als dat nodig is om een bestand te ontvangen dat 5 tot 20 keer groter is. Het klinkt ingewikkeld. Waar het op neer komt is dat als je een bestand hebt, en je een verbinding hebt van 5:1 het bijvoorbeeld 1 seconde zou duren om dat bestand te downloaden en 5 seconden om dat bestand te uploaden. Het bestand is hetzelfde maar de verbindingssnelheid is anders.Een aanvraag is meestal rond de 0.5kb. Bij kleine bestanden (2.5kb tot 10kb) is het dus goed mogelijk dat de beperkende factor zit bij de upload snelheid en niet bij de download snelheid! Er moet namelijk langer gewacht worden op het uploaden dan op het downloaden.

3. De bestanden laden niet in op de maximale snelheid

Als je ooit een bestand hebt gedownload van het internet dan heb je waarschijnlijk gemerkt dat de verbinding de eerste paar seconden traag begint en dan steeds sneller wordt. Dit heet TCP slow start.Het is best een ingewikkeld onderwerp dus ik zal het op een versimpelde manier uitleggen.Bij de start van een nieuwe verbinding wordt de volledige bandbreedte niet gebruikt. Dit om te voorkomen dat de verbinding verstopt raakt. De bandbreedte die gebruikt wordt, verdubbelt steeds met elke round trip. Dit betekent dat de volledige bandbreedte pas bereikt wordt na het product van de round trip vertraging en de beschikbare bandbreedte.Het enige wat je hieruit hoeft op te maken is dat de verbindingssnelheid van de bezoeker eigenlijk nooit maximaal gebruikt wordt. We hebben het hier dus over elke verbinding die opgestart wordt. De meeste bestanden laden dus relatief traag in.

Het is de communicatie die voor de meeste vertraging zorgt

Deze communicatie tussen client en server wordt round trip time (RTT) genoemd. Het is de tijd die nodig is voor een client om een aanvraag te versturen en de server om een antwoord terug te sturen. De tijd om het bestand ook daadwerkelijk te downloaden (de data transfer) wordt hier niet bij gerekend.De gemiddelde RRT is 40 ms via kabel. Lijkt weinig toch? Dat is het ook. Maar neem bijvoorbeeld de website waar je nu op zit. Als je de homepage van KarelGeenen.nl wil bekijken moeten er wel 109 bestanden opgevraagd worden! Nu hoef je als gebruiker natuurlijk niet op alle round trips te wachten. Als je 2 bestanden tegelijk opvraagt en de RRT van de ene is 40 ms en de andere ook 40 ms ben je dus maar 40 ms seconden aan het wachten, omdat ze tegelijkertijd bezig zijn.Stel dat we de website inladen met een browser die 2 bestanden per keer inlaadt, dan is de vertraging van de communicatie van de website van Karel Geenen met zijn 109 bestanden (109/2) x 40 ms = 2,18 seconden. De berekening klopt niet helemaal omdat er natuurlijk ook verbindingen worden geopend en DNS lookups en dergelijke. Dus laten we zeggen grofweg 3 seconden. Dat is 3 seconden wachten zonder dat je een enkel bestand hebt gedownload!Omdat de communicatie de vertragende factor is laadt 1 bestand sneller dan hetzelfde bestand dat in twee gedeeld is. En die 2 laden weer sneller dan als je er 4 bestanden van zou hebben gemaakt. Als je je gehele fotocollectie als aparte bestanden op het internet wil zetten kun je echt even een lange wandeling gaan maken. Maar als je er een enkel bestand van zou maken (een gecomprimeerde map) en die uploadt hoef je alleen even een plaspauze in te lassen. Stel dat je als bezoeker van een website alle bestanden als geheel en in een keer zou kunnen downloaden zou je supersnel over het web kunnen surfen. Maar helaas.. dat is dus niet het geval.Een gemiddelde website bestaat uit 30-60 minuscule bestanden. En met minuscuul bedoel ik ook echt minuscuul. De meeste bestanden zijn maar 1kb tot 10kb. Als je dat vergelijkt met de internet verbindingen die we tegenwoordig hebben is dat dus echt een fractie van de capaciteit die beschikbaar is.Als ik de website van KarelGeenen.nl inlaad met Webpagetest.org (Amsterdam, IE8) krijg je dit te zien:

Alleen het blauw (aangeven met de pijl) is het downloaden van het bestand. De rest is communicatie. De 'overhead' van de bestanden kost dus veel meer tijd dan het laden van de bestanden zelf. Soms is het zo weinig dat je het blauw amper kunt zien!Ook goed te zien hier is het trapsgewijs inladen van de bestanden: maar een beperkt aantal bestanden worden tegelijkertijd geladen.Waar het op neer komt is het volgende. Als je niet eens goed gebruik kan maken van een 2 Mb/s verbinding kun je niet verwachten dat je sneller kan surfen met een 10 Mb/s of 20 Mb/s verbinding. Het effect zal gewoon niet zo groot zijn. Nu zeg ik niet dat je helemaal niets hebt aan zo'n verbinding. Natuurlijk, als je grote bestanden zoals een film of een software pakket download is bandbreedte wel van belang! Maar als je veel kleine bestanden in een rij download heb je er weinig aan.

En nu is het extra belangrijk

Terug naar de vraag uit de inleiding. Waarom is snelheid optimalisatie nu opeens belangrijk?In de begin dagen van het web was de bestandsgrootte van de website de beperkende factor. Toen waren er maar een beperkt aantal bestanden per pagina. Er was wel wat vertraging maar in het downloaden van de objecten zelf zat meer tijd.De laatste tijd echter zijn websites exponentieel gegroeid. Met de groei van het aantal objecten per pagina is de situatie veranderd. Nu wordt de laadsnelheid voornamelijk bepaald door de ‘overhead' van de objecten en niet meer door de objecten zelf.

Bron: Website Optimization, LLCVandaag de dag willen we onze websites niet meer simpel bouwen. We willen gebruikmaken van alles wat er mogelijk is. Flitsend, dynamisch en interactief. En ik heb goed nieuws! Daar hoef je ook niet in te korten. Het is goed mogelijk om het aantal bestanden te verminderen, zonder grote concessies te doen. Met het volgende artikel beginnen de tips die je precies zullen uitleggen hoe je dat kunt doen.