Waarom laadt uw website langzaam? Oorzaken en oplossingen

Een trage website kost u zelden in één keer een klant, maar wel geleidelijk. Een inkoper die tussen twee afspraken door op zijn telefoon drie leveranciers vergelijkt, wacht niet op een pagina die blijft laden. Daarnaast gebruikt Google de Core Web Vitals als een van de signalen voor paginabeleving. Snelheid is dus geen technisch detail, maar onderdeel van hoe uw bedrijf overkomt.

In dit artikel leest u hoe u vaststelt waar het probleem zit, welke oorzaken wij in de praktijk het vaakst tegenkomen en in welke volgorde u ze aanpakt. Er bestaat geen enkele instelling die alles oplost, wel een vaste aanpak die werkt.

01Meet eerst: drie cijfers die ertoe doen

Google beoordeelt snelheid met drie Core Web Vitals. Largest Contentful Paint (LCP) meet wanneer het grootste zichtbare element is geladen, meestal een foto of een kop; goed is 2,5 seconden of minder. Interaction to Next Paint (INP) meet hoe snel de pagina reageert op klikken en tikken; goed is 200 milliseconden of minder. INP verving in maart 2024 de oudere First Input Delay. Cumulative Layout Shift (CLS) meet hoeveel de inhoud verspringt tijdens het laden; goed is 0,1 of minder. Google kijkt daarbij naar het 75e percentiel van echte bezoeken: drie op de vier bezoeken moeten binnen de grens blijven.

Let op het verschil tussen veldgegevens en labgegevens. PageSpeed Insights toont bovenaan veldgegevens van echte Chrome-gebruikers over de afgelopen 28 dagen, maar alleen als uw site genoeg verkeer heeft. Daaronder staat een Lighthouse-test: een gesimuleerde meting op een middenklasse telefoon met een vertraagde verbinding. Veel zakelijke websites hebben te weinig verkeer voor veldgegevens. Dan zijn de labmetingen en het rapport Core Web Vitals in Google Search Console uw belangrijkste bronnen. Zo maakt u in een halfuur een nulmeting:

1. Kies de vijf pagina's die voor uw omzet het zwaarst wegen: de homepage, uw belangrijkste dienstpagina, een referentie of case, de contactpagina en de landingspagina van uw advertenties.
2. Test elke pagina in PageSpeed Insights op mobiel en noteer LCP, INP (in de labtest Total Blocking Time) en CLS.
3. Kijk in het rapport welk element als LCP is aangewezen. Vaak is dat een grote foto of slider bovenaan.
4. Open het rapport Core Web Vitals in Search Console en kijk welke groepen URL's als ‘Slecht’ of ‘Verbetering nodig’ staan.
5. Leg de cijfers vast met datum. Zonder nulmeting weet u later niet of een aanpassing iets heeft opgeleverd.

02De oorzaken die wij het vaakst tegenkomen

Een trage server. Voordat de browser iets kan tonen, moet de server de pagina opbouwen. Op goedkope gedeelde hosting, zonder paginacache en met tientallen databasequery's per verzoek, kan dat al een groot deel van de beschikbare tijd kosten. Dit ziet u terug als een hoge Time to First Byte (TTFB); Google adviseert 0,8 seconden of minder. Staan uw bezoekers vooral in Nederland en België, dan ligt een server in een West-Europees datacenter voor de hand. Dat scheelt afstand en maakt ook de afweging onder de AVG eenvoudiger.

Te zware afbeeldingen. Een foto van enkele megabytes die op een telefoon 400 pixels breed wordt getoond, is nog steeds de meest voorkomende oorzaak van een hoge LCP. Andere klassiekers: geen moderne formaten zoals WebP of AVIF, één bestandsgrootte voor alle schermen, en lazy loading op de hoofdafbeelding bovenaan, waardoor de browser die juist later gaat ophalen. Ontbreken breedte en hoogte in de HTML, dan verspringt de pagina zodra de foto binnenkomt en stijgt uw CLS.

Te veel JavaScript en externe scripts. Sliders, paginabouwers, chatwidgets, A/B-testtools, ingesloten video's en een tagmanager vol oude tags: elk script moet worden gedownload én uitgevoerd. Terwijl de browser daarmee bezig is, reageert de pagina traag op invoer. Dat is de belangrijkste oorzaak van een slechte INP. Vaak weet niemand meer waarom een bepaald script er staat. Ook een cookiebanner kan een rem worden als hij zelf veel code laadt.

Lettertypen van externe servers. Drie lettertypefamilies in vijf gewichten, geladen van een externe dienst, vertragen de eerste weergave en laten tekst verspringen. Door lettertypen zelf te hosten, ze te beperken tot de tekens en gewichten die u echt gebruikt en het belangrijkste vooraf te laden, wint u tijd. Bijkomend voordeel: de IP-adressen van uw bezoekers gaan dan niet naar een derde partij.

03Wat u het eerst aanpakt

Niet elke verbetering levert evenveel op. Wij werken meestal in deze volgorde, omdat elke stap de volgende eenvoudiger maakt:

1. Server en caching: paginacache waar mogelijk, OPcache voor PHP, compressie met Brotli of gzip, HTTP/2 of HTTP/3 en zo nodig een CDN.
2. Het LCP-element: de juiste afmetingen, een modern formaat, meerdere formaten via srcset, een hoge laadprioriteit via fetchpriority en nooit lazy loading voor deze afbeelding.
3. Ruimte reserveren: breedte en hoogte op alle afbeeldingen, een vaste beeldverhouding voor video's en kaarten, en geen balken die de inhoud na het laden omlaag duwen.
4. JavaScript snoeien: ongebruikte scripts verwijderen, de rest uitgesteld laden en zware onderdelen zoals chat en video pas laden na een klik.
5. Lettertypen: zelf hosten, beperken tot twee gewichten en font-display gebruiken, zodat tekst direct zichtbaar is.

Een veelvoorkomend voorbeeld bij dienstverleners: de homepage opent met een slider van vijf grote foto's, er draait een chatwidget en de tagmanager laadt scripts van campagnes die al jaren voorbij zijn. Eén goed gecomprimeerde hoofdafbeelding in plaats van de slider, een chatknop die het script pas bij een klik laadt en een opgeschoonde tagmanager veranderen visueel weinig, maar halen een groot deel van het werk weg dat de browser moet doen.

04Snel blijven: snelheid is onderhoud

Een website wordt zelden in één keer traag. Het gebeurt geleidelijk: een nieuwe video op de homepage, een extra trackingtag voor een campagne, een plug-in voor één formulier. Spreek daarom een prestatiebudget af, bijvoorbeeld een maximaal paginagewicht, een maximale hoeveelheid JavaScript en een LCP onder 2,5 seconden op mobiel, en toets elke wijziging daaraan. Leg dit budget vast in de opdracht aan uw webbouwer, zodat het een afspraak is en geen voornemen.

• Test elk kwartaal dezelfde vijf pagina's opnieuw en vergelijk de cijfers met uw nulmeting.
• Loop twee keer per jaar uw tagmanager na en verwijder tags die niemand meer gebruikt.
• Laat uw CMS geüploade foto's automatisch verkleinen en omzetten, zodat redacteuren daar niet aan hoeven te denken.
• Houd framework, pakketten en serversoftware up-to-date; nieuwe versies zijn vaak ook sneller.
• Controleer na elke grote wijziging het rapport in Search Console.

Wanneer is optimaliseren niet meer genoeg? Als het grootste deel van het JavaScript uit een thema of paginabouwer komt die u niet kunt weglaten, als elke verbetering iets anders breekt, of als u de hosting niet zelf kunt kiezen. Dan is een nieuwe, lichtere opbouw vaak voordeliger dan blijven repareren. In alle andere gevallen geldt: eerst meten, dan in deze volgorde verbeteren.

Wilt u een eerste indruk van uw eigen site? De snelheidscheck op onze homepage meet uw homepage op mobiel en toont binnen een minuut de belangrijkste cijfers. Voor een volledige analyse bekijken wij in een intake uw belangrijkste pagina's en de opbouw erachter.