Uw hostingpakket kost acht euro per maand en staat, zonder dat u het wist, in Arizona. Dat hoeft geen ramp te zijn, maar het kost tijd die u nergens terugziet in een pluginlijstje. De serverlocatie van uw website is een van de weinige snelheidsfactoren die u niet kunt wegoptimaliseren: licht gaat nu eenmaal niet sneller.
In dit artikel leest u hoeveel afstand daadwerkelijk kost, waarom het effect groter is dan die ene meting suggereert, en in welke gevallen u zich er niets van hoeft aan te trekken.
Wat afstand in milliseconden kost
Elk verzoek van een browser aan een server legt de route heen en terug af. Binnen Nederland duurt zo’n heen-en-weertje ruwweg vijf tot vijftien milliseconden. Naar de oostkust van de Verenigde Staten zit u rond de negentig, naar de westkust rond de honderdvijftig, en naar Singapore al gauw op tweehonderd of meer.
Negentig milliseconden klinkt verwaarloosbaar. Het venijn zit erin dat een browser die route meerdere keren aflegt voordat er ook maar één letter op het scherm staat: het opzoeken van het adres, het opzetten van de verbinding, de beveiligde handdruk voor het slotje, en pas dan het opvragen van de pagina. Reken op vier tot zes rondes. Bij een server in Amerika bent u zo een halve seconde kwijt voordat uw thema überhaupt begint te laden.
Daarbovenop komt dat elke externe bron dat kunstje herhaalt. Laadt u lettertypen bij Google en een script bij een chatdienst, dan telt de afstand naar die diensten óók mee. Vandaar dat verbindingshints het verschil kunnen maken; dat leest u terug in de uitleg over preconnect en preload.
Waarom uw eigen meting u misleidt
Veel ondernemers testen hun site en zien een keurige laadtijd. Logisch: u zit waarschijnlijk op een snelle vaste verbinding, dicht bij een groot internetknooppunt, en uw browser heeft alles al in het geheugen staan.
Meettools staan bovendien vaak in een datacenter in Frankfurt of Londen, aan een verbinding die niets met de praktijk te maken heeft. Wilt u weten wat uw klant in Emmen op 4G ervaart, kies dan in uw meettool bewust een Europese meetlocatie en een mobiel profiel. Hoe u dat instelt, staat in het stappenplan om uw site op een trage verbinding te testen.
Serverlocatie, website en publiek: wanneer het echt uitmaakt
De afstand weegt zwaarder naarmate er meer heen-en-weerverkeer is. Dat is zo bij:
- Webshops. Winkelwagen, afrekenen en accountpagina’s kunnen niet uit een cache komen. Elke klik is een volledige ronde naar de server.
- Sites met veel formulieren of een ledengedeelte. Zelfde verhaal: persoonlijke pagina’s worden per bezoeker opgebouwd.
- Beheerwerk. Uzelf in het beheerscherm merkt afstand het sterkst, omdat daar niets gecacht wordt. Een trage backoffice is vaak het eerste signaal.
Het maakt juist weinig uit bij een statische bedrijfssite met goede caching, want dan wordt een kant-en-klare pagina uitgeserveerd en blijft het bij één ronde. Zit uw publiek bovendien verspreid over meerdere continenten, dan lost verhuizen niets op: u verplaatst het probleem alleen naar een andere groep bezoekers.
Locatie of CDN: welke van de twee?
Een contentnetwerk zet kopieën van uw afbeeldingen, stylesheets en scripts op servers over de hele wereld. De bezoeker haalt die bestanden dan bij het dichtstbijzijnde punt op. Dat werkt uitstekend voor alles wat voor iedereen hetzelfde is.
Wat een gewoon contentnetwerk níet versnelt, is de pagina zelf: die komt nog steeds van uw eigen server. Voor een Nederlands publiek is de combinatie dus simpel: zet de site op een server in Nederland of Duitsland, en gebruik desgewenst een netwerk voor de zware bestanden.
Zit uw hosting in Duitsland of België, dan hoeft u niets te doen. Het verschil met Amsterdam is enkele milliseconden en valt weg tegen elke andere factor.
Sommige providers bieden inmiddels een tussenvorm aan waarbij ook de pagina zelf op meerdere plekken wordt bewaard, zodat een bezoeker in Barcelona een kant-en-klare kopie krijgt in plaats van een pagina uit Amsterdam. Dat werkt goed voor bedrijfssites met vaste inhoud en veel minder goed voor webshops, waar de winkelwagen per bezoeker verschilt. Vraag daarom altijd door wat er precies gekopieerd wordt: alleen de bestanden, of ook de pagina’s, en wat er gebeurt als u een tekst wijzigt. Bij een verkeerd ingestelde kopie ziet uw klant een prijs van vorige week, en dat kost u meer dan de milliseconden die u ermee wint.
Uitzoeken waar uw site staat
- Vraag het gewoon aan uw provider. Nette partijen zetten de locatie van hun datacenter op de site. Staat er alleen “Europa”, vraag dan door.
- Controleer het zelf met een IP-opzoekdienst op basis van uw domeinnaam. Let op: gebruikt u Cloudflare, dan ziet u de locatie van Cloudflare, niet die van uw server.
- Kijk naar de reactietijd van de server in een meettool. Ligt die structureel boven een halve seconde terwijl uw pagina’s licht zijn, dan is afstand of overbelasting de oorzaak.
- Vergelijk het beheerscherm. Voelt het opslaan van een pagina traag terwijl de openbare site vlot is, dan zit u waarschijnlijk ver van de machine af.
Blijkt uw site inderdaad ver weg te staan, weeg dan mee wat een verhuizing kost. Reken op een halve dag werk, een testronde en een dag waarin naamserverwijzigingen doorlopen. Er zijn ook redenen om juist wél in Nederland te staan die niets met snelheid te maken hebben: gegevensverwerking binnen de EU, Nederlandstalige support en een factuur die u begrijpt.
De volgorde die wij aanhouden
Snelheidswerk heeft alleen zin in de goede volgorde. Eerst het gewicht van de pagina omlaag, dan caching goed instellen, dan pas kijken naar de server en zijn locatie. Bij WebMaintor is dat de standaardvolgorde binnen een traject waarin we eerst meten en daarna pas verbouwen, simpelweg omdat een verhuizing zonder die eerste twee stappen zelden meer dan een tiende seconde oplevert.
Concrete volgende stap: zoek het IP-adres van uw domein op en kijk in welk land dat uitkomt. Staat er iets buiten Europa en bedient u vooral Nederlandse klanten, dan heeft u een gegronde reden om uw provider te bellen.
