Hoe deze controle werkt
Scanaris verzint geen prestatiecijfers: hij vraagt PageSpeed Insights, de dienst van Google die Lighthouse draait, om je pagina in mobiele modus te meten en leest het resultaat. Daaruit haalt hij de score van 0 tot 100 en drie metrieken: LCP (Largest Contentful Paint, hoe lang het grootste zichtbare element nodig heeft om te verschijnen), CLS (Cumulative Layout Shift, hoeveel de pagina "springt" tijdens het laden) en TBT (Total Blocking Time, hoe lang JavaScript de hoofdthread blokkeert). De score wordt bewaard in een informatieve bevinding die niets kost en de score van de prestatiepijler voedt. Hij opent alleen bevindingen met een ernst wanneer een metriek in het bereik valt dat Google "slecht" noemt: LCP boven 4 seconden (gemiddeld), CLS boven 0,25 (laag) of TBT boven 600 milliseconden (laag). Geeft Lighthouse geen score terug (pagina niet meetbaar, fout in de tool), dan is er geen bevinding.
Waarom dit belangrijk is
Prestaties zijn gebruikerservaring en zijn SEO. Google gebruikt de Core Web Vitals sinds 2021 als rankingsignaal en meet die van je echte gebruikers in Chrome, niet alleen die uit het lab. Maar het meest directe effect zit in de business: elke extra seconde laadtijd op mobiel verlaagt de conversies meetbaar, en een LCP van 5 seconden betekent dat een flink deel van je bezoekers lang genoeg een wit scherm ziet om te vertrekken. De metrieken worden op mobiel gemeten omdat de meeste sites daar het slechtst presteren en Google daar als eerste indexeert.
Hoe je het oplost
Hoge LCP
- De hero-afbeelding is meestal het LCP-element. Serveer hem als WebP of AVIF, op de weergegeven grootte in plaats van het origineel, met
fetchpriority="high"en zonderloading="lazy". In Nuxt en Next.js doen de afbeeldingscomponenten (NuxtImg,next/image) dit voor je. - De responstijd van de server komt bij al het andere op. Paginacache, een CDN ervoor en, op WordPress, een goed geconfigureerde cacheplugin.
- Render-blokkerende CSS en JavaScript: zet de kritieke CSS inline en laad de rest daarna; scripts van derden met
deferofasync. - Webfonts:
font-display: swap, het hoofdlettertype preloaden en, als het kan, zelf hosten in plaats van laden vanaf Google Fonts.
Hoge CLS
Bijna altijd afbeeldingen zonder width en height, advertenties of embeds die plotseling verschijnen, en lettertypen die bij het laden van grootte veranderen. Declareer de afmetingen van elke afbeelding en iframe, reserveer ruimte voor dynamische blokken met min-height en voeg nooit inhoud in boven wat de gebruiker al aan het lezen is.
Hoge TBT
Te veel JavaScript dat bij het opstarten draait. Splits de bundel per route, laad zware componenten alleen wanneer nodig, stel analytics- en chatscripts uit tot na de interactie, en kijk naar het gewicht van bibliotheken: verouderde bibliotheken en een volledige kopie van jQuery voor één menu zijn de typische gevallen.
Controleer of het opgelost is
npx lighthouse https://jouwdomein.nl --only-categories=performance --preset=perf --form-factor=mobile --screenEmulation.mobile --viewOf plak de URL in PageSpeed Insights, dat naast de labmeting ook gegevens van echte gebruikers van de laatste 28 dagen toont. Doel: LCP onder 2,5 s, CLS onder 0,1 en TBT onder 200 ms. Meet meerdere keren: labresultaten variëren een beetje tussen runs.
Veelgestelde vragen
Mijn site laadt snel op mijn computer. Waarom scoort hij slecht?
Omdat de meting een middenklasse telefoon op een trage 4G-verbinding simuleert, wat een groot deel van je bezoekers gebruikt. Je laptop op glasvezel is niet het representatieve geval.
Helpt een 100 voor prestaties de SEO meer dan een 90?
Niet merkbaar. Google onderscheidt per metriek "goed", "moet beter" en "slecht"; ben je eenmaal in "goed", dan is de rest gebruikerservaring, geen ranking. Richt je op uit het rood komen, niet op het najagen van 100.
Meet deze controle al mijn pagina's?
Alleen de gescande URL. Hebben je productpagina of je blog andere problemen, scan ze dan apart. De andere controles in deze pijler, zoals toegankelijkheid, werken ook op de specifieke pagina.