Waarom is je website zo traag? En wat je eraan doet

In verreweg de meeste gevallen is het een van deze vier: te zware afbeeldingen, te veel plugins die elk hun eigen code meeslepen, goedkope gedeelde hosting waar je server het gewoon niet bijhoudt, of een thema dat vol zit met functies die je nooit gebruikt. Begin bij de afbeeldingen, want dat is bijna altijd de grootste winst voor het minste werk. Daarna kijk je naar de rest, in de volgorde hieronder.

Wat het bijna nooit is: iets mysterieus. Een trage site is meestal een site waar in de loop van twee jaar spullen bij zijn gekomen en nooit iets af is gegaan.

Hoe traag is traag eigenlijk?

Voordat je gaat sleutelen, meet je even. Zet je adres in Google PageSpeed Insights en kijk niet naar het cijfer bovenaan, maar naar de Largest Contentful Paint. Dat is het moment waarop het grootste zichtbare element op je scherm klaar is, en het is de beste enkele maat voor “wanneer voelt deze pagina geladen”. Google schrijft daarover: “To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less”, gemeten bij het 75e percentiel van je bezoekers.

Zit je daar ruim boven op mobiel, dan is er echt iets aan de hand. Zit je op 2,8 seconden, dan is dat geen ramp en is het de vraag of je er je weekend aan wil besteden.

En laat je niet gek maken door de score. Een perfecte honderd in PageSpeed Insights is een leuke sport, maar het is een testresultaat, geen omzet. Het verschil tussen acht seconden en drie merken je bezoekers. Het verschil tussen 92 en 98 niet.

Waarom zijn afbeeldingen bijna altijd de eerste oorzaak?

Omdat een foto rechtstreeks uit een telefoon of camera al snel drie tot vijf megabyte is, terwijl je hem op een website weergeeft in een vakje van achthonderd pixels breed. Die hele foto wordt wel gedownload. Op je eigen glasvezel merk je dat niet. Iemand met vier streepjes 4G in de trein wel.

Dat het geen randgeval is, blijkt uit de meting van HTTP Archive. In de Web Almanac 2025 weegt een mediane mobiele homepage 2,56 MB, waarvan ongeveer 911 KB aan afbeeldingen. Afbeeldingen zijn daarmee de zwaarste categorie op de gemiddelde pagina, goed voor zo’n 36 procent van het totaal.

Wat je eraan doet: schaal je afbeeldingen terug naar het formaat waarop ze getoond worden voordat je ze uploadt, en sla ze op in een modern formaat als WebP. In WordPress doet een plugin als ShortPixel of Imagify dat automatisch voor je hele mediabibliotheek, inclusief wat er al op staat. Zet daarnaast lazy loading aan, zodat afbeeldingen onderaan de pagina pas laden als iemand er echt naartoe scrolt. Dat is bij moderne WordPress-versies standaard, maar niet elk thema doet het goed.

Deze ene stap haalt op een verwaarloosde site vaak meer dan de helft van het gewicht weg.

Hoeveel plugins zijn te veel?

De vraag is niet hoeveel je er hebt, maar wat ze doen. Twintig kleine plugins die alleen iets in de beheeromgeving regelen kosten je bezoeker niets. Drie plugins die op elke pagina hun eigen stylesheet en JavaScript inladen, ook op pagina’s waar ze niets doen, kosten je bezoeker wel iets.

De klassieke boosdoeners zijn sliders, pagebuilders, contactformulieren met te veel opties, en alles met “all in one” in de naam. Verder loopt het vaak mis met dubbelop: twee cachingplugins naast elkaar, of een SEO-plugin plus een SEO-functie in je thema die elkaar in de weg zitten.

Loop je lijst een keer door en stel per plugin twee vragen. Gebruik ik dit nog? En werd deze in de afgelopen twaalf maanden bijgewerkt? Een plugin die twee jaar stilligt is niet alleen traag, hij is ook een beveiligingsrisico. Deactiveren is niet genoeg; verwijderen wel.

Ligt het aan je hosting?

Soms wel, en dat merk je aan één specifiek symptoom: de pagina blijft eerst een paar seconden helemaal leeg voordat er überhaupt iets gebeurt. Dat is de servertijd, en die staat los van hoe zwaar je pagina is. Zie je in PageSpeed Insights een hoge “server response time” of een trage Time to First Byte, dan ligt het aan de machine, niet aan je content.

Bij goedkope gedeelde hosting deel je een server met honderden andere sites. Krijgt de buurman een drukke dag, dan voel jij dat. Kleine hostingpakketten knijpen bovendien het aantal processen en het geheugen af, en WordPress heeft daar meer van nodig dan een simpele HTML-site.

Drie dingen die hier vaak schelen. Controleer welke PHP-versie je draait, want oudere versies zijn merkbaar trager en krijgen geen beveiligingsupdates meer. Zet server-side caching aan als je host dat aanbiedt. En kijk waar de server staat: een Nederlandse doelgroep op een server in Texas begint elke pagina met een achterstand die je nergens meer inhaalt.

Helpt dat allemaal niet, dan is verhuizen naar een pakket dat wel bij je site past de eerlijkste oplossing. Hoe zo’n verhuizing verloopt staat in Website verhuizen naar een andere hostingpartij.

Wat doet je thema ermee?

Meer dan de meeste mensen denken. Multipurpose-thema’s uit een themamarkt worden verkocht op het aantal meegeleverde ontwerpen, en die code zit er allemaal in, ook de veertien demo’s die je nooit gebruikt. Combineer dat met een pagebuilder en je hebt op elke pagina lagen code die alleen bestaan om iets flexibel te maken wat jij één keer hebt ingesteld.

Dat is geen reden om je site meteen te herbouwen. Maar als je toch al aan het overwegen bent om te vernieuwen, is dit het moment waarop snelheid van een probleem in een keuze verandert. Een licht thema dat doet wat jij nodig hebt is sneller dan welke optimalisatieplugin dan ook op een zwaar thema.

En al die dingen van buitenaf?

Elk script van een ander domein is een extra verbinding die je bezoeker moet opzetten voordat je pagina af is. Een chatwidget, een reviewbalk, drie trackingpixels, een ingesloten YouTube-video, lettertypen die van Google’s servers komen: apart valt het mee, bij elkaar is het vaak een halve seconde of meer.

Twee makkelijke winsten. Host je lettertypen lokaal in plaats van ze bij Google op te halen, want dat is sneller én het scheelt je een privacyvraag. En vervang een ingesloten video op je homepage door een klikbare afbeelding die de video pas laadt als iemand op play drukt.

Wat controleer je zelf, in welke volgorde?

Meet eerst, zodat je straks weet of je iets hebt bereikt. Noteer je LCP op mobiel.

Kijk dan naar het gewicht van je pagina en welk bestand het zwaarst is. Is dat een afbeelding, dan weet je genoeg en begin je daar. Comprimeer alles, zet lazy loading aan, meet opnieuw.

Ruim daarna je plugins op en verwijder wat je niet gebruikt. Zet vervolgens caching aan, als je dat nog niet had, via je host of via één cachingplugin. Eén, niet twee.

Meet nu opnieuw. Is je LCP nog steeds hoog terwijl je pagina licht is geworden, dan zit het in de server en is hosting je volgende stap. Zijn de cijfers goed maar voelt de site nog traag, kijk dan naar wat er van externe domeinen wordt ingeladen.

En verander één ding tegelijk. Zet je vier dingen tegelijk om en het wordt langzamer, dan weet je niet welke het was.

Wanneer geef je het uit handen?

Als je alles hierboven hebt gedaan en het is nog steeds traag, dan zit het probleem dieper: in de databank, in het thema, of in een plugin die zich niet gedraagt. Op dat punt is doorzoeken op eigen houtje meestal duurder dan het uitbesteden, gerekend in je eigen uren.

Dat geldt ook als je merkt dat het steeds terugkomt. Een site die je één keer opschoont wordt binnen een jaar weer traag als er niemand op let, want er komen plugins bij, er worden foto’s geüpload en er groeit rommel in de databank. Dat is precies wat er onder hosting en beheer gebeurt: hosting die bij je site past, updates en caching bijgehouden, en iemand die het merkt als de laadtijd wegloopt. Voordat je klanten het merken.

Gaat het niet om traag maar om helemaal niet bereikbaar, dan is dat een ander probleem met een andere volgorde. Die staat in Je website is offline: wat controleer je eerst?