Mijn website is traag — wat nu? MKB-diagnose in 10 minuten

Q: Hoe weet ik dat mijn website traag is?

Meet op pagespeed.web.dev (mobiel). Onder 50 = duidelijk traag. 50-79 = matig. 80+ = goed. Vergelijk met je drie grootste concurrenten op dezelfde test.

Q: Wat is meestal de hoofdoorzaak?

In 70% van MKB-cases zijn het ongeoptimaliseerde foto's (te groot in dimensie of bestandsformaat). In 20% is het een verouderd CMS-thema of te veel plugins. In 10% is het hosting.

Q: Kan ik dit zelf fixen?

Foto's optimaliseren en lazy-loading aanzetten kan iedereen met 1-2 uur en een gratis tool zoals Squoosh.app. Voor codebase- of plugin-problemen heb je technische hulp nodig of een rebuild.

TL;DR Doe 4 metingen: (1) PageSpeed mobiel + desktop, (2) Vergelijk met 3 concurrenten, (3) Check de zwaarte van je homepage in Chrome DevTools (Network-tab), (4) Tel je actieve plugins/scripts. Resultaat: je weet of het probleem foto's (70% kans), thema/plugins (20%) of hosting (10%) is. Begin altijd bij foto's — laagste hangende fruit en grootste impact.

Eerst: hoe traag is "traag"?

Voordat je gaat fixen, meten. "Voelt traag" is geen meeteenheid. We gebruiken twee benchmarks:

PageSpeed (Lighthouse) mobiel: onder 50 = duidelijk traag, 50-79 = matig, 80-89 = goed, 90+ = uitstekend.
LCP (Largest Contentful Paint): onder 2.5s = goed, 2.5-4s = matig, boven 4s = slecht. Dat is de tijd tot het grootste element zichtbaar is (meestal je hero).

De gemiddelde MKB-site die wij langs zien zit op mobiel-PageSpeed 32-48 en LCP 4.5-7s. Dat is structureel onder Google's drempel en je verliest daardoor zowel ranking als bezoekers.

Meting 1 — PageSpeed mobiel + desktop

Ga naar pagespeed.web.dev, vul je URL in, klik analyseren. Doe dit drie keer (resultaten variëren) en pak het gemiddelde. Belangrijk: kijk naar mobiel, niet desktop. Google indexeert mobiel-first.

Noteer vier getallen:

Performance-score (0-100)
LCP in seconden
CLS (Cumulative Layout Shift, 0-1)
INP of TBT (interactiviteit)

Meting 2 — vergelijk met drie concurrenten

Doe dezelfde test op drie van je belangrijkste concurrenten (gebruik Google: type "[jouw vak] [jouw stad]" en pak de top 3). Noteer hun PageSpeed-scores.

Als jouw site PageSpeed 35 haalt en je concurrenten 75, 80 en 65, weet je niet alleen dát je traag bent — je weet ook dat het meetbaar fixbaar is voor MKB in jouw sector.

Soms is iedereen in een sector traag (hoveniers, restaurants). Dan is jouw kans des te groter: snel zijn = pagina 1.

Meting 3 — homepage-zwaarte in Chrome

Open Chrome, ga naar je homepage, druk F12 (DevTools), klik "Network"-tab, druk Ctrl+R (refresh). Wacht tot alles geladen is. Onderin zie je: "X requests · Y MB transferred · Zs load".

Benchmarks voor MKB-homepages:

Goed: onder 30 requests, onder 1.5 MB, onder 2.5s
Matig: 30-60 requests, 1.5-3 MB, 2.5-4s
Slecht: 60+ requests, 3+ MB, 4+ seconden

Sorteer de requests op grootte (klik op "Size"-kolom). De top 5 zwaarste files vertellen je 80% van het verhaal. Bijna altijd zijn dat foto's of JS-frameworks.

Meting 4 — tel je plugins/scripts

WordPress? Ga naar Plugins. Tel ze. Onder 15 = ok. 15-25 = let op. Boven 25 = onhoudbaar. Veel kleine plugins zijn even erg als één zware.

Geen WordPress? Open je homepage-bron (rechtermuisklik, "View source"), zoek op <script. Tel de aantal externe scripts (analytics, hotjar, chat-widgets, ad-tracking). Boven 8 is al verdacht voor een MKB-site.

De diagnose — welke van de drie is jouw probleem?

Op basis van de vier metingen kun je vrijwel altijd in één van drie categorieën vallen:

Diagnose A — Foto's (70% van MKB-cases)

Tekenen: top 5 zwaarste requests in Chrome zijn .jpg of .png, je homepage is 3+ MB, je LCP is boven 4s. Fix: foto's omzetten naar WebP en correct schalen. Lees: image-optimalisatie voor MKB en WebP vs JPG.

Diagnose B — Thema of plugins (20%)

Tekenen: foto's zijn al klein maar PageSpeed blijft 30-50, je hebt 20+ plugins, je INP is hoog. Fix: thema-audit, plugin-saneren, eventueel rebuild op modern platform. Lees: INP uitleggen en WordPress-alternatieven.

Diagnose C — Hosting (10%)

Tekenen: TTFB (Time to First Byte) boven 800ms, alle metingen schommelen sterk, site gaat soms gewoon offline. Fix: betere hosting (€10-25/maand verschil tussen goedkope shared en degelijke managed). Lees: cluster hosting.

Welk probleem fix je eerst?

Altijd foto's eerst. Reden: laagste hangende fruit, snelste resultaat, geen risico op breken van de site. Voor 70% van MKB-sites die wij auditten verbetert alléén foto-optimalisatie de PageSpeed al van 35 naar 65-75. Vaak genoeg om uit het rode gebied te komen.

Daarna pas naar thema/plugins of hosting kijken, want die ingrepen zijn duurder en risicovoller.

Wanneer is rebuild de enige optie?

Als je na foto-optimalisatie en plugin-sanering nog steeds onder PageSpeed 60 zit op mobiel, is de codebase het probleem. Dan helpt knutselen niet meer. Voor MKB betekent dat doorgaans: rebuild op Astro, Webflow of een schone WordPress met modern thema.

Bij DesignCheck garanderen we PageSpeed mobiel 90+ op elk rebuild-pakket — zie prijzen (€1.995-€6.995 vast). Wil je weten of een rebuild zich terugverdient? Vul de verliescalculator in.

Snelheidsaudit — gratis

Wij meten je homepage + top 5 pagina's op echt mobiel en sturen binnen 48 uur een rapport met de drie grootste fixes en hun kosten. Geen sales-call, geen verplichtingen.

Audit aanvragen →

Volgende stappen — gerelateerde gidsen

Core Web Vitals voor MKB — wat Google precies meet
LCP fixen 2026 — de #1 metriek voor MKB
Traag laden kost bezoekers — de cijfers
DesignCheck Mijdrecht — als je hulp wilt van een lokaal bureau

FAQ — trage website

Hoe weet ik dat mijn website traag is?

Meet op pagespeed.web.dev (mobiel). Onder 50 = duidelijk traag. 50-79 = matig. 80+ = goed. Vergelijk met je drie grootste concurrenten op dezelfde test — soms is iedereen in jouw sector traag, dan ben jij minder traag dan je dacht.

Wat is meestal de hoofdoorzaak?

In 70% van MKB-cases zijn het ongeoptimaliseerde foto's (te groot in dimensie of bestandsformaat). In 20% is het een verouderd CMS-thema of te veel plugins. In 10% is het hosting. We zien dit patroon structureel terug in onze audits.

Kan ik dit zelf fixen?