Core Web Vitals: wat de cijfers werkelijk beweegt
Core Web Vitals zijn drie veldmetingen van hoe een pagina aanvoelt: hoelang het duurt voor de hoofdcontent verschijnt, hoeveel die verschuift tijdens het laden, en hoe snel de pagina op invoer reageert. Ze zijn een rankingsignaal en, belangrijker, ze hangen samen met of mensen blijven.
Deze gids behandelt wat elke meetwaarde meet, de specifieke oorzaken achter slechte scores, en de oplossingen die velddata bewegen in plaats van alleen labscores.
Wat de drie meetwaarden meten#
Elk heeft een drempel voor «goed» en een klein aantal gebruikelijke oorzaken. Merk op dat het cijfer dat voor ranking telt velddata van echte bezoekers is, niet een labscore vanaf jouw laptop.
| Meetwaarde | Goed | Meet | Gebruikelijke oorzaak bij een slechte score |
|---|---|---|---|
| LCP | Onder 2,5 s | Tijd tot het grootste zichtbare element getekend is | Niet-geoptimaliseerde koptafbeelding, trage server, renderblokkerende CSS |
| CLS | Onder 0,1 | Hoeveel de opmaak tijdens het laden verschuift | Afbeeldingen zonder afmetingen, ingevoegde banners, laat geladen webfonts |
| INP | Onder 200 ms | Reactiesnelheid op gebruikersinteractie | Lange JavaScript-taken die de hoofdthread blokkeren |
Labhulpmiddelen meten één laadbeurt op één machine. Velddata is het 75e percentiel van echte bezoeken, inclusief oude telefoons op slechte netwerken — juist de bezoekers die het snelst vertrekken.
LCP oplossen#
LCP is vrijwel altijd een afbeelding of een kop die achter iets anders is geblokkeerd. Werk deze punten op volgorde af; de eerste twee lossen de meeste sites op.
- Bepaal het werkelijke LCP-element in de velddata. De verkeerde afbeelding optimaliseren is de meest voorkomende verspilde moeite.
- Laad de LCP-afbeelding nooit uitgesteld. Geef haar in plaats daarvan fetchpriority="high".
- Serveer haar in een modern formaat op de grootte waarop ze wordt getoond, met srcset voor kleinere schermen.
- Laad het lettertype van de LCP-tekst vooraf en gebruik font-display: swap zodat tekst niet onzichtbaar is tijdens het wachten.
- Haal renderblokkerende CSS en JavaScript uit de head; zet de kritieke CSS inline als de pagina klein genoeg is.
- Verlaag de Time to First Byte met caching en een CDN — geen front-endwerk compenseert een trage server.
- Snoei in scripts van derden op het kritieke pad. Elk daarvan is een DNS-opzoeking, een verbinding en een onvoorspelbaar bestand.
CLS oplossen#
Verschuivende opmaak is vrijwel volledig te voorkomen en de oplossingen zijn goedkoop. Het is ook de meetwaarde die bezoekers het sterkst voelen — het is wat mensen op het verkeerde ding laat tikken.
- Stel width- en height-attributen in op elke afbeelding en video zodat de browser ruimte reserveert.
- Reserveer ruimte voor advertenties, insluitingen en iframes met een container met vaste beeldverhouding.
- Voeg na het laden nooit content boven bestaande content in — cookiebanners horen onderaan of als overlay.
- Stem de maten van het terugvallettertype af op het webfont, of gebruik size-adjust, zodat de wissel de pagina niet herschikt.
- Vermijd het animeren van opmaakeigenschappen. Animeer transform en opacity, die geen herberekening veroorzaken.
- Geef dynamisch geladen secties een min-height zodat ze niet vanaf nul uitklappen.
INP oplossen#
INP verving First Input Delay en is lastiger, omdat het elke interactie tijdens het bezoek meet in plaats van alleen de eerste. Slechte INP is vrijwel altijd te veel JavaScript op de hoofdthread.
| Oorzaak | Oplossing |
|---|---|
| Grote bundel die bij het laden wordt verwerkt | Code opsplitsen; alleen laden wat de pagina nodig heeft |
| Lange taken boven 50 ms | Werk opdelen en de hoofdthread teruggeven |
| Kostbare eventhandlers | Debouncen, en zwaar werk van het interactiepad halen |
| Zware tags van derden | Na interactie laden, of verwijderen — controleer wat elk oplevert |
| Grote DOM (meer dan 10.000 knopen) | Lange lijsten virtualiseren; diep geneste opmaak vereenvoudigen |
| Opmaakgeworstel in handlers | Lees- en schrijfacties bundelen in plaats van afwisselen |
Op contentsites is de waardevolste INP-ingreep meestal JavaScript verwijderen in plaats van optimaliseren. Vraag wat elk script oplevert; tagbeheerders stapelen scripts op waarvan niemand zich herinnert ze te hebben toegevoegd.
Veelgestelde vragen
Hoeveel effect hebben Core Web Vitals op ranking?
Ze zijn een echt maar bescheiden signaal, en werken meer als scheidsrechter bij gelijke stand dan als vervanging voor relevantie. Een snelle pagina over het verkeerde onderwerp verslaat geen tragere pagina die de vraag beantwoordt. Het sterkere argument om ze op te lossen is gedrag: trage, verspringende pagina's verliezen bezoekers voordat ranking überhaupt meespeelt.
Waarom is mijn Lighthouse-score goed en mijn velddata slecht?
Omdat Lighthouse één laadbeurt op jouw machine met jouw verbinding simuleert, en velddata het 75e percentiel van echte bezoeken is — inclusief drie jaar oude telefoons op overbelaste mobiele netwerken. Spreken de twee elkaar tegen, dan telt de velddata. Gebruik labhulpmiddelen om te diagnosticeren, niet om te scoren.
Moet ik alle drie de meetwaarden oplossen?
Los degene op die falen, in de volgorde van wat je bezoekers ervaren. CLS is meestal het goedkoopst op te lossen en voor gebruikers het irritantst, dus dat is een goed startpunt. LCP heeft het grootste effect op of mensen wachten. INP telt het meest op interactieve sites en het minst bij statische artikelen.
Hoelang duurt het voor verbeteringen zichtbaar worden?
Velddata is een voortschrijdend venster van 28 dagen, dus betekenisvolle beweging duurt ongeveer vier weken nadat een oplossing alle bezoekers heeft bereikt. Beoordeel een wijziging niet na drie dagen. Controleer wel meteen de labwaarden om te bevestigen dat de oplossing deed wat je verwachtte.
core web vitalslcpclsinppaginasnelheidwebprestaties
