Aan een trage website went niemand. Bezoekers klikken weg, formulieren worden halverwege verlaten en de eerste indruk van je bedrijf is er één van stroperigheid. Toch wordt snelheid bij veel projecten behandeld als iets voor later — een optimalisatieronde die je doet als alle functionaliteit af is. Dat is precies verkeerd om. Snelheid is geen bijzaak, maar een feature: iets wat je ontwerpt, meet en bewaakt. Google heeft die ervaring samengevat in drie meetwaarden, de Core Web Vitals. In deze blog leggen we uit wat ze betekenen en hoe je er praktisch mee aan de slag gaat.
Waarom snelheid meer is dan een technisch detail
Prestaties raken direct aan je bedrijfsresultaat. Elke seconde die een bezoeker moet wachten, is een moment waarop hij kan besluiten dat het hem te lang duurt. Bij een webshop of aanvraagformulier vertaalt dat zich rechtstreeks in gemiste omzet.
Daarnaast speelt zichtbaarheid mee. Google gebruikt de Core Web Vitals als onderdeel van de beoordeling van paginakwaliteit. Snelheid is niet de belangrijkste rankingfactor — relevante content blijft leidend — maar bij verder vergelijkbare pagina's kan het net het verschil maken. En omdat de meetwaarden gebaseerd zijn op echte bezoekers, meet je feitelijk hoe je site aanvoelt op een middelmatige telefoon met een matige verbinding. Dat is voor veel bezoekers de realiteit, ook al oogt de site razendsnel op de glasvezelverbinding van kantoor.
De drie Core Web Vitals
Largest Contentful Paint (LCP) meet hoe snel de belangrijkste inhoud van je pagina zichtbaar is — meestal de grote afbeelding of de kop bovenaan het scherm. Het is de beste benadering van "wanneer heeft de bezoeker het gevoel dat de pagina er staat". Een LCP van 2,5 seconden of sneller geldt als goed; boven de 4 seconden is het slecht.
Interaction to Next Paint (INP) meet de reactiesnelheid: hoe lang duurt het voordat de pagina zichtbaar reageert nadat iemand klikt, tikt of typt? Deze meetwaarde heeft in 2024 de oude First Input Delay vervangen en kijkt naar álle interacties tijdens het bezoek, niet alleen de eerste. Onder de 200 milliseconden is goed; boven de 500 milliseconden is slecht.
Cumulative Layout Shift (CLS) meet visuele stabiliteit: verspringt de lay-out terwijl de pagina laadt? Iedereen kent het effect — je wilt op een knop drukken, er laadt een banner in en je klikt op iets heel anders. Een score van 0,1 of lager is goed, boven 0,25 is slecht.
Bij alle drie geldt dat er naar het 75e percentiel van je bezoekers wordt gekeken. Je scoort dus pas goed als driekwart van je bezoeken binnen de norm valt. Dat is bewust streng: het gaat niet om het gemiddelde, maar erom dat de site voor de grote meerderheid prettig werkt.
Waar de vertraging meestal vandaan komt
In de praktijk zien we telkens dezelfde boosdoeners terugkomen.
Bovenaan staan afbeeldingen: te grote bestanden, geen moderne formaten, geen afmetingen in de HTML. Dat laatste is meteen een klassieke oorzaak van layoutverspringingen — zonder opgegeven breedte en hoogte weet de browser niet hoeveel ruimte hij moet reserveren.
Daarna komen externe scripts. Elke chatwidget, cookiebanner, tracker en A/B-testtool die je toevoegt, is extra code die opgehaald en uitgevoerd moet worden. Vaak zijn dit precies de dingen die de reactiesnelheid onderuithalen, en vaak staat er meer op de site dan iemand zich nog herinnert.
Ook lettertypen zijn een veelvoorkomend probleem: als tekst pas verschijnt nadat een custom font is gedownload, staart je bezoeker naar een lege pagina.
Aan de achterkant speelt de serverkant mee. Trage databasequeries, ontbrekende caching en hosting die niet berekend is op het verkeer zorgen ervoor dat de browser al aan de start staat te wachten voordat er ook maar iets te tekenen valt. Hier geldt: de snelste front-end kan een langzame back-end niet compenseren — iets waar we bij het bouwen van webapplicaties in Laravel dan ook expliciet rekening mee houden.
Zo pak je het aan
Begin met meten, niet met sleutelen. Meet zowel in het lab — met tools als Lighthouse of PageSpeed Insights — als in het veld, met data van je echte bezoekers. Labtests wijzen je op oorzaken; velddata vertelt je of het probleem er voor je publiek daadwerkelijk toe doet. Optimaliseer nooit op basis van een enkele testrun.
Kies vervolgens de pagina's die er commercieel toe doen: de homepage, de belangrijkste landingspagina's, de productpagina en het bestel- of aanvraagproces. Een perfecte score op een zelden bezochte pagina levert je niets op.
De grootste winst zit meestal in een paar concrete ingrepen. Comprimeer afbeeldingen en serveer ze in moderne formaten en op de juiste afmetingen. Geef altijd breedte en hoogte mee. Ruim externe scripts op: schrap wat je niet gebruikt en laad de rest zo laat mogelijk. Zorg dat tekst direct zichtbaar is, ook als het lettertype nog laadt. En regel caching op zowel server- als browserniveau goed in.
Tot slot: houd het vast. Prestaties eroderen sluipenderwijs, doordat er een plugin bijkomt of een marketingscript wordt toegevoegd. Spreek daarom een prestatiebudget af — een harde grens voor bijvoorbeeld het gewicht van een pagina — en meet structureel, zodat je een terugval ziet vóórdat je klanten hem voelen.
Hoe snel is jouw site echt?
Websitesnelheid is geen eenmalige opschoonactie maar een kwaliteitseis, net als veiligheid en toegankelijkheid. Het mooie is dat de meeste verbeteringen niet spectaculair zijn: het zijn tientallen kleine, goed uitgevoerde beslissingen die samen het verschil maken tussen een site die soepel aanvoelt en een site waar bezoekers ongeduldig van worden.
Benieuwd hoe jouw website of webapplicatie scoort, en waar de grootste winst te halen valt? CodeBros voert graag een performance-analyse uit en vertaalt de uitkomsten naar een concreet verbeterplan. Neem contact met ons op voor een vrijblijvend gesprek.