Metrics in CrUX worden aangestuurd door standaard webplatform-API's die door browsers beschikbaar worden gesteld. Met name in de BigQuery-dataset worden deze gegevens geaggregeerd tot oorsprongsresolutie. Site-eigenaren die meer gedetailleerde (bijvoorbeeld URL-niveau resolutie) analyse en inzicht in hun siteprestaties nodig hebben, kunnen dezelfde API's gebruiken om gedetailleerde gegevens over real-user measurement (RUM) voor hun eigen oorsprongen te verzamelen. Hoewel alle API's beschikbaar zijn in Chrome, ondersteunen andere browsers mogelijk niet de volledige set metrics.
De meeste statistieken worden weergegeven als een histogram-aggregatie, waardoor visualisatie van de distributie en benadering van percentielwaarden mogelijk is.
Cumulatieve lay-outverschuiving
Cumulatieve lay-outverschuiving (CLS) is een belangrijke, gebruikersgerichte metriek voor het meten van de visuele stabiliteit, omdat het helpt te kwantificeren hoe vaak gebruikers onverwachte lay-outverschuivingen ervaren. Een lage CLS zorgt ervoor dat de pagina er aantrekkelijk uitziet.
DOM-inhoud geladen
"DOMContentLoaded geeft het tijdstip aan waarop het oorspronkelijke HTML-document volledig is geladen en geparseerd, zonder te wachten tot de stylesheets, afbeeldingen en subframes volledig zijn geladen."
Eerste verf
First Paint rapporteert het tijdstip waarop de browser voor het eerst heeft gerenderd na navigatie. Dit is exclusief de standaard achtergrondverf, maar inclusief niet-standaard achtergrondverf. Dit is het eerste belangrijke moment waar ontwikkelaars rekening mee moeten houden bij het laden van een pagina: wanneer de browser is begonnen met het renderen van de pagina.
Eerste Contentful Paint
First Contentful Paint (FCP) rapporteert het tijdstip waarop de browser voor het eerst tekst, afbeeldingen (inclusief achtergrondafbeeldingen), niet-witte canvassen of SVG's heeft weergegeven. Dit omvat tekst met in behandeling zijnde webfonts. Dit is de eerste keer dat gebruikers pagina-inhoud konden bekijken.
Interactie met Next Paint
Interaction to Next Paint (INP) is een veldmetriek die de responsiviteit beoordeelt. INP registreert de latentie van alle interacties gedurende de gehele levenscyclus van de pagina. De hoogste waarde van die interacties – of bijna de hoogste waarde voor pagina's met veel interacties – wordt geregistreerd als de INP van de pagina. Een lage INP zorgt ervoor dat de pagina te allen tijde betrouwbaar reageert.
Interaction to Next Paint (INP) is in februari 2022 toegevoegd aan de CrUX-dataset. Deze nieuwe metriek legt de end-to-end-latentie van individuele gebeurtenissen vast en biedt een holistischer beeld van de algehele responsiviteit van een pagina gedurende de gehele levensduur.
Grootste contentvolle verf
"Largest Contentful Paint (LCP) is een belangrijke, gebruikersgerichte metriek voor het meten van de waargenomen laadsnelheid, omdat het het punt in de laadtijdlijn van de pagina markeert waarop de belangrijkste inhoud van de pagina waarschijnlijk is geladen. Een snelle LCP geeft de gebruiker het vertrouwen dat de pagina nuttig is."
Grootste Contentful Paint-brontype
"LCP rapporteert de rendertijd van de grootste afbeelding, het grootste tekstblok of de grootste video die zichtbaar is in de viewport, relatief ten opzichte van het moment waarop de gebruiker voor het eerst naar de pagina navigeerde."
web.dev/articles/lcp - Welke elementen worden overwogen voor LCP?
Tekst en afbeeldingen (inclusief het eerste videoframe) hebben vaak zeer verschillende laadkarakteristieken en optimalisatietechnieken. Inzicht in de verhouding tussen LCP-resourcetypen geeft u meer inzicht in uw LCP-statistieken en optimalisatiepaden.
Zie de blogpost over het starten van LCP-resourcetypen voor meer informatie.
Grootste Contentful Paint-afbeeldingssubonderdelen
Optimaliseren voor LCP kan een complexere taak zijn wanneer PageSpeed Insights u geen antwoord geeft op hoe u deze statistiek kunt verbeteren. Bij complexe taken is het over het algemeen beter om ze op te splitsen in kleinere, beter beheersbare taken en deze afzonderlijk aan te pakken.
web.dev/articles/optimize-lcp - LCP-onderverdeling in subonderdelen
Door LCP-afbeeldingen op te splitsen in de meest cruciale subonderdelen, kunt u specifieke aanbevelingen en best practices gebruiken om elk onderdeel te optimaliseren.
LCP-afbeeldingsonderdelen worden in vier afzonderlijke metrieken aangeboden:
-
largest_contentful_paint_image_time_to_first_byte -
largest_contentful_paint_image_resource_load_delay -
largest_contentful_paint_image_resource_load_duration -
largest_contentful_paint_image_element_render_delay
Subonderdelen zijn alleen opgenomen voor afbeeldingen en dit geldt niet voor afbeeldingen van het eerste videoframe, aangezien deze iets ingewikkelder zijn omdat we de volledige downloadtijd niet kunnen meten (let op: eerste videoframes zijn opgenomen in de LCP-resourcetypemetriek, waar die complicatie niet relevant is).
Tekstsubonderdelen zijn ook niet opgenomen, omdat ze minder nuttig zijn en de cijfers van de beeld-LCP's zouden vertekenen. Voor sites die grotendeels uit tekst-LCP's bestaan, zijn de totale TTFB- en totale FCP- statistieken nuttige overzichten – maar merk op dat ze voor alle LCP's gelden en niet specifiek voor tekst-LCP's.
Zie de blogpost over de lancering van de LCP-image-subonderdelen voor meer informatie.
Navigatietypen
De statistiek Navigatietypen biedt een overzicht van het percentage paginaweergaven van de volgende navigaties:
| Type | Beschrijving |
|---|---|
navigate | Een paginalading die niet in een van de andere categorieën past. |
navigate_cache | Een paginalading waarbij de hoofdbron (het HTML-document) vanuit de HTTP-cache werd geserveerd. Sites maken vaak gebruik van caching voor subbronnen, maar het HTML-document wordt vaak aanzienlijk minder gecached. Wanneer dat mogelijk is, kan dit leiden tot merkbare prestatieverbeteringen doordat het lokaal en op een CDN gecached kan worden. |
reload | De gebruiker heeft de pagina opnieuw geladen, door op de knop 'Vernieuwen' te klikken, door op Enter in de adresbalk te drukken of door een tabblad ongedaan te maken. Het opnieuw laden van pagina's leidt vaak tot een validatie naar de server om te controleren of de hoofdpagina is gewijzigd. Een hoog percentage pagina's dat opnieuw wordt geladen, kan wijzen op frustraties in de gebruikerservaring. |
restore | De pagina is opnieuw geladen na een herstart van de browser, of na een tabblad dat vanwege geheugenproblemen was verwijderd. Voor Chrome op Android worden deze meldingen weergegeven als 'opnieuw laden'. |
back_forward | Een geschiedenisnavigatie, wat betekent dat de pagina recent is bekeken en ernaar is teruggekeerd. Met correcte caching zouden dit redelijk snelle ervaringen moeten zijn, maar vereisen ze nog steeds dat de pagina wordt verwerkt en JavaScript wordt uitgevoerd – beide zaken die bfcache vermijdt. |
back_forward_cache | Een geschiedenisnavigatie die werd aangestuurd vanuit de bfcache. Het optimaliseren van je pagina's om bfcache te benutten door blokkeringen te verwijderen, zou moeten resulteren in snellere ervaringen, zodat sites er beter uitzien. |
prerender | De pagina is vooraf gerenderd, wat – net als bfcache – kan resulteren in vrijwel onmiddellijke paginaladingen. |
In sommige gevallen kan het laden van een pagina een combinatie zijn van meerdere navigatietypen. In dat geval rapporteert CrUX de eerste match in omgekeerde volgorde van de tabel (van onder naar boven).
Meer informatie vindt u in het aankondigingsbericht over de navigatietypen .
Onload
"De laadgebeurtenis wordt geactiveerd wanneer de pagina en de afhankelijke bronnen klaar zijn met laden."
Retourtijd
Geeft een schatting van de HTTP-roundtriptijd (applicatielaag) aan het begin van de navigatie, gebaseerd op recente netwerkverbindingen. Deze metriek is gebaseerd op de rtt eigenschap van de Network Information API , dezelfde API die verantwoordelijk is voor de voormalige dimensie Effective Connection Type (ECT) .
Zie de blogpost over het starten van LCP-resourcetypen voor meer informatie.
Experimentele metriek
Experimentele statistieken zijn beschikbaar in de CrUX-dataset met behulp van BigQuery , en sommige ook in de CrUX API . Deze statistieken zullen waarschijnlijk regelmatig veranderen naarmate ze evolueren op basis van gebruikersfeedback. Raadpleeg de release notes om op de hoogte te blijven van de laatste wijzigingen.
Tijd tot eerste byte
TTFB in CrUX wordt alleen verzameld bij het laden van volledige pagina's, in tegenstelling tot andere timers (zoals LCP ) die ook worden verzameld bij voor- en achterwaartse navigatie en vooraf gerenderde pagina's. De steekproefomvang van TTFB kan daarom kleiner zijn dan die van andere statistieken en hoeft niet per se direct met deze parameters te worden vergeleken.
TTFB is geen directe maatstaf voor de serverresponstijd, omdat het metingen omvat die daaraan voorafgaan, zoals de omleidingstijd, en wordt beïnvloed door het feit of een respons wordt geleverd vanuit de cache, het CDN of de server. Dit is met name duidelijk zichtbaar in veldgegevens zoals CrUX, terwijl laboratoriumtests doorgaans minder door deze factoren worden beïnvloed, omdat de eind-URL wordt getest en vaak herhaaldelijk cachewijzigingen tenietdoet.
Populariteit
De populariteitsrang is een relatieve maatstaf voor de populariteit van de site binnen de CrUX-dataset, gemeten aan de hand van het totale aantal navigaties op de bron. De rang wordt bepaald op een log10-schaal met halve stappen (bijv. top 1000, top 5000, top 10000, top 50000, top 1 miljoen, enz.), waarbij elke rang de vorige uitsluit (bijv. top 5000 is in feite 4000 URL's, exclusief top 1000). De bovengrens is dynamisch naarmate de dataset groeit.
Populariteit wordt gebruikt als leidraad voor uitgebreide analyses, bijvoorbeeld om de prestaties per land voor de top 1.000 van herkomsten te bepalen.
Meldingsmachtigingen
Voor websites die toestemming vragen om gebruikers meldingen te tonen, vertegenwoordigt deze statistiek de relatieve frequentie van de reacties van gebruikers op de prompts: accepteren, weigeren, negeren of verwijderen.