WordPress & Bricks
WordPress sneller maken zonder tien plugins
Vaak lost een snelheidsplugin vooral een probleem op dat een andere plugin veroorzaakte. Zo maak je WordPress structureel sneller, van hosting tot pagebuilder.
In het kort
- WordPress sneller maken begint met minder plugins en scripts, niet met extra optimalisatieplugins.
- Meerdere cache- of optimalisatieplugins naast elkaar kunnen conflicten en dubbel werk veroorzaken.
- Zware pagebuilders genereren veel extra HTML, CSS en JavaScript, wat de snelheid beperkt.
- De grote afbeelding bovenaan de pagina moet niet lazy geladen worden omdat die vaak het LCP-element is.
- De Core Web Vitals-drempels zijn LCP tot 2,5 seconden, INP tot 200 ms en CLS tot 0,1.
WordPress sneller maken begint niet met nóg een optimalisatieplugin, maar met minder: minder zware plugins, minder ongebruikte scripts en een lichter thema of builder. Daarna doen goede hosting, server-side caching en goed geoptimaliseerde afbeeldingen het meeste werk. Met één cacheoplossing en een opgeruimde basis kom je verder dan met tien plugins die elkaars problemen proberen te verhelpen.
In dit artikel lopen we de grootste snelheidsremmen van WordPress langs, in de volgorde waarin je ze het beste kunt aanpakken.
Waarom WordPress traag wordt
WordPress zelf is niet traag. Een kale installatie met een licht thema laadt vlot. Het gaat mis door alles wat er in de loop der jaren bij komt:
- Plugins die op elke pagina laden, ook waar ze niet gebruikt worden, zoals een sliderplugin of formulierplugin die overal CSS en JavaScript inlaadt.
- Zware thema’s en pagebuilders die veel geneste HTML, grote stylesheets en scripts genereren.
- Grote afbeeldingen die zonder compressie of juiste afmetingen geüpload worden.
- Externe scripts: chatwidgets, trackingpixels, embedded video’s en lettertypen van derden.
- Goedkope gedeelde hosting met een trage server-responstijd.
Het patroon is bijna altijd hetzelfde: er komt een probleem, er komt een plugin bij, en die plugin brengt weer eigen overhead mee. Wie WordPress echt sneller wil maken, moet dat patroon doorbreken.
Stap 1: meet voordat je gaat sleutelen
Begin met meten, anders weet je niet of een aanpassing helpt. Gebruik PageSpeed Insights voor je belangrijkste pagina’s (homepage, een dienstpagina, een blogartikel) en kijk vooral naar de veldgegevens van echte bezoekers als die beschikbaar zijn. De Core Web Vitals-drempels zijn LCP ≤ 2,5 seconden, INP ≤ 200 ms en CLS ≤ 0,1. Wat die drie meetwaarden betekenen, lees je in Core Web Vitals uitgelegd voor ondernemers.
Kijk daarnaast naar de server-responstijd (TTFB). Is die structureel traag, dan heeft optimaliseren aan de voorkant beperkt effect. Dan zit het probleem in hosting, database of zware plugins die bij elke paginaweergave veel werk doen.
Stap 2: ruim plugins en scripts op
Dit is de stap met de meeste winst en de minste kosten. Loop elke plugin langs en stel drie vragen: gebruiken we dit nog, kan het met minder, en laadt het alleen waar het nodig is?
| Type plugin | Veelvoorkomend probleem | Alternatief |
|---|---|---|
| Sliders en carrousels | Zware scripts op elke pagina | Statische hero of een lichte CSS-oplossing |
| Formulierplugins | CSS en JS op pagina’s zonder formulier | Assets alleen laden op pagina’s met een formulier |
| Social-share-knoppen | Externe scripts en tracking | Simpele deellinks zonder script |
| Meerdere optimalisatieplugins | Dubbele minificatie en conflicten | Eén cacheoplossing, bij voorkeur op serverniveau |
| Iconenbibliotheken | Hele fontbestanden voor een paar iconen | Inline SVG voor de iconen die je echt gebruikt |
Let ook op externe scripts. Een chatwidget, een heatmaptool en drie trackingpixels kunnen samen meer vertragen dan je hele thema. Vooral voor INP, de meetwaarde voor hoe snel je site reageert op een klik, zijn zware scripts funest.
Stap 3: thema en pagebuilder onder de loep
Je thema of pagebuilder bepaalt hoeveel HTML, CSS en JavaScript elke pagina meekrijgt. Sommige builders genereren voor een simpele sectie vele lagen geneste div’s en laden een grote stylesheet en meerdere scripts, ook als je maar een fractie van de functies gebruikt.
Je kunt daar met instellingen veel aan verbeteren: ongebruikte widgets uitschakelen, ‘geoptimaliseerde’ assets laden en lettertypen lokaal hosten. Maar er is een grens. Als de basis zwaar is, blijft hij zwaar. Daarom stappen steeds meer sites over van Elementor naar een lichtere builder zoals Bricks, die schonere HTML genereert en minder overbodige code laadt. Zo’n overstap vraagt om een zorgvuldige aanpak om je rankings te behouden; lees hoe wij een migratie van Elementor naar Bricks aanpakken.
Stap 4: afbeeldingen, caching en de server
Afbeeldingen
Upload afbeeldingen niet groter dan nodig, gebruik moderne formaten zoals WebP of AVIF en zorg dat WordPress responsive formaten aanbiedt via srcset. WordPress voegt zelf al lazy loading toe aan afbeeldingen. Let op: de grote afbeelding bovenaan de pagina, vaak je LCP-element, moet juist níet lazy geladen worden. Geef die bij voorkeur fetchpriority="high" mee.
Lettertypen
Beperk het aantal lettertypes en gewichten, host ze lokaal in WOFF2 en gebruik font-display: swap. Elke extra variant is een extra bestand dat geladen moet worden.
Caching
Kies één cacheoplossing. Veel goede WordPress-hosts bieden server-side caching en objectcaching; dan heb je vaak geen aparte cacheplugin nodig. Heeft je host dat niet, kies dan één degelijke cacheplugin en stapel er geen tweede overheen. Een CDN helpt vooral als je bezoekers uit verschillende landen komen.
Hosting, PHP en database
Alles wat hierboven staat, gaat over wat de browser moet doen. Maar voordat er überhaupt iets geladen wordt, moet de server de pagina opbouwen. Daar zitten drie knoppen waar je aan kunt draaien:
- Een ondersteunde PHP-versie. Nieuwere PHP-versies zijn doorgaans sneller en krijgen nog beveiligingsupdates. Controleer eerst op een stagingomgeving of je thema en plugins ermee overweg kunnen.
- Een opgeruimde database. Duizenden oude revisies, verlopen transients en restanten van verwijderde plugins maken queries trager. Ruim periodiek op, maar maak altijd eerst een back-up.
- Hosting die bij je site past. Een drukke webshop op het goedkoopste gedeelde pakket gaat haperen, hoe goed je de voorkant ook optimaliseert. Let op server-side caching, voldoende geheugen en een datacenter dicht bij je bezoekers.
Merk je dat je server-responstijd ook zonder bezoekerspieken traag blijft, dan zit de oorzaak vaak in een plugin die bij elke pagina zware queries uitvoert. Een query-monitor op je stagingomgeving laat zien welke plugin de boosdoener is.
Zo pak je het aan: WordPress sneller maken in 7 stappen
- Meet de Core Web Vitals en server-responstijd van je drie belangrijkste paginatypen en noteer de uitgangswaarden.
- Maak een back-up en werk bij voorkeur eerst op een stagingomgeving.
- Verwijder plugins die je niet gebruikt en vervang zware plugins door lichtere oplossingen.
- Beperk externe scripts tot wat echt nodig is en laad niet-kritieke scripts uitgesteld.
- Optimaliseer afbeeldingen en lettertypen: juiste afmetingen, moderne formaten en lokale fonts.
- Regel caching op één plek, bij voorkeur op serverniveau.
- Meet opnieuw en vergelijk. Houd daarna bij elke nieuwe plugin kritisch in de gaten wat hij kost.
Stel: een advocatenkantoor in Utrecht heeft een WordPress-site met zes optimalisatie- en cacheplugins die elkaar tegenwerken. Door ze terug te brengen naar één oplossing op serverniveau en een ongebruikte sliderplugin te verwijderen, vallen er conflicten weg en wordt de site voorspelbaarder om verder te optimaliseren. Het punt van dit voorbeeld: minder is vaak de eerste winst.
Conclusie
WordPress sneller maken is vooral opruimen. Meet eerst, schrap wat niet nodig is, kies een lichte basis en regel caching op één plek. Pas daarna heeft finetuning echt zin. Het resultaat is een site die sneller laadt, prettiger reageert en beter scoort op de signalen waar Google naar kijkt.
Wil je weten waar jouw site de meeste tijd verliest? Laat het uitzoeken met een technische SEO-check inclusief snelheidsanalyse.
Veelgestelde vragen
Hoeveel plugins zijn te veel voor WordPress?
Het gaat niet om het aantal maar om wat ze laden. Eén zware plugin die op elke pagina scripts inlaadt kan meer vertragen dan tien lichte plugins.
Heb ik een cacheplugin nodig?
Niet als je host server-side caching aanbiedt. Anders kies je één degelijke cacheplugin en combineer je die niet met een tweede.
Is Elementor slecht voor de snelheid?
Elementor kan snel genoeg zijn, maar genereert relatief veel code. Lichtere builders zoals Bricks laden doorgaans minder overbodige HTML, CSS en JavaScript.
Helpt een CDN altijd?
Een CDN helpt vooral bij bezoekers verspreid over verschillende regio's. Voor een lokale Nederlandse site is goede hosting met caching vaak belangrijker.