Je bent begonnen met een goed idee en hebt je WordPress-website live gezet. In het begin werkt alles perfect: je pagina’s laden razendsnel en bezoekers klikken zonder vertraging door je site. Dat is precies wat je wilt, want snelheid is het startpunt voor jouw internetsucces. Maar na verloop van tijd merk je dat die flitsende gebruikerservaring langzaam afbrokkelt en je website trager reageert.
Dat vertragen komt meestal door een opeenhoping van data en nieuwe functies. Denk aan extra plug-ins die je hebt toegevoegd, zware afbeeldingen of een database die steeds groter wordt door oude informatie. Omdat dit stap voor stap gebeurt, is het niet altijd meteen duidelijk waar de vertraging vandaan komt.
In dit artikel leggen we je precies uit waarom WordPress-websites na verloop van tijd langzamer worden. We bespreken de technische oorzaken en geven je direct bruikbare tips om de snelheid van je website te herstellen. Zo zorg je ervoor dat je site altijd optimaal bereikbaar blijft voor je doelgroep.
Elke keer dat je op 'opslaan' klikt in WordPress, gebeurt er op de achtergrond meer dan je denkt. WordPress is namelijk een echte verzamelaar. Een van de grootste boosdoeners van een trage site is de enorme berg aan revisions: telkens als je een artikel aanpast, bewaart WordPress de oude versie. Na een jaar bloggen heb je misschien honderd artikelen, maar in je database staan mogelijk duizenden revisies die je nooit meer inkijkt. Al die data scant de server telkens als er een zoekopdracht of een laad-verzoek voor een pagina binnenkomt.
Daarnaast groeien de metadata-tabellen van je site ongemerkt mee met elke actie die je onderneemt. Metadata is de informatie achter de informatie. Hieronder vallen zaken zoals:
Veel plug-ins laten gegevens achter in de database, zelfs als je de plug-in al hebt gedeactiveerd. Dit zorgt voor een onnodig zware structuur die de reactietijd van je server naar beneden haalt. Ook logboeken en tijdelijke bestanden spelen een rol. Veel systemen houden bij wie er inlogt of welke fouten er optreden. Als deze logboeken niet automatisch worden geleegd, groeien ze uit tot bestanden van vele megabytes, wat de verwerkingstijd van de server negatief beïnvloedt.
Het is de grootste verleiding in de wereld van WordPress: de enorme bibliotheek aan gratis plug-ins. Heb je een contactformulier nodig? Er is een plug-in voor. Wil je een sneeuweffect tijdens de kerstdagen? Ook daar is een plug-in voor. Hoewel plug-ins de kracht van WordPress vormen, zijn ze ook de meest voorkomende reden dat een site traag wordt. Eén plug-in doet je site meestal geen pijn, maar twintig plug-ins zorgen voor een constante strijd om serverbronnen.
Elke plug-in voegt namelijk zijn eigen scripts en stylesheets toe aan de header van je website. Dit betekent dat de browser van je bezoeker niet alleen jouw tekst en afbeeldingen moet laden, maar ook tientallen verschillende stukjes code van externe ontwikkelaars moet verwerken voordat de pagina getoond kan worden. Dit noemen we http requests, en hoe meer je er hebt, hoe langer het duurt voordat de pagina geladen is. Vooral plug-ins die op elke pagina worden geladen, terwijl ze maar op één pagina nodig zijn, zijn een enorme verspilling van snelheid.
Daarnaast is er het risico op conflicten in de code. Omdat plug-ins door verschillende ontwikkelaars worden geschreven, werken ze niet altijd goed samen. Soms proberen twee plug-ins tegelijkertijd dezelfde taak uit te voeren of gebruiken ze methodes die niet meer passen bij de huidige versie van WordPress. Deze technische conflicten kosten de server veel moeite om op te lossen, wat zorgt voor vertraagd laden.
Wees daarom kritisch:
Bij het kiezen van een thema kijken we vaak naar de plaatjes en de functies die de ontwikkelaar belooft. Veel populaire thema's in marktplaatsen worden verkocht als 'multifunctioneel'. Ze kunnen alles: van een portfolio voor een fotograaf tot een volledige webshop voor een bouwmarkt. Om al die functies mogelijk te maken, zit zo’n thema bomvol met code. Het nadeel hiervan is theme bloat: de browsers van je bezoekers moeten al die code laden, ook als je maar 20% van de functies van dat thema gebruikt. Dit vertraagt vooral het proces dat we rendering noemen: het moment waarop de browser de code omzet in een zichtbare pagina.
Vergeet ook de handmatige aanpassingen in de customizer niet. Elke kleurwijziging en elk lettertype dat je toevoegt, wordt door WordPress opgeslagen en moet telkens weer worden opgehaald.
Als je thema bovendien niet regelmatig wordt bijgewerkt door de maker, blijft het draaien op oude standaarden. Webtechnieken veranderen snel; wat drie jaar geleden een snelle manier van programmeren was, is nu misschien hopeloos verouderd en traag in moderne browsers.
De database is het hart van je WordPress-website. Hier staat alles: je teksten, je gebruikersnamen, je instellingen en de koppelingen tussen je afbeeldingen. Naarmate een site ouder wordt, raakt dit hart 'vervet'. Een specifiek probleem zijn de zogenaamde transients. Dit zijn tijdelijke opties die plug-ins gebruiken om informatie snel op te slaan, zoals de uitslag van een externe API-aanroep of een tijdelijke berekening. In een ideale wereld verwijdert WordPress deze transients weer zodra ze niet meer nodig zijn. Maar in de praktijk blijven ze vaak plakken.
Na een paar jaar kunnen er tienduizenden van deze verlopen transients in je tabellen staan. De server moet hier doorheen spitten voordat hij de juiste informatie vindt.
Daarnaast is er de prullenbak. WordPress bewaart verwijderde reacties, concepten en pagina's standaard dertig dagen. Als je een populaire site hebt met veel spam-reacties, kunnen er in die dertig dagen duizenden regels aan nutteloze data bijkomen.
Zonder regelmatige optimalisatie raakt de indexering van de database in de war. Je kunt dit zien als een soort digitale chaos waarbij de server de weg kwijtraakt. Plug-ins zoals WP-Optimize kunnen hierbij helpen, maar het is nog beter om direct in de database te kijken of er geen oude tabellen van verwijderde plug-ins zijn achtergebleven. Een schone database is een snelle database.
Als we kijken naar het ‘gewicht’ van een gemiddelde webpagina, dan maken afbeeldingen vaak wel 70% tot 80% van de totale omvang uit. Hier gaat het dan ook het vaakst mis. De foto's van tegenwoordig zijn al gauw 5 of 10 megabyte groot. Wanneer je zo'n foto onbewerkt op je website zet, dwing je elke bezoeker in feite om veel data te downloaden, en dat duurt tijd.
WordPress probeert hierbij te helpen door automatisch verschillende formaten van je foto aan te maken, de zogenaamde thumbnails. Voor elke afbeelding die jij uploadt, maakt WordPress misschien wel vijf tot tien kleinere versies aan. Dit vult je opslagruimte razendsnel. Maar er zit ook vertraging in het gebruik van de verkeerde bestandsformaten.
Overweeg deze stappen voor je media:
Misschien moeten we die laatste term wat toelichten. Als je geen lazy loading hebt ingesteld, probeert de browser bij het openen van een pagina direct alle foto’s in te laden, ook de afbeeldingen die helemaal onderaan staan. Bij lazy loading worden afbeeldingen alleen geladen als de gebruiker daadwerkelijk ernaartoe scrollt.
Je website staat niet op een eiland. Bijna elke moderne WordPress-site haalt informatie op van andere servers. Denk aan Google Fonts voor je mooie lettertype, een Facebook Pixel om je advertenties te meten, of een Google Maps-kaartje op je contactpagina. Hoewel deze functies handig zijn, hebben ze een grote keerzijde: je bent voor de snelheid van jouw site afhankelijk van de snelheid van die een andere service.
Elk extern script vereist een nieuwe verbinding met een andere server. Als de server van Google Fonts een fractie van een seconde traag reageert, moet jouw hele website wachten voordat het lettertype getoond kan worden. Dit zie je vaak gebeuren als een site eerst heel simpel geladen wordt en pas na twee seconden de juiste lay-out en letters krijgt. Dat noemen we layout shift, en het is niet alleen vervelend voor de gebruiker, maar Google straft het ook af in de zoekresultaten.
Ook live-feeds van social media zijn beruchte vertragers. Een widget die jouw laatste vijf Instagram-foto's direct van de Instagram-servers plukt, moet bij elke keer dat de pagina wordt geladen opnieuw 'bellen' naar Instagram. Als die koppeling traag is, blijft de rest van je site in de wacht staan. Het is daarom beter om deze data te cachen, zodat je site een lokale kopie laat zien in plaats van elke keer een verse update te downloaden. Zo houd je de controle over je eigen laadtijd.
Onder de motorkap van WordPress draait een programmeertaal die PHP heet. Net als Windows of macOS krijgt PHP regelmatig grote updates. Deze updates gaan bijna altijd over twee dingen: veiligheid en snelheid. Veel website-eigenaren durven echter niet te updaten uit angst dat de site kapotgaat. Hierdoor draaien veel sites nog op PHP 7.4 of zelfs ouder, terwijl PHP 8.3 al lang beschikbaar is. Het verschil in snelheid tussen deze versies is enorm. PHP 8 kan taken soms wel twee keer zo snel uitvoeren als de oude 7-serie. Door niet te updaten, laat je dus letterlijk de helft van de potentiële snelheid van je server liggen.
Hetzelfde geldt voor de WordPress-kern zelf. Elke nieuwe versie van WordPress bevat optimalisaties in de manier waarop de database wordt aangesproken en hoe de code wordt verwerkt. Het negeren van updates zorgt niet alleen voor een veiligheidslek, maar ook dat de code langzaam maar zeker vastloopt in verouderde processen die niet langer efficiënt zijn.
Het is belangrijk om te onthouden dat de snelheid van een WordPress-website geen eenmalige actie is. Het is een proces van continu onderhoud. Net zoals je af en toe je huis moet opruimen om het leefbaar te houden, moet je ook je digitale bezit verzorgen. Verwijder onnodige revisies, wees kritisch op elke nieuwe plug-in die je installeert en zorg dat je afbeeldingen altijd gecomprimeerd zijn voordat ze de server op gaan. Een snelle site is essentieel voor je vindbaarheid in Google en voor de ervaring van je klanten. Mensen wachten tegenwoordig niet langer dan drie seconden; daarna klikken ze weg naar de concurrent.
Je bent ooit begonnen met een klein hostingpakketje toen je nog maar tien bezoekers per dag had en drie pagina's aan content. Maar je site is gegroeid. Je hebt nu meer content, zwaardere plug-ins en hopelijk veel meer bezoekers. Bij goedkope shared hosting deel je de rekenkracht van de server met honderden andere websites.
En als één van je server-buren ineens veel verkeer krijgt, blijft er voor jouw WordPress-site minder kracht over. Bovendien maken oudere servers vaak nog gebruik van traditionele harde schijven in plaats van de veel snellere SSD-schijven. SSD's (en de nog snellere NVMe-schijven) kunnen data veel vlotter lezen en schrijven, wat direct invloed heeft op hoe snel jouw site reageert.
Naarmate je website groeit en meer bezoekers trekt, heeft deze simpelweg meer rekenkracht nodig om alles soepel te verwerken. Heb je zelf al je afbeeldingen verkleind en je database opgeschoond, maar blijft de laadtijd toch hoog? Dan heb je waarschijnlijk de limiet van je huidige hosting bereikt. Je website is dan te groot geworden voor de standaardinstellingen van je hostingpakket. Het is in zo’n situatie verstandig om te over te stappen naar hosting die volledig is ingericht op performance, zodat je site de ruimte krijgt om weer snel te reageren.
Ben je er klaar mee dat je WordPress-site met de dag trager lijkt te worden? Soms is de beste oplossing een frisse start op een fundering die wél gebouwd is voor snelheid. Je kunt de meest geoptimaliseerde code hebben, maar zonder de juiste hardware en slimme server-instellingen blijft het behelpen. Gun je website daarom de snelheid die hij verdient en laat je bezoekers niet langer wachten door over te stappen naar onze razendsnelle WordPress hosting of kies, bij de grootste ambities, voor onze performance hosting.