Waarom is mijn WordPress-site traag? Oorzaken en oplossingen

Een trage WordPress-site komt bijna altijd neer op een van deze vier dingen: een server die te lang doet over het opbouwen van elke pagina, ontbrekende paginacaching, te veel werk door plug-ins en het thema, of zware afbeeldingen en scripts in de browser. De oplossing: zoek uit welke daarvan jou echt parten speelt en werk ze dan op volgorde af, te beginnen bij de serverrespons en eindigend met de afwerking aan de front-end.

Meet voordat je iets verandert

Gokken is de duurste manier om WordPress sneller te maken. Voordat je plug-ins uitschakelt of van host wisselt, leg je een nulmeting vast waarmee je later kunt vergelijken.

• Gegevens van echte gebruikers: haal je URL door corewebvitals.page. Heeft je site genoeg verkeer, dan zie je velddata van echte Chrome-gebruikers voor LCP, INP en CLS. Dat is wat Google gebruikt voor paginagebruik.
• Labdata: het Lighthouse-gedeelte daaronder is één gesimuleerde laadbeurt. Handig om oorzaken te vinden, maar de score verschilt van run tot run.
• Serverrespons: controleer hoe lang de HTML zelf erover doet.

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

Voer dit een paar keer uit, en voor verschillende soorten pagina's: de homepage, een blogpost, een categoriearchief. Duurt de eerste byte al langer dan ongeveer een seconde, dan zit het probleem aan de serverkant en lost geen enkele afbeeldingsplug-in het op. web.dev noemt een TTFB van 0,8 seconden of minder (Engelstalig) als vuistregel.

Wil je dieper ingaan op labdata versus velddata en op een eerlijke voor-en-natest, lees dan websitesnelheid goed meten.

Hosting en responstijd van de server

Elk ongecachet WordPress-verzoek start PHP op, laadt de WordPress-core, alle actieve plug-ins en het thema, en voert tientallen tot honderden databasequery's uit. Hoe snel dat gaat, hangt sterk af van de server.

Tekenen dat je hosting de bottleneck is

• De TTFB is hoog, zelfs op eenvoudige pagina's met weinig inhoud.
• De site wordt merkbaar trager op drukke momenten of tijdens een nieuwsbriefverzending.
• Het beheer in wp-admin reageert traag, hoewel dat niets met front-end-bestanden te maken heeft.
• Het dashboard van je host laat zien dat je tegen CPU- of geheugenlimieten aanloopt.

Wat je kunt doen

• Werk PHP bij. Nieuwere PHP-versies zijn over het algemeen sneller en krijgen nog beveiligingsupdates. Kijk welke versie je host aanbiedt en test je site op de nieuwste versie die je plug-ins ondersteunen.
• Voeg een persistente object cache toe. Redis of Memcached houdt de resultaten van herhaalde databasequery's in het geheugen. Veel managed hosts bieden dat aan als schakelaar; het helpt het meest op dynamische pagina's en in wp-admin.
• Upgrade je pakket of stap over naar een andere host als de server simpelweg te krap is voor je verkeer. Soms is dat echt het juiste antwoord, en geen enkele hoeveelheid plug-intuning vervangt voldoende CPU.

Is de responstijd je grootste probleem, dan behandelt de gids over TTFB verlagen stap voor stap de oplossingen op de server, in de applicatie en aan de edge.

Paginacaching

Paginacaching is voor de meeste WordPress-sites de grootste hefboom. In plaats van dezelfde pagina voor elke bezoeker opnieuw met PHP en MySQL op te bouwen, wordt een gecachete kopie van de kant-en-klare HTML direct geleverd. Het WordPress-handboek voor ontwikkelaars geeft een goed overzicht van de verschillende cachelagen (Engelstalig).

Je hebt drie gangbare opties:

Deze lagen kunnen samenwerken. Waar het om gaat: anonieme bezoekers krijgen gecachete HTML, en pagina's die persoonlijk moeten blijven, worden uitgesloten.

Wat niet gecachet mag worden

• Ingelogde gebruikers en wp-admin (WordPress zet logincookies, en de meeste caches slaan die verzoeken over).
• Voorbeelden van reacties en met een wachtwoord beveiligde berichten.
• Winkelwagen, checkout en accountpagina's als je een webshop hebt. De gids over WooCommerce sneller maken behandelt die regels uitgebreid.

Controleer of de caching werkt

Kijk naar de response-headers. De meeste caches voegen een header toe die een hit of een miss laat zien:

curl -sI https://example.com/ | grep -i -E "cache|age"

Toont elk verzoek een miss, of is er helemaal geen cacheheader, dan omzeilt iets de cache. Bekende boosdoeners zijn een plug-in die bij elk bezoek een cookie zet, Cache-Control: no-cache-headers van een beveiligingsplug-in, of querystrings uit trackinglinks.

Plug-ins en thema's

Het aantal plug-ins zegt minder dan wat ze doen. Eén slecht gebouwde plug-in kan meer belasting veroorzaken dan twintig kleine.

Vind de dure plug-ins

• Installeer Query Monitor op een stagingkopie. Die laat per plug-in de databasequery's, trage query's, HTTP API-aanroepen en hooks zien, bij elke laadbeurt.
• Zoek naar plug-ins die bij het laden van de pagina externe HTTP-verzoeken doen (licentiecontroles, social tellers, externe fonts). Die houden de pagina op terwijl ze op een andere server wachten.
• Schakel verdachte plug-ins één voor één uit op staging en meet de TTFB opnieuw. Doe dit niet in een live webshop.

Veelvoorkomende patronen die sites vertragen

• Paginabouwers die hun volledige CSS en JavaScript op elke pagina laden, ook waar ze niet gebruikt worden.
• Sliders, pop-ups en chatwidgets die boven de vouw meerdere scripts inladen.
• Plug-ins voor gerelateerde berichten en statistieken die bij elk verzoek zware query's draaien.
• Meerdere plug-ins die hetzelfde doen (twee SEO-plug-ins, twee cachingplug-ins).

Een lichter thema helpt vaak meer dan welke optimalisatieplug-in ook. Levert je thema een groot framework mee dat je nauwelijks gebruikt, dan draait die code toch op elke pagina.

Afbeeldingen en media

Afbeeldingen zijn meestal het zwaarste onderdeel van een WordPress-pagina, en de hero-afbeelding is vaak het element dat je LCP bepaalt.

• Upload verstandige formaten. Een foto van 4.000 pixels uit je telefoon hoort niet in een contentkolom van 800 pixels. WordPress maakt kleinere formaten aan en gebruikt srcset, maar alleen als het thema ze goed uitvoert.
• Gebruik moderne formaten. WebP en AVIF zijn bij vergelijkbare kwaliteit veel kleiner dan JPEG en PNG.
• Lazy-load onder de vouw, niet erboven. WordPress voegt automatisch loading="lazy" toe, maar een hero-afbeelding die lazy laadt, vertraagt de LCP. Zorg dat de hoofdafbeelding meteen laadt.
• Geef breedte en hoogte op, zodat de browser ruimte reserveert en de lay-out niet verspringt (CLS).

De gids over afbeeldingen optimaliseren voor het web gaat dieper in op formaten, afmetingen en laadstrategie.

Database en achtergrondtaken

Oudere WordPress-sites verzamelen rommel die elk ongecachet verzoek vertraagt.

• Autoloaded options: plug-ins slaan instellingen op in wp_options, en items die op autoload staan, worden bij elk verzoek ingelezen. Verwijderde plug-ins laten vaak grote items achter. Sitediagnose (Site Health) waarschuwt in recente WordPress-versies als de autoloaded data te groot wordt.
• Verlopen transients en berichtrevisies blazen tabellen op. Ruim ze op met een onderhoudsplug-in of WP-CLI, na een back-up.
• WP-Cron voert geplande taken standaard uit bij gewone paginaweergaven. Op drukke sites schakel je dat uit in wp-config.php en start je het in plaats daarvan met een echte cronjob op de server:

define( 'DISABLE_WP_CRON', true );

• Heartbeat API: open editortabbladen sturen met vaste tussenpozen verzoeken naar admin-ajax.php. Op zwakke hosting telt dat op; met sommige performanceplug-ins kun je de frequentie verlagen.

Pak het in de juiste volgorde aan

In de juiste volgorde werken scheelt tijd, want de eerste stappen maken latere vaak overbodig.

1. Meet de TTFB en Core Web Vitals van je belangrijkste soorten pagina's.
2. Verbeter de serverrespons: PHP-versie, object cache, voldoende resources.
3. Zet paginacaching aan voor anonieme bezoekers en controleer de cacheheaders.
4. Verwijder of vervang zware plug-ins en beperk wat het thema inlaadt.
5. Optimaliseer afbeeldingen: formaat, bestandstype, geen lazy loading op de hero.
6. Ruim de database op en verplaats WP-Cron naar een servercron.
7. Meet opnieuw met dezelfde tools en pagina's, en vergelijk.

Komen je bezoekers uit meerdere landen, dan voegt ook de afstand tot je server bij elk verzoek latency toe, zelfs als de caching op de origin goed is. Daar helpt een edge-cache.

Zo helpt fast.site je

fast.site zit vóór je bestaande WordPress-hosting. Je houdt je host en je site; je voegt je domein toe in het dashboard en laat je nameservers naar fast.site wijzen. Daarna beheert fast.site je DNS, dus zorg dat alle bestaande records, inclusief MX-records voor e-mail, in de DNS-zone van fast.site staan.

Anonieme paginaweergaven worden dan door Fast Edge Cache™ geleverd vanaf edge-servers dicht bij je bezoekers, in de regio's die bij je abonnement horen. Een cache HIT bereikt je origin nooit, en dat ontlast de server op drukke momenten. Ingelogde sessies en wp-admin horen de cache te omzeilen, en de response-header fs-cache toont HIT, MISS of BYPASS, zodat je elke pagina zelf kunt controleren. Na het publiceren kun je losse URL's purgen in het dashboard of via de API, en een cache warmer houdt belangrijke pagina's warm.

Aan de front-end kan fast.site JPEG en PNG direct naar WebP omzetten (AVIF afhankelijk van je abonnement) en optioneel de hero-afbeelding preloaden en ontbrekende afmetingen aan afbeeldingen toevoegen. Details vind je op de WordPress-pagina en in de cachingdocumentatie.

Meet je site voor en na met dezelfde tests. Je kunt het uitproberen met een gratis proefperiode van 7 dagen, zonder creditcard.

Veelgestelde vragen

Waarom is mijn WordPress-site alleen traag als ik ben ingelogd?

De meeste paginacaches slaan ingelogde gebruikers over, dus elke pagina die jij bekijkt, wordt opnieuw door PHP opgebouwd. De adminbalk en editorscripts zorgen voor extra werk. Test in een privévenster om te zien wat bezoekers echt krijgen.

Maken te veel plug-ins WordPress traag?

Het aantal zegt minder dan wat elke plug-in doet. Een paar zware plug-ins die bij elk verzoek trage query's draaien of externe diensten aanroepen, kosten meer dan veel kleine. Gebruik Query Monitor op een stagingsite om de dure te vinden.

Is een cachingplug-in genoeg?

Voor een kleine site met lokale bezoekers is een goed ingestelde cachingplug-in op fatsoenlijke hosting vaak genoeg. Zijn je bezoekers over meerdere regio's verspreid, of heb je te maken met verkeerspieken, dan wint een edge-cache vóór de server afstand terug en ontlast hij de origin.

Waarom is het beheer van mijn WordPress-site zo traag?

wp-admin wordt nooit als pagina gecachet, dus daar zie je de pure snelheid van je server, plug-ins en database. Trage beheerpagina's wijzen meestal op te krappe hosting, een ontbrekende object cache, grote autoloaded options of een plug-in die bij elk adminverzoek zwaar werk doet.