Een trage WordPress-site is niet automatisch een “trage database”. De database kan wachten op schijf-I/O, steeds dezelfde zware query uitvoeren, te veel data laden of worden afgeremd door PHP-processen die aanvragen opstapelen. Goede optimalisatie begint daarom met meten, niet met willekeurige instellingen uit een blog kopiëren.
Meet waar de tijd werkelijk verdwijnt
Vergelijk snelle en trage URL’s, ingelogde en anonieme bezoekers en cache hits met misses. Gebruik slow-querylogging of applicatieprofiling om queryduur, aantallen en herhaling te zien. Een pagina met vijf langzame queries vraagt een andere oplossing dan een pagina met vijfhonderd kleine queries.
Indexen: sneller zoeken met een prijs
Een index voorkomt vaak een volledige tabelscan, maar kost opslag en maakt writes iets zwaarder. Voeg daarom geen indexen op gevoel toe. Analyseer WHERE-, JOIN- en ORDER BY-patronen, bekijk het queryplan en test op realistische data. Verwijder dubbele of ongebruikte indexen pas na controle.
WordPress-databasevervuiling
Autoloaded options, verlopen transients, revisies, sessies en tabellen van verwijderde plugins kunnen groeien. Opschonen zonder inzicht is riskant: een lange autoloadlijst kan relevant zijn en een onbekende tabel kan betalingen of licenties bevatten. Maak eerst een backup en controleer eigenaar en gebruik.
Object caching met Redis
Redis bewaart veelgebruikte objecten en queryresultaten in geheugen. Dat helpt vooral wanneer WordPress de pagina dynamisch moet opbouwen. Een volledig gecachete pagina bereikt PHP en de database vaak niet. Redis vervangt dus geen paginacache en repareert geen slechte query, maar vermindert herhaald databasewerk. Lees ook onze LiteSpeed-uitleg.
Buffers en geheugen verstandig instellen
Databasebuffers moeten passen bij dataset, workload en totaal beschikbaar geheugen. Een te kleine buffer veroorzaakt extra I/O; een extreem grote instelling kan het besturingssysteem en andere diensten verdringen. Baseer tuning op actuele statistieken en wijzig één groep instellingen tegelijk.
Hostingisolatie en MySQL-belasting
In een gedeelde omgeving helpt CloudLinux om resourcegebruik per account zichtbaar en begrensd te houden. Dat beschermt buren, maar een site die structureel zijn limieten raakt heeft optimalisatie of een passend pakket nodig. Zie ook PHP, OPcache en workers.
Veilig optimalisatieplan
- Maak een herstelbare backup en leg een nulmeting vast.
- Identificeer trage URL’s, queries en piekmomenten.
- Los applicatie- en queryproblemen vóór algemene tuning op.
- Test indexen, cache en opschoning op staging.
- Rol één wijziging tegelijk uit.
- Vergelijk responstijd, CPU, I/O en foutpercentages na afloop.
Veelgestelde vragen
Moet iedere WordPress-site Redis gebruiken?
Nee. Het voordeel hangt af van dynamische databasevragen en cachegedrag.
Helpt tabellen optimaliseren altijd?
Niet altijd en meestal niet als structurele oplossing voor slechte queries.
Is meer RAM automatisch sneller?
Alleen wanneer geheugen werkelijk de bottleneck is en correct wordt gebruikt.
Wilt u een databaseprobleem laten onderzoeken? Stuur URL, tijdstip en waarneembaar gedrag via het supportportaal.
