Waarom is mijn WordPress-website traag en hoe kan ik dit oplossen?

TL;DR

Als je WordPress-website traag is, voer dan de volgende stappen in deze volgorde uit:

• Maak een back-up van de website en gebruik een stagingomgeving. Wijzigingen in de prestaties kunnen de lay-out, formulieren, het afrekenproces, cookietoestemmingstools of functies voor ingelogde gebruikers verstoren.
• Meet de prestaties voordat je iets wijzigt. Test representatieve pagina’s met PageSpeed Insights, controleer de Core Web Vitals van echte gebruikers, registreer de Time to First Byte (TTFB) en bekijk in WordPress de informatie onder Gereedschap > Sitediagnose.
• Los eerst een trage serverreactie op. Controleer of je moderne PHP- en databaseversies gebruikt, of er voldoende CPU en RAM beschikbaar zijn, of OPcache is ingeschakeld, of de hostingserver zich in de buurt van je doelgroep bevindt en of de limieten van je hostingaccount niet zijn bereikt.
• Schakel één betrouwbare volledige paginacache in. Dankzij een gecachte openbare pagina hoeft WordPress niet bij elk bezoek opnieuw te worden opgebouwd en hoeven PHP- en databasequery’s niet telkens opnieuw te worden uitgevoerd.
• Identificeer belastende plugins, themacode en databasequery’s. Test dit in de stagingomgeving door onderdelen selectief uit te schakelen en na iedere wijziging opnieuw te meten. Alleen het aantal plugins geeft geen juiste diagnose; het gaat om de hoeveelheid werk die elke plugin uitvoert.
• Optimaliseer de grootste zichtbare afbeelding. Pas de afbeelding aan de weergegeven afmetingen aan, comprimeer deze, gebruik een efficiënt bestandsformaat en pas geen lazy loading toe op de LCP-afbeelding boven de vouw.
• Verwijder of vertraag niet-essentiële CSS, JavaScript en tools van derden. Chatwidgets, trackingtools, ingesloten video’s, kaarten, advertenties en functies van paginabouwers hebben vaak een negatieve invloed op de reactiesnelheid.
• Los problemen met de database en geplande taken op. Controleer op te grote automatisch geladen opties, mislukte cron-taken en geplande WooCommerce-acties. Verwijder geen databaserijen zonder een gecontroleerde back-up en beoordeling door een deskundige.
• Test dezelfde pagina’s opnieuw en behoud de behaalde verbeteringen. Houd praktijkgegevens, conversies en fouten bij, en vertrouw niet uitsluitend op één Lighthouse-score.

Voor veel informatieve websites is dit de snelste aanpak met de grootste impact: een snellere serverreactie → volledige paginacaching → een hero-afbeelding met de juiste afmetingen → minder scripts van derden → opschoning van plugins en databasequery’s. Een WooCommerce-, leden- of meertalige website vereist zorgvuldigere cache-uitsluitingen en databasetests, omdat een groot deel van de content dynamisch is.

Waarom is WordPress zo traag?

WordPress genereert veel pagina’s dynamisch. Bij een verzoek zonder cache moet de server mogelijk de WordPress-kern, het actieve thema en de plugins laden, de database raadplegen, de pagina opbouwen en de HTML terugsturen. Vervolgens moet de browser afbeeldingen, lettertypen, CSS en JavaScript downloaden voordat de pagina correct kan worden weergegeven en soepel kan reageren. Vertraging in een van deze onderdelen kan ervoor zorgen dat de website traag aanvoelt.

De meest voorkomende oorzaken zijn:

• Hosting met onvoldoende capaciteit, een overbelaste server of een server die geografisch te ver weg staat
• Een verouderde of slecht geconfigureerde PHP- en databaseomgeving
• Geen paginacache, een gemiste cache of conflicterende cachelagen
• Trage plugins, themafuncties, externe API-aanroepen of databasequery’s
• Te grote afbeeldingen en video’s, of te veel lettertypen
• Te veel CSS, JavaScript of code van paginabouwers
• Analytics-, advertentie-, chat-, kaart-, cookietoestemmings- en andere scripts van derden
• Een overvolle wp_options-tabel of te veel automatisch geladen gegevens
• Achterstanden bij WP-Cron-taken of WooCommerce-achtergrondtaken
• Malware, botverkeer, brute-forceaanvallen of plotselinge verkeerspieken
• Niet-gecachete gepersonaliseerde pagina’s, zoals winkelwagens, afrekenpagina’s, accountpagina’s en dashboards

Begin niet met de vraag “Welke snelheidsplugin moet ik installeren?” Begin met “Welke laag is op welke pagina traag voor welke bezoeker?” Ook het WordPress-handboek voor optimalisatie behandelt hosting, configuratie, software, caching, content en databaseoptimalisatie als afzonderlijke prestatiefactoren.

Wat betekent ‘traag’ eigenlijk?

“De website voelt traag aan” kan verschillende problemen beschrijven. Stel eerst vast welk probleem zich voordoet voordat je een oplossing kiest.

Gebruik Core Web Vitals, maar interpreteer ze op de juiste manier

De huidige grenswaarden van Google voor een beoordeling als ‘goed’ zijn:

• Largest Contentful Paint (LCP): 2,5 seconden of minder
• Interaction to Next Paint (INP): minder dan 200 milliseconden
• Cumulative Layout Shift (CLS): minder dan 0,1

Beoordeel deze waarden op het 75e percentiel en afzonderlijk voor mobiele apparaten en desktops. Deze statistieken meten respectievelijk de laadsnelheid, reactiesnelheid en visuele stabiliteit. Google adviseert om goede Core Web Vitals na te streven, maar geeft ook aan dat een perfecte score geen garantie biedt op betere posities in de zoekresultaten en dat het behalen daarvan niet altijd de beste tijdsinvestering is. Relevantie en een goede algemene pagina-ervaring blijven eveneens belangrijk. Raadpleeg de richtlijnen van Google over Core Web Vitals en pagina-ervaring.

Praktijkgegevens en testgegevens beantwoorden verschillende vragen

Praktijkgegevens beschrijven ervaringen die gedurende een langere periode bij echte gebruikers zijn verzameld, op verschillende apparaten en netwerken. Deze gegevens vormen het beste bewijs om vast te stellen of gebruikers daadwerkelijk een goede ervaring hebben. Testgegevens zijn afkomstig uit een herhaalbare, gesimuleerde test waarmee je op dat moment problemen met een specifieke URL kunt onderzoeken.

Gebruik indien mogelijk PageSpeed Insights voor beide soorten gegevens. Begin met ‘Ontdek wat je echte gebruikers ervaren’ en gebruik vervolgens de Lighthouse-diagnostiek om de problemen verder te onderzoeken. Voor een nieuwe pagina of een pagina met weinig verkeer zijn mogelijk onvoldoende praktijkgegevens beschikbaar. Dat betekent niet automatisch dat de pagina snel is. De workflow voor Core Web Vitals-tools van Google legt uit hoe resultaten op URL- en herkomstniveau en voor mobiele apparaten en desktops van elkaar kunnen verschillen.

Optimaliseer niet alleen de homepage. Test minimaal:

• De homepage
• Een belangrijke diensten- of landingspagina
• Een uitgebreid artikel
• Een pagina die met je zwaarste template is opgebouwd
• Zoek- of categoriepagina’s
• Voor webshops: een productpagina, categoriepagina, winkelwagen, afrekenpagina en accountpagina
• Een ingelogd beheerscherm wanneer wp-admin traag is

Voordat je wijzigingen aanbrengt: bescherm de website

Prestatieoptimalisatie verandert de manier waarop pagina’s worden gegenereerd, gecacht en geleverd. Behandel dit daarom als ontwikkelwerk.

• Maak een volledige en herstelbare back-up van alle bestanden en de database.
• Controleer of je weet hoe je de back-up moet terugzetten. Vertrouw niet alleen op de melding dat de back-uptaak ‘succesvol’ is uitgevoerd.
• Kloon de productieomgeving naar een stagingomgeving met vergelijkbare PHP- en serverinstellingen.
• Leg een nulmeting vast voor dezelfde URL’s, apparaten en testomstandigheden.
• Wijzig steeds één categorie tegelijk en houd een wijzigingslogboek bij.
• Test na iedere belangrijke wijziging de formulieren, zoekfunctie, menu’s, cookietoestemming, inlogfunctie, functie voor het opnieuw instellen van wachtwoorden, e-commercefuncties en analytics.
• Leeg na het implementeren van wijzigingen in de code of content alle relevante caches.

Experimenteer nooit rechtstreeks op een omzetgenererende website tijdens een drukke periode met het verwijderen van databasegegevens, het vertraagde laden van JavaScript, het cachen van de afrekenpagina of het isoleren van plugins.

Een stapsgewijze diagnose van de snelheid van WordPress

Stap 1: Voer de WordPress-sitediagnose uit

Ga in het WordPress-dashboard naar Gereedschap > Sitediagnose. Bekijk zowel Status als Informatie. WordPress kan kritieke en aanbevolen verbeterpunten signaleren en informatie tonen over WordPress, thema’s, plugins, media, de server, de database en het bestandssysteem. De cachecontroles kunnen vaststellen of volledige paginacaching actief is en of een permanente objectcache geschikt is.

Let op de volgende punten:

• Verouderde versies van PHP, WordPress, het thema of plugins
• Ontbrekende paginacaching of een aanbeveling voor permanente objectcaching
• Mislukte loopback-verzoeken of achtergrondupdates
• Ontbrekende PHP-modules
• Actieve PHP-sessies
• Een waarschuwing over te veel automatisch geladen opties
• Onverwachte actieve plugins of must-use plugins
• Ongebruikelijk grote mappen of mediabibliotheken

Sitediagnose is een goed uitgangspunt, maar geen volledige analysetool. WordPress beschrijft dit scherm op de pagina Sitediagnose en licht de ingebouwde cachecontroles toe in de WordPress 6.1-notitie over cachecontroles in Sitediagnose.

Stap 2: Stel een herhaalbare nulmeting vast

Leg voor iedere test-URL de volgende gegevens vast:

• LCP, INP en CLS uit praktijkgegevens, indien beschikbaar
• LCP en Total Blocking Time uit testgegevens
• TTFB of de responstijd van het document
• Het aantal overgedragen bytes en netwerkverzoeken
• Het LCP-element
• De grootste afbeeldings-, CSS- en JavaScript-bestanden
• Of de HTML vanuit de cache is geleverd
• Zichtbare fouten en niet-werkende functies

Test zowel op mobiele apparaten als op desktops, maar geef prioriteit aan mobiel als de meeste klanten de website op een mobiel apparaat bezoeken. Voer meerdere tests uit in plaats van één resultaat als de absolute waarheid te beschouwen. De testlocatie, het netwerk, de serverbelasting, een warme of koude cache, cookies en de beschikbaarheid van diensten van derden kunnen het resultaat beïnvloeden.

De Lighthouse-documentatie van Chrome beschrijft audits als aanwijzingen voor mogelijke verbeteringen. Een goede werkwijze is: voer een nulmeting uit, breng een wijziging aan en test opnieuw. Probeer niet alle gekleurde waarschuwingen tegelijkertijd op te lossen.

Stap 3: Bepaal of de server of de browser de knelpunten veroorzaakt

Gebruik hiervoor de volgende praktische indeling:

• Trage initiële HTML/TTFB: Onderzoek omleidingen, gemiste cacheverzoeken, PHP, WordPress-code, databasequery’s, externe verzoeken, servercapaciteit en de afstand tot de server.
• De HTML wordt snel geladen, maar de pagina verschijnt laat: Onderzoek de LCP-bron, lettertypen, CSS, JavaScript en afbeeldingen.
• De pagina wordt snel weergegeven, maar interacties reageren traag: Onderzoek de uitvoering van JavaScript, een te grote DOM, sliders, menu’s, filters en code van derden.
• De lay-out verspringt: Reserveer ruimte voor media en ingesloten elementen, zorg dat lettertypen en banners stabiel worden geladen en voorkom dat nieuwe content boven bestaande content wordt ingevoegd.

TTFB vindt plaats vóór de belangrijke weergavestatistieken. Een hoge TTFB verkleint daardoor de beschikbare tijd om een goede LCP te behalen. De TTFB-optimalisatiehandleiding van Google adviseert om eerst praktijkgegevens te gebruiken, omdat omleidingen, netwerkafstand en werkelijke gebruiksomstandigheden de TTFB beïnvloeden.

Stap 4: Controleer het netwerkverloop en de responseheaders

Open in Chrome DevTools het tabblad Network, laad de pagina opnieuw en controleer het HTML-document en de belangrijkste bestanden. Let op:

• Omleidingsketens vóór de definitieve URL
• De wachttijd van het HTML-document
• Cache-Control-, Age- en leveranciersspecifieke Cache-Status-headers
• Gecomprimeerde tekstbestanden, bijvoorbeeld met Brotli of gzip
• Grote of dubbele bestanden
• Stylesheets die de weergave blokkeren
• Scripts die vóór de bruikbare content worden geladen
• Verzoeken die mislukken, een time-out veroorzaken of afkomstig zijn van veel externe domeinen

Een ingeschakelde optie in een cacheplugin bewijst niet dat pagina’s daadwerkelijk worden gecachet. Controleer de serverrespons en herhaal het verzoek. Voor ingelogde gebruikers, cookies, querystrings en dynamische pagina’s wordt de volledige paginacache vaak bewust omzeild.

Een trage WordPress-website oplossen – in volgorde van prioriteit

1. Verbeter de hosting- en PHP-capaciteit

Hosting vormt de basis van je website. Het optimaliseren van afbeeldingen lost het probleem niet op als de server regelmatig PHP-verzoeken in een wachtrij plaatst of onvoldoende geheugen heeft.

Controleer samen met je hostingprovider:

• De huidige versies van PHP, MariaDB/MySQL en WordPress
• De PHP-geheugenlimiet en de limieten voor workers en processen
• CPU-beperkingen, RAM-belasting, schijf-I/O en fouten met betrekking tot de accountcapaciteit
• De status van OPcache
• De latentie van de database en aanwijzingen voor trage databasequery’s
• De locatie van de server ten opzichte van je klanten
• De beschikbaarheid van paginacaching op serverniveau en permanente objectcaching
• Pieken in verkeer of botactiviteit op het moment dat de website trager wordt

Op het moment van deze update adviseert WordPress PHP 8.3 of hoger en MariaDB 10.11+ of MySQL 8.0+. Oudere verouderde versies kunnen mogelijk nog functioneren, maar hebben het einde van hun levensduur bereikt. Controleer altijd eerst in een stagingomgeving of het thema en de plugins compatibel zijn voordat je de PHP-versie wijzigt. Bekijk de actuele WordPress-systeemvereisten.

Upgrade je hosting wanneer metingen aantonen dat de beschikbare servercapaciteit voortdurend volledig wordt benut, de TTFB zonder cache ondanks het opschonen van de applicatie traag blijft, er onvoldoende PHP-workers beschikbaar zijn voor gelijktijdig verkeer of de limieten van de database of opslag worden bereikt. Upgrade je hosting niet uitsluitend omdat een snelheidstest een algemene waarschuwing over de serverresponstijd toont. Stel eerst de werkelijke oorzaak vast.

2. Voeg volledige paginacaching toe of herstel deze

Voor een openbare pagina die zelden verandert, levert volledige paginacaching vaak met relatief weinig werk de grootste snelheidsverbetering op. Hierbij wordt de gegenereerde HTML opgeslagen en direct geleverd, zodat WordPress, PHP en de database niet bij ieder verzoek de volledige pagina opnieuw hoeven op te bouwen. WordPress noemt caching in zijn officiële optimalisatierichtlijnen de snelste verbetering met een grote impact.

Gebruik één goed afgestemde cachingstrategie. Mogelijk biedt je hostingprovider al paginacaching aan. Het toevoegen van meerdere cacheplugins kan daarom conflicten of onduidelijk gedrag bij het legen van de cache veroorzaken.

Voer na het inschakelen van caching de volgende stappen uit:

• Leeg de cache.
• Bezoek de pagina terwijl je bent uitgelogd en gebruik hiervoor een schone browsersessie.
• Controleer de responseheaders en laad de pagina opnieuw.
• Controleer of de tweede respons vanuit de cache wordt geleverd en sneller laadt.
• Bewerk de pagina, leeg de cache opnieuw en controleer of de bijgewerkte content wordt weergegeven.
• Test formulieren, de zoekfunctie, taal- en valutakeuzemenu’s en de werking voor ingelogde gebruikers.

Sluit gepersonaliseerde of transactiegevoelige URL’s en cookies waar nodig uit van caching. Bij WooCommerce mogen de winkelwagen, afrekenpagina, accountpagina en sessieafhankelijke reacties normaal gesproken niet als één gedeelde gecachete pagina worden geleverd. Volg voor je specifieke configuratie de documentatie van je hostingprovider, cacheleverancier en WooCommerce.

3. Gebruik permanente objectcaching wanneer dit geschikt is

Een paginacache slaat volledige serverreacties op. Een objectcache slaat herbruikbare resultaten op, zoals opties en resultaten van databasequery’s, zodat WordPress minder databasequery’s hoeft uit te voeren. Dit is vooral waardevol voor dynamische websites, omgevingen voor ingelogde gebruikers, webshops, ledenwebsites en websites met veel verkeer waarbij niet iedere serverreactie volledig als pagina kan worden gecached.

Permanente objectcaching vereist compatibele serverinfrastructuur en een correcte configuratie. Alleen een verbindingsplugin installeren zonder de bijbehorende serverservice levert geen voordeel op. Vraag je hostingprovider welke oplossingen worden ondersteund. Controleer het cachehitpercentage en de werking van de applicatie. Ga er niet van uit dat objectcaching problemen met een trage externe API, zware JavaScript-code of een te grote afbeelding oplost.

4. Zoek trage plugins in plaats van alleen naar het aantal plugins te kijken

Een goed ontwikkelde plugin kan nauwelijks invloed hebben op de prestaties, terwijl één slecht functionerende plugin bij ieder verzoek trage databasequery’s, externe aanroepen of grote scripts kan toevoegen. Het aantal plugins is daarom slechts een mogelijke aanwijzing.

Voer in de stagingomgeving de volgende stappen uit:

• Open de trage URL opnieuw en leg de laadtijd vast.
• Controleer de foutenlogboeken en analyseer de prestaties van de applicatie en databasequery’s.
• Schakel niet-essentiële plugins in logische groepen uit.
• Test hetzelfde verzoek opnieuw.
• Verklein de groep totdat je het problematische onderdeel hebt gevonden.
• Werk het onderdeel bij, pas de configuratie aan, vervang het of verwijder het.
• Controleer of de vervangende oplossing geen functie dupliceert die al door een ander onderdeel wordt uitgevoerd.

Besteed extra aandacht aan beveiligingsscans, back-ups, systemen voor gerelateerde berichten, controles op gebroken links, statistiekentools, paginabouwers, zoek- en filtertools, meertalige systemen, socialmediafeeds en plugins die externe diensten aanroepen. De toegevoegde waarde van deze functies kan de extra belasting rechtvaardigen, maar zware achtergrondtaken moeten worden ingepland en belastende front-endfuncties mogen alleen worden geladen op pagina’s waar ze nodig zijn.

Schakel betalings-, abonnements-, beveiligings- of back-upsystemen niet op de productiewebsite uit om alleen een test uit te voeren. Gebruik hiervoor een stagingomgeving of een onderhoudsvenster met een vooraf door de eigenaar goedgekeurd testplan.

5. Test het thema en de paginabouwer

Thema’s en paginabouwers kunnen op de hele website CSS, animatiebibliotheken, pictogrammensets en JavaScript laden, zelfs wanneer een pagina slechts een klein deel daarvan gebruikt. Ze kunnen ook diep geneste HTML genereren, waardoor de browser meer werk moet uitvoeren voor de opmaak, lay-out en interacties.

Controleer of een eenvoudige pagina met hetzelfde thema wel snel laadt. Vergelijk in een stagingomgeving de trage pagina met een lichtgewicht template of een standaard WordPress-thema. Als het thema of de paginabouwer de oorzaak is:

• Verwijder ongebruikte widgets, sliders, effecten en algemene add-ons.
• Vermijd geneste containers die uitsluitend voor witruimte worden gebruikt.
• Laad bestanden alleen op pagina’s waarop de bijbehorende functie wordt gebruikt.
• Vervang hero-secties met achtergrondvideo’s door een geoptimaliseerde voorbeeldafbeelding en een video die de gebruiker zelf kan starten.
• Vereenvoudig megamenu’s, filters en headers met veel animaties.
• Bouw eerst de template met het meeste verkeer opnieuw voordat je een volledige herontwikkeling van de website overweegt.

Een paginabouwer is niet automatisch traag. De ontwerpkeuzes, extensies, DOM-grootte en bestanden die de paginabouwer genereert, bepalen de uiteindelijke belasting.

6. Optimaliseer afbeeldingen – vooral de LCP-afbeelding

Afbeeldingen behoren vaak tot de grootste bestanden die worden overgedragen. Voer voor iedere belangrijke afbeelding de volgende stappen uit:

• Upload de afbeelding met afmetingen die dicht bij het grootste weergegeven formaat liggen.
• Gebruik de door WordPress gegenereerde responsieve afbeeldingsformaten in plaats van een zeer groot origineel bestand in een kleine container te plaatsen.
• Kies een efficiënt bestandsformaat en een compressieniveau dat geschikt is voor de afbeelding.
• Gebruik beschrijvende alt-tekst voor afbeeldingen die inhoudelijke waarde hebben.
• Pas lazy loading toe op afbeeldingen onder de vouw.
• Laad de LCP-afbeelding boven de vouw direct en zorg dat deze in de initiële HTML kan worden gevonden.
• Voeg de hero-afbeelding niet pas via vertraagde JavaScript of als CSS-achtergrond toe wanneer een normale responsieve afbeelding geschikt is.
• Genereer na het wijzigen van de ingestelde afbeeldingsformaten de thumbnails opnieuw. Maak vooraf een back-up.

Richt je niet uitsluitend op de bestandsextensie. Een onnodig groot AVIF- of WebP-bestand kan nog steeds traag laden. De visuele kwaliteit, afmetingen, compressie, responsiviteitsrcset en laadprioriteit zijn allemaal belangrijk. Google legt in zijn richtlijnen voor afbeeldingsformaten uit dat de afbeeldingsgrootte invloed heeft op LCP. In het artikel De prestatie-effecten van te veel lazy loading waarschuwt Google bovendien dat overmatig gebruik van lazy loading de content boven de vouw kan vertragen.

7. Verminder CSS en JavaScript zorgvuldig

Minificatie verwijdert onnodige tekens, maar geen overbodige functies. Het combineren van alle bestanden levert bij HTTP/2 of HTTP/3 niet automatisch betere prestaties op en kan juist één groot bestand creëren. Geef prioriteit aan het verwijderen van overbodige code en het voorwaardelijk laden van bestanden.

Voor CSS:

• Verwijder stijlen van uitgeschakelde functies en ongebruikte onderdelen.
• Plaats alleen CSS die echt essentieel is voor de content boven de vouw rechtstreeks in de HTML, indien je technische omgeving dit ondersteunt.
• Laad de resterende CSS waar mogelijk zonder dat deze de weergave van bruikbare content blokkeert.
• Vermijd grote frameworks of stylesheets van paginabouwers op pagina’s die deze niet gebruiken.

Voor JavaScript:

• Verwijder dubbele bibliotheken en trackingtools.
• Gebruik defer of laad scripts pas na een gebruikersinteractie wanneer de functionaliteit dit toelaat.
• Splits de code per functie of template.
• Houd eventhandlers compact en voorkom langdurige taken in de hoofdthread.
• Verminder de DOM-grootte en voorkom onnodige, herhaalde lay-outberekeningen.
• Test menu’s, formulieren, analytics, cookietoestemming en e-commercefuncties na iedere regel voor vertraagd laden of defer.

Stel essentiële handhaving van cookietoestemming, fraudebeveiliging, betalingsfunctionaliteit of toegankelijkheidsfuncties niet uit om uitsluitend een betere score te behalen. Prestaties zijn slechts één van de verschillende vereisten waaraan een website moet voldoen.

8. Beheer scripts van derden

Scripts van derden omvatten onder andere analytics, tagmanagers, advertenties, livechat, heatmaps, socialmediawidgets, reviews, kaarten, videospelers en A/B-tests. Ze kunnen extra downloads en CPU-belasting veroorzaken, privacyverplichtingen met zich meebrengen en de website afhankelijk maken van de beschikbaarheid van een externe aanbieder. De Google-richtlijnen voor JavaScript van derden adviseren om regelmatig overbodige tools te controleren en overlap tussen verschillende leveranciers te voorkomen.

Maak een overzicht van alle leveranciers en noteer voor iedere leverancier wie verantwoordelijk is en welk doel de tool heeft. Voer vervolgens de volgende stappen uit:

• Verwijder scripts waarvoor geen actieve verantwoordelijke of duidelijk zakelijk doel bestaat.
• Gebruik niet meerdere tools voor dezelfde functie.
• Laad chatfuncties, kaarten en video’s waar mogelijk pas na een klik of wanneer ze bijna zichtbaar worden in het scherm.
• Beperk scripts tot de templates of landen waarvoor ze noodzakelijk zijn.
• Stel voor marketingtags een limiet in voor het aantal bytes, netwerkverzoeken en de belasting van de hoofdthread.
• Controleer na iedere wijziging of conversie- en toestemmingsgegevens nog correct worden geregistreerd.

9. Optimaliseer lettertypen zonder afbreuk te doen aan de huisstijl

Lettertypen kunnen de weergave van tekst vertragen, lay-outverschuivingen veroorzaken en extra netwerkverzoeken toevoegen. Gebruik daarom minder lettertypefamilies, gewichten en stijlen. Kies bij voorkeur moderne, gecomprimeerde lettertypebestanden. Beperk de tekenset alleen wanneer de licentievoorwaarden en benodigde taalondersteuning dit toestaan. Preload uitsluitend het lettertypebestand dat nodig is voor belangrijke tekst boven de vouw. Stel een geschikte font-display-strategie in en kies terugvallettertypen met vergelijkbare afmetingen om verschuivingen zoveel mogelijk te beperken.

Preload niet alle lettertypen. Ieder vooraf geladen lettertype concurreert met de hero-afbeelding, CSS en andere essentiële bronnen.

10. Configureer browsercaching, compressie en een CDN

Met langdurige browsercaching kunnen terugkerende bezoekers eerder geladen versies van afbeeldingen, lettertypen, CSS en JavaScript opnieuw gebruiken. Tekstcompressie verkleint de overdrachtsgrootte van HTML-, CSS-, JavaScript-, SVG- en JSON-bestanden. Controleer via de responseheaders of beide functies daadwerkelijk actief zijn en vertrouw niet alleen op een instelling in het dashboard.

Een CDN kan statische bestanden en soms ook gecachte HTML dichter bij gebruikers aanbieden en zo de belasting van de oorspronkelijke server verminderen. Dit is vooral nuttig wanneer bezoekers geografisch verspreid zijn. Een CDN kan trage niet-gecachete PHP-processen, inefficiënte databasequery’s of overmatige JavaScript-belasting in de browser niet oplossen. Het verkort alleen de levertijd van content die kan worden gecached.

Test na wijzigingen aan het CDN of de caching: het legen van de cache, HTTPS, omleidingen, cookies, cache-uitsluitingen voor ingelogde gebruikers, afbeeldings-URL’s en cachevarianten per apparaat, taal of valuta. Het WordPress-handboek over hostingprestaties behandelt paginacaching, objectcaching, browsercaching en fragmentcaching als afzonderlijke cachelagen.

11. Ruim de database selectief op

Het ‘opschonen’ van de database is geen vervanging voor een goede diagnose. Normale berichtrevisies en transients vormen niet automatisch een ernstig probleem. Veelvoorkomende problemen zijn grote automatisch geladen opties, achtergebleven gegevens van plugins, inefficiënte databasequery’s, ontbrekende indexen in aangepaste tabellen en taakwachtrijen die zich voortdurend opnieuw vullen.

Begin bij Gereedschap > Sitediagnose. WordPress 6.6 introduceerde een controle voor automatisch geladen opties, met een standaard kritieke grenswaarde van 800.000 bytes. Het huidige WordPress-handboek voor optimalisatie adviseert om de automatisch geladen opties onder ongeveer 800 KB te houden. Dit is een diagnostische grenswaarde en geen toestemming om gegevens te verwijderen. Bekijk de prestatieverbeteringen in WordPress 6.6.

Veilige werkwijze:

• Maak een back-up van de database en test of deze correct kan worden teruggezet.
• Identificeer de grootste automatisch geladen opties en bepaal bij welk onderdeel iedere optie hoort.
• Vraag de leverancier van de plugin of het thema of de gegevens nog actueel en noodzakelijk zijn en veilig kunnen worden gewijzigd.
• Verwijder achtergebleven plugingegevens via de ondersteunde verwijderings- of onderhoudsfuncties.
• Optimaliseer tabellen alleen met een proces dat door de hostingprovider of database wordt ondersteund.
• Meet daarna opnieuw de uitvoeringstijd van databasequery’s en de responstijd van de pagina.

Voer geen onbekende SQL-code uit op de productiewebsite. Namen van opties zijn niet altijd duidelijk en het verwijderen ervan kan licenties, instellingen, widgets, het afrekenproces, geplande taken of de volledige website beschadigen.

12. Controleer WP-Cron en achtergrondtaken

WP-Cron controleert bij websitebezoeken of er geplande taken moeten worden uitgevoerd. Normaal gesproken is de extra belasting hiervan beperkt. Problemen ontstaan wanneer een plugin te veel taken inplant, taken herhaaldelijk mislukken of een wachtrij sneller groeit dan deze kan worden verwerkt.

Controleer op vertraagde publicaties, overlappende back-uptaken, import- en exporttaken, e-mailwachtrijen, beveiligingsscans en herhaaldelijk mislukte taken. Op websites met veel verkeer of een belangrijke operationele functie kan een echte server-cron WordPress volgens een vast schema activeren, maar pas nadat de servertaak correct is ingesteld en gecontroleerd. In de PHP-optimalisatiedocumentatie benadrukt WordPress dat het vervangen van WP-Cron optioneel en niet verplicht is.

Stel DISABLE_WP_CRON Nooit in voordat er een werkende vervanging beschikbaar is. Anders kunnen geplande berichten, e-mails, updates, abonnementen en andere taken stoppen.

13. Werk de software bij, maar test eerst de compatibiliteit

Gebruik ondersteunde versies van WordPress, het thema, de plugins, PHP en de database. Updates kunnen prestatie- en beveiligingsverbeteringen bevatten. Gebruik een stagingomgeving, lees de compatibiliteitsinformatie, maak een back-up, voer updates in gecontroleerde groepen uit en test alles opnieuw. Alleen updates uitvoeren is geen volledige prestatiestrategie, maar een verouderde technische omgeving maakt het stellen van een diagnose moeilijker en kan bekende inefficiënties in stand houden.

14. Onderzoek afwijkingen in verkeer en beveiliging

Als de website normaal gesproken snel is maar plotseling vertraagt, controleer dan of het incident samenvalt met:

• Verkeer van zoekmachines of AI-crawlers
• Kwaadaardige inlogpogingen of XML-RPC-verzoeken
• Hotlinking van afbeeldingen
• Scraping of herhaalde controles van voorraadgegevens en API’s
• Een campagne of plotseling veel verkeer via een virale verwijzing
• Een back-up, beveiligingsscan, importtaak of feedtaak
• Databasevergrendelingen, opslaglimieten of storingen bij de hostingprovider

Gebruik server- en CDN-logboeken, monitoringtools en gegevens van je hostingprovider. Pas snelheidslimieten of firewallregels zorgvuldig toe, zodat echte klanten, zoekmachinecrawlers, betalingswebhooks en uptime-monitoringdiensten correct blijven functioneren.

Een traag WordPress-beheerdashboard oplossen

Volledige paginacaching maakt ingelogde wp-admin-schermen doorgaans niet sneller. Een traag beheerdashboard wordt vaak veroorzaakt door plugincode, databasequery’s, externe verzoeken voor licentiecontroles, nieuws of API’s, te veel automatisch geladen opties, wachtrijen met achtergrondtaken of onvoldoende PHP-workers.

Volg deze stappen:

• Controleer Sitediagnose, foutenlogboeken en de limieten van PHP-resources.
• Noteer welke beheerschermen traag zijn. Het dashboard, de berichteditor, het besteloverzicht en de pluginschermen kunnen verschillende oorzaken hebben.
• Analyseer het trage verzoek in een stagingomgeving.
• Test de plugins en het thema afzonderlijk.
• Controleer de automatisch geladen opties en beoordeel of objectcaching geschikt is.
• Controleer WP-Cron of de geplande WooCommerce-acties op achterstanden.
• Onderzoek externe HTTP-verzoeken die een time-out veroorzaken.
• Controleer of browserextensies de editor niet beïnvloeden.

Het verhogen van de PHP-geheugenlimiet kan fouten door een tekort aan geheugen voorkomen, maar lost inefficiënte processen niet op. Beschouw extra geheugen als aanvullende capaciteit en niet als een universele oplossing voor snelheidsproblemen.

Specifieke snelheidsoptimalisaties voor WooCommerce

WooCommerce-pagina’s combineren openbare content met sessies, voorraadgegevens, belastingen, verzending, betalingen, bestellingen en achtergrondprocessen. Test na iedere optimalisatie elke stap van het aankoopproces.

Cache de productcatalogus, maar geen klantspecifieke transacties

Cache geschikte product- en categoriepagina’s, maar sluit de winkelwagen, afrekenpagina, accountpagina en sessiegebonden reacties uit volgens de gedocumenteerde configuratie van je hostingprovider of cacheoplossing. Controleer vervolgens de functies voor toevoegen aan de winkelwagen, kortingscodes, belastingen, verzending, valuta, voorraad en betalingscallbacks.

Controleer extensies en externe diensten

Betaalgateways, belastingdiensten, verzendtarieven, productaanbevelingen, zoek- en filtertools en abonnementen kunnen vertragingen in de database of het netwerk veroorzaken. Meet iedere stap afzonderlijk. Een trage afrekenpagina kan wachten op een externe dienst, zelfs wanneer de rest van WordPress snel werkt.

Controleer geplande acties

Ga naar WooCommerce > Status > Geplande acties. Controleer of het aantal wachtende, mislukte of door een time-out afgebroken taken blijft toenemen. Deze taken kunnen betrekking hebben op bestelmeldingen, webhooks, abonnementen en processen van extensies. Los het onderdeel op dat de fouten veroorzaakt, in plaats van de wachtrij steeds opnieuw te verwijderen. WooCommerce legt deze werkwijze uit in de documentatie over geplande acties.

Evalueer High-Performance Order Storage

High-Performance Order Storage (HPOS) van WooCommerce gebruikt speciale bestellingstabellen en indexen in plaats van het verouderde model met posts en postmeta. Sinds WooCommerce 8.2 is HPOS standaard ingeschakeld voor nieuwe installaties. Bestaande webshops kunnen migreren nadat de compatibiliteit van extensies is gecontroleerd en de gegevens zijn gesynchroniseerd. Test de back-up, compatibiliteit en terugzetmogelijkheden in een stagingomgeving voordat je de opslagmethode wijzigt. Bekijk de officiële HPOS-documentatie.

De WooCommerce-handleiding voor het oplossen van een trage website adviseert eerst de werkelijke oorzaak vast te stellen en daarna caching en het CDN, de hosting, afbeeldingen, minificatie, het beschikbare geheugen, extensies en het thema te controleren.

Zo verbeter je iedere Core Web Vital in WordPress

Een LCP-probleem wordt niet altijd door een afbeelding veroorzaakt. LCP omvat ook de serverresponstijd en de tijd die nodig is om de betreffende bron te ontdekken. Een INP-probleem kan niet uitsluitend aan de hand van de laadtijd worden vastgesteld, omdat INP de interacties tijdens het volledige bezoek meet. CLS kan ook na de eerste laboratoriumtest optreden. Daarom zijn praktijkgegevens en monitoring van echte gebruikers belangrijk.

Wat je niet moet doen

• Installeer niet meerdere cache- of minificatieplugins die allemaal dezelfde bestanden aanpassen.
• Verwijder niet de volledige wp_options-tabel, transients of onbekende databaserijen.
• Pas niet standaard lazy loading toe op de belangrijkste afbeelding boven de vouw.
• Cache de winkelwagen, afrekenpagina, accountpagina of gepersonaliseerde pagina’s niet als openbaar gedeelde HTML.
• Stel niet ieder script uit zonder formulieren, menu’s, cookietoestemming, analytics en betalingen te testen.
• Stel DISABLE_WP_CRON niet in voordat een werkende vervanging is gecontroleerd.
• Streef niet naar een Lighthouse-score van 100 terwijl klanten problemen ondervinden met niet-werkende functies.
• Optimaliseer niet alleen de reeds gecachete desktophomepage.
• Ga er niet van uit dat een CDN problemen met de oorspronkelijke server, PHP, databasequery’s of JavaScript oplost.
• Voer niet meerdere wijzigingen tegelijkertijd door, omdat je dan niet kunt bepalen welke wijziging een verbetering of probleem heeft veroorzaakt.

Een praktisch prestatiebudget

Een prestatiebudget voorkomt dat de prestaties geleidelijk achteruitgaan. Kies grenswaarden die passen bij je ontwerp en klanten en pas deze vervolgens toe op belangrijke templates. Bijvoorbeeld:

• Meet goede Core Web Vitals op het 75e percentiel voor zowel mobiele apparaten als desktops.
• Stel voor je doelregio’s een maximale TTFB vast voor zowel niet-gecachete als gecachete pagina’s.
• Beperk de bestandsgrootte van afbeeldingen boven de vouw en het totale paginagewicht.
• Beperk de hoeveelheid overgedragen JavaScript en de uitvoeringstijd in de hoofdthread.
• Beperk het aantal lettertypefamilies, gewichten en vooraf geladen lettertypen.
• Wijs voor iedere tag van derden een verantwoordelijke aan en stel een verval- of beoordelingsdatum vast.
• Blokkeer releases die het afrekenproces, leadformulieren of vastgestelde prestatiedrempels verstoren.

De exacte limiet in bytes is minder belangrijk dan een gemeten nulmeting, een afgesproken bovengrens en duidelijke verantwoordelijkheid wanneer een nieuwe functie deze grens overschrijdt.

Een 30-dagenplan om de snelheid van WordPress te verbeteren

Dag 1–3: Meten en beveiligen

• Maak back-ups en een stagingomgeving en controleer of deze goed werken.
• Selecteer representatieve URL’s en bedrijfskritische processen.
• Leg praktijk- en testgegevens, TTFB, paginagrootte, netwerkverzoeken en fouten vast.
• Exporteer de informatie uit Sitediagnose en verzamel gegevens over het gebruik van hostingresources.

Dag 4–7: Optimaliseer de oorspronkelijke server

• Controleer of ondersteunde versies van PHP en de database worden gebruikt en of OPcache actief is.
• Los problemen met resourcelimieten, foutenlogboeken en omleidingen op.
• Configureer en controleer één laag voor volledige paginacaching.
• Voeg alleen permanente objectcaching toe wanneer dit voor de website en hostingomgeving zinvol is.

Week 2: Verminder het paginagewicht

• Optimaliseer de LCP-afbeelding en andere grote afbeeldingen.
• Verwijder ongebruikte plugins, widgets, lettertypen en tools van derden.
• Verminder CSS die de weergave blokkeert en verwijder onnodige JavaScript.
• Test dezelfde pagina’s en functionele processen opnieuw.

Week 3: Optimaliseer de applicatieprocessen

• Analyseer de plugins, het thema en de databasequery’s in een stagingomgeving.
• Los problemen met te grote automatisch geladen opties op in overleg met de verantwoordelijken voor de betreffende onderdelen.
• Herstel mislukte cron- en achtergrondtaken.
• Controleer bij WooCommerce de cache-uitsluitingen, geplande acties en compatibiliteit met HPOS.

Week 4: Valideer de verbeteringen en voorkom terugval

• Test op mobiele apparaten en desktops, als uitgelogde en ingelogde gebruiker en vanuit de doelregio’s.
• Controleer formulieren, de zoekfunctie, cookietoestemming, analytics en het afrekenproces.
• Vergelijk de prestaties en conversieresultaten met de nulmeting.
• Stel prestatiebudgetten, monitoring, verantwoordelijken en een maandelijkse controle vast.

Zo toon je aan dat de verbeteringen werken

Gebruik drie soorten bewijs:

• Technisch: De responstijd van gecachete en niet-gecachete pagina’s, Core Web Vitals, paginagrootte, netwerkverzoeken, fouten en het gebruik van serverbronnen.
• Gebruikerservaring: Prestaties bij echte gebruikers per apparaat, template en regio, klachten bij de klantenservice en mislukte interacties.
• Bedrijfsresultaten: Het conversiepercentage, voltooide afrekenprocessen, ingevulde leadformulieren, bouncepercentage, betrokkenheid en omzet, waarbij rekening wordt gehouden met campagnes, seizoensinvloeden en de samenstelling van het verkeer.

Een testscore kan verbeteren zonder dat echte gebruikers verschil merken. Ook kan een vertraagd analyticsscript ervoor zorgen dat conversies niet meer correct worden geregistreerd. Controleer daarom eerst of de monitoring en metingen betrouwbaar werken voordat je concludeert dat de optimalisatie succesvol is.

Veelgestelde vragen

Je volgende stap

Kies vijf URL’s die representatief zijn voor omzet en gebruikersintentie: de homepage, een belangrijke landingspagina, een contentpagina, een pagina met een zware template en een conversiepagina. Doorloop voor iedere URL de volgende stappen:

• Wat ervaren echte gebruikers op mobiele apparaten en desktops?
• Wordt de eerste HTML traag geladen en is gecontroleerd of een herhaald openbaar verzoek daadwerkelijk vanuit de cache wordt geleverd?
• Wat is het LCP-element en heeft het de juiste afmetingen, kan de browser het snel ontdekken en krijgt het de juiste laadprioriteit?
• Welk CSS-bestand, JavaScript-bestand, lettertype of verzoek van derden veroorzaakt de meeste vermijdbare belasting?
• Toont Sitediagnose of een prestatieanalyse een probleem met een plugin, databasequery, automatisch geladen optie of cron-taak?
• Kan de oplossing in een stagingomgeving worden getest en indien nodig worden teruggedraaid?
• Zijn na de implementatie dezelfde URL, functie en bedrijfsresultaten verbeterd?

Doorloop deze cyclus van meten, testen en controleren voordat je een duurder hostingpakket aanschaft of nog een optimalisatieplugin toevoegt. Een klein aantal gemeten en veilig doorgevoerde verbeteringen levert doorgaans betere resultaten op dan een groot pakket niet-gecontroleerde instellingen.