Website performance optimaliseren: Core Web Vitals in de praktijk

Google rapporteert dat de kans dat een bezoeker afhaakt met 32% stijgt als de laadtijd van 1 naar 3 seconden gaat. Performance is geen technisch detail, het is direct gekoppeld aan omzet en vindbaarheid. De goede nieuws: de meeste sites laten makkelijke winst liggen. Hieronder waar die zit.

De drie Core Web Vitals

Google meet gebruikerservaring met drie cijfers. Ken je ze, dan weet je waar je op moet sturen.

• LCP (Largest Contentful Paint): hoe snel het grootste element zichtbaar is. Doel: onder 2,5 seconden. Meestal is dit een hero-afbeelding of een grote tekstblok.
• INP (Interaction to Next Paint): hoe snel de pagina reageert op een klik of tik. Doel: onder 200 milliseconden. Dit verving in 2024 de oude FID-meting.
• CLS (Cumulative Layout Shift): hoeveel de layout verspringt tijdens het laden. Doel: onder 0,1. Niets is irritanter dan een knop die wegspringt net als je erop tikt.

LCP verbeteren: de grootste winst

LCP is voor de meeste sites het laagst hangende fruit, en afbeeldingen zijn meestal de boosdoener.

• Comprimeer en converteer afbeeldingen naar moderne formaten zoals WebP of AVIF. Een hero van 2 MB kan vaak naar 150 KB zonder zichtbaar kwaliteitsverlies.
• Geef afbeeldingen de juiste afmeting. Serveer geen 4000px-foto die op 400px getoond wordt.
• Laad belangrijke beelden direct, de rest lazy. De hero meteen, alles onder de vouw pas wanneer de gebruiker scrollt.
• Gebruik een CDN. Cloudflare serveert je bestanden vanaf een server dichtbij de bezoeker.

Onze Next.js-sites halen LCP onder de seconde omdat het framework afbeeldingen automatisch optimaliseert en pagina's statisch serveert via Cloudflare.

INP verbeteren: houd de hoofdthread vrij

Trage reacties op interactie komen bijna altijd door te veel JavaScript dat de browser bezighoudt. De hoofdthread is de keuken: als die vol staat met taken, kan een klik niet door.

• Verklein en bundel JavaScript en verwijder wat je niet gebruikt. Veel sites laden complete bibliotheken voor één functie.
• Stel niet-kritieke scripts uit. Analytics, chat-widgets en trackers hoeven niet bij het laden te draaien.
• Splits code op zodat een pagina alleen laadt wat hij nodig heeft, niet de hele applicatie.

Een derde-partij chat-widget of cookiebanner is vaak de stille moordenaar van INP. Meet wat externe scripts kosten voordat je ze toevoegt.

CLS verbeteren: reserveer ruimte

Layout shift ontstaat als de browser ruimte moet maken voor iets dat later inlaadt. De oplossing is die ruimte vooraf reserveren.

• Geef afbeeldingen en video's vaste afmetingen mee in de code, zodat de browser de ruimte alvast kent.
• Reserveer plek voor advertenties en embeds in plaats van ze content te laten wegduwen.
• Laad lettertypen slim zodat tekst niet verspringt wanneer het echte font binnenkomt.

Meet eerst, fix dan

Optimaliseren zonder meten is gokken. Begin met data:

• PageSpeed Insights geeft je scores en concrete verbeterpunten, met echte gebruikersdata waar beschikbaar.
• Chrome DevTools en Lighthouse laten zien wat er tijdens het laden gebeurt.
• Fix het zwaarste probleem eerst. Eén grote ongecomprimeerde afbeelding fixen levert meer op dan tien micro-optimalisaties.

Performance is geen eenmalige actie. Elke nieuwe functie, elk extra script en elke afbeelding kan het weer omlaag halen. Meet daarom regelmatig, zeker na grote wijzigingen.

Waarom dit geld waard is

Een snelle site converteert beter, scoort hoger in Google en houdt bezoekers langer vast. Voor een webshop is een seconde sneller laden direct meetbaar in omzet. Voor een dienstverlener betekent het meer aanvragen uit hetzelfde verkeer. Bekijk onze webdevelopment-aanpak, waarbij performance vanaf de eerste regel code een uitgangspunt is, geen nazorg.

De stille snelheidskillers

Veel performance-problemen ontstaan niet bij de bouw, maar sluipen er later in. Dit zijn de meest voorkomende boosdoeners die we tegenkomen bij sites die langzaam zijn geworden:

• Externe scripts die zich opstapelen. Elke marketing-tool, chat-widget en trackingpixel voegt laadtijd toe. Drie trackers die elk een halve seconde kosten, kosten samen anderhalve seconde.
• Ongecomprimeerde afbeeldingen via een CMS. Een redacteur die een foto rechtstreeks uit de camera uploadt, plaatst zomaar een bestand van 5 MB op de pagina.
• Een page builder of zwaar thema. Visuele bouwers genereren vaak opgeblazen code met overbodige scripts en stijlen.
• Verouderde plugins. Naast een beveiligingsrisico zijn die ook vaak een rem op de snelheid.

De les: performance is een doorlopende discipline. Stel een budget vast (bijvoorbeeld: de homepage mag niet boven een bepaalde grootte komen) en bewaak dat bij elke wijziging.

Een concreet voorbeeld

Een typische bedrijfssite met een hero-afbeelding van 2 MB, drie ongebruikte JavaScript-libraries en een chat-widget die bij het laden start, scoort al snel een LCP van vier seconden. Comprimeer de afbeelding naar 150 KB, verwijder de ongebruikte libraries en stel de chat-widget uit tot na het laden, en diezelfde pagina zakt naar onder de twee seconden. Geen herbouw, alleen opruimen. Dat is het soort winst dat de meeste sites laten liggen.