De meeste adviezen over een trage website gaan over uw eigen site: minder plugins, kleinere afbeeldingen, caching aanzetten. Terecht, want daar zit vaak de winst. Maar soms is de site prima en ligt het aan de vloer eronder. Deze praktijkcase gaat over een bedrijf waar een snellere hosting de laadtijd halveerde, zonder dat er ook maar iets aan de website zelf is veranderd.
We beschrijven de klant anoniem: een installatiebedrijf uit Oost-Nederland met ongeveer tachtig pagina’s, een offerteformulier en een paar honderd bezoekers per dag. Geen webshop, geen bijzondere techniek. De cijfers hieronder zijn de gemeten waarden uit dat traject.
De klacht en de eerste meting
De klacht was vaag, zoals bijna altijd: “hij voelt zwaar aan, vooral ‘s middags.” Klanten belden niet, maar het aantal ingevulde offerteformulieren liep al maanden terug terwijl het bezoek gelijk bleef.
De eerste meting gaf dit beeld:
- Tijd tot het eerste antwoord van de server: 1,4 seconden op de homepage, oplopend tot 2,6 seconden tussen twee en vier uur ‘s middags.
- Grootste zichtbare element geladen: 4,1 seconden op mobiel.
- Beheerscherm: acht tot twaalf seconden voor het openen van de paginalijst.
- Aantal actieve plugins: veertien. Niet weinig, maar ook niet schokkend.
- Paginacaching: aanwezig en werkend, met een geldige cachetreffer.
Dat laatste is het interessante punt. De cache werkte. Bezoekers kregen een kant-en-klare pagina, en toch duurde het antwoord meer dan een seconde. Als een pagina die vrijwel geen rekenwerk kost al zo traag komt, dan zit de vertraging niet in het rekenwerk.
Waarom we naar de server keken en niet naar de site
Drie waarnemingen wezen naar de hosting.
De vertraging was tijdgebonden. ‘s Ochtends vroeg was dezelfde pagina bijna een seconde sneller dan ‘s middags. Een site die intern traag is, is dat de hele dag. Een server die met andere klanten wordt gedeeld, wordt traag wanneer de buren druk zijn.
Een leeg testbestand was ook traag. We zetten een bestandje neer dat alleen de tekst “ok” teruggeeft, zonder WordPress. Dat kwam in 700 milliseconden binnen. Dat getal hoort onder de honderd te liggen. WordPress had er dus niets mee te maken.
De schijf was traag. Een eenvoudige test die duizend kleine bestanden schrijft en leest, deed er ruim tien keer langer over dan op een gemiddeld pakket met snelle opslag. Dat verklaarde ook waarom juist het beheerscherm, dat veel bestanden aanraakt, zo stroperig aanvoelde.
De hosting bleek een oud gedeeld pakket van vijf euro per maand, jaren geleden afgesloten en nooit meer bekeken. De hoster bestond nog, het pakket werd nog steeds verkocht, maar de onderliggende machines waren duidelijk aan het einde van hun leven.
Wat de verhuizing inhield
Er is bewust niets anders gewijzigd, om te kunnen zien wat de hosting alleen zou doen. Het thema, de plugins, de instellingen en zelfs de cacheconfiguratie gingen ongewijzigd mee. De stappen:
- Een pakket bij een Nederlandse hoster met snelle opslag en een actuele PHP-versie, ongeveer 20 euro per maand.
- Een volledige kopie plaatsen op de nieuwe server en testen via een tijdelijk adres.
- De formulieren, de mailafhandeling en het SSL-certificaat controleren op de nieuwe plek.
- De verlooptijd van de DNS-instellingen een dag van tevoren verlagen, zodat de omschakeling snel doorwerkt.
- Omzetten op een dinsdagavond, met de oude omgeving nog een week beschikbaar als terugvaloptie.
Doorlooptijd: één werkdag voorbereiding, een avond omzetten, en de week erna nog wat controles. De hele operatie kostte minder tijd dan het opruimen van de plugins zou hebben gekost, en met minder risico op stukke functionaliteit.
De cijfers na afloop
Twee weken na de verhuizing, op dezelfde tijdstippen gemeten:
- Tijd tot het eerste antwoord: 280 milliseconden, met een middagpiek naar 340. Was 1,4 tot 2,6 seconden.
- Grootste zichtbare element op mobiel: 1,9 seconden. Was 4,1.
- Beheerscherm: paginalijst binnen twee seconden. Was acht tot twaalf.
- Het aantal ingevulde offerteformulieren lag over het kwartaal erna ongeveer een vijfde hoger, bij vergelijkbaar bezoek.
Dat laatste cijfer noemen we met een slag om de arm. Er speelt seizoen mee en er is geen zuivere vergelijking mogelijk. De technische cijfers zijn hard, het omzeteffect is een aannemelijke indicatie en geen bewijs.
Wanneer snellere hosting bij u helpt, en wanneer niet
Deze uitkomst is niet de regel. Een verhuizing helpt vooral als u dit patroon herkent:
- Uw servertijd is hoog terwijl caching aantoonbaar werkt.
- De traagheid wisselt met het tijdstip van de dag.
- Uw beheerscherm is trager dan de voorkant.
- U zit op een oud, goedkoop gedeeld pakket met een verouderde PHP-versie.
Herkent u dat niet, dan verplaatst u met een verhuizing alleen uw probleem. Een site met zestig plugins, ongeoptimaliseerde afbeeldingen van vier megabyte en een pagebuilder die tien stylesheets laadt, blijft op elke server traag. Wat dan wel helpt, staat in het overzicht van oorzaken van een trage website.
Ook eerlijk: duurdere hosting is niet automatisch snellere hosting. We zien regelmatig dure pakketten met matige opslag en goedkope pakketten die uitstekend presteren. Meet het, of vraag om een proefperiode. Waar u op let bij het kiezen, staat in de vergelijking van Nederlandse WordPress-hosting.
Wat wij eruit meenemen
Begin een snelheidsonderzoek altijd onderaan. Meet eerst de servertijd van een pagina die uit de cache komt en van een leeg testbestand. Zijn die twee getallen goed, dan ligt uw winst in de site. Zijn ze slecht, dan is elke plugin die u verwijdert weggegooide moeite. Die volgorde bespaart in de praktijk dagen werk.
Bij WebMaintor is dit de eerste stap van elk traject rond het versnellen van een bestaande WordPress-site: eerst de vloer, dan het meubilair. Soms is de uitkomst dat u niets aan uw site hoeft te veranderen, alleen aan uw abonnement.
Concrete volgende stap: meet de tijd tot het eerste antwoord van uw homepage op twee momenten van de dag, bijvoorbeeld om zeven uur ‘s ochtends en om drie uur ‘s middags. Scheelt dat meer dan een halve seconde, dan weet u waar u moet gaan kijken.
