In het kort
Meet eerst belangrijke pagina’s op mobiel en desktop. Gebruik echte gebruikersdata waar die beschikbaar zijn en een labtest om oorzaken te onderzoeken. Pak daarna de grootste bottleneck aan: het hoofdbeeld, de serverreactie, blokkerende scripts of verspringende onderdelen. Test na iedere wijziging ook het formulier, de navigatie en de cookiekeuze. Een snelle website moet bezoekers betrouwbaar naar hun volgende stap brengen.
1. Kies de pagina’s waarop snelheid ertoe doet
Begin met een korte lijst van pagina’s waarop bezoekers een beslissing nemen: je belangrijkste dienst, een productoverzicht, een veelgelezen artikel en de contact- of aanvraagpagina. Noteer per pagina welke taak iemand moet kunnen afronden. Een bezoeker van een dienstenpagina wil bijvoorbeeld het aanbod begrijpen en een aanvraag doen. Een productbezoeker wil een variant kiezen en verder kunnen naar bestellen.
Open die routes zelf op een telefoon en een computer. Kijk wanneer de belangrijkste uitleg verschijnt, of knoppen direct reageren en of tekst verschuift terwijl je leest. Test zowel een eerste bezoek als een terugkeer. Noteer waarnemingen apart van gemeten waarden. “De knop reageert pas na wachten” is een bruikbaar onderzoekssignaal; het is nog geen bewezen diagnose. Maak vervolgens afspraken over wie de meting doet, wie een wijziging uitvoert en wie het resultaat beoordeelt.
2. Maak een nulmeting met velddata en een labtest
Gebruik PageSpeed Insights voor de gekozen URL en controleer mobiel en desktop afzonderlijk. Het onderdeel met gebruikerservaringen bevat, wanneer beschikbaar, CrUX-gegevens uit de voorgaande 28 dagen. Controleer of de gegevens over deze URL of over de hele website-oorsprong gaan. Bij onvoldoende bezoekers kan URL-data ontbreken of terugvallen op origin-data. Dat zegt op zichzelf niet dat jouw pagina snel of langzaam is.
De labtest onderaan onderzoekt een gesimuleerd bezoek en helpt je oorzaken vinden. Bewaar de URL, datum, apparaatinstelling en belangrijkste bevindingen. Herhaal een test onder vergelijkbare omstandigheden om toevalsverschillen te herkennen. Houd lab- en veldresultaten apart in je overzicht; ze beantwoorden verschillende vragen. De officiële uitleg van PageSpeed Insights beschrijft dit onderscheid en de beperkingen van de beschikbare data.
Gebruik de Core Web Vitals als concrete meetpunten. LCP beschrijft wanneer het grootste zichtbare inhoudselement verschijnt, INP hoe snel een pagina reageert op interacties en CLS hoeveel onverwachte layoutverschuiving optreedt. Google noemt voor een goede ervaring LCP van maximaal 2,5 seconden, INP van maximaal 200 milliseconden en CLS van maximaal 0,1. De beoordeling kijkt naar het 75e percentiel, uitgesplitst naar mobiel en desktop. Leg vast welke waarden daadwerkelijk beschikbaar zijn.
3. Onderzoek waarom het hoofdbeeld of de hoofdtekst laat verschijnt
Bij een hoge LCP zoek je eerst het element dat de meting bepaalt. Dat kan een groot beeld zijn, maar ook een tekstblok. De vertraging kan zitten in de serverreactie, het ontdekken van het benodigde bestand, het downloaden ervan of het uiteindelijk tonen van de inhoud. Google beschrijft deze onderdelen in de LCP-optimalisatiegids. Alleen een kleinere afbeelding maken lost bijvoorbeeld geen lange wachttijd vóór het starten van de download op.
Laat bij een beeldprobleem controleren welke afmetingen de bezoeker werkelijk nodig heeft. Gebruik een passende variant voor het scherm, een efficiënt formaat zoals WebP of AVIF en een verantwoorde compressie. Het belangrijke LCP-beeld hoort direct beschikbaar te zijn; lazy loading kan die afbeelding juist vertragen. Beelden verderop kunnen meestal later worden geladen. Controleer na aanpassing de scherpte, uitsnede en downloadvolgorde. Noteer ook wie de juiste beeldvarianten bij toekomstige uploads bewaakt.
4. Maak klikken, menu’s en formulieren snel bruikbaar
Een pagina kan al zichtbaar zijn terwijl een knop nog slecht reageert. Bij een hoge INP onderzoek je welke interactie traag is: het menu openen, een filter wijzigen, een formulier versturen of een dialoog sluiten. Zware JavaScript-taken en veel werk bij een klik kunnen de reactie vertragen. De INP-optimalisatiegids helpt een ontwikkelaar om de vertraging vóór, tijdens en na de verwerking van een interactie te onderzoeken.
Maak een lijst van scripts en widgets met hun doel en eigenaar. Vraag of ieder onderdeel op iedere pagina nodig is. Een ongebruikte integratie kun je gericht verwijderen; een belangrijk formulier moet na iedere aanpassing opnieuw worden getest. De gewone Lighthouse-laadtest meet geen echte INP van gebruikersinteracties. Gebruik de labdiagnose daarom als aanwijzing en controleer het werkelijke klikgedrag. Beschrijf bij een bug precies welke handeling, browser en pagina het probleem veroorzaken.
5. Voorkom dat de pagina tijdens het lezen verspringt
Een verspringende pagina kan ervoor zorgen dat iemand de verkeerde knop raakt of zijn plek in een tekst kwijtraakt. Controleer daarom of afbeeldingen, ingeladen onderdelen en banners vooraf voldoende ruimte krijgen. Vaste afbeeldingsdimensies helpen de browser om ruimte te reserveren. Ook een laat geladen lettertype of een onderdeel dat boven bestaande inhoud verschijnt, kan de indeling veranderen. De CLS-optimalisatiegids beschrijft de belangrijkste oorzaken en passende maatregelen.
Loop een paar echte gebruikssituaties door: de pagina openen, de cookiekeuze maken, een formulierfout tonen en een menu openen. Schrijf op welk onderdeel schuift en op welk moment. Voorbeeld: een foutmelding boven het formulier kan alle invulvelden naar beneden duwen. Laat de bouwer onderzoeken of de boodschap dichtbij het betreffende veld kan verschijnen met een stabiele indeling. Het resultaat moet ook met toetsenbordbediening en op een smal scherm begrijpelijk blijven.
6. Kies één verbetering met een duidelijk acceptatiebewijs
Maak een eenvoudig verbeterregister met vijf velden: pagina, waargenomen probleem, vermoedelijke oorzaak, geplande wijziging en acceptatiebewijs. Koppel daar een eigenaar en een herstelmogelijkheid aan. Geef prioriteit aan een probleem dat bezoekers echt hindert, dat met een meting of test is aangetoond en dat je gericht kunt oplossen. Zo kun je het effect van een wijziging beter beoordelen en voorkom je dat meerdere aanpassingen elkaars resultaat onduidelijk maken.
Voorbeeld, geen gemeten klantresultaat: een dienstenpagina toont een onnodig groot hoofdbeeld. De geplande wijziging is een kleinere, passende beeldvariant. Het acceptatiebewijs bestaat uit een correct geladen bestand, voldoende beeldkwaliteit, een vergelijkbare hertest en een werkende aanvraagroute. Wanneer juist de eerste serverreactie de grootste vertraging vormt, vraag je om onderzoek naar die oorzaak voordat je een nieuwe afbeeldingsronde laat uitvoeren. Leg open vragen zichtbaar vast.
Bespreek ook onderhoud en toegang. Wie mag een plugin verwijderen, wie kan terug naar de vorige versie en wie bewaakt nieuwe uploads? Gebruik de uitleg over websiteonderhoud om structureel beheer en losse verbeteringen af te bakenen. Als er tegelijk een nieuw platform of andere URL-structuur nodig is, maak dan apart een website-migratieplan. Snelheidswerk geeft op zichzelf geen reden om bestaande, goed werkende pagina’s of URL’s te vervangen.
7. Test het resultaat én de complete aanvraagroute
Herhaal na de wijziging de relevante meting onder vergelijkbare omstandigheden en bewaar beide uitkomsten. Gebruik dezelfde pagina, apparaatcategorie en testaanpak. Leg schommelingen eerlijk vast. Velddata worden over een periode verzameld; daarin zie je de volledige verandering niet meteen na één publicatie. Noteer wanneer een nieuwe beoordeling zinvol is en welke bezoekersgegevens tegen die tijd beschikbaar moeten zijn.
Controleer daarnaast dat belangrijke onderdelen goed blijven werken. Komt een echte testaanvraag in het juiste systeem aan? Kun je het menu met het toetsenbord bedienen? Blijven de cookiekeuze, noodzakelijke scripts en formuliermeldingen begrijpelijk? Werken afbeeldingen en links op mobiel? Spreek vooraf af bij welke fout je teruggaat naar de vorige versie. Bewaar een klein opleverbewijs met de geteste routes, de datum, de uitkomst en eventuele resterende beperkingen.
Gebruik voor de inrichting van die aanvraagroute de vijf controlepunten voor een conversiegerichte website. Daarmee beoordeel je ook of aanbod, vervolgstap en overdracht duidelijk zijn. Een snelle pagina kan immers nog steeds onduidelijk zijn voor een bezoeker. Door de route van eerste scherm tot bevestigde aanvraag apart te controleren, krijg je een bruikbaarder oplevering dan met alleen een losse prestatiescore.
8. Verbind snelheid aan SEO, inhoud en een onderhoudsafspraak
Google gebruikt Core Web Vitals binnen zijn rankingsystemen, maar een goede beoordeling garandeert geen toppositie. Relevantie, inhoud en de bredere pagina-ervaring blijven belangrijk. De richtlijn over pagina-ervaring benadrukt dat je meerdere aspecten samen moet beoordelen. Zorg dus ook voor een duidelijke hoofdvraag, toegankelijke tekst, correcte links en een pagina die op een telefoon prettig werkt.
Leg bij een website laten maken alvast vast welke pagina’s worden getest, hoe de beelden worden aangeleverd en welk bewijs je bij oplevering ontvangt. Neem die afspraken op in je websitebriefing. Voor een bestaande site kun je dezelfde aanpak gebruiken om een gerichte verbetering te laten uitvoeren. Softora helpt bij websites en maatwerksoftware; bespreek eerst de huidige situatie en het gewenste resultaat, zodat de opdracht en het onderhoud duidelijk zijn.
Over deze uitleg
Deze uitleg is opgesteld door Softora met hulp van AI en gecontroleerd aan de genoemde officiële documentatie. De voorbeelden zijn uitlegscenario’s; er worden geen gemeten klantresultaten of persoonlijke praktijkervaring geclaimd.
