Gepubliceerd op

Wat is PageSpeed Insights?

PageSpeed Insights, vaak afgekort tot PSI of Google PageSpeed, is een webtool die één URL op mobiel en desktop beoordeelt. De centrale entiteit is de geteste webpagina. De belangrijkste attributen zijn het apparaatprofiel, beschikbare echte gebruikerservaringen, gesimuleerde prestatiemetingen, audits en mogelijke verbeteringen.

PSI is geen volledige technische SEO-crawler en evenmin een live overzicht van alle bezoekers. De tool beantwoordt twee afgebakende vragen: hoe hebben echte Chrome-gebruikers de pagina of origin recent ervaren, en welke technische oorzaken verschijnen in een gecontroleerde Lighthouse-test? Voor indexering, zoekprestaties en groepen vergelijkbare URL's gebruik je aanvullende bronnen.

OnderdeelDatabronWat het beantwoordtBeperking
Core Web Vitals-beoordelingCrUX-velddataHoe echte gebruikers de URL of origin ervoerenAlleen bij voldoende openbare gegevens
Performance-scoreLighthouse-labdataHoe één gesimuleerde testrun presteerdeKan tussen runs variëren
OpportunitiesLighthouse-auditsWaar mogelijke tijdwinst of optimalisatie zitGeen automatische prioriteitenlijst
DiagnosticsLighthouse-auditsWelke technische patronen aandacht vragenVraagt interpretatie in de code en context

Hoe gebruik je PageSpeed Insights stap voor stap?

Open PageSpeed Insights, voer de volledige openbare URL in en kies Analyseren. Test het definitieve adres dat bezoekers en zoekmachines gebruiken, inclusief HTTPS en het juiste pad. Een homepage-test zegt weinig over een product-, categorie- of diensttemplate met andere afbeeldingen, scripts en gegevens.

  1. Kies een representatieve URL voor het paginatype dat je wilt verbeteren.
  2. Voer de URL in en start de analyse zonder parameters die gewone bezoekers niet gebruiken.
  3. Bekijk eerst of velddata voor de URL of volledige origin beschikbaar is.
  4. Controleer LCP, INP en CLS afzonderlijk voor mobiel en desktop.
  5. Open daarna de Lighthouse-labdata en noteer welke metriek de score beperkt.
  6. Koppel terugkerende opportunities en diagnostics aan concrete bronnen in de waterfall of code.
  7. Test vergelijkbare pagina's om te bepalen of het probleem lokaal of templatebreed is.
  8. Voer één samenhangende wijziging uit en herhaal de labtest onder dezelfde omstandigheden.
  9. Monitor vervolgens de vernieuwde velddata, bezoekersgedrag en conversies.

Bewaar per meting de URL, datum, apparaatkeuze, relevante metriekwaarden en uitgevoerde wijziging. Zo ontstaat een controleerbaar logboek in plaats van een reeks losse screenshots met wisselende scores.

Wat is het verschil tussen velddata en labdata?

Velddata komt uit het Chrome User Experience Report, of CrUX. De gegevens vatten geanonimiseerde ervaringen van echte Chrome-gebruikers samen over de vorige 28 dagen. PSI toont onder andere LCP, INP en CLS op het 75e percentiel. Dat betekent dat je niet naar de gemiddelde ideale bezoeker kijkt, maar controleert of minstens 75 procent van de gemeten ervaringen binnen de gewenste grens valt.

Labdata wordt door Lighthouse in een gesimuleerde omgeving verzameld. Ze is geschikt voor snelle diagnose omdat apparaat, netwerk en testproces gecontroleerd worden. Eén testrun vertegenwoordigt echter niet alle apparaten, verbindingen, locaties, caches, accounts of interacties van echte bezoekers.

Vergelijking van CrUX-velddata over 28 dagen en Lighthouse-labdata uit één test
Velddata bevestigt de gebruikersimpact. Labdata helpt de technische oorzaak te vinden.

Volgens de actuele officiële PSI-documentatie worden de twee databronnen bewust naast elkaar getoond. Een goede labtest garandeert dus geen goede velddata, en slechte velddata wordt niet ontkracht door één groene labrun.

Hoe lees je LCP, INP en CLS?

De drie Core Web Vitals meten verschillende eigenschappen van de ervaring. Een pagina slaagt voor de algemene beoordeling wanneer alle beschikbare kernmetingen op het 75e percentiel in de goede categorie vallen. Beoordeel geen samengestelde score zonder eerst te zien welke metriek faalt.

MetriekMeetGoedVoor verbetering vatbaarSlecht
LCPWanneer de grootste zichtbare inhoud verschijntTot en met 2,5 sBoven 2,5 tot en met 4 sBoven 4 s
INPReactiesnelheid tijdens interactiesTot en met 200 msBoven 200 tot en met 500 msBoven 500 ms
CLSOnverwachte visuele verschuivingenTot en met 0,1Boven 0,1 tot en met 0,25Boven 0,25

LCP, INP en CLS zijn geen synoniemen voor volledige websitesnelheid. Een snelle eerste weergave kan nog traag reageren op een menu, filter of formulier. Een stabiele lay-out kan tegelijk een te zware hero laden. Lees daarom ook ondersteunende signalen zoals FCP, TTFB, Speed Index en Total Blocking Time, maar houd de kernvraag van iedere metriek apart.

De uitgebreide Core Web Vitals-gids behandelt de drie gebruikersmetingen en hun technische oorzaken verder. Deze pagina richt zich op het correct gebruiken van de PageSpeed-tool en het vertalen van het rapport naar een werkvolgorde.

Wat betekent de Lighthouse-prestatiescore?

De ronde score van 0 tot 100 is een gewogen samenvatting van labmetingen. In de actuele Lighthouse-score wegen onder andere Largest Contentful Paint, Total Blocking Time en Cumulative Layout Shift mee. De gewichten en auditengine kunnen in nieuwe Lighthouse-versies veranderen. Vergelijk historische scores dus niet blind wanneer de testomgeving of toolversie is gewijzigd.

  • 90 tot 100: de labrun valt in de groene categorie.
  • 50 tot 89: de labrun is voor verbetering vatbaar.
  • 0 tot 49: de labrun valt in de slechte categorie.

De opportunities en diagnostics tellen niet rechtstreeks als losse punten op bij de prestatiescore. Ze wijzen op oorzaken die de onderliggende metriekwaarden kunnen beïnvloeden. De officiële documentatie over Lighthouse-scoring beschrijft daarom de score als een gewogen metriekmodel, niet als een optelsom van waarschuwingen.

Waarom verandert de PageSpeed-score zonder websitewijziging?

Een labscore kan bewegen omdat een webpagina en haar omgeving niet volledig statisch zijn. Serverbelasting, netwerkroute, testlocatie, cache, advertenties, personalisatie, A/B-tests en externe diensten kunnen per run verschillen. Ook dynamische afbeeldingen, consenttools en tagmanagers beïnvloeden het moment waarop werk in de browser wordt uitgevoerd.

Herhaal een test daarom meerdere keren en vergelijk de mediaan van relevante metriekwaarden. Noteer vooral terugkerende oorzaken. Een eenmalige waarschuwing met kleine potentiële winst is minder overtuigend dan een LCP-bron die in vijf tests en op alle dienstpagina's te laat wordt ontdekt.

Waarom verschillen mobiel en desktop?

PSI voert afzonderlijke tests uit voor mobiel en desktop. Het mobiele profiel simuleert beperktere hardware en netwerkcondities dan de desktoptest. Daardoor worden grote scripts, zware afbeeldingen, lange hoofdtaken en trage serverreacties op mobiel vaak duidelijker. Een hoge desktopscore maakt een slechte mobiele ervaring niet ongedaan.

Prioriteer op basis van je publiek en bedrijfsdoel. Controleer in analytics welke apparaten belangrijke landingspagina's bezoeken en converteren. Een B2B-site kan veel desktopconversies hebben, terwijl de eerste oriëntatie mobiel gebeurt. Test daarom niet alleen het apparaat met de hoogste conversieratio.

Wat is het verschil tussen PSI, Lighthouse en Search Console?

ToolBeste toepassingNiveauBelangrijkste beperking
PageSpeed InsightsVelddata en labdiagnose voor één openbare URLURL of originGeen volledige sitecrawl
Lighthouse in DevToolsLokaal debuggen, ook op test- of ingelogde pagina'sExacte pagina en sessieGeen ingebouwde CrUX-context
Search ConsoleProbleemgroepen en trends in echte gebruikersdataURL-groepen binnen de propertyMinder detail over codeoorzaken
CrUX-dashboard of APITrends en segmentatie van openbare velddataURL of origin, indien beschikbaarVoldoende meetvolume vereist
Eigen RUMGedrag van je eigen publiek en specifieke interactiesBezoek, pagina en interactieImplementatie en privacybeheer nodig

Begin in Search Console wanneer je wilt weten welke paginagroepen een veldprobleem hebben. Open daarna representatieve URL's in PSI. Gebruik Lighthouse of browserprofielen om de codeoorzaak te onderzoeken. Deze volgorde verbindt brede impact met technische diepte.

Hoe vertaal je PageSpeed-audits naar oplossingen?

Een auditnaam is een aanwijzing, geen kant-en-klaar implementatieplan. Koppel iedere melding aan de bron, eigenaar, getroffen template en gebruikersmetriek. Controleer vervolgens of de aanbevolen wijziging geen functies, tracking, toegankelijkheid of conversie breekt.

Melding of patroonMogelijke oorzaakGerichte controleVaak passende actie
LCP-element laatAfbeelding wordt laat ontdekt of server reageert traagIdentificeer LCP-bron en requestketenPrioriteit, formaat, compressie, caching of serverpad verbeteren
Renderblokkerende bronnenCSS of scripts blokkeren eerste weergaveControleer kritieke CSS en afhankelijkhedenSplits, stel uit of laad alleen noodzakelijke code
Ongebruikte JavaScriptGrote bundels of externe tags op iedere paginaMeet codecoverage en functiegebruikVerwijder, splits of laad conditioneel
Hoofdthread lang bezetParsing, rendering of scripts vragen lange takenBekijk performanceprofiel en long tasksVerminder werk, deel taken op en vereenvoudig componenten
Afbeeldingen niet efficiëntVerkeerde afmetingen, formaat of kwaliteitVergelijk bronpixels met renderformaatResponsieve formaten, moderne compressie en correcte dimensies
Tekstcompressie ontbreektHTML, CSS of JS wordt onnodig groot verzondenControleer responseheadersBrotli of gzip op de server/CDN activeren
Lange cacheduur ontbreektStatische bestanden worden opnieuw opgehaaldBekijk cache-control per bestandstypeVersiebeheer en passende browsercache instellen
Layout shiftsRuimte voor media, banners of fonts ontbreektGebruik de layout-shift regionsDimensies reserveren en late invoeging beheersen

Welke acties verbeteren LCP?

Bepaal eerst welk element de LCP vormt. Op commerciële pagina's is dat vaak een hero-afbeelding of groot tekstblok. Controleer daarna de keten vóór het element: serverrespons, HTML-ontdekking, stylesheet, afbeeldingrequest, formaat en rendervertraging. Alleen de afbeelding comprimeren helpt niet wanneer het request pas na een client-side script start.

  • Maak het LCP-element rechtstreeks vanuit de initiële HTML vindbaar.
  • Geef het belangrijkste beeld gepaste fetch-prioriteit zonder alle afbeeldingen te preloaden.
  • Serveer een responsief afbeeldingsformaat dat bij de werkelijke weergave past.
  • Verminder trage redirects, backendwerk en cachemissers vóór de HTML-response.
  • Beperk renderblokkering door CSS en scripts die niet nodig zijn voor de eerste viewport.

Welke acties verbeteren INP?

INP meet de reactiesnelheid tijdens echte interacties. Zoek dus niet alleen naar traag laden. Test menu's, filters, formulieren, tabs, zoekvelden en configurators. Een klik kan wachten op een lange JavaScript-taak, veel synchronisch werk uitvoeren of een grote hertekening veroorzaken.

  • Splits lange taken zodat de browser sneller op invoer kan reageren.
  • Beperk JavaScript dat op iedere route wordt geladen en uitgevoerd.
  • Vermijd zware eventhandlers en onnodige herberekeningen na iedere invoer.
  • Geef onmiddellijke visuele feedback wanneer achtergrondwerk langer duurt.
  • Meet specifieke interacties met echte gebruikersdata wanneer CrUX te weinig detail geeft.

Welke acties verbeteren CLS?

CLS gaat over onverwachte verschuivingen, niet over animatie op zich. Reserveer ruimte voor afbeeldingen, video's, embeds, advertenties en formulieren voordat de inhoud geladen is. Voeg banners niet plots boven bestaande inhoud toe en controleer hoe webfonts de tekstbreedte veranderen.

  • Gebruik breedte, hoogte of een stabiele aspect-ratio voor media.
  • Reserveer ruimte voor dynamische modules met een voorspelbare maximale afmeting.
  • Plaats consent- en promotiebanners zonder bestaande inhoud onverwacht te verplaatsen.
  • Kies fallbackfonts met vergelijkbare metriek en laad noodzakelijke fonts doelgericht.
  • Controleer shifts na interactie afzonderlijk van shifts tijdens de eerste laadfase.

Hoe bepaal je welke PageSpeed-fix eerst komt?

Sorteer niet uitsluitend op de geschatte milliseconden in het rapport. Combineer vier kenmerken: bewijs in velddata, invloed op een Core Web Vital of conversiestap, aantal getroffen URL's en uitvoeringsrisico. Een templatefix met middelgrote winst kan meer waarde hebben dan een grote winst op één zelden bezochte pagina.

Matrix voor PageSpeed-prioriteiten op basis van gebruikersimpact en bereik
Prioriteit ontstaat uit aantoonbare impact en bereik, niet uit de opvallendste auditkleur.
BeslisvraagSterk signaalZwak signaal
Is het probleem echt?Rode of oranje velddata en herhaalbare labdiagnoseEenmalige audit zonder gebruikersdata
Hoe breed is de impact?Gedeeld template of veel organische landingspagina'sEén weinig bezochte uitzondering
Raakt het de taak?Vertraagt lezen, klikken, filteren of converterenGeen merkbare invloed op de gebruikersstroom
Is de oplossing beheersbaar?Kleine wijziging met duidelijke eigenaar en testGrote herschrijving zonder regressieplan

Wanneer is een PageSpeed-score van 100 het verkeerde doel?

Een perfecte labscore kan disproportioneel veel ontwikkeltijd vragen voor een kleine resterende winst. Ze kan teams ook verleiden om nuttige functionaliteit, analytics of bewijs weg te halen zonder de impact op bezoekers en omzet te controleren. Streef naar een snelle, stabiele en responsieve ervaring voor echte gebruikers, niet naar een decoratief rapportcijfer.

Een score van 100 op één URL zegt bovendien niets over andere templates, interacties na de laadfase of bezoekers op tragere apparaten. Definieer daarom per project een prestatiebudget en acceptatiecriteria voor de onderliggende metriekwaarden. Controleer tegelijk toegankelijkheid, inhoud en conversie.

Wat betekent onvoldoende velddata?

CrUX toont alleen gegevens voor openbare URL's en origins met voldoende representatieve metingen. Een nieuwe pagina, lage bezoekersaantallen of versnipperde URL-varianten kunnen ervoor zorgen dat geen URL-niveau beschikbaar is. PSI kan dan origin-data tonen, die ervaringen van verschillende pagina's op hetzelfde protocol en domein samenneemt.

Gebruik origin-data niet als bewijs dat de geteste URL exact hetzelfde presteert. Test de pagina in het lab, vergelijk haar template met URL's die wel velddata hebben en overweeg eigen real-user monitoring wanneer de interactie commercieel belangrijk is. Wacht niet blind 28 dagen met elke diagnose, maar geef velddata wel tijd om een structurele wijziging te weerspiegelen.

Hoe test je meerdere pagina's zonder verkeerde conclusies?

Maak eerst een inventaris van paginatypes. Test niet willekeurig twintig URL's, maar kies per template een zware, een typische en een belangrijke organische landingspagina. Zo zie je of een probleem uit de gedeelde layout, contentmodule, afbeelding of externe integratie komt.

  1. Groepeer URL's in homepage, dienst, categorie, product, artikel en conversiepagina.
  2. Kies per groep representatieve URL's op basis van verkeer, omzet en technische variatie.
  3. Voer meerdere vergelijkbare mobiele en desktoptests uit.
  4. Label iedere bevinding als URL-specifiek, componentbreed of templatebreed.
  5. Los gedeelde oorzaken eerst op en controleer daarna uitzonderingen.
  6. Voeg regressietests toe voor prestatiebudgetten en kritieke gebruikersstromen.

Bij een technische SEO-audit hoort deze performanceanalyse naast crawlbaarheid, indexering, rendering, canonicals, structured data en interne links. PageSpeed Insights alleen kan die bredere technische diagnose niet vervangen.

Wanneer gebruik je de PageSpeed Insights API?

De API is nuttig wanneer je dezelfde URL's periodiek wilt testen, resultaten wilt opslaan of een dashboard en releasecontrole bouwt. Leg toolversie, strategie, testtijd en relevante metriekwaarden vast. Houd rekening met quota, variatie en mogelijke wijzigingen in Lighthouse-audits. Een automatisch rapport zonder steekproefcontrole kan schijnprecisie creëren.

Gebruik Lighthouse CI voor regressies in ontwikkel- en releaseprocessen. Gebruik CrUX of eigen real-user monitoring voor trends bij echte bezoekers. De API maakt de labtest herhaalbaar, maar verandert een gesimuleerde run niet in veldbewijs.

Hoe rapporteer je websiteperformance aan een bedrijf?

Een bruikbaar rapport verbindt de technische metriek met een pagina, doelgroep en bedrijfsrisico. Rapporteer niet alleen dat LCP 3,8 seconden is. Benoem welk element vertraagt, hoeveel belangrijke templates het raakt, wat de voorgestelde wijziging is en wanneer velddata opnieuw wordt beoordeeld.

RapportonderdeelVoorbeeld van een controleerbare invulling
ScopeMobiele dienstpagina's op het primaire domein
BewijsLCP op URL- of originniveau, 75e percentiel en meetperiode
DiagnoseHero-afbeelding wordt pas na client-side rendering ontdekt
ActieAfbeelding in initiële HTML, responsief formaat en doelgerichte prioriteit
EigenaarFrontend, contentbeheer of hostingpartner
VerificatieLabtest na release, veldtrend na voldoende nieuwe data
BedrijfssignaalBounce, formulierstart, conversie en organische landingspagina's

Heeft PageSpeed Insights direct invloed op SEO?

De Lighthouse-score zelf is geen afzonderlijke garantie op een hogere positie. Google beschrijft Core Web Vitals als signalen rond echte laadprestatie, responsiviteit en visuele stabiliteit die aansluiten op wat de rankingsystemen rond paginabeleving proberen te belonen. Relevantie en sterke, nuttige inhoud blijven noodzakelijk. Een groene score maakt een irrelevante pagina niet het beste antwoord.

De actuele Google Search Central-richtlijn over Core Web Vitals adviseert goede waarden voor zoeksucces en gebruikerservaring, zonder te stellen dat perfecte scores een ranking garanderen. Gebruik performance daarom als onderdeel van technische SEO, conversie en productkwaliteit.

Wanneer laat je PageSpeed-problemen onderzoeken?

Schakel hulp in wanneer velddata structureel faalt, meerdere templates hetzelfde probleem tonen, JavaScript en rendering de diagnose complex maken of een wijziging risico geeft voor omzet en tracking. Een goede analyse levert geen lijst met alle rode audits op, maar een korte reeks oorzaken, eigenaars, acceptatiecriteria en controles na implementatie.

Jakency beoordeelt PageSpeed binnen een bredere SEO-dienst of technische audit. Je kunt ook starten met een gratis SEO-scan wanneer je eerst wilt weten of snelheid werkelijk de belangrijkste blokkade is ten opzichte van indexering, content, interne links en conversie.

Welke bronnen onderbouwen deze gids?

De definities van velddata, labdata, CrUX, de 28-daagse periode, het 75e percentiel en de categoriegrenzen volgen de officiële documentatie van Google en Chrome. Toolinterfaces en Lighthouse-versies kunnen wijzigen. Controleer voor implementaties daarom ook de actuele bronpagina's.