Hoe los je WordPress traag na een plugin-installatie op

Het patroon is heel specifiek. Gisteren liep de site prima, vandaag heb je een plugin geïnstalleerd of geactiveerd, en nu is er iets trager. Misschien voelt wp-admin stroperig. Misschien laadt de homepage een seconde langer. Misschien allebei. De taak in dit artikel is om met zekerheid vast te stellen of die nieuwe plugin ook echt de oorzaak is, en daarna te bepalen wat eraan te doen, zonder lukraak plugins te deactiveren tot je iets ziet bewegen.

Wat je aan het eind hebt

Een helder antwoord op één vraag: is de plugin die je net installeerde de echte oorzaak van de vertraging, en zo ja, welk van drie acties lost het op: behouden en tunen, vervangen door iets lichters, of helemaal weghalen. Het stappenplan werkt zowel voor traagheid op de voorkant als in de admin.

Voor je begint

Dit stappenplan gaat ervan uit dat je het volgende kunt doen op de getroffen site:

• Inloggen in wp-admin als beheerder. Als de vertraging je helemaal uit de admin gooit, lees dan eerst het kritieke fout-artikel om weer binnen te komen.
• Twee gratis plugins uit de WordPress.org-repository installeren en activeren: Health Check & Troubleshooting en Query Monitor. Allebei worden onderhouden door vertrouwde contributors en zijn GPL.
• Browser-developer tools openen in een Chromium-browser. Je gebruikt alleen het Network-paneel en het Performance-paneel.
• Eventueel een staging-kopie van de site benaderen als de live-site te druk is om er rustig op te profileren. Een staging-kopie is geen vereiste, maar het scheelt je de zorg dat troubleshooting mode plugins kort onzichtbaar maakt voor echte bezoekers.
• Weten welke plugin je net hebt geïnstalleerd of geüpdatet. Het hele uitgangspunt van dit stappenplan is "ik heb net iets geïnstalleerd". Kun je niet één specifieke plugin aanwijzen, dan is het algemene trage WordPress-site artikel een betere startplek.

Stap 1: Stel zeker dat de plugin echt de oorzaak is

Het eerste werk is toeval uitsluiten. Plugins zijn niet het enige dat op een dinsdagmiddag het prestatiebeeld kan veranderen. Een verkeerspiek, een back-up window, een externe API die kuren heeft, of een cron-job die op het hele uur afgaat, geven allemaal traagheid die toevallig samenvalt met dat ene wat jij vijf minuten eerder deed. Health Check's Troubleshooting Mode is de schoonste manier om die variabele te isoleren, want hij zet de actieve pluginset uit alleen voor jouw sessie, en laat je daarna één plugin tegelijk weer aan zetten.

1. Ga in wp-admin naar Gereedschap : Sitediagnose : Probleemoplossing.
2. Klik op Probleemoplossingsmodus inschakelen. De pagina laadt opnieuw en bovenin de admin verschijnt een banner: "Je bevindt je in de probleemoplossingsmodus".
3. De site draait nu het standaardthema (op dit moment Twenty Twenty-Four) met alle plugins uitgeschakeld, maar alleen voor jouw ingelogde sessie. Bezoekers zonder login zien de live-site met alle plugins gewoon actief.
4. Op hetzelfde Sitediagnose-scherm klik je op Plugins. Schakel alléén de verdachte plugin weer aan via Inschakelen tijdens probleemoplossing naast de naam.
5. Herlaad de voorkant van de site in een incognito-venster zonder login, en herlaad daarna ook de admin in je gewone browser.

Verwacht resultaat. Met alleen de verdachte plugin actief en een standaardthema draait de pagina nu ongeveer de WordPress-core code path plus die ene plugin. Is de site snel, dan is de verdachte plugin op zichzelf niet de oorzaak. Is hij nog steeds traag, dan heb je het probleem zojuist eenduidig gekoppeld aan die ene plugin. De Health Check plugin-pagina beschrijft het mechanisme tot in detail.

Profileert de plugin in z'n eentje wel netjes maar is de live-site na alles aanzetten nog steeds traag, dan zit het probleem in een interactie met een van de andere actieve plugins. Herhaal het stappenplan: zet de verdachte plus één andere plugin tegelijk aan, op volgorde van waarschijnlijkheid, tot je de vertraging weer ziet. Dat is langzamer dan in één keer alles uitschakelen, maar het is wel de enige methode die je niet voor de gek houdt op een complexe site.

Klaar? Klik op Probleemoplossingsmodus uitschakelen in de banner. Je oorspronkelijke pluginset komt precies terug zoals hij was. Troubleshooting mode is per sessie en raakt de databasestate van geen enkele plugin aan.

Stap 2: Profileer wat de plugin op elke request doet

Zodra je weet wélke plugin verantwoordelijk is, is de volgende vraag wat hij precies doet om een pagina trager te maken. Het eerlijke antwoord is bijna altijd één van vier dingen: hij draait databasequeries die eerst niet draaiden, hij laadt PHP en assets die eerst niet werden geladen, hij doet een HTTP-call naar een externe dienst die eerst niet plaatsvond, of hij hangt extra werk in een hook die op elke request afgaat. Query Monitor maakt alle vier zichtbaar.

1. Met de live pluginset weer actief en de verdachte plugin aan, installeer je Query Monitor als je dat nog niet had. Activeer hem.
2. Herlaad een willekeurige pagina op de voorkant terwijl je als beheerder ingelogd bent. Query Monitor zet rechtsboven in de adminbalk een zwart blokje neer met page generation time, memory peak, database query count en database query time. Een richtgetal voor "normaal" op een typische kleine WordPress-pagina is ongeveer 30 tot 80 queries en 20 tot 80 ms databasetijd, met een totale pagegen onder de 300 ms. Getallen die daar ruim boven zitten, zijn het signaal.
3. Klik op het adminbalk-blokje om het Query Monitor-paneel te openen.
4. Open Queries : Queries by Component. Zoek de verdachte plugin op in de componentlijst. Het getal ernaast is hoeveel queries die plugin per page load doet, en de tijdkolom is wat die queries kosten.
5. Open HTTP API Calls. De HTTP API van WordPress is wat plugins gebruiken om met externe diensten te praten, en Query Monitor logt elke call die tijdens een request gebeurt plus hoe lang die duurde. Een plugin die op elke page load extern een call doet, is een veelvoorkomende oorzaak van trage admin-pagina's, vooral bij betaalde plugins die hun licentieserver bellen.
6. Open Hooks & Actions. De lijst met hooks waar de verdachte plugin aan hangt, vertelt je of de plugin alleen op zeldzame events draait of juist op init, wp, wp_enqueue_scripts of template_redirect, hooks die op elke pagina afgaan.
7. Open Scripts en Styles. Plugins die grote JavaScript-bundels of third-party fonts op elke pagina enqueueen, verschuiven de kosten naar de browser, waar het terugkomt als een slechtere Largest Contentful Paint in plaats van een tragere serverresponse. Query Monitor laat de bestandsgroottes en bronnen zien.

Verwacht resultaat. Je hebt nu een gemeten profiel: hoeveel queries de plugin doet, hoe lang die duren, of hij externe HTTP-calls maakt en hoe lang die duren, op welke hooks hij draait, en welke scripts en styles hij enqueuet. Dat profiel is het bewijs dat je in stap 4 nodig hebt. De Query Monitor plugin-pagina documenteert elk paneel.

Een plugin die één query van 5 ms op init doet, is onschadelijk. Een plugin die 80 queries van samen 400 ms op template_redirect doet, is het hele probleem. Een plugin die op elke admin-pagina synchroon één HTTP-call naar een externe API doet, is het hele probleem. De getallen zeggen je in welk geval je zit.

Stap 3: Loop de plugin-instellingen na op performance-knoppen

De meeste plugins die meetbaar traagheid veroorzaken, hebben minstens één instelling die bepaalt hoe vaak het dure werk gebeurt. De plugins die zo'n instelling niet hebben, zijn meestal te vervangen. Open de instellingenpagina van de plugin in wp-admin en let specifiek op deze patronen:

• Polling- en refresh-intervallen. Een plugin die op elke page load data ophaalt bij een externe dienst, laat je soms het cache-interval verlengen naar elk uur of elke dag. Zoek op woorden als "refresh interval", "cache duration", "update frequency", "TTL".
• Ingebouwde caching-toggles. SEO-plugins, schema-plugins, related-posts plugins en analytics-plugins hebben vaak een eigen cache-laag die standaard uit staat. Zet hem aan.
• Background processing of cron-instellingen. Back-up plugins, security scanners, image optimizers en analytics plugins kun je meestal van het request-pad af halen en op WP-Cron of system cron zetten, zodat ze niet meer op de request-thread van de bezoeker draaien. Zoek op "schedule", "background", "queue", "cron".
• Logging-niveau. Security- en debug-plugins loggen op standaardniveau vaak op elke page load naar de database. Het niveau verlagen, of de log naar een bestand schrijven, scheelt een write per request in de database.
• Externe endpoints. Payment-, social-, analytics- en chat-plugins bellen op schema's die je meestal kunt instellen. Zoek de endpoints in de instellingen, verleng het interval, of zet calls uit die je toch niet gebruikt.
• Frequentie van licentiechecks. Premium plugins van EDD-, FastSpring- of Paddle-stijl winkels checken hun licentie op een schema. Sommige laten je dat interval aanpassen. De licentiecheck is niet load-bearing voor de voorkant, alleen voor de admin, dus een trage check geeft het hele specifieke symptoom van een trage wp-admin terwijl de publieke site prima loopt.

Verwacht resultaat. Of je hebt een setting gevonden die in theorie het werk per request zou moeten verminderen, of je hebt bevestigd dat zo'n setting er niet is en het dure gedrag van de plugin niet door jou bij te stellen valt. Allebei voeden stap 4.

Heb je iets aangepast, draai dan het Query Monitor-profiel uit stap 2 nog een keer op dezelfde pagina en kijk of het query count, de query time, de HTTP API-tijd of de memory peak omlaag ging. De getallen zijn ofwel verschoven, ofwel niet.

Stap 4: Beslis: tunen, vervangen of weghalen

Je hebt nu een gemeten profiel en je weet of de plugin instelbaar is. De beslissing valt in één van drie bakken.

Tunen en houden, als: de instellingen van de plugin de gemeten kosten in dezelfde range brengen als de rest van de actieve plugins, de functionaliteit echt nodig is, en een snelle blik op het WordPress.org supportforum van de plugin laat zien dat andere gebruikers met dezelfde klacht het hebben opgelost via vergelijkbare instellingen of een update van de developer. Abonneer je op de updates en herprofileer na elke release.

Vervangen, als: de gemeten kosten flink uit de pas lopen met vergelijkbare plugins, geen enkele instelling de getallen beweegt, de functionaliteit wel echt waardevol is, en er een lichter alternatief in dezelfde categorie bestaat. De vervanging is alleen een verbetering als je hem op precies dezelfde manier profileert voordat je hem produceert. Ga niet uit van "lichter" zonder te meten. Draai stap 2 op dezelfde pagina op een staging-kopie tegen de kandidaat-vervanger voordat je hem op productie wisselt.

Weghalen, als: de gemeten kosten flink uit de pas lopen, de functionaliteit nice-to-have is in plaats van load-bearing, of je geen vervanger vindt die meetbaar beter profileert. Weghalen is de enige fix die de kosten die de plugin toevoegde gegarandeerd terugneemt. Elke andere fix vermindert ze alleen.

Een handige vuistregel uit het beheren van tientallen WordPress-sites: de kosten van een plugin zijn niet wat de readme adverteert en niet wat de marketingpagina belooft. De kosten zijn wat Query Monitor op jouw site, op jouw hosting, met jouw andere plugins actief, op de pagina's die jouw bezoekers ook echt opvragen, meet. Maak de keuze op die getallen, niet op een onderbuikgevoel over plugin-kwaliteit.

Stap 5: Verifieer de fix op de live-site

Heb je de plugin getuned, vervangen of verwijderd, dan is de laatste stap om te bevestigen dat de vertraging ook echt weg is, en niet alleen wegvalt achter een verse cache. De val is dat een full-page cache de voorkant de eerste paar minuten na elke wijziging snel laat aanvoelen, ook als de onderliggende plugin-kosten er nog steeds zijn. Je moet zowel een cached pagina meten (de route die de meeste bezoekers nemen) als een uncached pad (het worst case).

1. Herlaad dezelfde voorpagina die je in stap 2 profileerde in een incognito-venster. Zet de DevTools Network panel open vóór je navigeert, zodat hij de load vangt. Noteer de TTFB-waarde in de documentregel en het moment waarop het grootste hero image, de headline of het blok in beeld komt. De LCP-richtlijn van web.dev zet de "good"-drempel op 2,5 seconde of minder.
2. Herlaad dezelfde pagina ingelogd als beheerder. Ingelogde requests gaan standaard om de full-page cache heen en raken het volledige PHP- en database-pad bij elke request. Dit is de zwaardere test. Vergelijk de nieuwe Query Monitor-getallen met wat je in stap 2 zag op precies die pagina.
3. Trof de vertraging alleen wp-admin, herlaad dan de admin-pagina's waar je het probleem origineel voelde (Berichten, Pagina's, Updates) en let in de Query Monitor-adminbalk op de page generation time. Zet die af tegen je stap 2-baseline.
4. Wacht een kwartier en herhaal de voorkanttest. Een echte fix blijft. Een fix die alleen werkte omdat er net iets gecached zat, komt in dat kwartier weer terug.

Verwacht resultaat. Lager query count, lagere query time, lagere HTTP API-tijd, lagere page generation time, of alle vier, op precies dezelfde pagina's die je in stap 2 mat. Die verschuiving is de verificatie. Zijn de getallen niet bewogen, dan heeft de fix niet gewerkt, hoe snel de pagina ook subjectief aanvoelt.

Wat er vaak misgaat

Dit zijn de terugkerende valkuilen bij dit stappenplan. Elke valkuil verwijst naar een gerelateerd KB-artikel.

• De vertraging reproduceert niet in incognito. Een ingelogde browsersessie gaat om de full-page cache heen en raakt een zwaarder code path. Bezoekers van de voorkant zien dus een snellere site dan jij, en de vertraging die jij voelt is de admin-traagheid plus het bredere admin-pad. Is alleen de admin traag, dan blijft het stappenplan gelden, maar verandert het verificatiedoel. De PHP-FPM worker pool kan op drukke sites ook meespelen; zie het PHP workers uitgeput artikel.
• De vertraging verdwijnt na het inschakelen van Troubleshooting Mode tijdelijk. Troubleshooting Mode is per sessie, maar het inschakelen flusht wel de object cache. Is de site de eerste paar requests na activatie snel en daarna weer traag, dan komt er iets in de cache wat er niet zou moeten staan. Profileer wat er bij de eerste trage request na het opwarmen wordt geladen.
• De plugin profileert prima op de homepage maar de site is nog steeds traag. Profileer de échte pagina waar je de vertraging voelde, niet de homepage. Plugins gedragen zich vaak heel anders op archive pages, winkelwagen-pagina's, zoekresultaten of admin-lijsten dan op de voorpagina. De getallen van Query Monitor zijn per request.
• De plugin doet de server tegen z'n CPU-plafond aan onder belasting, terwijl hij in z'n eentje prima profileert. Eén page load profileert netjes, maar elke extra gelijktijdige bezoeker vermenigvuldigt de kosten. De oorzaak is niet meer alleen de plugin maar het CPU-plafond waar de plugin de site nu tegenaan duwt. Pak ze allebei aan: tune de plugin én kijk of het hostingpakket past bij de feitelijke concurrency.
• De vertraging blijft staan na het volledig verwijderen van de plugin. Een plugin kan autoloaded options achterlaten in wp_options die op elke request blijven worden geladen, ook na deactivatie. Kijk in Gereedschap : Query Monitor : Queries naar autoloaded options met de prefix van de verwijderde plugin en wis ze met de hand als de uninstall dat niet deed. De algemene framing staat in het trage WordPress-site artikel, en specifiek hoge serverresponses staan in het hoge TTFB artikel.
• De vertraging begon na een plugin-update in plaats van een plugin-install. Hetzelfde stappenplan, ander zusterartikel. Het concept-artikel over traagheid na een update gaat over het verschil tussen een tijdelijke dip en een structurele regressie, dat bij updates speelt en bij verse installs niet.

Waar je daarna heen kunt

Heeft het stappenplan bevestigd dat de nieuwe plugin de oorzaak is en is de fix in stap 5 blijven staan, dan ben je klaar. Bevestigde het wel de plugin maar bleef de fix niet staan, dan zijn de kosten verschoven naar een interactie-laag (caching, de database, of de worker pool) en is het volgende artikel het laagspecifieke: hoge TTFB voor trage server-responses, PHP workers uitgeput voor traagheid onder concurrency, en hoge CPU-belasting voor het volraken van je hostingquota. Heeft het stappenplan de plugin juist uitgesloten, dan zit de oorzaak elders en is het trage WordPress-site artikel de juiste startplek.