Uw site heeft een cacheplugin, de afbeeldingen zijn geoptimaliseerd en toch duurt het bij sommige pagina’s seconden voordat er iets gebeurt. Vooral als u bent ingelogd, in de webshop zoekt of een filter gebruikt. Een cache helpt bij pagina’s die voor iedereen hetzelfde zijn, maar zodra WordPress de pagina echt moet opbouwen, komt de database in beeld. En een trage database in WordPress is een oorzaak die de meeste snelheidstools niet laten zien.

Het goede nieuws: u kunt zelf vaststellen of dit bij u speelt, en welke plugin of tabel de boosdoener is. Dit stappenplan gebruikt één gratis plugin en vraagt geen kennis van SQL. Waar de oplossing technisch wordt, zeggen wij dat eerlijk.

Stap 1: herken de signalen van een trage database in WordPress

Niet elke trage site heeft een databaseprobleem. Deze signalen wijzen die kant op:

  • De wachttijd voordat de pagina begint te laden (TTFB) is hoog, meer dan een seconde, terwijl de pagina daarna vlot verschijnt.
  • Ingelogd is de site veel trager dan uitgelogd. Voor ingelogde gebruikers wordt de paginacache meestal overgeslagen.
  • Het WordPress-beheer is traag, vooral het overzicht van berichten, producten of bestellingen.
  • Zoekopdrachten, productfilters of een agenda-overzicht duren lang.
  • De hostingpartij meldt dat de database veel CPU gebruikt.

Herkent u twee of meer punten, dan loont het om verder te kijken.

Stap 2: installeer Query Monitor

Query Monitor is een gratis plugin uit de officiële pluginmap die laat zien wat WordPress doet bij het opbouwen van een pagina: welke databasequery’s er draaien, hoe lang ze duren en welke plugin ze veroorzaakt. Installeer de plugin, activeer hem en laad de trage pagina terwijl u bent ingelogd. In de beheerbalk bovenaan verschijnt een nieuw item met cijfers, bijvoorbeeld “0,84s 212Q”. Dat betekent: de pagina kostte 0,84 seconde aan opbouw en deed 212 query’s.

Query Monitor toont alleen iets voor ingelogde beheerders. Bezoekers merken er niets van. Toch is het verstandig om de plugin na het onderzoek weer te deactiveren; hij hoeft niet permanent aan te staan.

Stap 3: lees de cijfers

Klik op het item in de beheerbalk. Het paneel dat opent heeft verschillende tabbladen. Voor dit doel zijn er drie belangrijk.

Queries toont alle query’s van deze pagina. Sorteer op tijd. Een paar honderd query’s van elk een fractie van een milliseconde is normaal. Eén query van 300 milliseconden is dat niet.

Queries by component groepeert de query’s per plugin, thema of WordPress-kern. Hier ziet u in één oogopslag welke plugin de meeste databasetijd opeist. In de praktijk is dit het tabblad dat de zaak oplost.

Slow queries of de rood gemarkeerde regels: Query Monitor markeert query’s die langer dan een ingestelde drempel duren. Begin bij die regels.

Noteer voor de drie langzaamste query’s welke component ze veroorzaakt en welke tabel ze bevragen (u ziet namen als wp_postmeta, wp_options of wp_wc_orders). Meer hoeft u niet te begrijpen om de volgende stap te zetten.

Stap 4: de bekende boosdoeners

Bij verreweg de meeste sites komt de vertraging uit een van deze hoeken.

Een opgezwollen wp_options-tabel

WordPress laadt bij elk bezoek alle opties met de markering “autoload” in het geheugen. Plugins die u ooit heeft verwijderd, laten daar vaak gegevens achter. Groeit die set tot meerdere megabytes, dan voelt u dat op elke pagina. Query Monitor toont de query op wp_options met autoload = ‘yes’; duurt die lang, dan is dit uw probleem.

Zoeken in postmeta

Productfilters, plugins voor gerelateerde berichten en sommige agendaplugins zoeken in wp_postmeta op de waarde van een veld. Die tabel heeft daar geen index op, dus de database leest hem van voor naar achter. Bij een webshop met tienduizend producten en veertig eigenschappen per product is dat een tabel van honderdduizenden regels.

Verlopen transients

Plugins bewaren tijdelijke gegevens als “transients” in de database. Worden die nooit opgeruimd, dan stapelen ze zich op in dezelfde optiestabel.

Statistieken- en logplugins

Plugins die elk bezoek in de database wegschrijven, doen dat ook bij elk bezoek. Bij drukte wordt dat een rem.

WooCommerce-bestellingen in de oude opslag

Webshops die orders nog als berichten opslaan in plaats van in de nieuwe ordertabellen, zien het bestellingenoverzicht traag worden zodra er tienduizenden orders zijn.

Stap 5: aanpakken

Afhankelijk van wat u vond:

  1. Autoload opschonen. Verwijder achtergebleven opties van oude plugins en zet grote opties die niet bij elk bezoek nodig zijn op autoload “no”. Dit vraagt zorgvuldigheid; maak eerst een back-up. Hoe u de database netjes opruimt zonder iets kwijt te raken, staat in ons stappenplan voor het opschonen van de database.
  2. Plugin vervangen. Blijkt één plugin structureel de zwaarste query’s te doen, kijk dan of een alternatief hetzelfde doet met minder databasewerk. Bij plugins voor gerelateerde berichten en statistieken loont dat bijna altijd.
  3. Index toevoegen. Voor terugkerende zoekopdrachten op meta_value kan een index op die kolom veel schelen. Dit is werk voor iemand die MySQL kent; verkeerd toegepast maakt het schrijven trager.
  4. Objectcache inschakelen. Met Redis of Memcached bewaart WordPress de uitkomst van query’s in het geheugen, zodat dezelfde vraag niet steeds opnieuw aan de database wordt gesteld. Voor webshops en sites met veel ingelogde gebruikers is dit vaak de grootste sprong. Of dat bij u loont, leest u in het artikel over objectcaching met Redis.
  5. WooCommerce naar HPOS. Bij grote webshops is de overstap naar de nieuwe orderopslag het overwegen waard, na een test op staging.

Stap 6: controleer op serverniveau

Blijft de database traag terwijl de query’s er netjes uitzien, dan kan de oorzaak bij de hosting liggen: een overbelaste gedeelde databaseserver, een te kleine buffer of een verouderde MySQL-versie. Vraag uw hostingpartij naar het “slow query log” en naar de belasting van de databaseserver. Een goede hoster kan dat zo laten zien. Een slechte weet niet waar u het over heeft, en ook dat is informatie.

Wanneer u hulp inschakelt

Stap 1 tot en met 3 kan iedere sitebeheerder zelf. Bij stap 5 wordt het technischer: een verkeerde ingreep in wp_options of een index op de verkeerde kolom is niet zomaar ongedaan gemaakt. Als u de veroorzaker heeft gevonden maar de oplossing niet zelf wilt uitvoeren, is dat een overzichtelijke klus voor een specialist in snelheidsoptimalisatie; met de cijfers uit Query Monitor erbij is het werk in een paar uur gedaan. WebMaintor pakt dit regelmatig op, maar elke ervaren WordPress-ontwikkelaar kan hiermee uit de voeten.

Begin vandaag met Query Monitor op de traagste pagina. Binnen tien minuten weet u of de database het probleem is, en welke plugin u daarover moet aanspreken.