Uw website is traag, en iemand zegt dat het aan de hosting ligt. Iemand anders zegt dat het aan de plugins ligt. Uw hostingprovider zegt dat de server prima draait. Wie heeft er gelijk? Overstappen naar een andere hoster kost geld en tijd, en als het probleem in de site zelf zit, verhuist u het probleem gewoon mee.

Gelukkig hoeft u niet te gokken. Of uw hosting traag is, kunt u meten. Niet met één score, maar met een paar gerichte metingen die de server los van de website beoordelen. Dit stappenplan kost u ongeveer een halfuur en geeft een antwoord waar u iets mee kunt.

Eerst: wat is “hosting” en wat is “de site”?

Bij elk bezoek gebeuren er grofweg twee dingen. Eerst moet de server het verzoek ontvangen, WordPress opstarten, de database bevragen en de HTML samenstellen. Daarna moet de browser die HTML ontvangen en alle bestanden (afbeeldingen, scripts, stylesheets) ophalen en tekenen.

Het eerste deel is grotendeels de hosting: processorkracht, geheugen, schijfsnelheid, databaseconfiguratie en hoeveel andere sites dezelfde server delen. Het tweede deel is grotendeels de site: hoe zwaar het thema is, hoeveel plugins scripts laden, hoe groot de afbeeldingen zijn. Een langzame server maakt vooral het eerste deel traag. Een zware site maakt vooral het tweede deel traag. Die twee kunt u apart meten.

Meting 1: de wachttijd tot de eerste byte

De belangrijkste maatstaf voor de server is de Time To First Byte, de tijd tussen het versturen van het verzoek en het ontvangen van het eerste stukje antwoord. Zit daar de vertraging, dan is de server (of iets wat de server belast) de verdachte.

Zo meet u het: open uw site in Chrome, druk op F12, ga naar Netwerk, herlaad de pagina en klik op het eerste item (de pagina zelf). Onder “Timing” ziet u “Waiting for server response”. Doe dit een paar keer, ook op andere pagina’s. Wat de getallen betekenen, hebben wij uitgebreider beschreven in ons artikel over TTFB. Kort gezegd: onder de 200 milliseconden is goed, tussen 200 en 600 is matig, boven de 800 is er iets aan de hand.

Let op: als u een cacheplugin gebruikt, meet u de cache en niet de server. Meet daarom ook een pagina die niet in de cache zit, bijvoorbeeld door achter de URL ?test=123 te zetten (de meeste cacheplugins slaan URL’s met parameters over) of door ingelogd een pagina te bekijken.

Meting 2: een pagina zonder WordPress

Dit is de meest eerlijke test van de server zelf. Maak via FTP of de bestandsbeheerder van uw hostingpaneel een bestandje aan in de hoofdmap van uw site, bijvoorbeeld test.html, met alleen het woord “test” erin. Open het in uw browser en meet opnieuw de wachttijd tot de eerste byte.

Dit bestand vraagt de server om niets: geen PHP, geen database, geen WordPress. Als deze wachttijd ook al hoog is (ruim boven de 200 milliseconden vanuit Nederland), dan is de server of het netwerk traag, punt. Als dit bestand razendsnel is maar uw WordPress-pagina niet, zit de vertraging in het opbouwen van de pagina, en dat kan zowel de server (te weinig kracht voor PHP en database) als de site zijn. Verwijder het testbestand daarna weer.

Meting 3: WordPress met alles uit

Nu wilt u weten of WordPress zelf traag is op deze server, of dat uw thema en plugins de tijd opslokken. Dit doet u bij voorkeur op een staging-omgeving, of anders op een rustig moment met een back-up achter de hand.

  1. Schakel alle plugins uit en activeer tijdelijk een standaardthema (Twenty Twenty-Four of nieuwer).
  2. Meet de wachttijd tot de eerste byte van een pagina die niet in de cache zit.
  3. Schakel het thema en de plugins weer in en meet opnieuw.

Een kale WordPress-installatie hoort op fatsoenlijke hosting binnen 100 tot 300 milliseconden te antwoorden. Is dat het geval, en springt de tijd naar anderhalve seconde zodra uw thema en plugins aan staan? Dan is de site de boosdoener, niet de hosting. Is de kale installatie zelf al traag? Dan is het de server.

Wie dit liever niet handmatig doet: de gratis plugin Query Monitor toont per pagina hoeveel tijd PHP en de database kosten en welke plugin het meeste bijdraagt. Ook de zogenoemde Health Check-plugin heeft een probleemoplossingsmodus waarmee u plugins alleen voor uzelf uitschakelt, terwijl bezoekers de site normaal zien.

Meting 4: op verschillende momenten

Gedeelde hosting deelt de server met tientallen tot honderden andere sites. Als een buurman om 10:00 uur een zware import draait, wordt uw site op dat moment trager. Meet daarom de wachttijd op verschillende tijden: ‘s ochtends vroeg, midden op de dag en ‘s avonds. Grote verschillen tussen die metingen wijzen op een overvolle server, en dat is iets wat u met optimalisatie van uw eigen site niet oplost.

Een uptime-monitor die ook de responstijd bijhoudt, doet dit werk automatisch. Na een week ziet u een grafiek waarin pieken zichtbaar worden die u met losse metingen zou missen.

Wat de uitkomsten betekenen

  • Testbestand traag, kale WordPress traag, alles traag: hosting. Praat met uw provider over een zwaarder pakket of stap over.
  • Testbestand snel, kale WordPress snel, uw site traag: de site. Thema, plugins, database of afbeeldingen. Hier helpt een hostingwissel niet.
  • Testbestand snel, kale WordPress al traag: waarschijnlijk de PHP- of databaseconfiguratie van de hosting. Vraag naar de PHP-versie, het geheugen en of de database op dezelfde server staat.
  • Grote schommelingen over de dag: een overbelaste gedeelde server. Ook hosting.
  • Mengvorm: komt het vaakst voor. De server is matig én de site is zwaar. Begin dan bij de site, want dat kost u geen verhuizing.

Een voorbeeld uit de praktijk

Een fictief maar herkenbaar geval: een cateraar uit Nijmegen wilde overstappen van hoster omdat de site “altijd traag” was. De metingen gaven een ander beeld. Het testbestand kwam binnen 40 milliseconden terug, een kale WordPress binnen 180 milliseconden. Met het eigen thema en 27 plugins duurde het 2,3 seconden. De verhuizing zou dus niets hebben opgelost. Na het opruimen van de zwaarste plugins en het inschakelen van objectcaching kwam de site uit op ongeveer 400 milliseconden, op dezelfde hosting.

Het omgekeerde komt ook voor: een site die na uitgebreide optimalisatie nog steeds ruim boven de seconde blijft hangen, waarna het testbestand laat zien dat de server zelf 700 milliseconden nodig heeft om überhaupt te antwoorden. Dan is een hostingwissel wél de oplossing, en scheelt het dat u niet eerst weken aan de site heeft gesleuteld. Beide situaties zien wij geregeld voorbijkomen bij een professionele snelheidsoptimalisatie, en de metingen hierboven zijn altijd de eerste stap.

Conclusie

Meet voordat u beslist. Vier metingen, een halfuur werk, en u weet of de vertraging in de server of in de site zit. Bewaar de uitkomsten; ze zijn ook nuttig als u het gesprek met uw hostingprovider aangaat, want “de site is traag” is een mening en “een statisch bestand doet er 600 milliseconden over” is een feit. Wilt u weten waar u op let als u dan toch gaat overstappen? Lees dan onze uitleg over het kiezen van hosting voor WordPress.