Sneller laden, fijner browsen. Dit kun je zelf doen.

Je klikt op een link, het scherm blijft wit, en je drukt na drie seconden op terug. Iedereen doet het. Je bezoekers dus ook. Een trage website kost aandacht, aanvragen en verkopen. En Google houdt er rekening mee.

Het goede nieuws: de oorzaken zijn bijna altijd dezelfde, en een flink deel kun je zelf aanpakken of gericht laten oplossen.

Meet eerst

Ga naar PageSpeed Insights en vul het adres van je belangrijkste pagina in. Je krijgt een score en, belangrijker, een lijst met concrete verbeterpunten. Test ook de mobiele versie, want daar zijn de verschillen het grootst.

Je ziet daar drie termen terugkomen. Samen heten ze de Core Web Vitals:

Largest Contentful Paint (LCP). Hoe snel het grootste element in beeld verschijnt, vaak een foto of een kop. Goed is binnen 2,5 seconden.

Interaction to Next Paint (INP). Hoe snel de pagina reageert als je ergens op klikt of tikt. Goed is binnen 200 milliseconden.

Cumulative Layout Shift (CLS). Hoeveel de pagina verspringt tijdens het laden. Je kent het: je wilt op een knop tikken en net op dat moment schuift er iets in beeld. Goed is een waarde onder 0,1.

Je hoeft deze cijfers niet uit je hoofd te kennen. Ze helpen wel om te begrijpen wat er gemeten wordt, en om na een verbetering te zien of het werkte.

Stap 1: maak je beelden lichter

Bij de meeste trage sites zijn afbeeldingen de grootste boosdoener. Een foto rechtstreeks van een camera of telefoon kan vele megabytes zijn, terwijl hij op je site maar een paar honderd pixels breed wordt getoond.

Verklein foto's tot de maat waarop ze echt worden gebruikt. Gebruik moderne formaten zoals WebP of AVIF, die bij dezelfde kwaliteit veel kleiner zijn dan JPG of PNG. Laat afbeeldingen die pas verderop in de pagina staan later laden, zodat het begin van de pagina sneller in beeld is. Veel websitesystemen kunnen dit automatisch.

Stap 2: voorkom verspringen

Geef afbeeldingen, video's en advertentieblokken vaste afmetingen. Dan reserveert de browser alvast ruimte en springt de pagina niet als ze binnenkomen. Let ook op cookiebanners en meldingen die bovenaan in beeld schuiven en alles naar beneden duwen.

Stap 3: ruim scripts op

Elke chatwidget, elke trackingcode, elke slider en elke plugin laadt extra code. Eén is geen probleem, tien wel. Loop na wat er op je site draait. Gebruik je die chatfunctie echt? Kijk je ooit in die tweede analysetool? Wat niet bijdraagt, kan weg.

Zelf bouw ik websites met Next.js. Dat zet pagina's klaar voordat een bezoeker komt, maakt afbeeldingen automatisch lichter en laadt alleen de code die een pagina echt nodig heeft. Het verschil met een zware paginabouwer zit precies in die stappen: lichtere beelden en minder scripts.

Stap 4: wees zuinig met lettertypes

Mooie lettertypes zijn bestanden die geladen moeten worden. Twee lettertypes met elk vier diktes zijn acht bestanden. Kies wat je echt gebruikt. Laat de tekst al zichtbaar worden in een standaardletter terwijl het eigen lettertype laadt, zodat bezoekers niet naar een leeg scherm kijken.

Stap 5: kijk naar ingesloten video

Een ingesloten YouTube-video laadt veel code, ook als niemand op afspelen drukt. Een veelgebruikte oplossing is eerst alleen een afbeelding met een afspeelknop te tonen, en de video pas te laden na een klik. Vraag je maker ernaar.

Stap 6: hosting en caching

Staat je site op goedkope gedeelde hosting, dan kan de server zelf traag zijn. Caching zorgt ervoor dat pagina's niet bij elk bezoek opnieuw worden opgebouwd. Een CDN levert bestanden vanaf een server dicht bij je bezoeker. Dit zijn technische keuzes, maar het is goed om te weten dat ze bestaan en om er bij je maker of hostingpartij naar te vragen.

Je volgende stap

Test je drie belangrijkste pagina's in PageSpeed Insights en schrijf de scores op. Pak dan eerst de beelden aan, want daar zit meestal de grootste winst. Meet daarna opnieuw. Zo zie je zwart op wit wat je verbetering heeft opgeleverd.

Wil je meer achtergrond? Op web.dev legt Google de Core Web Vitals uitgebreid uit.