Hoe snel is snel genoeg?
Een bezoeker die op je link tikt, gunt je geen minuut. Onderzoek van onder meer Google toont al jaren dezelfde vuistregel: reageert een pagina binnen een seconde of twee, dan blijft vrijwel iedereen; duurt het langer dan een seconde of drie, dan haakt een flink deel af nog vóór er iets op het scherm staat. Ze zien geen foutmelding en geen half geladen pagina, ze zien je zaak gewoon nooit.
Erger nog: die afhakers tellen dubbel. Google meet mee hoe snel je pagina’s zijn en verwerkt dat in de rangschikking, onder de noemer Core Web Vitals. In mensentaal zijn dat drie vragen. Hoe snel verschijnt het grootste element, meestal je titel of je hoofdafbeelding? Hoe snel reageert de pagina als iemand ergens op tikt? En verspringt de boel nog terwijl alles inlaadt, zodat je op de verkeerde knop drukt? Snel, meteen en stabiel: dat is wat zowel je bezoeker als Google wil zien.
Snelheid is dus geen technisch detail voor de bouwer, maar de eerste indruk die je maakt nog vóór je eerste woord gelezen is. Een trage site staat te hakkelen, terwijl de concurrent ernaast gewoon opendoet.
Test het zelf in één minuut
Je hoeft niemand op zijn woord te geloven, jezelf incluis. Surf naar pagespeed.web.dev, het gratis meetinstrument PageSpeed Insights van Google zelf. Plak het adres van je site in het vak, druk op analyseren, en na een halve minuut heb je een score van 0 tot 100 plus, belangrijker, een lijst met wat je pagina precies traag maakt.
Eén detail bepaalt of de meting iets zegt: kijk naar de gsm-score, niet naar de desktop-score. Het rapport toont beide, en de desktop-score oogt bijna altijd mooier. Maar het gros van je bezoekers komt binnen via de gsm, vaak op een matige verbinding onderweg, en dat is precies waar de geruststellende desktop-cijfers je op het verkeerde been zetten.
De zes oorzaken (en hoe je ze herkent)
Bijna elke trage site struikelt over dezelfde handvol dingen. Hieronder de zes klassiekers, met hoe je ze zelf herkent en wat de oplossing is. Waarschijnlijk knik je bij minstens twee ervan.
| Oorzaak | Herkenning | Oplossing |
|---|---|---|
| Te zware afbeeldingen | Foto’s van 5 MB die recht van de camera of de gsm op de site zijn gezet, veel groter dan het scherm ze ooit toont. | Verklein en comprimeer elke foto vóór upload. Dit levert doorgaans de grootste winst voor de minste moeite. |
| Thema- en plugin-ballast | Een kant-en-klaar thema dat alles kan en daarom bij elke bezoeker ook alles laadt, plus een lange lijst plugins die ooit “handig leek”. | Gooi weg wat je niet gebruikt en kies een thema dat past bij wat je site echt doet, niet bij wat het theoretisch zou kunnen. |
| Trage of overvolle hosting | Het goedkoopste hostingpakket, gedeeld met honderden andere sites die samen om dezelfde server vechten. | Stap over naar degelijke hosting. Een van de weinige knoppen waar wat meer geld direct tijd wint. |
| Scripts van derden | Chatwidgets, trackers en ingesloten video’s die elk stiekem code van een andere website ophalen voor ze iets tonen. | Houd alleen wat echt iets oplevert en laad de rest pas als het nodig is, niet meteen bij het openen. |
| Geen caching | Elke bezoeker krijgt de pagina volledig opnieuw opgebouwd, alsof de site hem voor het eerst ziet. | Zet caching aan, zodat de site een klaargezette versie serveert in plaats van alles telkens opnieuw te berekenen. |
| Video of slider bovenaan | Een automatisch spelende video of een draaiende slider helemaal bovenaan: het zwaarste element op de belangrijkste plek. | Vervang het door één sterke foto. Die laadt in een fractie van de tijd en verkoopt vaak beter dan een carrousel die niemand uitkijkt. |
De volgorde is niet toevallig: afbeeldingen en hosting leveren doorgaans de grootste winst voor de minste moeite.
WordPress traag? De drie gebruikelijke verdachten
Meer dan de helft van de trage sites die wij te zien krijgen draait op WordPress, en vrijwel nooit ligt dat aan WordPress zelf. Het systeem is prima; de stapel die er in de loop van de jaren bovenop is gezet, is het probleem. Wil je je WordPress website sneller maken, begin dan bij deze drie verdachten:
- De pagebuilder. Visuele bouwers zoals Elementor of Divi zijn handig, maar voegen per element extra lagen code toe die elke bezoeker moet downloaden. Een pagina die er eenvoudig uitziet, kan onder de motorkap tien keer zwaarder zijn dan nodig.
- De pluginstapel. Elke plugin laadt zijn eigen scripts en stijlen, vaak op álle pagina’s, ook waar hij niets doet. Boven de twintig actieve plugins is opruimen bijna altijd de snelste winst: schakel op een testkopie de helft uit en meet het verschil.
- De instaphosting. WordPress bouwt elke pagina per bezoeker opnieuw op en voelt dat op traag gedeeld hosting dubbel. Degelijke hosting met caching erop scheelt vaak meer dan alle plugin-optimalisaties samen.
De volgorde van aanpak: eerst meten op pagespeed.web.dev, dan plugins en builder-ballast afbouwen, dan hosting en caching. Pas als dat allemaal gebeurd is en de cijfers nog altijd rood staan, is het thema of de constructie zelf het plafond.
Wat een trage site je echt kost
Reken even mee, voorzichtig en zonder schijnprecisie. Stel dat je site 1.000 bezoekers per maand trekt, wat voor een lokale zaak heel gewoon is. En stel dat hij zo traag laadt dat een kwart afhaakt nog vóór de pagina staat. Dan zijn dat 250 mensen per maand die op je link tikten, interesse hadden en toch nooit iets van je zagen. Elke maand opnieuw.
Je hoeft daar geen exacte omzet op te plakken om te voelen dat dit pijn doet. Een deel van die tweehonderdvijftig bezoekers had gebeld, een offerte gevraagd of iets gekocht. Zet daar de kost van een goede, snelle site tegenover, die je één keer betaalt: een handvol extra klanten per maand verdient die investering doorgaans binnen het jaar terug. Trage laadtijd is dan letterlijk geld dat aan de deur blijft staan.
En er is een stil tweede verlies. Google toont trage sites minder graag, dus je verliest niet alleen de bezoekers die afhaken, maar ook een deel van de mensen die je door een lagere positie nooit bereikt. Zo betaal je twee keer voor dezelfde traagheid: eenmaal aan de voordeur en eenmaal bovenaan de zoekresultaten.
Sneller worden zonder alles opnieuw te bouwen
Het goede nieuws uit de oorzakentabel: de meeste zijn op te lossen zonder je site af te breken. Begin bij de quick wins, en ongeveer in deze volgorde, want ze staan gerangschikt van meeste naar minste winst per uur werk:
- Verklein en comprimeer je afbeeldingen vóór je ze uploadt. Vaak halveer je in één namiddag het gewicht van de hele site.
- Gooi ongebruikte plugins en scripts weg. Elk stukje dat je schrapt, is code die niet meer geladen hoeft te worden.
- Zet caching aan. Zo bouwt de site zichzelf niet voor elke bezoeker opnieuw op, maar dient hij een klaargezette versie.
- Neem betere hosting. De overstap is meestal een kwestie van dagen, en het verschil voel je bij de eerste klik.
- Vervang de video of slider bovenaan door één sterke foto. Lichter, sneller en meestal overtuigender.
Werk deze lijst af en veel sites zitten weer ruim onder de pijngrens. Eén eerlijke kanttekening: soms is het thema of het platform zelf het plafond. Als de fundering log en verouderd is, blijf je pleisters plakken op iets dat traag ontworpen is, en dan is opnieuw bouwen de enige echte fix. Waar je bij die keuze op let, van eigendom tot redirects, staat in de checklist-gids.
De doelen die je je bouwer meegeeft
Of je nu zelf opruimt of het uitbesteedt: spreek meetbare doelen af in plaats van “maak hem wat sneller”. Google publiceert daarvoor officiële drempelwaarden, de Core Web Vitals. Dit zijn ze, in mensentaal:
| Meetpunt | Doel | In mensentaal |
|---|---|---|
| LCP | ≤ 2,5 s | Het grootste element (je titel of hoofdfoto) staat binnen tweeënhalve seconde op het scherm. |
| INP | ≤ 200 ms | Wie ergens op tikt, voelt de reactie meteen, niet na een denkpauze. |
| CLS | ≤ 0,1 | De pagina verspringt niet meer terwijl hij laadt, dus niemand drukt op de verkeerde knop. |
Officiële drempels van Google, te meten op pagespeed.web.dev, telkens op de gsm-score.
En dit is de briefing die je letterlijk kunt doorsturen naar wie je site onderhoudt of herbouwt:
- Haal de drie Core Web Vitals groen op de gsm-meting van pagespeed.web.dev, voor de homepage én de twee belangrijkste dienstpagina’s.
- Comprimeer alle afbeeldingen en lever ze aan op het formaat waarop ze getoond worden.
- Verwijder plugins en scripts die niets meer doen, en laad wat overblijft pas wanneer het nodig is.
- Zet caching aan en onderbouw de hostingkeuze.
- Stuur een meting van vóór en na, zodat de verbetering zwart op wit staat.
Kost de opruimbeurt meer dan een paar honderd euro, vraag dan eerst wat een herbouw zou kosten; vanaf een bepaald punt is doorbouwen op een log fundament duurder dan opnieuw beginnen. Waar dat kantelpunt ligt, staat in de gids over vernieuwen of opnieuw beginnen.