Er is een oorzaak van traagheid die op geen enkele snelheidsmeting duidelijk zichtbaar wordt en die met een cacheplugin niet verdwijnt: te grote WordPress autoload opties. Bij elk bezoek aan elke pagina leest WordPress een deel van de instellingentabel volledig in, nog voordat er iets op het scherm staat. Is dat deel uitgegroeid tot enkele megabytes, dan betaalt elke bezoeker daarvoor.
Dit is een van de weinige problemen waarbij een half uur werk een structureel verschil maakt, ook op een site die verder netjes is opgezet. Hieronder wat het is, hoe u meet of het bij u speelt, en hoe u het veilig opruimt.
Wat er bij elke paginaweergave gebeurt
WordPress bewaart instellingen in een tabel met opties. Denk aan uw sitenaam, uw permalinkstructuur, en de instellingen van elke plugin. Elke rij heeft een vlaggetje dat aangeeft of hij automatisch moet worden ingelezen.
Staat dat vlaggetje aan, dan wordt die rij bij elk verzoek opgehaald, of de pagina hem nu nodig heeft of niet. Dat is bedoeld als versnelling: één opvraging in plaats van tientallen losse. Het werkt goed zolang het totaal klein blijft.
Het loopt mis wanneer plugins grote hoeveelheden gegevens in die tabel zetten met het vlaggetje aan. Een cachebestand, een logboek, een lijst met verwijzingen, een verzameling opgeslagen ontwerpen. Dan wordt bij elke paginaweergave een blok van een paar megabyte uit de database gehaald, door PHP uitgepakt en weer weggegooid.
Een gezonde site zit onder de 800 kilobyte, en de meeste zitten onder de 400. Boven de 1 megabyte gaat het merkbaar knijpen; boven de 3 megabyte is het de belangrijkste oorzaak van uw trage beheerscherm.
Zo meet u de autoload-opties in WordPress
Er zijn drie manieren, van eenvoudig naar precies.
- Via de sitegezondheidspagina. Onder de technische gegevens staat bij nieuwere WordPress-versies informatie over de grootte van de automatisch geladen opties. Dit is de snelste controle en vereist geen extra gereedschap.
- Via een opschoonplugin. Verschillende databaseplugins tonen een overzicht van de grootste automatisch geladen rijen, met de naam erbij. Die naam is wat u nodig heeft: daaruit leidt u af welke plugin de veroorzaker is.
- Via een databasevraag. Heeft u toegang tot phpMyAdmin of de opdrachtregel, dan vraagt u de som van de lengte van alle automatisch geladen rijen op, en daarna de twintig grootste. Dit geeft het scherpste beeld.
Wat u zoekt is niet het totaal alleen, maar de uitschieters. Meestal veroorzaken twee of drie rijen tachtig procent van het probleem.
Wie de vervuilers zijn
In de praktijk komen deze categorieën het vaakst naar boven.
- Verwijderde plugins die hun instellingen achterlieten. Dit is veruit de grootste groep. Een plugin verwijderen ruimt de database meestal niet op.
- Paginabouwers die opgeslagen ontwerpen, sjablonen of een cache van hun stijlbestanden in de optietabel zetten.
- Beveiligings- en statistiekplugins die logboeken of teller-standen bijhouden op een plek die daar niet voor bedoeld is.
- Verlopen tijdelijke gegevens. WordPress bewaart tijdelijke waarden die na hun houdbaarheidsdatum moeten verdwijnen, maar dat gebeurt niet altijd. Verlopen exemplaren stapelen zich op.
- Webshopplugins die verzendtarieven, belastingregels of sessiegegevens opslaan met het vlaggetje aan.
Veilig opruimen
Hier is voorzichtigheid op zijn plaats: u werkt in de tabel waar de instellingen van uw hele site in staan. Houd deze volgorde aan en sla geen stap over.
- Maak een back-up van de database. Los van de bestanden, en zet hem ergens neer waar u erbij kunt.
- Ruim eerst verlopen tijdelijke gegevens op. Dit is de veiligste actie en levert vaak al de helft van de winst. Vrijwel elke opschoonplugin heeft er een knop voor.
- Bekijk de twintig grootste rijen en zoek per rij op welke plugin erbij hoort. De naam begint meestal met een herkenbaar voorvoegsel.
- Hoort de rij bij een plugin die u nog gebruikt? Laat hem staan. Kijk of de plugin zelf een opschoonfunctie heeft.
- Hoort hij bij een plugin die weg is? Dan kunt u de rij verwijderen. Doe dat één voor één, niet in bulk, en ververs telkens de site.
- Twijfelt u bij een rij? Zet dan alleen het vlaggetje uit in plaats van de rij te verwijderen. De gegevens blijven bestaan, maar worden niet meer bij elk verzoek ingelezen. Dit is de omkeerbare variant.
Die laatste stap is de belangrijkste tip uit dit artikel. Vlaggetje uitzetten is bijna altijd veilig; verwijderen is dat niet. Meer over wat er verder in de database mag verdwijnen, staat in het overzicht van wat u wel en niet uit uw WordPress-database mag halen.
Wat het oplevert
Wees realistisch over het effect. Zit u op 300 kilobyte, dan verandert opruimen niets merkbaars. Zit u op 4 megabyte, dan is het verschil groot: wij hebben sites gezien waar de tijd tot het eerste antwoord van de server halveerde en het beheerscherm van stroperig naar normaal ging.
Het effect is het duidelijkst op pagina’s die niet uit de cache komen: het beheerscherm, de winkelwagen, de afrekenstap en de accountpagina. Juist daar zit het geduld van uw klant, en juist daar helpt caching u niet. Voelt uw beheerscherm traag terwijl de voorkant snel is, dan is dit een van de eerste dingen om na te lopen; de andere oorzaken van een traag WordPress-beheerscherm staan apart beschreven.
Voorkomen dat het terugkomt
Twee gewoontes houden dit onder controle. De eerste: verwijder plugins die u niet gebruikt echt, en gebruik daarbij de opschoonoptie als de plugin die aanbiedt. Deactiveren alleen laat alle gegevens staan. De tweede: meet dit één keer per kwartaal, samen met uw overige controles. Het is een meting van dertig seconden.
Bij sites die wij in beheer nemen, is dit een van de eerste dingen die wij meten, omdat het bij verwaarloosde sites zo vaak raak is. Daarna hoort het bij de vaste controles binnen het maandelijks nalopen van database en prestaties, zodat het niet opnieuw uit de hand loopt.
Concrete volgende stap: ga naar de pagina met sitegezondheid, open de technische gegevens en zoek de regel over automatisch geladen opties. Staat daar meer dan een megabyte, dan heeft u zojuist de belangrijkste rem op uw site gevonden.
