WordPress-plugins die we slopen voor elke performance-audit

Een klant geeft je een WordPress-site. Ze willen 'm sneller. Je opent GTmetrix en ziet de waterfall 312 requests tekenen voordat de hero-afbeelding begint te laden. Vierentwintig scripts. Elf losse CSS-bestanden. Een 'slimme' lazy-loader die vecht met die van de browser zelf. Voordat je één afbeelding of DNS-record aanraakt, ligt er al echt geld in de pluginmap.

Dit is de lijst die we op elke WordPress-performanceklus aflopen, voordat de eigenlijke audit begint. Sommige plugins zijn netjes gebouwd. De meeste niet. Allemaal verdienen ze hun verwijdering om een andere reden.

Eerst triage, dan tuning

We beginnen niet met meetwaarden. We beginnen met de pluginlijst, gesorteerd op installatiedatum, en stellen per plugin één vraag: wat gaat er kapot als ik 'm nu deactiveer? Ongeveer een derde van de antwoorden is 'niets zichtbaars'. Die gaan als eerste. Nog een derde doet één specifieke taak slecht en die vervangen we. De rest blijft, soms met tegenzin.

Het eerste commando bij elke audit is steeds hetzelfde:

wp plugin list --status=active --fields=name,version,update --format=table

Je kunt een site met vijftig actieve plugins niet zinvol meten. Het signaal verdrinkt in de ruis. Eerst strippen, dan meten.

Page builders die de DOM gijzelen

Elementor en WPBakery zien we het vaakst. Beide laden een runtime op elke pagina, of die nou met de builder is gemaakt of niet. Beide stoppen elke alinea in drie geneste divs met utility-klassen die de browser tussen pagina's niet kan cachen. WPBakery overleeft in de database als shortcodes die geen andere tool kan lezen, en dat is het slechtste van twee werelden: vendor lock én een opgeblazen DOM.

Onze standaardzet is migreren naar een blockthema met core Gutenberg, en daarna de builder en zijn addons wissen (de 'Essential Addons', 'Ultimate Addons' en 'Premium Addons' zijn allemaal eigen plugins). De HTML-output halveert. De JavaScript-payload zakt vaak met 200KB voordat er iets anders verandert.

Houdt de klant écht van een builder, dan zetten we 'm over naar Breakdance of Bricks. Beide geven veel minder wrapping-markup en laden hun runtime alleen waar nodig.

Sliders waar niemand doorheen scrollt

Het patroon is op elke site die we auditen hetzelfde: de tweede slide van een hero-slider wordt door een minuscule minderheid van de bezoekers gezien. De derde door bijna niemand. Je betaalt de JavaScript- en afbeeldingskosten van een carousel voor een feature die vrijwel niemand gebruikt.

Slider Revolution en LayerSlider komen meestal mee via theme-bundles, vaak verouderd, en hebben een lange historie van beveiligingsgaten. De local file inclusion uit 2014 in Slider Revolution (terug te vinden in de Patchstack-vulnerability-database) werd nog jaren na de patch actief misbruikt, omdat installs die met een thema meekomen niet automatisch updaten. Wij halen ze eruit en vervangen de eerste slide door een statische sectie. De conversie gaat omhoog, niet omlaag.

Het analytics-sediment

WordPress-sites verzamelen analytics-plugins zoals oude laptops browser-toolbars verzamelen. Jetpack Stats, WP Statistics, Slimstat Analytics, Matomo for WordPress, Google Site Kit, en een losse GA-tag in de header, allemaal naast elkaar. Elke schrijft bij elke pageview naar de database. Elke laadt z'n eigen script.

Wij kiezen er één. Meestal Plausible of een server-side Matomo-installatie. Beide draaien zonder cookies en zonder wp_options vol te schrijven. Wil de klant per se Google Analytics, dan laden we het via Cloudflare Zaraz of een server-side container. Niet als nog een script-tag in de head.

WP Statistics laat vaak een bezoekers-tabel van miljoenen rijen achter waar de nachtelijke backup van de host op vastloopt. Die tabel is regelmatig groter dan de rest van de database bij elkaar.

Caching-plugins die met je host vechten

Hosts als SiteGround, Kinsta, WP Engine en Hostinger leveren allemaal hun eigen caching op serverniveau. Daar W3 Total Cache of WP Super Cache bovenop installeren geeft je twee cachelagen die niks van elkaar weten en op verschillende momenten invalideren. Het symptoom is 'waarom toont mijn checkoutpagina de prijs van gisteren'. De oorzaak is twee caches en niemand met de regie.

Onze regel: cachet de host, gebruik dan de cache van de host. Is de host kaal (een goedkope VPS, een oud shared plan), dan installeren we LiteSpeed Cache op LiteSpeed/OpenLiteSpeed, of FlyingPress op alles daarbuiten. We stapelen ze nooit.

SEO-suites met het verkeerde zwaartepunt

Yoast SEO werkt. Het komt alleen met een admin-UI die zwaar genoeg is dat redacteuren erover klagen, en het slaat schema op een manier op die migraties pijnlijk maakt. Op de meeste sites verhuizen we naar RankMath of SEOPress. Allebei geven ze schonere schema-output en importeren ze tijdens de overstap de bestaande Yoast-meta.

Waarom dit voor performance uitmaakt zit niet aan de voorkant (alle drie zijn daar ongeveer gelijk). Het zit in de redactie-ervaring en in wat de plugin in wp_postmeta schrijft. Yoast laat postmeta soms zo uitdijen dat queries erop het traagste deel van de admin-pageload worden. We hebben sites gered waar het wissen van verweesde Yoast-meta-rijen de admin-laadtijd halveerde.

Formulier-plugins die een heel framework meeleveren

Contact Form 7 is prima, alleen laadt elke addon op elke pagina, ook op pagina's zonder formulier. Voeg de Conditional Fields-addon, de reCAPTCHA-addon, de database-storage-addon en de e-mail-styling-addon toe, en je hebt vier extra script-bundles meegestuurd om de About-pagina te lezen.

Onze voorkeur is Fluent Forms, met één runtime die alleen op pagina's met een formulier laadt, en met conditional logic, file uploads en database-storage uit de doos. Gravity Forms kan ook prima, vooral voor complexe multi-step flows, maar voor een contactformulier is dat overkill.

De laat-met-rust-lijst

Niet elke populaire plugin sneuvelt. WooCommerce blijft, want het alternatief is de webshop opnieuw bouwen. WP Mail SMTP blijft, want transactionele e-mail moet daadwerkelijk aankomen. ACF (Advanced Custom Fields) blijft, want zonder ACF verdwijnt het contentmodel.

WordFence is een afweging. Op een host zonder eigen WAF verdient het z'n plek. Achter Cloudflare of een managed WAF doet het dubbel werk en vertraagt het de admin. We vervangen het meestal door de security-module van de host plus de gratis Cloudflare-WAF-regels.

De vervangende stack die we achterlaten

Na de triage ziet een schone WordPress-installatie voor een brochure- of contentsite er meestal zo uit:

• ACF (custom fields)
• Fluent Forms (formulieren)
• RankMath (SEO + schema)
• LiteSpeed Cache of de cache van de host (caching)
• ShortPixel (image-optimisatie, eenmalig draaien en uitschakelen)
• WP Mail SMTP (transactionele e-mail)
• Plausible (analytics)
• Limit Login Attempts Reloaded (bescherming tegen brute-force)

Acht plugins. We hebben deze exacte stack sites zien tillen van een Lighthouse-score in de 30 naar de lage 90 op mobiel, zonder dat iemand het thema aanraakte. De grootste winst komt niet van optimaliseren. Hij komt van wissen.

Voor sites die echt page-builder-functionaliteit nodig hebben, voegen we Breakdance toe of blijven we op Gutenberg met een gecureerde blockplugin (GenerateBlocks of Kadence Blocks, niet de hele bibliotheek). Voor WooCommerce zetten we CartFlows of FunnelKit erop, maar alleen als de klant ook echt funnels draait. Nooit speculatief.

Wat we daarna meten

Zodra de pluginlijst eerlijk is, draaien we de echte audit. Lighthouse op mobiel (niet desktop, mobiel is waar het geld zit), Core Web Vitals over de afgelopen 28 dagen uit het Chrome UX Report, query-monitoring via Query Monitor, en met de hand door de vijf traagste templates scrollen. Cijfers die we eerder niet vertrouwden zijn nu wel betrouwbaar, omdat niets nog tegen niets vecht.

De vervangende stack is geen religie. Het is gewoon wat onze laatste vijftig audits heeft overleefd. Heeft een klant een echte use case voor de CDN van Jetpack, of voor de premium-redirectmanager van Yoast, dan blijven die staan. We weigeren ze alleen standaard te accepteren.

Toen we vorig jaar de marketingsite van een Nederlandse groothandel herbouwden als een legacy-migratie van WPBakery naar een blockthema, daalde het aantal actieve plugins van 47 naar 9 en ging de homepage van 4,2s naar 0,9s op een throttled 4G-verbinding. De grootste winst kwam niet van caching, image-optimisatie of een CDN. De grootste winst was de page builder die het pand verliet.

Open de pluginspagina van je eigen site in een nieuw tabblad. Sorteer op installatiedatum. Stel voor elke plugin de vraag: wat gaat er kapot als ik 'm nu deactiveer? De helft van je auditwerk is dan al gedaan.