Dinsdagochtend duwde Jim onze eigen URL door PageSpeed Insights. Het rapport vertelde wat we al vermoedden: onze homepage was te traag, met een handvol concrete verbeterpunten. Twee uur later was de PageSpeed-score met grofweg 30 punten omhoog gegaan, de Largest Contentful Paint gehalveerd en de Total Blocking Time gereduceerd tot wat Google “goed” noemt. Geen plugin gekocht, geen externe developer ingehuurd. Zeven fixes die elke MKB-ondernemer met basis-toegang tot zijn WordPress-site zelf kan toepassen.
Hieronder leggen wij precies uit wat we deden, hoeveel bytes elke fix bespaarde en welke fixes je via een plugin kunt doen versus welke iets meer kennis vereisen. We gebruiken onze eigen voor-en-na cijfers, niet abstracte richtlijnen. Wat hier werkte voor circularmedia.nl, werkt voor 80% van de MKB-WordPress-sites die wij in onze audits zien.
Waarom snelheid écht uitmaakt voor jouw bedrijf
Een trage website kost je drie dingen tegelijk: bezoekers die wegklikken, Google-rankings die wegzakken en omzet die niet binnenkomt. De vuistregel van Google's eigen onderzoek: elke seconde extra laadtijd kost ongeveer 7% conversie. Op een MKB-site met 500 bezoekers per maand en 2% gemiddelde conversie betekent dat bij één seconde te traag al een paar verloren leads per maand. Over een jaar tikt dat aan.
Plus: Google ziet snelheid sinds 2021 expliciet mee in de ranking. De Core Web Vitals (LCP, INP en CLS) zijn officieel ranking-factoren. In ons artikel Core Web Vitals voor MKB leggen we uit wat die metrics zijn. Voor dit artikel volstaat: hoe hoger je PageSpeed-score, hoe groter de kans dat Google jouw site boven die van een concurrent toont bij dezelfde zoekopdracht.
Onze startpositie was niet rampzalig, maar wel typisch. Een PageSpeed-rapport vol “Reduce unused CSS”, “Avoid long main-thread tasks” en “Use efficient cache lifetimes”. Allemaal vage termen die je makkelijk negeert. Tot je de impact in cijfers ziet.
Fix 1: CSS daadwerkelijk minifyen, niet alleen hernoemen
Eerste verrassing: ons hoofd-stylesheet heette main.min.css, maar bevatte nog steeds spaties, tabs, commentaar en regelovergangen. Iemand had ooit main.css simpelweg gekopieerd en hernoemd naar .min.css zonder daadwerkelijk een minify-tool te draaien. Resultaat: 125 KB per pageload waar 85 KB had volstaan.
Wij draaien nu csso-cli via Node (gratis, één commando per CSS-bestand) en bewaren zowel het bronbestand als de geminifyde versie naast elkaar. 40 KB bespaard per bezoeker. Voor onze mascot-styling: extra 4 KB. Bij elkaar een 30%-reductie op alle CSS-traffic.
Voor wie geen toegang heeft tot de command line: WP-Optimize, LiteSpeed Cache of Autoptimize doen dit automatisch via een aanvinkbare optie “Minify CSS”. Belangrijk: na het inschakelen, leeg de cache en hertest. Veel sites hebben deze setting nooit gevonden of bewust uitgezet wegens compatibiliteit-zorgen die meestal onterecht zijn.
Fix 2: Animaties verplaatsen naar de GPU
PageSpeed klaagde over “36 niet-gecomposite animaties”. Wat dat betekent: bepaalde CSS-eigenschappen (box-shadow, background-position, top, left) animeren via de CPU, terwijl transform en opacity via de GPU draaien. CPU-animaties veroorzaken layout-recalculaties die de browser elke frame uitvoert. Op een laptop merk je het niet, op een 3 jaar oude Android-telefoon zie je hortende animaties en hogere battery-drain.
Onze fix was specifiek: een pulserende cyan-stip onder onze mascot gebruikte box-shadow voor het pulse-effect. We vervingen het door een pseudo-element met transform: scale() en opacity. Visueel identiek, maar nu GPU-versneld. Idem voor een driftend achtergrond-grid dat background-position animeerde, vervangen door transform: translate().
Hard om dit via een plugin op te lossen, want het zit in je theme-CSS. Als je een developer hebt, geef hem deze regel: vervang alle keyframe-animaties die niet alleen op transform of opacity werken. Vragen kost een uurtje, kan veel websites helpen.
Fix 3: Niet-kritieke CSS uitstellen tot na de eerste paint
Een browser blokkeert de pagina-rendering tot alle CSS in de <head> binnen is. Logisch, anders zou je een ongestileerde flits zien. Maar onze 85 KB hoofd-stylesheet bevatte regels voor de hele site, terwijl voor de eerste pagina-paint slechts een fractie nodig is. De rest kan later komen.
De oplossing heet het “print-then-all” pattern. Je laadt de stylesheet eerst als media="print", waardoor de browser hem op de achtergrond ophaalt zonder rendering te blokkeren. Zodra de file binnen is, zet een onload-handler de media-attribute terug naar all en wordt de hele site gestyled.
Effect: de eerste pagina-paint gebeurt nu 450 ms eerder. Voor de fase tussen download en oplijning hebben we de cruciale boven-de-vouw-styling als “critical CSS” direct inline in de <head> gezet (zie fix 5). Geen flikkering, geen rampscenario.
Fix 4: JavaScript uitstellen via defer
Hetzelfde principe geldt voor scripts. Onze theme laadde main.js en een tweede helper-script standaard synchroon, waardoor de browser het document-parsing pauzeerde voor elke script-tag. PageSpeed flagde dit als een “long task” van ongeveer 105 ms op de main thread.
De fix is één attribute: defer. Voeg je dat toe aan een script-tag, dan downloadt de browser het script parallel met de pagina-parsing en voert het pas uit zodra het document klaar is. Geen wachttijd, geen blocking.
In WordPress kun je dit via een filter op script_loader_tag doen, of via een plugin als Async JavaScript of Flying Scripts. Onze long-task duurde na deze fix nog ongeveer 30 ms, ruim binnen Google's grens van 50 ms. Werkende JavaScript, geen pagina-vertraging.
Fix 5: Critical CSS inline in de head
Toen we fix 3 hadden ingebouwd, ontdekten we een vervelend neveneffect: bij een harde refresh schoof het mobiele menu in een seconde van het scherm naar rechts uit beeld. De reden: de mobile-nav-drawer heeft als default-styling transform: translateX(100%) met een 360 ms transition. Voor de stylesheet binnen was, stond hij gewoon in beeld. Zodra de CSS laadde, kreeg hij positie + transform en speelde de transition af. Het oog ziet een drawer die wegschuift.
Oplossing: een mini-versie van de critical CSS direct in de <head> plaatsen als inline <style>-blok. Voor onze site is dat ongeveer 3 KB: header-layout, container-rules, taalswitcher-styling, plus de essentiele “de mobile drawer is uit beeld”-regels. Vanaf de eerste paint staat alles op de juiste plek. Geen schuif-glitch, geen flits van ongestileerde tekst.
Plus: onze mascot-systeem-CSS (waar de hero-styling op draait) hebben we ook inline gezet. 7 KB extra HTML per pageload, maar de hero rendert nu meteen scherp in plaats van 450 ms te wachten op een externe stylesheet.
Fix 6: Responsive afbeeldingen via srcset
Onze portfolio-sectie toont 10 screenshots in een grid. Elke kaart toont een afbeelding op ongeveer 178 pixels breed. Wij serveerden echter de full-size 1024×683-versie. Het verschil: een 1024-pixel-screenshot is 100-200 KB, de 300-pixel-thumbnail die de browser daadwerkelijk nodig heeft is 15-30 KB. Bij 10 portfolio-items: circa 500 KB bespaard per pageload.
WordPress maakt automatisch meerdere thumbnail-formaten aan bij elke upload. De truc is dat je de juiste formaat-variant moet aanroepen vanuit je template. Wij gebruikten eerst wp_get_attachment_image_url($id, 'large') wat altijd 1024px geeft. Vervangen door wp_get_attachment_image($id, 'medium_large', [...]) met een sizes-attribuut geeft de browser een keuze: hier zijn 4 formaten, kies de juiste voor het scherm dat je hebt.
Het resultaat is een srcset-attribuut waar de browser zelf uit kiest. Op een retina-iPhone neemt hij 300px, op een 4K-desktop pakt hij 768px. Op de meeste schermen is de download een fractie van wat het was.
Fix 7: Browser-cache aanzetten via .htaccess
De laatste fix kost één keer 5 minuten en levert blijvend op. Statische assets (afbeeldingen, video, fonts, soms ook CSS) veranderen zelden. Toch downloadt elke terugkerende bezoeker ze opnieuw als je geen cache-headers stuurt. Bij ons gold dat voor onze Sunny-hero-video van 351 KB. Iemand die je site twee keer per week bezocht, downloadde die video 100 keer per jaar.
De oplossing zit in een paar regels in je .htaccess-bestand. Apache (de standaard WordPress-webserver) leest die regels en stuurt cache-headers mee bij elk gerelateerd bestand:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType video/webm "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(webm|mp4|webp|jpg|jpeg|png|svg|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>Een jaar cache, met de “immutable”-flag die de browser vertelt: dit bestand verandert nooit voor zijn naam verandert. Voor onze terugkerende bezoekers: 351 KB minder bandbreedte per bezoek. Voor mobiele gebruikers met een data-budget: serieuze besparing.
Belangrijk: na het deployen moet je de file-naam veranderen als de inhoud verandert. WordPress doet dit standaard met ?ver=-parameters achter URLs, dus dat is geregeld. Voor handmatige assets: voeg een hash of versie-suffix toe aan de bestandsnaam.
Wat is een goede PageSpeed-score en welke winst leverden 7 fixes op?
De zeven fixes samen leverden ons:
- ~45 KB minder per pageload aan CSS-transfer (echte minify + defer)
- ~500 KB minder aan portfolio-afbeeldingen via srcset
- ~351 KB minder per terugkerende bezoeker aan video-bandbreedte
- 450 ms snellere first paint dankzij inline critical CSS
- 75 ms minder long-task time via JS-defer en reflow-batching
- 0 niet-gecomposite animaties (was 36)
- Geen mobile-nav-schuif-glitch meer bij harde refresh
Onze PSI-score op de Engelse homepage ging in een paar uur van rond 60 naar ergens in de 90. Niet door één magische plugin, maar door 7 kleine, gerichte ingrepen. Voor wie minutieus mee wil meten: ons artikel 5 gratis Google-tools die je website-snelheid blootleggen beschrijft welke tools je gebruikt om voor en na te meten.
Hoe verbeter je je PageSpeed-score zonder developer?
Niet alle 7 zijn even toegankelijk. Een eerlijke verdeling per moeilijkheidsgraad:
- Via plugin, zonder developer (15 minuten): fix 1 (CSS minify via WP-Optimize / Autoptimize), fix 3 (CSS defer via dezelfde plugin), fix 4 (JS defer via Async JavaScript), fix 6 (op moderne thema's al automatisch via responsive images core feature van WordPress 4.4+)
- Met basale FTP-toegang (30 minuten): fix 7 (htaccess cache headers, kopieer-plak het bovenstaande blok in je .htaccess vóór de WordPress-regels)
- Vereist developer of theme-edit: fix 2 (animations herschrijven), fix 5 (critical CSS extract + inline), fix 6 op custom theme zonder responsive images support
Voor de meeste MKB-sites zonder developer kun je dus al 4 van de 7 zelf doen, met direct meetbaar effect. De overige 3 zijn een paar uur werk voor een ervaren WordPress-developer.
Veelgestelde vragen
Wat is een goede PageSpeed Insights-score voor een MKB-website?
Google noemt een PageSpeed-score van 90 of hoger “goed”, 50 tot 89 “verbetering nodig” en onder 50 “slecht”. Belangrijker dan het ene getal zijn de Core Web Vitals eronder: een Largest Contentful Paint onder 2,5 seconden, een Cumulative Layout Shift onder 0,1 en een Interaction to Next Paint onder 200 ms. Onze eigen homepage ging van rond 60 naar circa 95 met de 7 fixes uit dit artikel.
Hoe verbeter je de Largest Contentful Paint (LCP) op een WordPress-site?
De grootste LCP-winst halen MKB-sites doorgaans uit drie ingrepen: critical CSS inline in de <head> plaatsen zodat de eerste paint niet wacht op een externe stylesheet, de hero-afbeelding correct dimensioneren via srcset zodat een mobiel een kleine versie laadt, en niet-kritieke CSS uitstellen via het print-then-all pattern. In ons geval leverde dat een 450 ms snellere first paint op en een gehalveerde LCP.
Kun je je PageSpeed-score verbeteren zonder developer of betaalde plugins?
Ja, vier van de zeven fixes uit dit artikel kun je zonder developer doen: CSS-minify, CSS-defer, JS-defer (via gratis plugins als WP-Optimize, Autoptimize of Async JavaScript) en responsive afbeeldingen (sinds WordPress 4.4 standaard via srcset). Browser-caching via .htaccess vraagt FTP-toegang en kost ongeveer 30 minuten. Animaties op de GPU zetten en critical CSS inline plaatsen vragen wel theme-kennis of een developer.
Waarom telt website-snelheid mee voor je Google-ranking?
Google maakt sinds 2021 de Core Web Vitals (LCP, INP en CLS) expliciet onderdeel van zijn rankingalgoritme. Bij twee sites met vergelijkbare content kan een betere PageSpeed-score doorslaggevend zijn voor wie boven staat. Daarnaast verliest een trage site direct conversie: Google’s eigen onderzoek wijst uit dat elke seconde extra laadtijd ongeveer 7% conversie kost, wat op een MKB-site met 500 bezoekers per maand al snel meerdere leads scheelt.
Wat doet het defer-attribuut op een JavaScript-bestand?
Met defer downloadt de browser het script parallel met de pagina-parsing en voert het pas uit zodra het document klaar is. Zonder defer pauzeert de browser het parsen van je HTML telkens als hij een script-tag tegenkomt, wat PageSpeed Insights flagt als een “long task”. Bij ons reduceerde defer de hoofd-thread-blokkade van 105 ms naar ongeveer 30 ms, ruim onder Google’s grens van 50 ms.
Tot slot
Sneller maken hoeft niet duur te zijn. Het hoeft ook geen grote rebuild te zijn. Twee uur werk op onze eigen site bracht concrete verbeteringen op alle Core Web Vitals. Geen toveroplossingen, geen nieuwe plugins, geen vervangen theme. Gewoon zeven gerichte ingrepen, met meetbare impact per stuk.
Wil je weten welke van deze 7 fixes voor jouw site het meeste opleveren? Vraag een gratis website-analyse aan via circularmedia.nl/#website-audit. Wij draaien PageSpeed op je site, bekijken welke optimalisaties de grootste impact zouden hebben en geven binnen 1 werkdag een eerlijk overzicht. Geen verkooppraat, geen automatische offerte, gewoon waar de winst zit.
