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.
| Onderdeel | Databron | Wat het beantwoordt | Beperking |
|---|---|---|---|
| Core Web Vitals-beoordeling | CrUX-velddata | Hoe echte gebruikers de URL of origin ervoeren | Alleen bij voldoende openbare gegevens |
| Performance-score | Lighthouse-labdata | Hoe één gesimuleerde testrun presteerde | Kan tussen runs variëren |
| Opportunities | Lighthouse-audits | Waar mogelijke tijdwinst of optimalisatie zit | Geen automatische prioriteitenlijst |
| Diagnostics | Lighthouse-audits | Welke technische patronen aandacht vragen | Vraagt 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.
- Kies een representatieve URL voor het paginatype dat je wilt verbeteren.
- Voer de URL in en start de analyse zonder parameters die gewone bezoekers niet gebruiken.
- Bekijk eerst of velddata voor de URL of volledige origin beschikbaar is.
- Controleer LCP, INP en CLS afzonderlijk voor mobiel en desktop.
- Open daarna de Lighthouse-labdata en noteer welke metriek de score beperkt.
- Koppel terugkerende opportunities en diagnostics aan concrete bronnen in de waterfall of code.
- Test vergelijkbare pagina's om te bepalen of het probleem lokaal of templatebreed is.
- Voer één samenhangende wijziging uit en herhaal de labtest onder dezelfde omstandigheden.
- 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.
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.
| Metriek | Meet | Goed | Voor verbetering vatbaar | Slecht |
|---|---|---|---|---|
| LCP | Wanneer de grootste zichtbare inhoud verschijnt | Tot en met 2,5 s | Boven 2,5 tot en met 4 s | Boven 4 s |
| INP | Reactiesnelheid tijdens interacties | Tot en met 200 ms | Boven 200 tot en met 500 ms | Boven 500 ms |
| CLS | Onverwachte visuele verschuivingen | Tot en met 0,1 | Boven 0,1 tot en met 0,25 | Boven 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?
| Tool | Beste toepassing | Niveau | Belangrijkste beperking |
|---|---|---|---|
| PageSpeed Insights | Velddata en labdiagnose voor één openbare URL | URL of origin | Geen volledige sitecrawl |
| Lighthouse in DevTools | Lokaal debuggen, ook op test- of ingelogde pagina's | Exacte pagina en sessie | Geen ingebouwde CrUX-context |
| Search Console | Probleemgroepen en trends in echte gebruikersdata | URL-groepen binnen de property | Minder detail over codeoorzaken |
| CrUX-dashboard of API | Trends en segmentatie van openbare velddata | URL of origin, indien beschikbaar | Voldoende meetvolume vereist |
| Eigen RUM | Gedrag van je eigen publiek en specifieke interacties | Bezoek, pagina en interactie | Implementatie 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 patroon | Mogelijke oorzaak | Gerichte controle | Vaak passende actie |
|---|---|---|---|
| LCP-element laat | Afbeelding wordt laat ontdekt of server reageert traag | Identificeer LCP-bron en requestketen | Prioriteit, formaat, compressie, caching of serverpad verbeteren |
| Renderblokkerende bronnen | CSS of scripts blokkeren eerste weergave | Controleer kritieke CSS en afhankelijkheden | Splits, stel uit of laad alleen noodzakelijke code |
| Ongebruikte JavaScript | Grote bundels of externe tags op iedere pagina | Meet codecoverage en functiegebruik | Verwijder, splits of laad conditioneel |
| Hoofdthread lang bezet | Parsing, rendering of scripts vragen lange taken | Bekijk performanceprofiel en long tasks | Verminder werk, deel taken op en vereenvoudig componenten |
| Afbeeldingen niet efficiënt | Verkeerde afmetingen, formaat of kwaliteit | Vergelijk bronpixels met renderformaat | Responsieve formaten, moderne compressie en correcte dimensies |
| Tekstcompressie ontbreekt | HTML, CSS of JS wordt onnodig groot verzonden | Controleer responseheaders | Brotli of gzip op de server/CDN activeren |
| Lange cacheduur ontbreekt | Statische bestanden worden opnieuw opgehaald | Bekijk cache-control per bestandstype | Versiebeheer en passende browsercache instellen |
| Layout shifts | Ruimte voor media, banners of fonts ontbreekt | Gebruik de layout-shift regions | Dimensies 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.
| Beslisvraag | Sterk signaal | Zwak signaal |
|---|---|---|
| Is het probleem echt? | Rode of oranje velddata en herhaalbare labdiagnose | Eenmalige audit zonder gebruikersdata |
| Hoe breed is de impact? | Gedeeld template of veel organische landingspagina's | Eén weinig bezochte uitzondering |
| Raakt het de taak? | Vertraagt lezen, klikken, filteren of converteren | Geen merkbare invloed op de gebruikersstroom |
| Is de oplossing beheersbaar? | Kleine wijziging met duidelijke eigenaar en test | Grote 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.
- Groepeer URL's in homepage, dienst, categorie, product, artikel en conversiepagina.
- Kies per groep representatieve URL's op basis van verkeer, omzet en technische variatie.
- Voer meerdere vergelijkbare mobiele en desktoptests uit.
- Label iedere bevinding als URL-specifiek, componentbreed of templatebreed.
- Los gedeelde oorzaken eerst op en controleer daarna uitzonderingen.
- 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.
| Rapportonderdeel | Voorbeeld van een controleerbare invulling |
|---|---|
| Scope | Mobiele dienstpagina's op het primaire domein |
| Bewijs | LCP op URL- of originniveau, 75e percentiel en meetperiode |
| Diagnose | Hero-afbeelding wordt pas na client-side rendering ontdekt |
| Actie | Afbeelding in initiële HTML, responsief formaat en doelgerichte prioriteit |
| Eigenaar | Frontend, contentbeheer of hostingpartner |
| Verificatie | Labtest na release, veldtrend na voldoende nieuwe data |
| Bedrijfssignaal | Bounce, 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.
