U heeft niets veranderd, geen plugin bijgewerkt en geen foto geüpload, en toch reageert uw site sinds twee weken traag. Vooral ‘s middags. Dit is het klassieke beeld van trage buren gedeelde hosting: uw site staat op een machine die u deelt met tientallen andere sites, en een van die buren is te druk geworden.
Hieronder leest u hoe u dat patroon herkent, hoe u het aantoonbaar maakt, en welke gesprekken u dan voert. Want zonder bewijs krijgt u van uw provider het standaardantwoord dat het aan uw plugins ligt.
Trage buren, gedeelde hosting: hoe dat samenwerkt
Op één fysieke machine draaien meestal tientallen tot honderden websites. Ze delen de processor, het werkgeheugen en de schijf. Een goede provider verdeelt dat met limieten per account, zodat één site niet alles kan opeisen.
Die limieten zijn echter zelden waterdicht. Een webshop die ‘s middags een grote voorraadsynchronisatie draait, een site die door een zoekmachinebot wordt afgestruind, of een site die wordt aangevallen met duizenden inlogpogingen per minuut: allemaal leggen ze beslag op de machine. Uw pagina staat dan in de rij.
Wat u merkt is niet dat uw afbeeldingen trager binnenkomen, maar dat het langer duurt voordat de server überhaupt antwoordt. Dat is de tijd tot het eerste byte, en dat is precies het getal waar u naar moet kijken.
Vijf signalen die op de buren wijzen
- Wisselende snelheid zonder eigen wijzigingen. Vandaag 400 milliseconden reactietijd, morgen 1,8 seconde, met dezelfde pagina.
- Een duidelijk dagpatroon. Traag tussen elf en drie, vlot in de avond. Dat wijst op werkverkeer van andere sites op dezelfde machine.
- Het beheerscherm is trager dan de site. Daar wordt niets gecacht, dus daar voelt u de server het eerst.
- Uw meettool geeft wisselende uitkomsten terwijl het paginagewicht gelijk blijft. Het gewicht is uw kant; de reactietijd is die van de server.
- Andere sites bij dezelfde provider hebben hetzelfde. Heeft u er twee, vergelijk ze dan.
Let op: dezelfde klachten kunnen ook uit uw eigen site komen, bijvoorbeeld door een zware query of een plugin die op de achtergrond werk doet. De oorzaken staan op een rij in het overzicht van veelvoorkomende oorzaken van traagheid.
Het aantoonbaar maken
- Meet de reactietijd op vaste momenten. Drie keer per dag, een week lang, steeds dezelfde pagina. Noteer datum, tijd en uitkomst in een simpel overzicht.
- Gebruik een bewakingsdienst met responstijdmeting. Die meet elke vijf minuten en levert u meteen een grafiek over de hele week. Dat is overtuigender dan een handvol losse metingen.
- Meet ook een pagina zonder WordPress als dat kan, bijvoorbeeld een eenvoudig tekstbestand op uw server. Is dát ook traag, dan ligt het zeker niet aan uw site.
- Kijk in het beheerpaneel van uw hosting naar het verbruik van uw eigen account. Zit u ver onder uw limiet terwijl de site traag is, dan is het niet uw verbruik dat knelt.
- Controleer uw eigen logboeken op een piek in verzoeken. Soms bent u zelf de drukke buur, bijvoorbeeld door een bot die uw webshopfilters afstruint.
Met een week aan metingen heeft u een gesprek in plaats van een gevoel. Dat is het hele punt van deze exercitie.
Het gesprek met uw provider
Stuur uw grafiek mee en stel drie concrete vragen. Ten eerste: is er sprake van overbelasting op de machine waar mijn account op staat? Ten tweede: kan mijn account naar een minder belaste server worden verplaatst? Ten derde: welke limieten gelden er voor mijn pakket en hoe dicht zit ik daarbij in de buurt?
Nette Nederlandse partijen antwoorden hier gewoon op en verplaatsen desgevraagd een account. Krijgt u een standaardmail terug over het uitschakelen van plugins, terwijl u een meting van een leeg tekstbestand heeft meegestuurd, dan weet u genoeg over de kwaliteit van de support.
Vraag ook naar de manier waarop uw provider limieten hanteert. Sommige partijen knijpen een account af zodra het te veel vraagt, waardoor uw bezoekers een foutmelding krijgen in plaats van een trage pagina. Andere laten alles doorlopen tot de machine kraakt. Geen van beide is per se fout, maar u wilt weten welke van de twee u heeft, want dat bepaalt hoe uw storingen eruitzien en waar u naar moet zoeken.
Wat u zelf kunt doen
Ook op een drukke machine kunt u de schade beperken. Zorg dat er goede paginacaching draait, zodat de meeste bezoekers een kant-en-klare pagina krijgen en de server nauwelijks werk heeft. Beperk achtergrondtaken tot rustige uren. Blokkeer agressieve bots die geen bezoekers opleveren. En zet de heartbeat van WordPress lager als u met meerdere mensen tegelijk in het beheerscherm werkt.
Levert dat onvoldoende op, dan is verhuizen een reële optie. Kijk dan verder dan de prijs: het aantal accounts per machine, het gehanteerde geheugen per site en de reactietijden van de support zeggen meer dan een gratis eerste jaar. De afweging tussen pakketten staat in de handleiding voor het kiezen van Nederlandse hosting.
Meten blijft de kern
Het lastige aan dit probleem is dat het komt en gaat, en dat er dus altijd iemand is die zegt dat het bij hem prima werkt. Alleen een reeks metingen over een week doorbreekt die discussie. Wij leggen bij WebMaintor daarom bij dit soort klachten eerst een week aan meetgegevens vast voordat er iets wordt aangepast, want dat is de enige manier om achteraf te weten of een verhuizing echt heeft geholpen. Die werkwijze hoort bij een aanpak waarin eerst de oorzaak wordt vastgesteld.
Concrete volgende stap: meet vandaag drie keer de reactietijd van uw startpagina, om negen uur, om twee uur en om acht uur ‘s avonds. Zit daar meer dan een halve seconde verschil tussen, dan heeft u uw eerste aanwijzing.
