Website sneller maken: wat echt werkt, met onze eigen cijfers

Iedereen zegt dat een website snel moet zijn. Veel minder mensen laten zien wat ze precies deden en wat het opleverde. Wij houden bij elke optimalisatieronde de meetwaarden bij, ook op onze eigen site, dus dit artikel gaat over wat echt werkt, wat zonde van je tijd is en hoe een meting je voor de gek kan houden.

Kort antwoord: de grootste winst zit zelden in je hosting. Hij zit in scripts die te vroeg laden, in beeld en video die te zwaar zijn en in lettertypen en CSS die het tekenen van de pagina tegenhouden. Onze mobiele score ging van 38 naar 87, het paginagewicht van ongeveer 9,5 MB naar 1,3 MB en de blokkeertijd van bijna zes seconden naar onder de tiende van een seconde. Voor ondernemers in de hoofdstad nemen we dit meteen mee, zie website laten maken in Amsterdam.

Wat drie optimalisatierondes opleverden

Dit zijn de cijfers van een beeldrijke site: een homepage met een videoslider, een projectgalerij en een chatfunctie. Zulke sites starten nooit hoog, want elk van die onderdelen brengt gewicht mee. Mobiel gemeten, van de eerste meting in augustus 2026 tot na drie rondes.

• Prestatiescore: eerst 38 van de 100, na de eerste ronde 66 en in oktober 87.
• Blokkeertijd: van 5.910 milliseconden naar 300 en later naar 60. De norm is 200.
• Paginagewicht: van ongeveer 9,5 MB naar 1,3 MB.
• JavaScript: van 414 naar 332 kB verpakt, nadat we de vertaallaag uit de browser haalden.
• Verschuivende tekst: van 0,207 op blogpagina’s terug naar 0. Dat kwam door het lettertype, daarover verderop meer.

1. Zet zware scripts op een later moment

Een chatwidget staat meestal op elke pagina en neemt zijn animatiebibliotheek meteen mee, terwijl niemand hem in de eerste seconden gebruikt. Hij kan dus wachten tot de pagina klaar is of tot iemand hem aanraakt. Dat was in één ingreep de grootste winst van de hele ronde: de blokkeertijd ging van 5.910 naar 300 milliseconden, een daling van 95 procent. Kijk daarom eerst naar chatwidgets, cookiebanners, reviewsliders en alles wat van een derde partij komt.

2. Laat video en beeld pas laden als ze nodig zijn

Op een dienstpagina met meerdere achtergrondvideo’s laadden die allemaal tegelijk. Door ze pas te laden wanneer ze in beeld komen, ging die pagina van 4,1 MB naar 0,67 MB. Bij beeld geldt hetzelfde: alleen het eerste beeld dat de bezoeker ziet mag met voorrang laden, de rest wacht. Een achtergrondvideo van 10 MB valt verder op geen enkele manier op, behalve in een meting. Dat soort dingen vind je niet door te kijken maar door te meten.

3. Laat meetscripts wachten op de eerste interactie

Analytics en advertentiepixels horen niet in de eerste seconde thuis. Laad ze pas bij de eerste interactie, met een terugvaltimer voor het geval niemand iets doet. Let op de valkuil: laat die timer niet vanaf het laden van de pagina lopen, want dan valt hij precies in het venster dat gemeten wordt en gaat je score juist omlaag. Vanaf het moment dat de pagina klaar is, klopt het wel. Controleer meteen of je meetcode niet dubbel binnenkomt, rechtstreeks via de pagina en nog eens via de tagmanager. Dat scheelde 190 kB.

4. Waar een meting bijna altijd iets vindt

• Een favicon dat in werkelijkheid het volledige logo is. Zo stuur je 275 kB mee bij elk paginabezoek, terwijl 64 pixels genoeg is.
• Hetzelfde logo dat op drie plekken in drie formaten wordt opgehaald, bijvoorbeeld door de header, een script en de chatfunctie. Één bron is genoeg.
• Studiofoto’s van 45 megapixel die rechtstreeks uit de camera het CMS in gaan en daarna op tientallen plekken terugkomen.
• Kaarten onder de vouw die op voorrang laden en zo met het hero-beeld om bandbreedte vechten.

5. Haal lettertype en CSS uit het kritieke pad

Google Fonts houdt het tekenen van een pagina al snel ruim een seconde tegen, bij ons 1,6 seconde, doordat het stylesheet eerst geladen moest worden en pas daarna de lettertypebestanden. Door dat stylesheet niet blokkerend te laden verdween die wachttijd. Daar kwam wel iets voor terug: de browser tekende eerst met een vervangend lettertype en bij het omwisselen verschoof de tekst, tot 0,207 aan verschuiving op blogpagina’s. De oplossing was een terugvallettertype dat exact dezelfde regelbreedte heeft, zodat er bij het wisselen niets meer beweegt. Daarna stond de verschuiving weer op nul. Onze blok-CSS hebben we bovendien per component gesplitst: op blogpagina’s ging dat van 171 naar 19 kB.

Wat we probeerden en wat niet werkte

• Een extra beeldformaat aanzetten. Dezelfde acht beelden werden tien procent kleiner, maar een beeld dat nog niet klaarstond ging van ongeveer 70 naar 480 milliseconden. Teruggedraaid.
• Elk blok apart laden. De bouwtool voegde ze in productie alsnog samen. Gemeten verschil: één kilobyte, de verkeerde kant op.
• Pagina’s op de rand van het netwerk cachen. Drie varianten geprobeerd, geen enkele hielp zolang de pagina per bezoeker wordt opgebouwd. Teruggedraaid en opnieuw uitgerold.

Dat laatste is misschien wel de belangrijkste les: draai een wijziging terug die niets oplevert. Anders houd je een site over vol ingrepen die niemand meer durft aan te raken.

Meet je het eigenlijk wel goed?

Een meting gaf ons een keer een 97 op mobiel. Prachtig cijfer, alleen klopte het niet: twee van de belangrijkste meetwaarden stonden op een foutmelding en die twee zijn samen goed voor meer dan de helft van de score. De oorzaak was een animatie waarbij alles boven de vouw op onzichtbaar begint en daarna infaadt, want dan registreert de browser geen enkel element om de laadtijd aan af te meten. Na de aanpassing stond er een 84 die wel echt was. Een eerlijke 84 zegt meer dan een 97 die nergens op slaat. Drie dingen om te onthouden:

1. Controleer of alle meetwaarden een getal hebben. Een score met een gat erin is niet vergelijkbaar.
2. Meet meerdere keren en op mobiel. Eén meting zegt weinig.
3. Stop lokale servers voordat je meet, anders meet je je eigen computer. Wij hadden zo een uitschieter van 7.640 milliseconden.

Maakt snelheid uit voor Google?

Snelheid is een signaal, geen hoofdprijs. Een trage pagina met het beste antwoord wint het nog steeds van een snelle pagina zonder inhoud. Maar snelheid raakt wel alles eromheen: mensen haken af, formulieren worden minder ingevuld en bots halen minder op bij elk bezoek. Dus zie het als onderhoud, niet als scorejacht. Meer daarover in hoe je de conversie van je website verhoogt en in wat website-onderhoud kost.

Waar je zelf begint

1. Meet je belangrijkste pagina op mobiel en schrijf de waarden op.
2. Kijk welke scripts van derden meteen laden en zet ze uit of stel ze uit.
3. Zoek het zwaarste beeld of de zwaarste video op die pagina en vervang of verlaat hem.
4. Controleer of je lettertype het tekenen tegenhoudt.
5. Meet opnieuw en bewaar het verschil, zodat je weet wat werkte.

Veelgestelde vragen

Kortom

Een snellere website is zelden één grote ingreep. Het is een rij kleine beslissingen: wat laadt er wanneer, hoe zwaar is het en houdt het iets tegen. Begin met meten, pak de zwaarste post aan en meet opnieuw. Wil je dat je site daarbij ook goed gelezen wordt door zoekmachines en AI-antwoorden, lees dan hoe je vindbaar wordt in ChatGPT.

Lees ook

• Webbouwer kiezen in Oosterhout: waar moet je op letten?
• Webdesignbureau kiezen in Waalwijk: kosten, maatwerk en lokale SEO
• Google Ads of SEO? Wanneer je wat inzet
• Website laten maken voor ZZP: waar moet je op letten?
• Google Ads uitbesteden: kosten, werkwijze en wat het oplevert
• Hoe lang duurt het om een website te laten maken?
• Wat is een headless website (en waarom Next.js)?
• AI-chatbot voor je website laten maken: zo pak je het slim aan
• Waarom staat mijn website niet in Google? 10 oorzaken en oplossingen