Performance-optimalisatie voor websites

Het korte antwoord

Website-performance-optimalisatie betekent dat je een merkbaar trage bezoekersroute meet, de grootste technische oorzaak opspoort en precies die oorzaak aanpakt. Daarna controleer je dezelfde route opnieuw. Een PageSpeed-score kan het onderzoek starten. Metingen van echte bezoeken laten zien of er werkelijk een probleem is en of de verbetering standhoudt.

Begin daarom niet met alle afbeeldingen, scripts en lettertypen tegelijk. Kies bijvoorbeeld de mobiele landingspagina waarop de meeste aanvragen beginnen. Leg vast wat daar misgaat, onderzoek de vertraging en voer één samenhangende wijziging uit. Zo blijft zichtbaar welk werk effect had.

Wat merkt een bezoeker van een trage website?

Snelheid gaat verder dan wachten tot een pagina zichtbaar is. Een bezoeker kan de hoofdinhoud laat zien verschijnen, na een klik te lang op reactie wachten of per ongeluk de verkeerde knop raken doordat onderdelen verspringen. Een formulier kan bovendien snel openen en tijdens het typen alsnog haperen.

De drie Core Web Vitals koppelen zulke ervaringen aan meetbare onderdelen. Ze vertellen nog niet automatisch waarom iets misgaat. Daarvoor moet je de trage route, het betrokken element en de technische tijdvakken verder onderzoeken.

• LCP helpt beoordelen wanneer de belangrijkste zichtbare inhoud verschijnt.
• INP helpt beoordelen hoe snel de pagina reageert op klikken, tikken en toetsen.
• CLS helpt onverwachte verschuivingen van zichtbare onderdelen opsporen.

Lees PageSpeed Insights in twee delen

PageSpeed Insights toont velddata uit het Chrome User Experience Report en een Lighthouse-labtest. De velddata beschrijft echte Chrome-bezoeken uit de voorgaande meetperiode van 28 dagen. De labtest simuleert één paginalading met vastgelegde omstandigheden en geeft technische aanwijzingen.

Controleer bij de velddata altijd of je naar de ingevoerde pagina of naar het hele domein kijkt. Als er te weinig gegevens voor de pagina zijn, kan PageSpeed Insights terugvallen op domeindata. Ontbreekt ook die, dan is de juiste conclusie dat er onvoldoende openbare velddata is. Je weet dan alleen dat de openbare steekproef te klein is om de pagina op basis daarvan te beoordelen.

Een rode veldmeting en een groene labtest kunnen dus allebei kloppen. Bezoekers gebruiken andere apparaten, netwerken en paginastaten dan de gesimuleerde test. Gebruik de velddata om prioriteit te bepalen en de labtest om een concreet probleem te reproduceren.

Welke waarden gelden voor Core Web Vitals?

De huidige grens voor een goede Largest Contentful Paint is maximaal 2,5 seconden. Voor Interaction to Next Paint geldt maximaal 200 milliseconden. Cumulative Layout Shift is goed bij maximaal 0,1. Waarden boven 4 seconden voor LCP, 500 milliseconden voor INP en 0,25 voor CLS vallen in de categorie slecht. De tussenliggende waarden krijgen het label verbetering nodig.

Deze beoordeling gebruikt het 75e percentiel. Dat betekent dat ten minste 75 procent van de gemeten bezoeken de gekozen grens moet halen. De grenswaarden zijn voor mobiel en desktop gelijk, maar beide apparaatgroepen worden afzonderlijk beoordeeld. Een snel kantoorapparaat kan een probleem bij mobiele bezoekers daarom niet wegmiddelen.

Een complete Core Web Vitals-beoordeling is pas goed wanneer LCP, INP en CLS binnen dezelfde beoordeelde apparaatgroep alle drie goed zijn. Weeg ook de omvang en het belang van de getroffen route. Een drukke offertepagina verdient eerder aandacht dan een nauwelijks bezochte archiefpagina met dezelfde meetwaarde.

Onderzoek LCP via vier tijdvakken

LCP loopt vanaf het starten van de navigatie tot het grootste relevante beeld- of tekstonderdeel in het zichtbare scherm is weergegeven. Die totale tijd bestaat uit vier delen. Je voorkomt veel zinloos werk door eerst te bepalen welk deel de meeste vertraging veroorzaakt.

Een grote afbeelding comprimeren helpt alleen bij een trage overdracht. Dezelfde afbeelding kan ook laat worden ontdekt doordat ze pas via CSS of JavaScript bekend wordt. Ze kan al binnen zijn en toch wachten op zwaar browserwerk. In die gevallen moet de ontdekking of rendering worden aangepakt.

• TTFB: hoeveel tijd verstrijkt vóór de eerste byte HTML aankomt?
• Resource load delay: hoe lang wacht de browser voordat het LCP-bestand wordt aangevraagd?
• Resource load duration: hoeveel tijd kost het downloaden van dat bestand?
• Element render delay: hoe lang wacht de browser daarna nog met weergeven?

Zoek bij INP naar de vertraagde interactie

INP kijkt naar de reactie op klikken, tikken en toetsen gedurende het bezoek. Begin bij de concrete handeling die traag voelt, zoals het openen van het menu, kiezen van een filter of typen in een formulier.

Meet daarna waar de tijd blijft: vóór de gebeurteniscode kan starten, tijdens die code of voordat de browser het nieuwe beeld toont.

Veel JavaScript, externe scripts en lange taken kunnen de eerste fase blokkeren. Zware gebeurteniscode vertraagt de verwerking. Een grote pagina of dure layoutberekening kan de laatste weergave vertragen. Total Blocking Time uit Lighthouse helpt bij het vinden van opstartwerk, maar is niet hetzelfde als INP en vervangt geen echte interactiemeting.

Volg CLS door de hele pagina

CLS registreert onverwachte beweging van zichtbare inhoud. Denk aan tekst die opschuift zodra een lettertype verschijnt, een afbeelding zonder gereserveerde ruimte of een cookiemelding die andere onderdelen verplaatst. Ook advertenties, reviews, formulieren en embeds kunnen later tijdens het bezoek nog verschuiven.

Een rustige eerste schermopname sluit een CLS-probleem daarom niet uit. Doorloop de echte pagina, inclusief scrollen, toestemmingskeuzes en dynamische onderdelen. Reserveer passende ruimte voor media en widgets, maak lettertypewissels voorspelbaar en laat animaties waar mogelijk via transforms lopen. Controleer steeds of de pagina natuurlijk blijft werken.

Bepaal welke aanpassing voorrang krijgt

Kies eerst één belangrijke bezoekersroute en apparaatgroep. Leg de veldwaarde, het gegevensniveau en de meetperiode vast. Reproduceer het probleem daarna meerdere keren met dezelfde labinstellingen. Pas daarna het gemeten knelpunt aan.

Vraag bij een voorstel altijd welk element of proces de vertraging veroorzaakt en welk deel van de meting daardoor zou veranderen. “Afbeeldingen optimaliseren” is te breed. “De mobiele hero staat pas na clientcode in de pagina, waardoor de aanvraag 700 milliseconden later begint” is een toetsbare hypothese.

• Welke route, handeling en apparaatgroep hebben prioriteit?
• Is de velddata van deze pagina, een groep vergelijkbare pagina’s of het hele domein?
• Welke metric en welk technisch tijdvak veroorzaken de vertraging?
• Welke ene wijziging hoort bij die oorzaak en welk neveneffect kan ontstaan?
• Hoe worden formulierwerking, toegankelijkheid, inhoud en visuele stabiliteit meegetest?

Controleer het resultaat op drie momenten

Direct na de wijziging herhaal je de labtest en de belangrijke interacties. Controleer ook formulieren, foutmeldingen, toetsenbordbediening en verschillende schermformaten. Als eigen real-user monitoring is ingericht, kan die in de dagen na publicatie laten zien of de bedoelde bezoekersgroep verbetert.

Openbare CrUX-data in PageSpeed Insights kijkt terug over 28 dagen. Kort na een release bevat die periode dus oude en nieuwe bezoeken. Een directe groene labtest is technisch bewijs voor de gekozen test, terwijl de latere veldverdeling laat zien of echte bezoeken als groep zijn verbeterd.

Leg voor terugkerend beheer een klein performancebudget vast voor de onderdelen die het team kan beheersen, zoals kritieke scripts, het LCP-bestand, externe scripts en zware hoofdtaken. Dat maakt een toekomstige vertraging eerder zichtbaar dan wachten op een rode maandrapportage.

Wat betekent performance-optimalisatie voor SEO?

Google gebruikt Core Web Vitals binnen zijn rankingsystemen en adviseert een goede pagina-ervaring. Google zegt tegelijk dat goede scores in Search Console of andere tools geen toppositie garanderen. Relevantie blijft zwaar wegen en pagina-ervaring omvat meer dan deze drie waarden.

Optimaliseer snelheid dus voor de bezoeker en controleer zoekprestaties afzonderlijk. Een betere LCP bewijst niet dat een stijging in vertoningen of aanvragen daardoor is veroorzaakt. Contentwijzigingen, concurrentie, seizoenen en andere releases kunnen tegelijk invloed hebben.

Wanneer de oorzaak in hosting, rendering, scripts of website-architectuur zit, past een technisch Website Groei-gesprek. Voor terugkerend werk waarin content, techniek en organische vindbaarheid samen worden beoordeeld, biedt Redframe Vindbaarheid Groei.

Zo gebruik je velddata en labdata