Core Web Vitals: LCP, INP en CLS uitgelegd

Core Web Vitals beschrijven drie aspecten van de ervaring: laden met LCP, reactiesnelheid met INP en visuele stabiliteit met CLS. De aanbevolen doelen zijn een LCP van maximaal 2,5 seconden, een INP van maximaal 200 milliseconden en een CLS van maximaal 0,1.

De beoordeling gebruikt het 75e percentiel van bezoeken, afzonderlijk voor mobiel en desktop. Ze vat een site dus niet samen op basis van één test op één computer.

Largest Contentful Paint meet wanneer de grootste zichtbare in aanmerking komende afbeelding of tekstzone in het browservenster wordt weergegeven. Dat moment benadert doorgaans wanneer de belangrijkste inhoud bovenaan de pagina zichtbaar wordt.

• Bepaal bij een trage LCP eerst welk element wordt gemeten.
• Onderzoek daarna de serverreactie, omleidingen, renderblokkerende bronnen, het laden van media en client-side rendering.
• De geschikte oplossing hangt af van de vastgestelde oorzaak.

Interaction to Next Paint observeert de vertraging bij klikken, tikken en toetsaanslagen tijdens een bezoek. Een hoge INP kan ontstaan door lang werk op de main thread, zware JavaScript-taken of omvangrijke updates na een interactie.

Praktijkgegevens zijn voor deze metriek bijzonder belangrijk. Lighthouse kan zonder gebruikersinteractie geen echte INP meten en gebruikt onder meer Total Blocking Time als diagnostische labindicator.

Cumulative Layout Shift meet onverwachte verschuivingen van zichtbare inhoud. Een afbeelding zonder gereserveerde ruimte, een laat toegevoegd component of bepaalde lettertypes kunnen een knop of tekst tijdens het bekijken verplaatsen.

Leg afmetingen van media vast, reserveer plaats voor later geladen onderdelen en controleer echte gebruikerspaden. Een test van alleen de eerste paginalaad vindt niet noodzakelijk verschuivingen die pas na interactie optreden.

PageSpeed Insights kan praktijkgegevens uit het Chrome User Experience Report tonen wanneer er voldoende steekproeven zijn. Daarnaast voert het een Lighthouse-test uit in een gesimuleerde omgeving. De eerste beschrijven eerdere bezoeken; de tweede helpt oorzaken reproduceren en onderzoeken.

• De resultaten kunnen verschillen door apparaten, netwerken, inhoud en interacties.
• Gebruik praktijkgegevens om de bereikte ervaring te volgen en labgegevens voor diagnose.
• Geen praktijkgegevens betekent niet dat een pagina goed of slecht is.

Praktijkgegevens komen uit het Chrome User Experience Report, gevoed door bezoekers die Chrome gebruiken, het delen van gebruiksstatistieken hebben aanvaard en een publieke pagina bezoeken. Ze worden samengevoegd over achtentwintig voortschrijdende dagen en per URL gepubliceerd wanneer het volume volstaat, anders per oorsprong, dus voor de hele site.

• Een Brusselse kmo-site met enkele honderden bezoeken per maand haalt vaak de drempel per URL niet en soms ook de drempel per oorsprong niet.
• In dat geval toont PageSpeed Insights alleen de labtest, en blijft het Core Web Vitals-rapport in Search Console leeg.
• Dat is geen gebrek van de site, het is een statistische grens.

Er zijn twee oplossingen. De eerste: een eigen praktijkmeting installeren via een kleine bibliotheek die LCP, INP en CLS van elk bezoek naar een analysetool stuurt, wat vanaf de eerste bezoekers echte gegevens oplevert. De tweede: het lab als leidraad aanvaarden en controleren op echte toestellen, met een gesimuleerde gemiddelde mobiele verbinding.

De tijd tot de LCP valt uiteen in vier stukken: de antwoordtijd van de server voor de HTML, de vertraging voordat de browser de hoofdbron opvraagt, de laadtijd van die bron, en de vertraging tussen haar aankomst en haar weergave. Elk stuk heeft zijn oorzaken en zijn correcties.

Een trage server — verzadigde gedeelde hosting, CMS zonder cache, kettingomleidingen — wordt gecorrigeerd door caching of een andere hosting. Een hoge ontdekkingsvertraging betekent dat de hoofdafbeelding door JavaScript of CSS wordt geladen in plaats van in de HTML te staan; de oplossing is ze rechtstreeks te vermelden en als prioritair te markeren.

• Een lange laadtijd komt van het gewicht of het formaat van de afbeelding, en wordt gecorrigeerd door verkleinen en omzetten.
• Een late weergave na aankomst wijst erop dat blokkerende CSS of JavaScript de weergave tegenhoudt.
• De vier delen meten, wat de ontwikkeltools van browsers toelaten, voorkomt dat u op goed geluk corrigeert.

De INP houdt per bezoek een van de traagste interacties bij — klik, tik, toetsaanslag — met uitsluiting van de extreme gevallen. Een pagina kan dus snel laden en slecht scoren op INP als het openen van het mobiele menu, het kiezen van een variant of het bevestigen van een formulier zwaar werk uitlokt.

De gebruikelijke schuldigen zijn externe scripts die naar elke klik luisteren, animatiebibliotheken die de hele pagina herberekenen, eventhandlers die te veel synchroon doen, en volledig aan clientzijde gerenderde sites op bescheiden smartphones. De Total Blocking Time uit het lab helpt om lange taken te vinden, maar alleen de praktijkmeting wijst de precieze interactie aan.

De correcties bestaan erin minder werk te doen bij de interactie: uitstellen wat niet nodig is voor de onmiddellijke visuele reactie, lange taken opdelen, scripts verwijderen die niets bijbrengen, en meteen visuele feedback geven ook al loopt de verwerking erachter door. Een pagina die in minder dan tweehonderd milliseconden reageert, voelt onmiddellijk aan, wat de totale tijd ook is.

Een labtest meet de CLS tijdens het eerste laden, in een vast venster. De echte verschuivingen komen vaak later: een toestemmingsbanner die alle inhoud naar beneden duwt in plaats van erover te liggen, een afbeelding die bij het scrollen laadt zonder gereserveerde ruimte, een vervanglettertype dat door het definitieve wordt vervangen met een andere breedte, een blok dat na een netwerkverzoek wordt ingevoegd.

Om ze te vinden, navigeert u op de site met een echte smartphone en een vertraagde verbinding, en kijkt u naar wat beweegt. De ontwikkeltools van browsers kunnen ook een sessie opnemen en elke verschuiving oplijsten met het verantwoordelijke element.

De correcties zijn bijna altijd dezelfde: de afmetingen van elke afbeelding en video vermelden, ruimte reserveren voor later ingevoegde componenten, banners over de inhoud leggen in plaats van ze in de stroom in te voegen, en de weergave van lettertypes instellen om de breedtewijziging te beperken. Geen enkele vraagt een vernieuwing; allemaal vragen ze dat u de verschuiving hebt gezien.

Open één keer per maand het Core Web Vitals-rapport van Search Console als het beschikbaar is, en noteer het aantal goede, te verbeteren en slechte URL’s, op mobiel en desktop. Een verschil van maand tot maand is een signaal, geen alarm; twee opeenvolgende maanden in dezelfde richting verdienen een onderzoek.

Test daarna drie representatieve sjablonen — startpagina, diensten- of productpagina, artikel — in PageSpeed Insights, en vergelijk de labmetrieken met die van de vorige maand, in het besef dat ze van test tot test enkele procenten schommelen. Noteer de resultaten in een eenvoudige tabel, met de datum en de wijzigingen die intussen op de site zijn gebeurd.

• Die tabel wordt het geheugen van de site.
• Wanneer een metriek achteruitgaat, toont hij welke release samenviel met de achteruitgang, wat het onderzoek tot enkele minuten herleidt.
• Zonder die tabel begint elk prestatieprobleem van nul.

Google beveelt goede Core Web Vitals aan voor de gebruikerservaring en zegt dat dit, samen met andere aspecten van pagina-ervaring, aansluit bij wat de belangrijkste rankingsystemen willen belonen. Een groene score garandeert echter geen positie, verkeer of conversie.

Begin bij de paginatypes en metriek met een probleem, bevestig de oorzaak, voer de correctie uit, controleer op regressies en volg daarna de praktijkgegevens. Tijd en inspanning zijn pas na diagnose verantwoord te ramen.