Bezoekers hebben nergens last van. De homepage laadt in een seconde, de productpagina’s ook, PageSpeed geeft een keurige score. Maar zodra u zelf inlogt, wordt het wachten. Het dashboard doet acht seconden over het laden. Het openen van een pagina in de editor duurt een halve minuut. Een bestelling bekijken in WooCommerce: koffie halen. Het is een klacht die we regelmatig horen, en de eigenaar denkt vaak dat het aan de eigen internetverbinding ligt.
Dat is het meestal niet. Een WordPress admin die traag is terwijl de site snel is, heeft bijna altijd een technische oorzaak, en die oorzaak zit in het verschil tussen wat de voorkant en de achterkant van uw site doen. In dit artikel lopen we de zeven oorzaken langs die wij in de praktijk het vaakst tegenkomen, hoe u ze herkent en wat u eraan doet.
Waarom de voorkant snel kan zijn en de achterkant niet
Het belangrijkste verschil is caching. Wanneer een bezoeker een pagina opvraagt, krijgt die in de meeste gevallen een kant-en-klare kopie uit de cache. De server hoeft dan geen PHP te draaien en geen database te raadplegen. Dat is snel, ook op een zwakke server.
Het beheer wordt nooit gecachet. Elke klik in het dashboard betekent: PHP opstarten, alle actieve plugins laden, de database bevragen, de pagina opbouwen. U ziet dus de werkelijke snelheid van uw server en uw installatie, zonder hulp van de cache. Een traag beheer is daarom vaak een eerlijker beeld van de gezondheid van uw site dan een snelle voorkant. Wat de cache voor uw bezoekers verbergt, wordt u als beheerder elke dag voorgeschoteld.
Oorzaak 1: plugins die vooral in het beheer werken
Sommige plugins doen aan de voorkant niets, maar laden in het beheer een compleet dashboard, halen gegevens op bij externe diensten of scannen bestanden. Denk aan statistiekplugins die bij elke pagina van het beheer een grafiek opbouwen, SEO-plugins die per bericht analyses draaien, of beveiligingsplugins die een scan uitvoeren zodra u inlogt.
Herkennen: installeer tijdelijk Query Monitor. Die toont per pagina welke plugins tijd kosten en welke databasequery’s traag zijn. Meestal springt er één plugin uit. Oplossen: de plugin instellen om minder te doen (bijvoorbeeld de dashboardwidget uitschakelen), of vervangen door een lichter alternatief.
Oorzaak 2: dashboardwidgets die naar buiten bellen
Het dashboard van WordPress bevat standaard een nieuwswidget die berichten ophaalt van wordpress.org. Veel plugins en thema’s voegen daar hun eigen widgets aan toe, met nieuws, aanbiedingen of statistieken van hun servers. Elk van die widgets wacht op een antwoord van buiten. Reageert een van die servers traag, dan wacht uw dashboard mee.
Herkennen: is alleen het dashboard traag, en zijn andere beheerpagina’s normaal? Dan is dit het. Oplossen: klik rechtsboven op Scherminstellingen en zet alle widgets uit die u niet gebruikt. Vaak is dat alles.
Oorzaak 3: WP-Cron die op uw klik meelift
WordPress heeft geen echte taakplanner. Geplande taken (back-ups, geplande berichten, controles op updates) worden uitgevoerd wanneer iemand de site bezoekt. Aan de voorkant vangt de cache dat af. In het beheer niet: u bent vaak degene die de wachtrij aan taken in gang zet, en u wacht erop.
Herkennen: het beheer is met vlagen traag, vooral de eerste klik na een tijdje niet ingelogd te zijn geweest. Oplossen: WP-Cron uitschakelen in wp-config.php en een echte cron-taak instellen bij uw hosting die elke vijf of tien minuten draait. Hoe dat werkt, staat in ons artikel over WP-Cron, de verborgen taakplanner.
Oorzaak 4: een opgezwollen database
De tabel wp_options is de plek waar WordPress en plugins hun instellingen bewaren. Een deel daarvan staat gemarkeerd als “autoload”: het wordt bij elke pagina, ook in het beheer, volledig ingeladen. Bij een schone installatie is dat een paar honderd kilobyte. Bij een site met jaren aan plugins die kwamen en gingen, kan dat oplopen tot vele megabytes, elke pagina opnieuw.
Daarnaast: tienduizenden berichtrevisies, verlopen transients (tijdelijke cachegegevens die nooit werden opgeruimd), en bij webshops: sessies en logtabellen die blijven groeien. De voorkant merkt daar door de cache weinig van. Het beheer merkt het bij elke klik. Oplossen: de database opschonen, met een back-up vooraf en bij voorkeur met iemand die weet wat weg mag.
Oorzaak 5: te weinig PHP-geheugen of een trage server
Het beheer heeft meer geheugen nodig dan de voorkant, zeker met WooCommerce of een paginabouwer. Zit de site tegen de geheugenlimiet aan, dan wordt PHP traag voordat het echt vastloopt. Ook een server die eigenlijk te zwak is voor uw site, valt in het beheer sneller door de mand dan aan de gecachete voorkant.
Herkennen: bij Hulpmiddelen, Sitegezondheid, tabblad Info, ziet u de geheugenlimiet en de PHP-versie. Een limiet van 64 of 128 MB is voor een webshop krap. Een PHP-versie ouder dan 8.1 is niet alleen onveilig, maar ook merkbaar trager. Oplossen: geheugenlimiet verhogen (via wp-config.php of de hosting) en de PHP-versie bijwerken, na een test op een kopie.
Oorzaak 6: de Heartbeat API
Terwijl u in de editor werkt, stuurt WordPress elke 15 tot 60 seconden een berichtje naar de server om te controleren of u nog aanwezig bent en om automatisch op te slaan. Handig, maar op een drukke server of met veel geopende tabbladen tikt dat aan. Sommige plugins haken daar bovendien op in en voeren bij elke hartslag extra werk uit.
Oplossen: de frequentie verlagen of Heartbeat uitschakelen op pagina’s waar u het niet nodig heeft. De meeste optimalisatieplugins hebben daar een instelling voor.
Oorzaak 7: de objectcache ontbreekt
Paginacache helpt de voorkant. Objectcache helpt het beheer. Die bewaart de resultaten van databasequery’s in het werkgeheugen, zodat dezelfde vraag niet steeds opnieuw aan de database gesteld hoeft te worden. Voor een eenvoudige site maakt het weinig uit. Voor een webshop met duizenden producten of een site met veel ingelogde gebruikers is het verschil groot.
Het vereist Redis of Memcached op de server; niet elke hosting biedt dat. Vraag ernaar. Meer over wanneer het loont, leest u in ons artikel over objectcaching met Redis.
Waar u begint
Werk van goedkoop naar duur. Zet eerst de dashboardwidgets uit (een minuut). Installeer daarna Query Monitor en kijk welke plugin of query eruit springt (een kwartier). Controleer bij Sitegezondheid het geheugen en de PHP-versie (vijf minuten). Pas daarna gaat u naar de database, WP-Cron en de objectcache, want die vragen om meer zorgvuldigheid.
Blijft het beheer traag terwijl de voorkant vlot is, dan is het probleem structureel en niet met een enkele instelling te verhelpen. Het is dan meestal een combinatie van een volle database, een handvol zware plugins en een server die aan de krappe kant is. Het opsporen en oplossen daarvan is werk dat wij regelmatig doen als onderdeel van het oplossen van hardnekkige WordPress-problemen, maar de eerste stappen hierboven brengen u vaak al een heel eind. Een traag beheer is geen ongemak dat erbij hoort. Het is een symptoom, en symptomen hebben oorzaken.
