Waarom je site traag is
Trage sites hebben bijna altijd dezelfde grondoorzaken. De tools zijn anders, de symptomen zijn hetzelfde. Ik zie dit patroon bij Magento-shops, WordPress-blogs, Wix-sites en maatwerk-builds:
- ▸Te grote JavaScript-bundles die de browser moet parsen voordat er iets zichtbaar wordt. Elke onnodige library telt.
- ▸Render-blocking resources: CSS of scripts die in de <head> staan en het tekenen van de pagina blokkeren.
- ▸Afbeeldingen zonder compressie, zonder WebP-conversie, zonder correct sizing per viewport.
- ▸Hoge TTFB (Time to First Byte) door een trage server, ontbrekende caching of een suboptimale databasequery op elke request.
- ▸Third-party scripts die asynchroon laden maar toch de main thread bezetten: Google Tag Manager, chat-widgets, consent-banners, social embeds.
De meeste sites hebben er drie of vier tegelijk. Dat is geen toeval. Platforms zoals Wix en vroege WordPress-thema's zijn gebouwd voor functionaliteit, niet voor snelheid. De technische schuld stapelt zich op zolang niemand er actief op stuurt.
Wat Core Web Vitals echt meten
Google meet drie signalen voor gebruikservaring. LCP (Largest Contentful Paint) meet hoe snel het grootste zichtbare element geladen is. Dat is bijna altijd een hero-afbeelding of een grote koptekst. Alles boven 2,5 seconden is slecht. Alles boven 4 seconden is zeer slecht.
INP (Interaction to Next Paint) meet hoe snel de pagina reageert op een klik of toetsaanslag. Dit is in 2024 definitief CID (Click-to-first-interaction delay) vervangen en is nu het voornaamste responsiviteitsignaal. CLS (Cumulative Layout Shift) meet hoe stabiel de pagina is terwijl hij laadt. Knoppen die verschuiven, tekst die opschuift door een laattijdig ladende advertentie: dat zijn CLS-bronnen.
Google gebruikt deze drie als rangschikkingssignaal in zoekresultaten. Maar los van SEO: een pagina met LCP van 4 seconden verliest gemiddeld 7% conversie per extra seconde vertraging. Dat zijn geen abstracte statistieken. Dat zijn bestellingen, aanvragen en contactformulieren die nooit binnenkomen.
Mijn audit-aanpak
Een perf-audit zonder data is giswerk. Ik meet altijd twee dingen tegelijk: lab-data en field-data. Lab-data komt uit Lighthouse en de PSI API, gerund op jouw URL onder gecontroleerde omstandigheden. Field-data komt uit het Chrome User Experience Report (CrUX), de echte meetwaarden van jouw bezoekers over de afgelopen 28 dagen.
- ▸PSI API-run op alle kritieke pagina's: homepage, categoriepagina, productpagina, contactpagina. Elke pagina afzonderlijk, want problemen zijn zelden uniform.
- ▸Network waterfall-analyse in Chrome DevTools: welke resource blokkeert wat, welke requests zijn sequentieel die parallel kunnen.
- ▸Treeshake-check op JavaScript-bundles: welke dependencies worden geladen maar deels of niet gebruikt.
- ▸Image-audit: formaat, compressieverhouding, dimensies versus weergavegrootte, lazyload-implementatie.
- ▸Third-party impact-meting: hoeveel main thread time claimen scripts van buiten jouw domein.
Het resultaat is een gerangschikte lijst van knelpunten, gesorteerd op impact. Niet alle problemen zijn even zwaar. Ik begin bij wat het meeste oplevert.
Wat ik typisch fix
Na de audit implementeer ik de fixes. Op de meeste sites gaat het om een combinatie van de volgende ingrepen:
- ▸Next.js Image-component: automatische WebP-conversie, correct sizing via srcset, lazyload buiten viewport, eager load voor de LCP-afbeelding.
- ▸ISR-cache configuratie: pagina's worden gerenderd en gecached als statische bestanden, zodat de server niets hoeft te berekenen bij elke bezoeker.
- ▸Font-display: swap instellen op webfonts zodat de pagina tekst toont terwijl het font laadt, in plaats van een onzichtbaar flash.
- ▸CSS-blocking verwijderen: kritieke CSS inline, niet-kritieke CSS deferred of via preload met media-queries.
- ▸Third-party scripts deferred laden: Google Analytics, GTM en consent-banners na het first contentful paint, niet ervoor.
- ▸Kritieke afbeeldingen preloaden: de LCP-resource in de <head> aanmelden zodat de browser hem eerder ophaalt.
Welke fixes van toepassing zijn, hangt af van jouw stack. Op een Magento-installatie pak ik andere knoppen aan dan op een WordPress-site of een Next.js-applicatie. De aanpak is altijd specifiek voor wat de data laat zien.
-- Klant-casus
CarCare24: LCP van 14 seconden naar 6,8s lab, 2,14s echte bezoekers
CarCare24 is een Magento 2 webshop met ongeveer 3400 producten op Hypernode met Cloudflare Free. Voor de performance-waves stond de LCP op 14 tot 16 seconden in PSI lab op mobiel. Lighthouse mobiele performance score varieerde sterk.
Bij de audit kwamen drie primaire knelpunten naar boven:
Na negen waves met hero-image optimalisatie, WebP-conversie, deferred third-party scripts en een custom CSP-module staat de PSI lab-LCP op 6,8 seconden. De mobile performance score in lab varieert tussen 38 en 65 op dezelfde dag, afhankelijk van CPU-throttle-variance. Dat is normaal voor lab-metingen. Wat telt: de CrUX-data van echte bezoekers over 28 dagen toont LCP 2,14 seconden, INP 111ms, CLS 0,05. Alle Core Web Vitals zitten in het groen. Accessibility ging van 90 naar 100, Best Practices van 88 naar 96, SEO 100. PSI lab simuleert 4x CPU-throttling en Slow 4G. Dat is een worst-case, geen representatief scenario. CrUX is wat jouw klanten ervaren. Ik optimaliseer voor de tweede.
Wat ik niet doe
Er zijn shortcuts die een Lighthouse-score omhoog duwen zonder de gebruikerservaring te verbeteren. Ik gebruik ze niet.
- ✕Preloaden van resources die niet op het kritieke pad zitten, alleen om de score te verhogen.
- ✕Font-display: optional instellen zodat fonts worden weggelaten als ze niet snel genoeg laden. Scoort beter, ziet er slechter uit.
- ✕Afbeeldingen wegstrepen of verstoppen om CLS te verlagen zonder de onderliggende oorzaak te fixen.
- ✕Content Security Policy headers aanpassen op een manier die third-party scripts kapotmaakt om de impact te verbergen.
- ✕Serveer een lichtere pagina aan Lighthouse-bots dan aan echte bezoekers. Google detecteert dit.
Een score van 100 op een pagina die niemand bezoekt is waardeloos. Ik optimaliseer de pagina's die verkeer binnenhalen, met fixes die standhouden bij echte gebruikers op echte netwerken.
Tools die ik gebruik
De kern van mijn gereedschapskist: de PSI API voor reproduceerbare lab-scores op elke URL, Chrome DevTools voor network waterfall en main thread profilering, WebPageTest voor multi-step en geographic testing, en Lighthouse CI in de build-pipeline zodat regressions vroeg worden gevangen. Voor field-data gebruik ik het CrUX-dashboard en de Google Search Console Core Web Vitals-rapportage.
Bij Magento-specifiek werk gebruik ik daarnaast Blackfire voor PHP-profieling van trage backend-processen, en de Magento Performance Toolkit voor load-patronen. Op Next.js-stacks analyseer ik bundle-output via @next/bundle-analyzer en traceer ik server-side rendering-bottlenecks met de ingebouwde Next.js trace-viewer.
Audit en optimalisatie-trajecten
Een snelheids-traject loopt in twee fasen. Eerst de audit: meten, analyseren, knelpunten rangschikken. Dan optioneel de implementatie: fixes doorvoeren, meten, itereren. Je kunt instappen op audit-only of voor het volledige traject.
Auditprijs afhankelijk van aantal pagina's en stack. Magento en custom builds vereisen meer meetpunten dan een enkelvoudige Next.js-site. Prijs wordt vastgesteld na een eerste orientatiegesprek.