Een trage WordPress-website is meer dan alleen irritant. Bezoekers verwachten dat een website vrijwel direct reageert. Wanneer pagina's langzaam laden, klikken mensen sneller weg, worden minder pagina's bekeken en kan uiteindelijk ook het aantal aanvragen, bestellingen of inschrijvingen dalen.

Daarnaast speelt snelheid een rol in de gebruikerservaring die Google meet met de Core Web Vitals. Daarbij kijkt Google onder andere naar hoe snel de belangrijkste content zichtbaar wordt, hoe snel een website reageert op interacties en of de pagina tijdens het laden onverwacht verspringt.

Het goede nieuws is dat een trage WordPress-site meestal geen mysterie is. De oorzaak zit vrijwel altijd in één of meerdere onderdelen van de technische keten: hosting, PHP, WordPress, plugins, het thema, de database, afbeeldingen, JavaScript, CSS, externe scripts of caching.

In deze handleiding leggen we stap voor stap uit hoe je een trage WordPress-website sneller maakt, waar je als eerste naar moet kijken en welke optimalisaties in de praktijk het meeste verschil maken.

Waarom wordt een WordPress-website langzaam?

Om WordPress sneller te maken, helpt het om eerst te begrijpen wat er gebeurt wanneer iemand een pagina opent.

Bij een traditionele, niet-volledig-gecachete WordPress-pagina moet de server onder andere:

1. het verzoek van de bezoeker ontvangen;
2. WordPress en de benodigde PHP-code uitvoeren;
3. actieve plugins laden;
4. het actieve thema verwerken;
5. gegevens uit de database ophalen;
6. de HTML van de pagina samenstellen;
7. deze HTML naar de browser sturen;
8. waarna de browser nog CSS, JavaScript, afbeeldingen, lettertypen en andere bestanden moet downloaden en verwerken.

Er zijn dus twee grote gebieden waarop vertraging kan ontstaan:

Server-side performance: hoe snel de hostingomgeving, PHP, WordPress en database de pagina kunnen genereren.

Front-end performance: hoe snel de browser alle HTML, CSS, JavaScript, afbeeldingen, fonts en andere resources kan laden en weergeven.

Een snelle website vereist aandacht voor beide.

1. Meet eerst waar het probleem zit

Een veelgemaakte fout is direct allerlei optimalisatieplugins installeren zonder eerst vast te stellen waarom de website langzaam is.

Dat kan soms helpen, maar het kan het probleem ook verbergen of zelfs nieuwe problemen veroorzaken.

Begin daarom met meten.

Een bekende optie is Google PageSpeed Insights. Daarmee kun je een URL analyseren en zien welke onderdelen van een pagina verbetering nodig hebben.

Daarnaast kun je de developer tools van Chrome of Firefox gebruiken. Ook WordPress zelf raadt browserontwikkelaarstools en externe benchmarkingtools aan voor performanceanalyse.

Test niet alleen je homepage. Controleer bijvoorbeeld ook:

• een blogartikel;
• een categoriepagina;
• een productpagina bij WooCommerce;
• de winkelwagen;
• een belangrijke landingspagina;
• een pagina met een formulier;
• en eventueel het WordPress-dashboard.

Een snelle homepage betekent namelijk niet automatisch dat de rest van de website snel is.

Kijk verder dan alleen de PageSpeed-score

Een score van bijvoorbeeld 95 of 100 ziet er aantrekkelijk uit, maar het doel moet niet zijn om koste wat kost een perfecte score te behalen.

Kijk vooral naar de daadwerkelijke gebruikerservaring en naar meetwaarden zoals:

Largest Contentful Paint (LCP)
Meet hoe snel het grootste zichtbare contentelement wordt weergegeven. Google beschouwt een LCP van maximaal ongeveer 2,5 seconden als goed.

Interaction to Next Paint (INP)
Meet hoe snel de pagina visueel reageert nadat een bezoeker ermee interacteert. Voor een goede gebruikerservaring adviseert Google maximaal ongeveer 200 milliseconden.

Cumulative Layout Shift (CLS)
Meet hoeveel elementen tijdens het laden onverwacht verschuiven. Een CLS van maximaal 0,1 wordt als goed beschouwd.

Daarnaast is de Time to First Byte (TTFB) interessant. Deze geeft grofweg aan hoelang het duurt voordat de browser de eerste gegevens van de server ontvangt.

Een hoge TTFB kan bijvoorbeeld wijzen op:

• langzame hosting;
• onvoldoende CPU-capaciteit;
• trage PHP-verwerking;
• een zware databasequery;
• te veel WordPress-plugins;
• onvoldoende caching;
• externe API-verzoeken;
• of een overbelaste server.

2. Begin bij goede WordPress-hosting

Je kunt WordPress extreem goed optimaliseren, maar een website blijft uiteindelijk afhankelijk van de server waarop hij draait.

Hosting vormt daarom de basis van vrijwel iedere WordPress-optimalisatie.

Een WordPress-site die weinig servercapaciteit krijgt, kan vertragen zodra meerdere bezoekers tegelijkertijd pagina's openen of wanneer plugins zware PHP-processen uitvoeren.

Let bij WordPress-hosting onder andere op:

• beschikbare CPU-capaciteit;
• beschikbaar RAM-geheugen;
• opslagprestaties;
• PHP-configuratie;
• PHP workers of vergelijkbare proceslimieten;
• databaseprestaties;
• server-side caching;
• beschikbare object caching;
• datacenterlocatie;
• netwerkverbindingen;
• en eventuele limieten die op het hostingpakket gelden.

Shared hosting hoeft niet automatisch langzaam te zijn

Het woord shared hosting betekent op zichzelf niet dat een website langzaam moet zijn.

Het gaat vooral om hoeveel resources beschikbaar zijn, hoeveel accounts een server moet verwerken en hoe de hostingomgeving is ingericht.

Een kleine bedrijfswebsite kan uitstekend functioneren op een goed ingericht hostingpakket. Een grote WooCommerce-webshop met duizenden producten, veel gelijktijdige bezoekers en complexe plugins stelt daarentegen heel andere eisen.

Daarom is het belangrijk dat het hostingpakket past bij de website.

Wanneer is hosting waarschijnlijk de bottleneck?

Hosting verdient extra aandacht wanneer:

• vrijwel alle pagina's langzaam zijn;
• ook het WordPress-dashboard langzaam reageert;
• pagina's soms snel en soms extreem langzaam openen;
• de website bij piekverkeer sterk vertraagt;
• PHP-processen regelmatig tegen limieten lopen;
• je regelmatig 502-, 503- of 504-fouten ziet;
• zware WooCommerce-acties langzaam zijn;
• of caching de website snel maakt, maar niet-gecachete pagina's extreem traag blijven.

In dat geval kan meer optimaliseren aan de voorkant het onderliggende probleem niet volledig oplossen.

3. Gebruik een moderne PHP-versie

WordPress draait grotendeels op PHP. De gekozen PHP-versie heeft daarom invloed op zowel beveiliging, compatibiliteit als prestaties.

WordPress adviseert momenteel een moderne PHP-versie en vermeldt in zijn actuele requirements PHP 8.3 of hoger als aanbevolen serveromgeving. Oudere versies kunnen nog werken, maar WordPress waarschuwt expliciet tegen versies die inmiddels End of Life zijn.

Voordat je PHP bijwerkt:

• maak een volledige back-up;
• update WordPress;
• update plugins;
• update je thema;
• controleer de compatibiliteit;
• en test de website bij voorkeur eerst in een stagingomgeving.

Gebruik dus niet blind de nieuwste beschikbare PHP-versie wanneer één van je cruciale plugins daar nog niet mee overweg kan.

Een moderne maar volledig compatibele PHP-configuratie is de juiste keuze.

4. Gebruik page caching

Caching behoort tot de belangrijkste WordPress-optimalisaties.

Normaal gesproken moet WordPress voor iedere niet-gecachete pagina PHP uitvoeren en vaak meerdere databasequeries uitvoeren. Met page caching kan een reeds gegenereerde versie van de pagina worden opgeslagen.

Een volgende bezoeker krijgt vervolgens grotendeels die opgeslagen versie te zien.

WordPress omschrijft caching zelf als een van de snelste manieren om de performance te verbeteren en legt uit dat page caching statische paginaresultaten kan serveren zonder WordPress telkens opnieuw volledig te laten rekenen.

Verschillende soorten caching

Het woord caching wordt voor meerdere technieken gebruikt.

Page cache

Slaat de gegenereerde HTML van pagina's op.

Dit is meestal de optimalisatie met de grootste directe impact voor publieke WordPress-pagina's.

Browser caching

Laat statische bestanden zoals afbeeldingen, CSS en JavaScript langer in de browser van de bezoeker bewaren.

Bij een volgend bezoek hoeven deze bestanden dan niet altijd opnieuw volledig te worden gedownload.

Object caching

WordPress haalt voortdurend gegevens uit zijn database. Object caching kan resultaten daarvan tijdelijk opslaan zodat bepaalde databasebewerkingen niet steeds opnieuw hoeven te worden uitgevoerd.

WordPress beschrijft zijn Object Cache specifiek als een mechanisme waarmee het aantal databaseverzoeken kan worden verminderd.

Voor grotere dynamische WordPress-sites en WooCommerce-webshops kan een persistente object cache, bijvoorbeeld via Redis of Memcached, bijzonder waardevol zijn.

WordPress heeft hiervoor zelfs een Site Health-controle die onder bepaalde omstandigheden een persistente object cache aanbeveelt.

Opcode caching

PHP-code moet normaal gesproken worden geïnterpreteerd en gecompileerd voordat deze kan worden uitgevoerd. Een opcode cache zoals OPcache bewaart gecompileerde PHP-code in het geheugen.

WordPress noemt opcode caching eveneens als een belangrijke server-side optimalisatie.

Gebruik niet meerdere page-cacheplugins tegelijk

Meer cachingplugins betekent niet meer snelheid.

Twee plugins die tegelijkertijd dezelfde vorm van page caching, minification of JavaScript-optimalisatie uitvoeren, kunnen elkaar juist tegenwerken.

Gebruik daarom bij voorkeur één duidelijke performanceoplossing en combineer alleen technieken waarvan je begrijpt hoe ze elkaar aanvullen.

5. Optimaliseer je afbeeldingen

Afbeeldingen behoren op veel websites tot de grootste bestanden op een pagina.

Een hero-afbeelding van 4 MB kan een pagina bijvoorbeeld aanzienlijk vertragen, terwijl dezelfde afbeelding na goede resizing en compressie soms slechts een fractie daarvan hoeft te zijn.

WordPress adviseert zelf om afbeeldingen voor het web te optimaliseren en moderne formaten zoals WebP te overwegen.

Verklein afbeeldingen vóór of tijdens het uploaden

Een afbeelding hoeft niet groter te worden geleverd dan nodig.

Als een afbeelding op maximaal 1200 pixels breed wordt weergegeven, heeft het weinig zin om iedere bezoeker een bronbestand van bijvoorbeeld 6000 pixels breed te laten downloaden.

WordPress genereert automatisch verschillende beeldformaten. Zorg ervoor dat je thema en plugins deze responsive images correct gebruiken.

Gebruik moderne formaten zoals WebP of AVIF

WebP en AVIF kunnen afbeeldingen vaak aanzienlijk efficiënter opslaan dan traditionele JPEG- en PNG-bestanden, afhankelijk van het soort afbeelding en de gekozen compressie.

Google adviseert moderne afbeeldingsformaten zoals WebP en AVIF te overwegen om de bestandsgrootte te verminderen.

Comprimeer afbeeldingen

Er zijn twee algemene vormen:

Lossless compression probeert de bestandsgrootte te verkleinen zonder zichtbare informatie te verwijderen.

Lossy compression verwijdert bepaalde beeldinformatie om veel kleinere bestanden te verkrijgen.

Voor foto's is een enigszins lossy compressie vaak prima zolang het verschil visueel nauwelijks merkbaar is.

Het doel is niet de kleinst mogelijke afbeelding, maar de beste verhouding tussen kwaliteit en bestandsgrootte.

6. Gebruik lazy loading, maar niet overal

Met lazy loading worden afbeeldingen en bijvoorbeeld iframes die nog ver buiten beeld staan niet onmiddellijk geladen.

Dat bespaart netwerkverkeer tijdens de eerste paginalaad. Google beschrijft lazy loading als een manier om onnodige downloads uit te stellen totdat een resource waarschijnlijk nodig is.

Maar hier zit een belangrijke valkuil.

Gebruik lazy loading niet voor je belangrijkste afbeelding bovenaan de pagina als deze je LCP-element is.

Google waarschuwt specifiek dat het lazy-loaden van de LCP-afbeelding de laadtijd juist kan verslechteren.

Een goede vuistregel:

• hero-afbeelding direct laden;
• afbeeldingen onder de fold lazy-loaden;
• belangrijke afbeeldingen prioriteit geven;
• onzichtbare media uitgesteld laden.

7. Controleer het WordPress-thema

Een WordPress-thema bepaalt veel meer dan alleen kleuren en lettertypen.

Een thema kan:

• CSS laden;
• JavaScript laden;
• fonts toevoegen;
• sliders initialiseren;
• databasequeries uitvoeren;
• widgets genereren;
• WooCommerce-functionaliteit uitbreiden;
• iconlibraries laden;
• trackingcode toevoegen;
• en aanvullende frameworks activeren.

Een zwaar thema kan daarom een groot verschil maken.

Pas op met alles-in-één-thema's

Thema's met honderden functies kunnen handig zijn, maar bevatten soms functionaliteit die op jouw website helemaal niet nodig is.

Controleer daarom hoeveel scripts en stylesheets daadwerkelijk worden geladen.

Een lichtgewicht thema met alleen de benodigde functionaliteit is doorgaans eenvoudiger snel te houden.

Dat betekent overigens niet dat iedere pagebuilder automatisch slecht is. Elementor, Divi, Bricks, Gutenberg en vergelijkbare systemen kunnen allemaal snelle én trage websites produceren.

Het gaat uiteindelijk om:

• hoeveel elementen je gebruikt;
• hoeveel DOM-elementen worden gegenereerd;
• hoeveel CSS wordt geladen;
• hoeveel JavaScript wordt uitgevoerd;
• welke add-ons je installeert;
• en hoe efficiënt de pagina is opgebouwd.

8. Verwijder onnodige WordPress-plugins

Plugins zijn één van de grootste voordelen van WordPress, maar ze kunnen ook een belangrijke bron van vertraging worden.

WordPress adviseert bij performanceproblemen expliciet om onnodige plugins te verwijderen en plugins selectief uit te schakelen om hun impact te meten.

Het probleem is niet simpelweg het aantal plugins.

Twintig goed geschreven plugins kunnen minder impact hebben dan één slecht geoptimaliseerde plugin.

Let vooral op plugins die:

• zware databasequeries uitvoeren;
• scripts op iedere pagina laden;
• externe API's aanroepen;
• uitgebreide statistieken verzamelen;
• realtime zoekfunctionaliteit aanbieden;
• redirects of securitychecks uitvoeren;
• grote hoeveelheden data in wp_options opslaan;
• veel scheduled tasks creëren;
• of bij ieder paginaverzoek complexe berekeningen uitvoeren.

Test plugins systematisch

Schakel niet zomaar alles uit op een live website.

Maak indien mogelijk een stagingkopie en:

1. meet de performance;
2. deactiveer één verdachte plugin;
3. test opnieuw;
4. vergelijk TTFB en laadtijd;
5. herhaal dit voor andere plugins.

Op die manier ontdek je welke plugin werkelijk invloed heeft.

9. Let op plugins die scripts op iedere pagina laden

Stel dat je een contactformulier alleen op /contact/ gebruikt.

Idealiter hoeft de JavaScript- en CSS-code daarvoor niet per se op iedere blogpost en productpagina te worden geladen.

Toch doen sommige plugins dat wel.

Hetzelfde kan gebeuren met:

• sliders;
• pop-ups;
• WooCommerce-uitbreidingen;
• social-sharingplugins;
• formulieren;
• chatwidgets;
• reviewtools;
• analytics;
• afspraakmodules.

Met geavanceerde optimalisatietools kun je assets conditioneel uitschakelen op pagina's waar ze niet nodig zijn.

Doe dit wel voorzichtig. Verkeerd uitschakelen van JavaScript of CSS kan functionaliteit breken.

10. Minimaliseer zware JavaScript-code

JavaScript heeft steeds meer invloed op moderne websiteperformance.

Een browser moet JavaScript:

1. downloaden;
2. verwerken;
3. compileren;
4. uitvoeren.

Vooral op tragere smartphones kan veel JavaScript de pagina merkbaar minder responsief maken.

Dat heeft onder andere invloed op INP, de Core Web Vital die meet hoe snel een pagina reageert op gebruikersinteracties.

Let bijvoorbeeld op:

• sliders;
• animaties;
• chatwidgets;
• cookiebanners;
• advertenties;
• analytics;
• heatmaps;
• socialmedia-embeds;
• A/B-testsoftware;
• trackingpixels;
• pagebuilder-add-ons.

Eén script lijkt misschien niet zwaar. Maar tien verschillende diensten van externe partijen kunnen samen een aanzienlijk deel van de laadtijd en main-thread-belasting veroorzaken.

Delay en defer

Niet-kritische scripts kunnen in sommige gevallen worden uitgesteld.

defer zorgt er bijvoorbeeld voor dat een script niet noodzakelijk de HTML-parser blokkeert.

Sommige performanceplugins kunnen daarnaast bepaalde JavaScript-code pas uitvoeren nadat er gebruikersinteractie heeft plaatsgevonden.

Dat kan effectief zijn voor bijvoorbeeld chat- en marketingscripts, maar test altijd uitvoerig:

• menu's;
• formulieren;
• cookiebanners;
• winkelwagens;
• sliders;
• tracking;
• betalingsprocessen.

Performanceoptimalisatie is niet geslaagd wanneer de website snel wordt maar functionaliteit kapotgaat.

11. Verminder render-blocking CSS en JavaScript

De browser probeert zo snel mogelijk iets op het scherm te tekenen.

Wanneer belangrijke resources eerst moeten worden gedownload en verwerkt voordat de pagina kan worden weergegeven, spreken we vaak over render-blocking resources.

Mogelijke optimalisaties zijn:

• critical CSS;
• niet-kritische CSS later laden;
• ongebruikte CSS verminderen;
• scripts met defer laden;
• zware libraries verwijderen;
• assets alleen laden waar ze nodig zijn.

Pas op met agressieve automatische instellingen zoals:

• combine all CSS;
• combine all JavaScript;
• remove unused CSS;
• delay all JavaScript.

Dit kan uitstekend werken, maar kan ook leiden tot visuele fouten of kapotte functionaliteit.

Wijzig daarom telkens één categorie en test daarna de website.

12. Optimaliseer webfonts

Lettertypen worden regelmatig vergeten tijdens WordPress-optimalisatie.

Een website kan ongemerkt:

• vijf fontfamilies;
• meerdere weights;
• italic-versies;
• iconfonts;
• en externe Google Fonts

laden.

Daardoor ontstaan extra requests en downloads.

Gebruik daarom alleen gewichten die daadwerkelijk nodig zijn.

In plaats van:

• 300;
• 400;
• 500;
• 600;
• 700;
• 800;

heb je misschien alleen 400 en 700 nodig.

Lokale fonts of externe fonts?

Fonts lokaal hosten kan meer controle geven over caching en externe verbindingen voorkomen.

Maar lokaal hosten is niet automatisch sneller. Je moet de bestanden nog steeds goed comprimeren, preloaden waar nodig en alleen noodzakelijke varianten aanbieden.

Gebruik bij voorkeur moderne WOFF2-bestanden en preload alleen fonts die daadwerkelijk vroeg in de pagina nodig zijn.

Te veel preloads kunnen namelijk ook averechts werken.

13. Gebruik een CDN wanneer dat zinvol is

Een Content Delivery Network (CDN) verspreidt statische websitebestanden over servers op verschillende locaties.

Wanneer een bezoeker een bestand opvraagt, kan dat vervolgens vanuit een infrastructuur dichter bij de bezoeker worden aangeboden.

Een CDN kan onder andere helpen bij:

• afbeeldingen;
• CSS;
• JavaScript;
• fonts;
• downloads;
• en soms volledige HTML-caching.

Daarnaast bieden moderne CDN-platforms vaak aanvullende optimalisaties zoals compressie en uitgebreide cachingregels. Cloudflare ondersteunt bijvoorbeeld Brotli-compressie voor clients die dit protocol ondersteunen.

Is een CDN altijd noodzakelijk?

Nee.

Wanneer vrijwel al je bezoekers uit Nederland en België komen en je website eveneens in een dichtbijgelegen Europees datacenter staat, kan de winst voor sommige websites beperkt zijn.

Maar een CDN wordt interessanter wanneer:

• je bezoekers wereldwijd verspreid zijn;
• je veel statische bestanden serveert;
• je veel afbeeldingen hebt;
• je extra caching wilt;
• of je origin-server wilt ontlasten.

Een CDN is bovendien geen vervanging voor slechte hosting.

Een trage backend blijft een trage backend wanneer de betreffende request niet uit de cache kan worden bediend.

14. Optimaliseer de WordPress-database

WordPress bewaart onder andere berichten, instellingen, gebruikers, reacties en metadata in een MySQL- of MariaDB-database.

Na verloop van tijd kan deze database veel informatie bevatten die niet meer actief nodig is.

Denk aan:

• post revisions;
• verlopen transients;
• oude plugininstellingen;
• spamreacties;
• prullenbakitems;
• sessiegegevens;
• logs;
• WooCommerce metadata;
• achtergebleven tabellen van verwijderde plugins.

Een grote database is niet automatisch langzaam

Een belangrijke nuance: een database van 2 GB is niet per definitie langzamer dan een database van 200 MB.

Het probleem ontstaat vooral wanneer WordPress of een plugin inefficiënte queries uitvoert op grote tabellen of wanneer bepaalde records voortdurend automatisch worden ingeladen.

Optimaliseren betekent daarom niet simpelweg "alle tabellen zo klein mogelijk maken".

Het betekent vooral:

• ongebruikte data verwijderen;
• problematische queries identificeren;
• indexering controleren;
• overmatig grote tabellen onderzoeken;
• en plugins aanpakken die structureel te veel data opslaan.

Maak altijd eerst een back-up

Database-optimalisatie kan onomkeerbaar zijn.

Maak daarom vóór het verwijderen of opschonen van records altijd een volledige databaseback-up.

15. Controleer de wp_options-tabel en autoloaded data

Een specifiek WordPress-probleem dat bij oudere of uitgebreidere websites kan voorkomen, is een te grote hoeveelheid automatisch geladen data in de wp_options-tabel.

Sommige plugins slaan instellingen op die bij vrijwel iedere request automatisch in het geheugen worden geladen.

Wanneer plugins na verwijdering grote hoeveelheden oude instellingen achterlaten, kan dat uiteindelijk onnodige overhead veroorzaken.

Dit moet je niet lukraak opschonen.

Verwijder alleen data waarvan je zeker weet:

• bij welke plugin deze hoort;
• dat de plugin niet meer wordt gebruikt;
• en dat de data niet meer nodig is.

Werk bij twijfel vanuit een stagingomgeving en houd een databaseback-up beschikbaar.

16. Gebruik persistent object caching bij dynamische websites

Page caching werkt fantastisch voor pagina's die voor meerdere bezoekers hetzelfde zijn.

Maar bij dynamische websites is volledige page caching niet altijd mogelijk.

Denk bijvoorbeeld aan:

• ingelogde gebruikers;
• WooCommerce-winkelwagens;
• persoonlijke dashboards;
• membershipwebsites;
• learning-managementsystemen;
• zoekresultaten;
• dynamische filters.

Hier kan persistent object caching extra waardevol worden.

WordPress gebruikt zijn object cache om herhaalde databaseverzoeken te verminderen. Een persistente backend zoals Redis of Memcached kan bepaalde gecachete objecten over meerdere requests beschikbaar houden.

Voor een eenvoudige brochurewebsite is dit niet altijd noodzakelijk.

Voor grotere dynamische websites kan het een behoorlijk verschil maken.

17. Houd WooCommerce apart in gedachten

Een WooCommerce-webshop optimaliseren is anders dan een eenvoudige WordPress-blog optimaliseren.

Waarom?

Omdat veel pagina's persoonlijk of dynamisch zijn.

De volgende onderdelen kun je doorgaans niet zomaar volledig cachen alsof het statische pagina's zijn:

• winkelwagen;
• checkout;
• klantaccount;
• dynamische voorraad;
• gepersonaliseerde prijzen;
• bepaalde productfilters;
• sessiegegevens.

Daarom zijn bij WooCommerce vooral belangrijk:

• snelle PHP-verwerking;
• voldoende serverresources;
• een snelle database;
• object caching;
• efficiënte plugins;
• goede productafbeeldingen;
• verstandig gebruik van AJAX;
• en correct ingestelde cache-exclusions.

Pas op met tientallen WooCommerce-extensies

WooCommerce zelf kan prima functioneren, maar webshops groeien vaak langzaam uit tot een verzameling uitbreidingen:

• betaalplugins;
• verzendplugins;
• productfilters;
• wishlist;
• reviews;
• productfeeds;
• ERP-koppelingen;
• boekhouding;
• marketingautomation;
• dynamische pricing;
• voorraadkoppelingen.

Iedere uitbreiding kan queries, cronjobs, scripts of externe API-calls toevoegen.

Bij een trage webshop is daarom pluginprofiling bijzonder belangrijk.

18. Controleer WP-Cron

WordPress gebruikt WP-Cron voor geplande taken.

Denk aan:

• geplande berichten;
• updates;
• back-ups;
• e-mails;
• WooCommerce-taken;
• synchronisaties;
• feedgeneratie;
• opruimacties.

Bij standaard WordPress wordt WP-Cron doorgaans geactiveerd door websiteverkeer.

Op drukkere of complexere websites kan het praktischer zijn om de standaard WordPress-crontrigger uit te schakelen en wp-cron.php via een echte servercron op vaste intervallen te laten uitvoeren.

Doe dit alleen wanneer je hostingomgeving dat ondersteunt en je weet hoe vaak de taken moeten draaien.

Een slecht ingestelde cronconfiguratie kan bijvoorbeeld juist:

• e-mails vertragen;
• geplande taken overslaan;
• imports uitstellen;
• of WooCommerce-processen verstoren.

19. Vermijd zware externe scripts

Niet alles wat je website langzaam maakt staat op je eigen server.

Veel websites laden scripts van externe partijen, bijvoorbeeld voor:

• Google Analytics;
• Google Tag Manager;
• Facebook/Meta;
• LinkedIn;
• Hotjar;
• chatsoftware;
• reviews;
• advertenties;
• YouTube;
• Google Maps;
• boekingssystemen;
• cookieconsent;
• CRM-systemen.

Bij externe scripts heb je minder controle over:

• responstijd;
• caching;
• bestandsgrootte;
• uptime;
• JavaScript-uitvoering.

Daarom is het verstandig om regelmatig te onderzoeken welke externe diensten werkelijk noodzakelijk zijn.

Een marketingteam voegt bijvoorbeeld gemakkelijk vijf trackingtools toe, terwijl de performancekosten daarvan nooit worden geëvalueerd.

20. Embed video's niet onnodig zwaar

Een standaard YouTube- of Vimeo-embed kan meerdere aanvullende scripts en netwerkrequests veroorzaken.

Wanneer een pagina meerdere video's bevat, kan dit snel oplopen.

Een veelgebruikte oplossing is een facade of lite embed.

Daarbij ziet de bezoeker eerst:

• een thumbnail;
• een play-knop;

en wordt de daadwerkelijke videoplayer pas geladen wanneer de gebruiker erop klikt.

Dat kan vooral op pagina's met meerdere video's veel initiële requests besparen.

21. Vermijd gigantische DOM-structuren

Pagebuilders maken het eenvoudig om complexe layouts te bouwen.

Maar ieder:

• section;
• column;
• container;
• wrapper;
• widget;
• icon;
• button;
• heading;

wordt uiteindelijk HTML.

Wanneer iedere simpele sectie uit tientallen geneste containers bestaat, ontstaat een zeer grote DOM-structuur.

Dat kost de browser extra verwerking.

Gebruik daarom waar mogelijk een eenvoudige hiërarchie.

Een knop hoeft bijvoorbeeld niet in vijf wrappers te zitten wanneer één container voldoende is.

22. Verwijder functionaliteit die niemand gebruikt

Een verrassend effectieve performance-optimalisatie is simpelweg minder doen.

Vraag bij ieder onderdeel van de website:

Heeft de bezoeker dit werkelijk nodig?

Voorbeelden:

• een slider met zes afbeeldingen;
• drie verschillende animatiebibliotheken;
• Instagramfeed in de footer;
• realtime chat op iedere pagina;
• drie trackingplatforms;
• live bezoekerscounter;
• achtergrondvideo;
• animated counters;
• social-shareknoppen voor tien netwerken.

Iedere functie heeft een technische prijs.

Een eenvoudige website is niet alleen gemakkelijker snel te maken, maar meestal ook makkelijker te onderhouden.

23. Houd WordPress, plugins en thema's bijgewerkt

Updates worden meestal vanuit beveiliging besproken, maar kunnen ook performanceverbeteringen bevatten.

WordPress, plugins en themes ontwikkelen voortdurend verder.

Gebruik daarom recente, ondersteunde software.

Controleer vóór grote updates wel:

• compatibiliteit;
• changelogs;
• back-ups;
• staging;
• kritieke websitefuncties.

Verwijder daarnaast plugins en thema's die definitief niet meer worden gebruikt.

24. Controleer redirects

Een redirect is soms noodzakelijk.

Bijvoorbeeld:

http://voorbeeld.be
→ https://voorbeeld.be

Maar onnodige redirectketens kosten extra requests.

Bijvoorbeeld:

http://voorbeeld.be
→ https://voorbeeld.be
→ https://www.voorbeeld.be
→ https://www.voorbeeld.be/nl/

Wanneer dit bij iedere bezoeker gebeurt, introduceert het extra netwerkstappen voordat de uiteindelijke pagina wordt geladen.

Probeer interne links daarom direct naar de definitieve URL te laten verwijzen.

25. Controleer 404-fouten

Wanneer pagina's voortdurend verwijzen naar bestanden die niet bestaan, moet de server nog steeds requests verwerken.

Denk aan ontbrekende:

• afbeeldingen;
• JavaScript;
• CSS;
• fonts;
• faviconbestanden.

Open de Network-tab van je browser en controleer regelmatig op 404-responses.

Een enkele ontbrekende afbeelding maakt je website niet direct extreem langzaam, maar tientallen mislukte requests zijn onnodig.

26. Activeer HTTP-compressie

HTML, CSS en JavaScript bestaan voornamelijk uit tekst en zijn daardoor goed te comprimeren.

Servers kunnen hiervoor bijvoorbeeld Gzip of Brotli gebruiken.

Hierdoor hoeft er minder data over het netwerk te worden verstuurd.

Veel moderne hostingplatformen en CDN's regelen dit automatisch. Cloudflare ondersteunt bijvoorbeeld Brotli wanneer de client daarmee overweg kan.

Controleer dus eerst wat je hostingprovider al doet voordat je nog een extra plugin installeert.

27. Gebruik HTTP/2 of HTTP/3 wanneer beschikbaar

Moderne HTTP-versies kunnen netwerkcommunicatie efficiënter afhandelen dan oudere configuraties.

Dit is normaal gesproken iets wat op server- of CDN-niveau wordt geregeld en niet in WordPress zelf.

Wanneer je hostingomgeving moderne protocollen ondersteunt, profiteert WordPress daar automatisch van zonder dat je je pagina's hoeft aan te passen.

28. Let op je LCP-afbeelding

Voor veel WordPress-websites is de hero-afbeelding bovenaan de pagina het Largest Contentful Paint-element.

Dat betekent dat deze afbeelding grote invloed kan hebben op de waargenomen laadsnelheid.

Google adviseert onder andere om een LCP-afbeelding snel vindbaar te maken voor de browser en deze niet via lazy loading uit te stellen.

Optimaliseer je hero-afbeelding daarom extra zorgvuldig:

• gebruik de juiste afmetingen;
• comprimeer het bestand;
• gebruik WebP of AVIF wanneer geschikt;
• lazy-load hem niet;
• zorg dat hij vroeg in de HTML ontdekt kan worden;
• voorkom dat JavaScript nodig is voordat de afbeelding geladen kan worden.

29. Voorkom layout shifts

Heb je weleens een pagina geopend waarbij je op een knop wilde klikken en die knop plotseling naar beneden versprong?

Dat is precies het soort probleem dat CLS probeert te meten.

Een belangrijke manier om layout shifts te voorkomen is ruimte vooraf reserveren voor afbeeldingen, advertenties en andere dynamische elementen. Google adviseert bijvoorbeeld dat templates ruimte reserveren voor lazy-loaded afbeeldingen zodat omliggende content niet plots verschuift.

Controleer daarom:

• of afbeeldingen correcte afmetingen hebben;
• of embeds ruimte reserveren;
• of cookiebanners content verschuiven;
• of advertenties plots verschijnen;
• of fonts grote layoutverschillen veroorzaken.

30. Gebruik preloading selectief

Met kun je de browser vertellen dat een bepaalde resource vroeg nodig zal zijn.

Dit kan nuttig zijn voor bijvoorbeeld:

• een belangrijk font;
• een hero-afbeelding;
• een cruciale CSS-resource.

Maar preload niet automatisch alles.

Iedere preload vertelt de browser feitelijk: dit bestand heeft hoge prioriteit.

Wanneer twintig resources allemaal hoogste prioriteit krijgen, verdwijnt het voordeel.

Gebruik preloading daarom alleen voor een klein aantal daadwerkelijk kritieke resources.

31. Minification helpt, maar verwacht geen wonderen

Met minification verwijder je bijvoorbeeld overbodige witruimte en opmerkingen uit CSS- en JavaScriptbestanden.

Daardoor worden bestanden iets kleiner.

Het kan nuttig zijn, maar op een moderne website is de impact vaak kleiner dan die van:

• goede hosting;
• caching;
• afbeeldingsoptimalisatie;
• minder JavaScript;
• minder plugins;
• betere databasequeries.

Besteed dus niet drie uur aan het besparen van 15 KB JavaScript terwijl je hero-afbeelding nog 3 MB groot is.

Optimaliseer eerst wat het grootste verschil maakt.

32. Gebruik WordPress Site Health

WordPress heeft onder Gereedschap → Sitediagnose een ingebouwde Site Health-functie.

Daarmee kan WordPress onder andere controles uitvoeren op:

• PHP-versie;
• WordPress-versie;
• databaseomgeving;
• caching;
• scheduled events;
• REST API;
• HTTPS;
• plugin- en theme-updates.

De WordPress Site Health-code bevat bovendien specifieke controles voor page caching en persistent object caching.

Het vervangt geen volledige performanceanalyse, maar het is een goed startpunt.

33. Gebruik debugging en profiling bij complexere problemen

Sommige WordPress-performanceproblemen kun je niet oplossen met PageSpeed Insights.

Bijvoorbeeld:

• één PHP-functie duurt twee seconden;
• één databasequery wordt 500 keer uitgevoerd;
• een externe API wacht drie seconden;
• een plugin veroorzaakt tientallen extra queries.

Dan heb je profiling nodig.

Ontwikkelaars gebruiken hiervoor onder andere:

• Query Monitor;
• serverlogs;
• PHP-profileringssoftware;
• Application Performance Monitoring;
• browserdeveloperstools;
• databaseanalyse.

WordPress ondersteunt daarnaast zijn eigen debugfunctionaliteit via WP_DEBUG, maar waarschuwt dat deze debugtools primair voor development- en stagingomgevingen bedoeld zijn en niet zomaar zichtbaar op een live productieomgeving moeten worden geactiveerd.

34. Maak eerst een back-up voordat je gaat optimaliseren

Performanceplugins kunnen:

• cachebestanden schrijven;
• CSS aanpassen;
• JavaScript uitstellen;
• databasegegevens verwijderen;
• .htaccess aanpassen;
• configuratiebestanden veranderen.

Maak daarom vooraf een volledige back-up van:

• bestanden;
• database;
• WordPress-configuratie.

Nog beter is testen via een stagingomgeving.

Dan kun je agressievere optimalisaties proberen zonder dat bezoekers daar direct last van hebben.

35. Verander één ding tegelijk

Dit is misschien wel de belangrijkste praktische tip uit dit hele artikel.

Stel dat je tegelijkertijd:

• een cacheplugin installeert;
• JavaScript uitstelt;
• CSS combineert;
• afbeeldingen naar WebP converteert;
• PHP bijwerkt;
• Redis activeert;
• en vijf plugins verwijdert.

De website wordt sneller, maar het contactformulier stopt met werken.

Welke wijziging veroorzaakte het probleem?

Dat is lastig te achterhalen.

Werk daarom systematisch:

meten → aanpassen → cache legen → opnieuw meten → functionaliteit testen.

Daarna ga je pas naar de volgende optimalisatie.

Welke WordPress-optimalisaties leveren meestal de meeste winst op?

Iedere website is anders, maar in de praktijk is het verstandig ongeveer in deze volgorde te kijken:

1. Hosting en serverrespons
2. Page caching
3. PHP-versie en serverconfiguratie
4. Grote afbeeldingen
5. Zware plugins
6. Thema en pagebuilder
7. JavaScript en externe scripts
8. Database
9. Object caching
10. Fonts en overige front-endoptimalisaties

Begin dus met grote problemen.

Een slecht hostingpakket vervangen kan een groter effect hebben dan tientallen micro-optimalisaties.

Een afbeelding van 5 MB verkleinen levert waarschijnlijk meer op dan obsessief een paar regels CSS verwijderen.

Praktisch stappenplan voor een trage WordPress-website

Heb je op dit moment een trage WordPress-site? Pak het dan als volgt aan.

Stap 1: Maak een volledige back-up

Zorg dat zowel bestanden als database veilig zijn opgeslagen.

Stap 2: Meet de huidige prestaties

Test de homepage én een paar belangrijke subpagina's.

Noteer minimaal:

• laadtijd;
• LCP;
• INP;
• CLS;
• TTFB;
• totale paginagrootte;
• aantal requests.

Stap 3: Controleer de hostingomgeving

Controleer:

• PHP-versie;
• resourcegebruik;
• CPU-limieten;
• RAM;
• opslag;
• eventuele errors;
• serverrespons.

Stap 4: Controleer page caching

Als publieke pagina's niet worden gecachet, is dit vaak één van de eerste optimalisaties die je moet oplossen.

Stap 5: Optimaliseer afbeeldingen

Zoek naar extreem grote afbeeldingen en converteer waar passend naar moderne formaten.

Stap 6: Analyseer plugins

Verwijder ongebruikte plugins en onderzoek zware plugins in een stagingomgeving.

Stap 7: Analyseer JavaScript en CSS

Kijk welke bestanden het renderen vertragen of onnodig op iedere pagina worden geladen.

Stap 8: Controleer externe scripts

Verwijder tracking-, marketing- en widgetscripts die niet voldoende waarde bieden.

Stap 9: Onderzoek de database

Vooral belangrijk bij oudere WordPress-sites en WooCommerce-installaties.

Stap 10: Overweeg object caching

Met name bij dynamische of database-intensieve WordPress-sites.

Stap 11: Test opnieuw

Gebruik dezelfde URL's en vergelijk de nieuwe resultaten met je oorspronkelijke metingen.

Stap 12: Test functionaliteit

Controleer minimaal:

• menu;
• contactformulieren;
• zoekfunctie;
• mobiele weergave;
• cookies;
• analytics;
• login;
• winkelwagen;
• checkout;
• betalingen.

Een snellere website heeft weinig waarde als essentiële onderdelen niet meer functioneren.

Veelgemaakte fouten bij WordPress-snelheidsoptimalisatie

Alles oplossen met één performanceplugin

Een plugin kan veel automatiseren, maar kan geen te kleine server, slecht geprogrammeerde plugin of structureel trage externe API magisch repareren.

Drie cacheplugins tegelijk installeren

Cachingfunctionaliteit kan overlappen en conflicten veroorzaken.

Alleen naar een score kijken

Een PageSpeed-score is een hulpmiddel, geen bedrijfsdoel.

De website moet vooral snel én betrouwbaar aanvoelen voor echte bezoekers.

Alle JavaScript uitstellen

Dit kan menu's, formulieren, analytics, cookiebanners en checkoutfunctionaliteit breken.

De hero-afbeelding lazy-loaden

Dit kan je LCP juist vertragen. Google adviseert expliciet om een LCP-afbeelding niet via lazy loading uit te stellen.

Databaseopschoning uitvoeren zonder back-up

Sommige gegevens zijn niet terug te halen nadat ze verwijderd zijn.

Alleen desktop testen

Een website die op een krachtige laptop en snelle glasvezelverbinding uitstekend presteert, kan op een mobiele telefoon veel langzamer zijn.

Optimaliseren zonder vooraf te meten

Zonder nulmeting weet je niet welke wijziging daadwerkelijk effect had.

Wanneer is een WordPress-website "snel genoeg"?

Er bestaat geen universele laadtijd die voor iedere website perfect is.

Een eenvoudige landingspagina is totaal anders dan een gepersonaliseerd WooCommerce-account.

Voor Core Web Vitals hanteert Google momenteel als richtwaarden voor een goede gebruikerservaring:

• LCP: maximaal 2,5 seconden;
• INP: maximaal 200 ms;
• CLS: maximaal 0,1.

Google beoordeelt dit idealiter op basis van het 75e percentiel van daadwerkelijke paginaweergaven.

Maar kijk naast deze cijfers ook naar de praktijk.

Vraag jezelf af:

• verschijnt de belangrijkste content snel?
• reageert het menu direct?
• kan de bezoeker snel scrollen?
• werkt de zoekfunctie zonder vertraging?
• reageert een productfilter snel?
• voelt de checkout soepel?
• is ook het WordPress-dashboard werkbaar?

Performance is uiteindelijk gebruikerservaring, niet alleen een technisch rapport.

Waarom blijft mijn WordPress-site langzaam na caching?

Wanneer page caching actief is en de website toch langzaam blijft, onderzoek dan onder andere:

• of de cache daadwerkelijk wordt geraakt;
• of ingelogde gebruikers van caching zijn uitgesloten;
• of een cookie caching verhindert;
• of externe scripts langzaam zijn;
• of afbeeldingen erg groot zijn;
• of JavaScript de browser blokkeert;
• of de CDN-configuratie correct is;
• of de server langzaam reageert bij cache misses.

Test daarnaast zowel een eerste bezoek als een herhaald bezoek.

Een cache kan een onderliggend serverprobleem namelijk tijdelijk verbergen.

Waarom is het WordPress-dashboard langzaam?

Een cacheplugin versnelt voornamelijk de publieke voorkant van een website.

Het dashboard is dynamisch en wordt doorgaans niet op dezelfde manier gecachet.

Een traag /wp-admin/ kan daarom wijzen op:

• zware plugins;
• trage databasequeries;
• externe API-verzoeken;
• WooCommerce-processen;
• te weinig PHP-resources;
• cronjobs;
• te grote adminqueries;
• problemen met object caching;
• serverbelasting.

Wanneer de homepage razendsnel is maar het dashboard tien seconden nodig heeft, moet je daarom vooral de backend onderzoeken.

Kan te goedkope hosting WordPress langzaam maken?

Ja, wanneer een hostingomgeving onvoldoende resources biedt voor de betreffende website kan dat de performance beperken.

Maar prijs alleen zegt weinig.

Belangrijker zijn:

• beschikbare serverresources;
• configuratie;
• caching;
• databaseprestaties;
• netwerk;
• beheer;
• en hoeveel capaciteit daadwerkelijk beschikbaar is tijdens piekmomenten.

Een eenvoudige website heeft bovendien veel minder nodig dan een WooCommerce-webshop met duizenden producten.

Is een CDN nodig voor WordPress?

Niet altijd.

Een CDN is vooral nuttig wanneer je:

• geografisch verspreide bezoekers hebt;
• veel statische assets serveert;
• veel afbeeldingen gebruikt;
• serverbelasting wilt verminderen;
• of caching dichter bij bezoekers wilt uitvoeren.

Voor een lokaal georiënteerde website op goede hosting dicht bij zijn bezoekers kan de meerwaarde kleiner zijn.

Welke cacheplugin is het beste?

Er bestaat geen cacheplugin die voor iedere WordPress-omgeving de beste keuze is.

De hostingomgeving speelt hierin een grote rol.

Sommige hosts hebben server-side caching die nauw met een specifieke plugin samenwerkt. In andere situaties kan een algemene cachingplugin geschikt zijn.

WordPress zelf noemt page caching een van de belangrijkste performanceoptimalisaties.

Vraag je hostingprovider daarom eerst welke caching al op serverniveau beschikbaar is voordat je verschillende plugins gaat combineren.

WordPress sneller maken begint bij de juiste diagnose

Een snelle WordPress-website ontstaat meestal niet door één magische instelling.

De beste resultaten komen uit een combinatie van:

• snelle hosting;
• een moderne PHP-omgeving;
• page caching;
• efficiënte plugins;
• een licht en goed gebouwd thema;
• geoptimaliseerde afbeeldingen;
• zo weinig mogelijk onnodige JavaScript;
• een gezonde database;
• object caching waar dat zinvol is;
• en regelmatige monitoring.

Belangrijker nog: optimaliseer op basis van metingen.

Installeer niet willekeurig tien performanceplugins omdat een snelheidstest een lage score laat zien. Zoek eerst uit waar de vertraging daadwerkelijk ontstaat.

Ligt het aan de server? Los de server op.

Is de hero-afbeelding 5 MB? Optimaliseer die afbeelding.

Voert een plugin honderden databasequeries uit? Onderzoek of vervang die plugin.

Wordt iedere pagina belast met tientallen marketing- en trackingscripts? Verminder die scripts.

Die aanpak levert vrijwel altijd betere resultaten op dan willekeurige instellingen wijzigen.

Hulp nodig met een trage WordPress-website?

Wanneer je WordPress-website ondanks optimalisaties langzaam blijft, kan de hostingomgeving onderdeel van het probleem zijn.

Controleer daarom of je hostingpakket voldoende capaciteit heeft voor je website en of belangrijke technologieën zoals moderne PHP-versies, caching en een snelle databaseomgeving beschikbaar zijn.

Kom je er niet uit? Neem contact op met Actiefhost. Dan kun je samen bekijken of je huidige hostingomgeving goed aansluit bij de technische eisen van je WordPress-website.

Een snelle WordPress-site begint tenslotte niet bij een perfecte PageSpeed-score, maar bij een goede technische basis.