WordPress site traag Core Web Vitals fix: audit in 90 min

WordPress site traag core web vitals fix is de vraag die ik krijg zodra Google Search Console een “Slecht” of “Verbeteringen nodig” melding stuurt over de Page Experience. Vorige week een klant uit Middelburg: webshop met 60 verkopen per dag, PageSpeed-score 34 op mobiel, LCP van 4,8 seconden en INP boven de 500 ms.

De frustratie is herkenbaar. Je hebt geen fouten gemaakt, alleen normaal WordPress gebruikt, en toch straft Google je positie af.

In dit stuk lees je hoe ik zulke sites systematisch uitpluis met PageSpeed Insights, Query Monitor en browser DevTools, en welke ingrepen per hostingpaneel het meeste opleveren. Reken op 60 tot 90 minuten voor een volledige eerste ronde, mits je toegang hebt tot je hosting en wp-admin.

Wat er precies gebeurt onder de motorkap

Eerst meten, dan sleutelen. Snap dus wat Google eigenlijk meet. Core Web Vitals zijn drie veldmetingen op basis van echte bezoekers via het Chrome User Experience Report (CrUX). Het zijn geen lab-metingen van jouw laptop. Google kijkt naar het 75e percentiel over een rollend venster van 28 dagen. In gewone taal: 75 procent van je bezoekers moet een “goede” ervaring hebben, anders faal je.

De drie metrics anno 2026:

LCP (Largest Contentful Paint) ≤ 2,5 seconden. Meet hoe snel het grootste zichtbare element binnen de viewport verschijnt. Meestal je hero-image, hero-videoposter of een grote H1. Boven 4 seconden is “slecht”. LCP-problemen komen 80 procent van de tijd door één te grote afbeelding of door een render-blocking CSS-bestand.

INP (Interaction to Next Paint) ≤ 200 ms. Sinds maart 2024 heeft INP definitief FID vervangen. INP meet de totale reactietijd op elke klik, tap of toetsindruk, gedurende het bezoek. Boven 500 ms is “slecht”. INP-issues ontstaan bijna altijd door zware JavaScript op de main thread: page builders zoals Elementor, tag managers, chat-widgets, ads-scripts.

CLS (Cumulative Layout Shift) ≤ 0,1. Meet hoe vaak content onverwacht van plaats verspringt tijdens het laden. Boven 0,25 is “slecht”. Klassieke oorzaken: afbeeldingen zonder width/height-attributen, webfonts die laat inladen en tekst herformatteren, cookie-banners die van bovenaf naar beneden vallen.

Ter verdieping: DebugBear legt de p75-berekening en de CrUX-flow tot in detail uit. Wat veel eigenaren onderschatten: als je vandaag optimaliseert, zie je pas na 3 tot 4 weken groene score. CrUX heeft tijd nodig om nieuwe data te verzamelen.

Stap 1: Baseline meten voor je iets aanraakt

Optimaliseren zonder meten is gokken. Meet daarom eerst, sla de cijfers op, en meet opnieuw na elke ingreep. Ik gebruik drie tools naast elkaar:

PageSpeed Insights is de bron waar Google zelf naar kijkt. Geeft veld-data (CrUX, echte bezoekers, 28 dagen rollend) én lab-data (Lighthouse, momentopname). De veld-data telt voor je ranking, niet de lab-score. Test altijd zowel Mobile als Desktop, want mobiel telt zwaarder mee voor mobiel-first indexering.

GTmetrix is visueel scherper, laat een waterfall zien en een filmstrip van elke render-stap. Gratis met een account, test-locatie standaard Vancouver. Zet dit op London of Frankfurt voor Europese bezoekers.

WebPageTest is de meest technische tool. Test vanuit specifieke locaties met specifieke netwerksnelheden, geeft “connection view” om third-party scripts te isoleren.

Noteer voor de startsituatie minimaal:

Stap 2: CrUX versus lab-data begrijpen

Een terugkerend misverstand: PageSpeed Insights toont “Geen voldoende CrUX-data” voor kleinere sites. Dat betekent niet dat je faalt, maar dat er te weinig maandelijkse bezoekers zijn voor een steekproef. Leun in dat geval op lab-data en synthetische monitoring via DebugBear of SpeedCurve.

Voor sites mét CrUX-data: check ook de CrUX History API voor de trend over 6 maanden. Één rode meting is een uitschieter. Drie maanden rood is structureel.

Test altijd met verse cache. In PSI automatisch. In je browser: DevTools (F12), Network-tab, “Disable cache” aanvinken, hard reload met Ctrl+Shift+R.

Stap 3: Query Monitor installeren en trage plugins vinden

De grootste winst zit vaak in één plugin die 40 procent van je PHP-tijd opeet. Om dat te vinden, gebruik ik Query Monitor van John Blackbourn. Gratis, actief onderhouden, ruim 200.000 actieve installaties, versie 4.0.7 in 2026.

Installatie.

WordPress admin → Plugins → Add new → zoek "Query Monitor" → Install → Activate

Na activatie verschijnt in de admin-toolbar een dropdown met performance-cijfers voor elke pagina die je bekijkt. Open je homepage (ingelogd als admin) en klik in de toolbar op de melding. Kijk naar.

• Overview → Page Generation Time: hoe lang PHP nodig had om de HTML te bouwen. Boven 1 seconde is verdacht.
• Queries → Queries by Component: sorteert op plugin/theme. De plugin bovenaan is je hoofdverdachte.
• Queries → Duplicate Queries: dezelfde SQL-query 20 keer op één page load betekent een slecht geschreven plugin.
• Scripts → filter op JS: welke JS-bestanden van welke plugin. Klik door naar file-size.

In mijn praktijk zijn de vaste verdachten: Elementor, WooCommerce zonder HPOS, oude sliders, “related posts”-plugins die 200 queries afvuren, en statistiek-plugins zoals Jetpack Stats of MonsterInsights.

Stap 4: Autoload-audit uitvoeren

WordPress laadt bij élk pageview de wp_options-tabel met alle rijen waar autoload = 'yes'. Als daar 30 MB aan verlopen transients of plugin-configuratie in zit, is elke pagina traag. Ook wp-admin. Deze audit is de meest onderschatte snelheidswinst.

Draai deze SQL via je hostingpaneel (phpMyAdmin of Adminer).

-- Top 20 grootste autoload-rijen tonen
SELECT option_name, LENGTH(option_value) AS size_bytes, autoload 
FROM wp_options 
WHERE autoload = 'yes' 
ORDER BY size_bytes DESC 
LIMIT 20;

Alles boven de 500.000 bytes (0,5 MB) is een rode vlag. Vaak zie je verlopen transients van plugins die je jaren geleden hebt uitgeschakeld. Opruimen.

-- Alle transients verwijderen (WordPress bouwt ze automatisch opnieuw op)
DELETE FROM wp_options 
WHERE option_name LIKE '_transient_%' 
AND option_name NOT LIKE '_transient_timeout_%';

DELETE FROM wp_options 
WHERE option_name LIKE '_transient_timeout_%';

-- Site-transients (multisite)
DELETE FROM wp_options 
WHERE option_name LIKE '_site_transient_%';

Sneller via SSH met WP-CLI.

# Alle transients purgen
wp transient delete --all

# Autoload uitzetten voor een specifieke bulky option
wp option set autoload no _optie_naam_hier_

# Database optimaliseren
wp db optimize

Belangrijk: maak een backup voor je deze queries draait. Ik heb een keer meegemaakt dat een klant zijn cart-inhoud verloor omdat een plugin de winkelwagen als transient bewaarde.

Stap 5: Image-audit en compressie

Beelden zijn nummer één oorzaak van hoge LCP. Open DevTools → Network-tab → filter op Img → sorteer op Size. Alles boven 200 KB is verdacht. Boven 500 KB is bijna altijd fout.

Compressie-tools die ik nu in 2026 gebruik, met actuele prijzen.

• ShortPixel: credit-model vanaf $3,99/maand voor 7.000 credits. Beste kwaliteit-per-KB naar mijn ervaring. Gratis tier 100 beelden per maand.
• Imagify: flat rate $9,99/maand voor onbeperkt. Gratis tier ± 200 beelden per maand. Van hetzelfde bedrijf als WP Rocket, geen dubbele integratie nodig.
• Smush: gratis versie prima voor kleine sites. Pro vanaf $60/jaar met WebP-conversie en CDN.
• Optimole: server-side, geen originele beelden op je server nodig.

Naast compressie: converteer naar WebP of AVIF. WebP is 25 tot 35 procent kleiner dan JPEG. AVIF nog 20 procent kleiner dan WebP en in 2026 breed ondersteund.

Preload van de hero-image (de LCP-kandidaat) versnelt LCP met 300 tot 800 ms.

// functions.php: hero-image preload voor de homepage
add_action('wp_head', function() {
    if (is_front_page()) {
        echo '<link rel="preload" as="image" 
              href="' . get_stylesheet_directory_uri() . '/img/hero.webp" 
              fetchpriority="high">';
    }
}, 1);

Zorg voor width en height op ELKE in je HTML. Dit reserveert layout-ruimte en fixt CLS-issues.

<img src="/hero.webp" width="1200" height="600" 
     alt="Beschrijving" fetchpriority="high">

Stap 6: Plugin- en third-party-audit

Voor INP-issues is de vraag simpel: welke JS blokkeert de main thread? Query Monitor’s Scripts-tab geeft de eerste aanwijzing. Voor diepere analyse: Chrome DevTools → Performance-tab → klik “Record”, refresh de pagina, klik ergens (om INP te triggeren), stop opname. Zoek in de flamegraph naar “Long tasks” boven 50 ms.

Klassieke boosdoeners in 2026.

• Google Tag Manager met 15+ tags: laadt Facebook Pixel, LinkedIn Insight, TikTok Pixel, hotjar en 10 andere pixels tegelijk.
• Live-chat widgets (Tawk, Tidio, Intercom): vaak 300 KB JS die niets doet tot iemand klikt.
• Ads-libraries (Google AdSense, Ezoic): vaak niet uit te sluiten, maar wel te “delayen”.
• Elementor met veel widgets: DOM van 3.000+ nodes vertraagt elke interactie.

Fix voor GTM: verplaats zware tags naar server-side GTM, of verwijder tags die je toch niet analyseert.

Fix voor chat-widgets: laad ze met vertraging, alleen na eerste user-interactie.

// Delay chat-widget tot na eerste scroll of klik
add_action('wp_footer', function() { ?>
    <script>
    (function() {
        var loaded = false;
        function loadChat() {
            if (loaded) return;
            loaded = true;
            var s = document.createElement('script');
            s.src = 'https://embed.tawk.to/JOUW_ID/default';
            s.async = true;
            document.body.appendChild(s);
        }
        ['scroll', 'click', 'touchstart'].forEach(e => 
            window.addEventListener(e, loadChat, {once: true, passive: true})
        );
        setTimeout(loadChat, 5000); // fallback na 5 sec
    })();
    </script>
<?php }, 99);

Optimalisatie per hostingpaneel

De ideale stack verschilt per hosting. Wat op LiteSpeed werkt, breekt op Apache. Hieronder wat ik per paneel adviseer.

DirectAdmin (Antagonist, Vimexx, mijn.host)

Deze hosters draaien vaak op LiteSpeed Enterprise. Grote winst.

1. Installeer LiteSpeed Cache (gratis). Deze bundelt QUIC.cloud CDN, image optimization (WebP/AVIF), critical CSS en object cache in één plugin.
2. In cPanel → Select PHP Version → zet op 8.3 (of hoger als beschikbaar).
3. cPanel → Optimize Website → schakel mod_deflate (gzip) aan voor alle content types.
4. In LiteSpeed Cache → Toolbox → Object Cache → koppel aan Memcached als je hosting dat aanbiedt.

Plesk (Argeweb, en op VPS bij TransIP en Combell)

1. Websites & Domains → jouwsite.nl → PHP Settings → PHP 8.3, memory_limit 512M, max_execution_time 60.
2. Plesk-integratie met LiteSpeed Cache als je hosting LSWS draait.
3. Anders: WP Rocket (Single-licentie $59/jaar) of Cache Enabler (gratis).
4. Apache & nginx Settings → activeer nginx als reverse proxy voor statische bestanden.

cPanel (o.a. Neostrada)

DirectAdmin heeft minder ingebouwde optimalisatie.

1. Login → PHP Selector → 8.3, memory_limit 512M, activeer OPcache en APCu.
2. File Manager → .htaccess uitbreiden met browser-caching (zie code onder).
3. Cache-plugin: W3 Total Cache (gratis, meer manuele instellingen) of WP Rocket.
4. Overweeg Cloudflare als edge cache. Free plan is voldoende voor de beginnersfase.

.htaccess-snippet voor browser-caching op Apache/DirectAdmin.

# Browser-caching voor statische bestanden
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

# Gzip-compressie
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/css application/javascript
    AddOutputFilterByType DEFLATE application/json image/svg+xml
</IfModule>

Hostinger hPanel

Hostinger LiteSpeed-servers, dus.

1. hPanel → Advanced → Cache Manager → All Cache aan.
2. LiteSpeed Cache plugin (gratis).
3. Hostinger’s ingebouwde Object Cache (Redis) aanzetten in hPanel.
4. PHP 8.3 via Advanced → PHP Configuration.

Managed WordPress (Kinsta, Cloudways, WP Engine)

Bij managed hosting is 60 procent van de basis geregeld. Kinsta biedt server-level page cache, edge caching, Redis Object Cache (add-on €100/maand) en de gratis Kinsta APM tool voor trage transacties. Cloudways draait Varnish + Redis standaard met gratis Breeze cache. WP Engine heeft ingebouwde EverCache. Een tweede cache-plugin is meestal contraproductief.

WP-CLI voor SSH-gebruikers

Snel alle caches purgen en optimaliseren.

# Cache purgen (werkt met de meeste cache-plugins)
wp cache flush
wp litespeed-purge all      # LiteSpeed Cache
wp rocket clean --confirm    # WP Rocket

# Database optimaliseren
wp db optimize

# Verlopen transients weggooien
wp transient delete --expired --all

# WooCommerce sessies opruimen (kan honderden MB besparen)
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_wc_session_%'"

Cache-plugin vergelijking per situatie

Er is geen universele winnaar. Kies op basis van hosting en budget:

Voor de meeste MKB-klanten adviseer ik LiteSpeed Cache waar het kan (Antagonist, Hostinger, Combell), anders WP Rocket. FlyingPress is technisch iets sneller, maar het verschil is onmerkbaar voor gemiddelde bezoekers.

Object cache: Redis of Memcached

Als je database veel queries doet (WooCommerce, LMS, forum), versnelt een object cache je site aanzienlijk door query-resultaten in RAM te bewaren.

Redis is de standaard in 2026. Snel, persistent, ondersteunt clustering. Plugin: Redis Object Cache van Till Krüss. Managed hosters zoals Kinsta bieden Redis als add-on. Voor high-traffic: Object Cache Pro (paid, developer-license) is nog sneller.

Memcached is ouder, heeft minder features, maar is simpel en snel. Meeste cPanel-hosters bieden dit aan. Plugin: w3-total-cache heeft Memcached-support ingebouwd.

Redis activeren via wp-config.php (nadat de plugin geïnstalleerd is).

// wp-config.php: Redis Object Cache configuratie
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Na activatie geeft Query Monitor’s “Object Cache”-sectie aan of hits/misses correct binnenkomen. Ratio boven 80 procent hits is gezond.

Drie concrete scenario’s uit mijn praktijk

Scenario A: LCP 5,0 s door hero-image van 2 MB

Klant uit Terneuzen, kapper-website. Hero was een 4032×3024 JPG rechtstreeks uit de iPhone geüpload, 2,3 MB. WordPress serveerde die 1-op-1 op mobiel.

Diagnose: DevTools → Network → Img → 2,3 MB, LCP 5,0 s.

Fix:

1. Origineel gecomprimeerd en geconverteerd naar WebP via ShortPixel: 187 KB (92 procent kleiner).
2. Responsive images-set gegenereerd via ShortPixel Adaptive Images (1200w, 800w, 400w).
3. Preload-hint toegevoegd in functions.php.
4. fetchpriority="high" op de hero-.

Resultaat: LCP van 5,0 s naar 1,8 s in Lighthouse, na 3 weken bevestigd in CrUX. Werk: 45 minuten.

Scenario B: INP 400 ms door Elementor-bloat

Klant uit Hulst, adviesbureau. Homepage in Elementor Pro met 12 widgets, DOM van 4.200 nodes. INP piekte op 480 ms bij menu-clicks.

Diagnose: Chrome DevTools → Performance-tab → Long tasks van 250 ms tijdens interaction. Query Monitor: Elementor-scripts 890 KB gzipped.

Fix:

1. Hero-sectie vervangen door native Gutenberg-block (Cover-block met eigen achtergrond).
2. Elementor global font-icons uitgeschakeld (Elementor → Settings → Advanced).
3. “Improved Asset Loading” en “Improved CSS Loading” experiments aangezet (Elementor → Experiments).
4. Ongebruikte widgets uit de theme-instellingen weggehaald.

Resultaat: INP van 400 ms naar 150 ms, DOM-size van 4.200 naar 1.100 nodes. Werk: 90 minuten.

Scenario C: CLS 0,35 door late cookie-banner

Klant uit Gent, webshop. CLS in het rood, alle andere metrics goed. Oorzaak: cookie-banner van Complianz laadde met 800 ms vertraging bovenaan de pagina, duwde alle content naar beneden.

Diagnose: GTmetrix filmstrip toonde exact het moment van shift. Layout Shift regions in Lighthouse wees banner aan.

Fix: Preallocated ruimte via CSS, direct in de .

/* Reserveer 60px voor cookie-banner op mobiel, 80px op desktop */
.cmplz-cookiebanner,
.cc-window {
    min-height: 60px;
    contain: layout;
}

@media (min-width: 768px) {
    .cmplz-cookiebanner,
    .cc-window {
        min-height: 80px;
    }
}

/* Reserveer ruimte in de body tot banner geladen is */
body { padding-top: 60px; }
body.cmplz-loaded { padding-top: 0; }

Resultaat: CLS van 0,35 naar 0,05. Werk: 20 minuten.

Cloudflare als edge-laag

Voor sites met internationale bezoekers of piekverkeer voegt Cloudflare een edge-caching-laag toe. Het Free plan geeft DNS, basic CDN, gratis SSL en DDoS-protectie. Voor HTML op de edge heb je Cloudflare APO nodig: $5/maand losse add-on of inbegrepen bij Pro ($20/maand). Bij dynamische content (checkouts, member-only pages) zorgvuldig zijn met cache-bypass-rules via het Cache Rules dashboard.

Preventie na een wordpress site traag core web vitals fix

Na de eerste optimalisatie-ronde is er nog werk. Sites vervallen. Nieuwe plugins voegen weer JS toe. Cover-images worden opnieuw ongecomprimeerd geüpload.

1. Maandelijkse PSI-check via automation. Lighthouse CI draaien in GitHub Actions of GitLab CI stuurt een waarschuwing zodra scores achteruit gaan.

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on:
  schedule:
    - cron: '0 3 1 * *'   # elke 1e van de maand, 03:00 UTC
  workflow_dispatch:
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 20
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install -g @lhci/cli@0.15.x
      - run: lhci autorun --collect.url=https://jouwsite.nl --upload.target=temporary-public-storage

2. Real-User Monitoring (RUM). SpeedCurve (vanaf $114/maand), DebugBear (vanaf $61/maand) of gratis via de Kinsta APM tool voor Kinsta-klanten. Deze tools meten écht bij bezoekers, dus je ziet de veld-data trend voordat Google ‘m gebruikt voor ranking.

3. Plugin-cap. Voor kleine sites (brochureware, kappers, adviesbureaus) hou ik maximaal 20 actieve plugins aan. Elke extra plugin voegt gemiddeld 30 tot 80 KB JS/CSS toe. Voor webshops mag meer, maar houd de “actief”-lijst kritisch.

4. CDN vanaf dag één. Cloudflare free is gratis en voegt DDoS-bescherming en basis-caching toe. Ik zet ‘m standaard op elke nieuwe site.

5. Image-workflow op cliëntkant. Klanten die zelf beelden uploaden krijgen bij mij ShortPixel geactiveerd voor auto-compressie bij upload. Voorkomt 90 procent van de LCP-terugval.

Wanneer een echte webmaster inschakelen

Zelf de eerste ronde doen is prima. Bel in deze gevallen iemand in.

• Na 4 uur werk zit je nog steeds in het rood op één of meer metrics.
• Query Monitor wijst een custom-thema aan als hoofdverdachte (custom PHP is geen DIY-terrein).
• Redis of Memcached configuratie vereist SSH-toegang die je niet hebt.
• De site draait WooCommerce met €10.000+ omzet per maand. Dan lopen de kosten van een expert minder snel op dan de kosten van rood ranken.

Voor mijn klanten kost een complete Core Web Vitals-audit met optimalisatie meestal 4 tot 8 uur (€280 tot €560). Daarin zit de baseline-meting, de ingrepen, een herhaalmeting na 2 weken en een documentatie-rapport voor de eigenaar.

Vast in het rood?

Zit je site al maanden in de rode Core Web Vitals-zone en heb je de basis geprobeerd zonder resultaat? Stuur me de PSI-link plus je hosting via /contact/. Ik doe een kosteloze eerste scan en geef binnen 24 uur aan of ik winst zie. De volledige audit-en-fix loopt tussen 4 en 8 uur werk (€70/uur), inclusief hermeting na 2 weken. Zie ook mijn achtergrond op /diensten/ en eerdere troubleshooting-cases op /website-onderhoud/.