Laadtijd is vakmanschap, geen bijzaak
Een trage WordPress-site is bijna nooit pech. Het is het resultaat van keuzes die eerder in het bouwproces zijn gemaakt — of niet gemaakt. Afbeeldingen zonder optimalisatie, plugins die overal laden, geen caching, hosting die de belasting niet aankan. Als bouwer zijn dit oplosbare problemen. Maar voorkomen is goedkoper dan oplossen.
Waarom laadtijd een bouwvraagstuk is, geen beheervraagstuk
De meeste ondernemers merken een trage site pas als hij al maanden traag is. Ze zien het niet zelf — bezoekers vertrekken stilletjes, Google registreert het langzaam, en de statistieken laten pas na weken een daling zien.
Tegen die tijd is de schade al gedaan. Niet dramatisch, niet plotseling, maar sluipend.
Wat de meeste ondernemers niet weten: de oorzaak van die traagheid is bijna altijd terug te leiden naar beslissingen die bij het bouwen zijn gemaakt. Of juist niet gemaakt. Een thema met te veel meegeladen code, plugins die op elke pagina actief zijn ook als ze niets doen, afbeeldingen die nooit geoptimaliseerd zijn, hosting die net te krap is voor het verkeer dat de site trekt.
Dat zijn geen beheerproblemen. Het zijn bouwproblemen. En een bouwprobleem los je niet op met een plugin achteraf.
De drie meest voorkomende oorzaken — en wanneer ze ontstaan
1. Afbeeldingen die niet geoptimaliseerd zijn. Een foto rechtstreeks van de camera of telefoon is vaak 3 tot 8 MB. Op een website heeft diezelfde foto misschien 150 KB nodig om er goed uit te zien. Het verschil laadt de browser sowieso — ook als de foto op 400 pixels breed wordt getoond.
Dit probleem ontstaat bijna altijd bij het vullen van de site, niet bij het bouwen. De inhoud wordt aangeleverd, de afbeeldingen worden geüpload, en niemand controleert de bestandsgrootte. Bij oplevering ziet de site er goed uit. Drie maanden later, als er meer pagina’s zijn gevuld, is de site merkbaar trager.
Ik optimaliseer afbeeldingen vóór oplevering — en ik stel in de beheersomgeving een automatische compressie in voor nieuwe uploads via een plugin als Imagify of ShortPixel. Zo blijft de site ook na oplevering snel, ongeacht wie er content toevoegt.
2. Plugins die laden op pagina’s waar ze niets doen. Een contactformulier-plugin laadt zijn scripts op elke pagina, ook op pagina’s zonder formulier. Een sliderscript is actief op pagina’s zonder slider. Elke overbodige script vertraagt de laadtijd — niet dramatisch per stuk, maar de opstapeling telt op.
Dit is een configuratiekwestie, geen pluginkwestie. Goede plugins hebben een instelling om scripts alleen te laden waar ze nodig zijn. Die instelling staat standaard uit. Ik zet hem standaard aan.
3. Geen caching. WordPress bouwt elke pagina opnieuw op bij elk bezoek — het haalt content op uit de database, verwerkt dat via PHP en stuurt het resultaat naar de browser. Met caching wordt een kant-en-klare versie van de pagina opgeslagen en direct geserveerd, zonder die hele keten te doorlopen. Het verschil in laadtijd is aanzienlijk.
Caching instellen kost een halfuur. Toch staat het op de meeste WordPress-sites die ik binnenkrijg niet correct geconfigureerd. De plugin is geïnstalleerd, de standaardinstellingen staan aan, maar de specifieke instellingen die het verschil maken — browser caching, GZIP-compressie, database-optimalisatie — zijn nooit aangepast.
Wat ik standaard doe bij elke oplevering
Vier dingen die bij elke site worden afgevinkt vóór de sleutels worden overgedragen:
PageSpeed-score controleren op mobiel
Niet op desktop — Google beoordeelt primair op mobiele prestaties. Een score van 50 of hoger op mobiel is het minimum. Zit de score lager, dan ga ik eerst de oorzaak opsporen voordat ik oplever.
Afbeeldingen geoptimaliseerd
Alle afbeeldingen die bij oplevering op de site staan zijn geoptimaliseerd. Nieuwe uploads worden automatisch gecomprimeerd
Caching correct geconfigureerd
Niet alleen geïnstalleerd — geconfigureerd. Browser caching, GZIP, eventueel een CDN als de hosting dat ondersteunt.
Overbodige plugin-scripts beperkt
Scripts laden alleen op de pagina’s waar ze nodig zijn. Dat geldt voor het contactformulier, — alles wat geladen wordt zonder direct nut op die specifieke pagina.
Dat zijn geen extra’s. Het is wat opleveren betekent.
Wat een ondernemer zelf kan meten
Ga naar PageSpeed Insights. Vul je URL in. Twee minuten werk.
De mobiele score is de relevante score. Onder de 50 is onacceptabel. Hiervoor riskeer je een indirecte penalty van Google (Core vitals, gauw wegklikken bezoekers) waardoor je lager in de zoekresultaten komt. Onder de 70 is een probleem dat aandacht vraagt. Tussen 70 en 89 is voor verbetering vatbaar. 90 of hoger is goed.
Onder de scores staan de oorzaken. PageSpeed Insights benoemt precies wat traagheid veroorzaakt — je hoeft de techniek niet te begrijpen om te zien waar het knelt. Die lijst is het startpunt voor een gesprek met een bouwer, niet het eindpunt.
Wat je zelf kunt aanpassen: afbeeldingen comprimeren via Squoosh — gratis, geen installatie nodig, kwaliteit instellen op 80% en de bestandsgrootte daalt meestal met 60 tot 80% zonder zichtbaar kwaliteitsverlies. Plugins opschonen: wat gebruik je niet meer? Deactiveren en verwijderen.
Wat je niet zelf moet aanpakken: serveroptimalisatie, database-optimalisatie, het verwijderen van render-blocking resources. Hier is één verkeerde stap genoeg om de site plat te leggen.
Het concrete effect van een trage site
Een pagina die drie seconden laadt verliest gemiddeld 40% van zijn bezoekers ten opzichte van een pagina die in één seconde laadt. Die bezoekers klikken weg voordat ze iets gelezen hebben. Ze bellen niet.
Dat staat los van AI-zichtbaarheid. De lat ligt hoger beschreef al hoe Google en AI-tools steeds meer dezelfde signalen gebruiken. Een trage site scoort slecht op beide fronten — minder bezoekers die blijven, én minder kans dat AI-tools de site als relevante bron herkennen.
Tel je die twee effecten bij elkaar op, dan is een trage laadtijd geen technisch detail. Het is een direct rendementsprobleem.
De test is eenvoudig: pagespeed.web.dev jouw URL, twee minuten. Als de mobiele score onder de 70 zit, is dat de eerste prioriteit — ongeacht hoe mooi de site eruitziet.
Dit artikel is onderdeel van de serie ‘Websites bouwen in het tijdperk van AI‘. De serie gaat over wat er concreet veranderd is — en wat je eraan kunt doen. Niet als technische handleiding, maar als praktische uitleg voor MKB en ZZP ondernemers die willen dat hun website gewoon werkt. Ook in 2026.