Statistieken

Gepubliceerd: 23 juni 2022, Laatst bijgewerkt: 18 november 2025

De statistieken in CrUX worden gegenereerd door standaard webplatform-API's die door browsers beschikbaar worden gesteld. In de BigQuery-dataset worden deze gegevens met name geaggregeerd tot op origin-niveau. Website-eigenaren die behoefte hebben aan een meer gedetailleerde analyse (bijvoorbeeld op URL-niveau) en inzicht in de prestaties van hun site, kunnen dezelfde API's gebruiken om gedetailleerde Real User Measurement (RUM)-gegevens voor hun eigen origins te verzamelen. Houd er rekening mee dat hoewel alle API's beschikbaar zijn in Chrome, andere browsers mogelijk niet de volledige set statistieken ondersteunen.

De meeste meetwaarden worden weergegeven als een histogram, waardoor de verdeling kan worden gevisualiseerd en percentielwaarden kunnen worden benaderd.

Cumulatieve lay-outverschuiving

"Cumulatieve lay-outverschuiving (CLS) is een belangrijke, gebruikersgerichte maatstaf voor het meten van visuele stabiliteit, omdat het helpt kwantificeren hoe vaak gebruikers onverwachte lay-outverschuivingen ervaren. Een lage CLS draagt ​​bij aan een prettige gebruikerservaring."

web.dev/articles/cls

DOM-inhoud geladen

"De DOMContentLoaded-functie geeft het tijdstip aan waarop het initiële HTML-document volledig is geladen en geparseerd, zonder te wachten tot stylesheets, afbeeldingen en subframes klaar zijn met laden."

MDN

Eerste verfbeurt

"First Paint geeft het tijdstip aan waarop de browser de pagina voor het eerst weergeeft na navigatie. Dit sluit de standaard achtergrondweergave uit, maar omvat wel de niet-standaard achtergrondweergave. Dit is het eerste cruciale moment voor ontwikkelaars tijdens het laden van een pagina: wanneer de browser begint met het weergeven van de pagina."

Paint Timing API

Eerste tevredenstellende verf

"First Contentful Paint (FCP) registreert het tijdstip waarop de browser voor het eerst tekst, afbeeldingen (inclusief achtergrondafbeeldingen), niet-witte canvas-elementen of SVG-bestanden heeft weergegeven. Dit omvat ook tekst met nog niet geladen webfonts. Dit is het eerste moment waarop gebruikers de pagina-inhoud kunnen bekijken."

Paint Timing API

Interactie met volgende verfbeurt

"Interaction to Next Paint (INP) is een veldmetriek die de responsiviteit beoordeelt. INP registreert de latentie van alle interacties gedurende de volledige levenscyclus van de pagina. De hoogste waarde van die interacties – of een waarde die daar dicht bij ligt voor pagina's met veel interacties – wordt geregistreerd als de INP van de pagina. Een lage INP garandeert dat de pagina te allen tijde betrouwbaar responsief zal zijn."

web.dev/articles/inp

Interaction to Next Paint (INP) werd in februari 2022 toegevoegd aan de CruX-dataset. Deze nieuwe metriek registreert de totale latentie van individuele gebeurtenissen en biedt een completer beeld van de algehele responsiviteit van een pagina gedurende de gehele levensduur.

Grootste Inhoudelijke Verf

"Largest Contentful Paint (LCP) is een belangrijke, gebruikersgerichte indicator voor het meten van de waargenomen laadsnelheid, omdat het het punt in de laadtijdlijn van de pagina aangeeft waarop de belangrijkste inhoud van de pagina waarschijnlijk is geladen. Een snelle LCP geeft de gebruiker het vertrouwen dat de pagina nuttig is."

web.dev/articles/lcp

Grootste Contentful Paint-brontype

"LCP rapporteert de weergavetijd van de grootste afbeelding, tekstblok of video die zichtbaar is in het weergavegebied, ten opzichte van het moment waarop de gebruiker de pagina voor het eerst bezocht."

web.dev/articles/lcp - Welke elementen worden in aanmerking genomen voor LCP?

Tekst en afbeeldingen (inclusief het eerste videobeeld) hebben vaak zeer verschillende laadeigenschappen en optimalisatietechnieken. Inzicht in de verhouding tussen de verschillende LCP-resourcetypen stelt u in staat uw LCP-statistieken en optimalisatiepaden beter te begrijpen.

Opmerking: LCP-resourcetypen worden alleen verzameld bij het volledig laden van pagina's, in tegenstelling tot de LCP-metriek zelf, die ook wordt verzameld bij navigaties heen en weer en bij vooraf gerenderde pagina's.

Voor meer informatie kunt u het blogbericht over de lancering van de LCP-resourcetypen raadplegen.

Grootste Contentful Paint-afbeeldingsonderdelen

"Optimaliseren voor LCP kan een complexere taak zijn als PageSpeed ​​Insights geen antwoord geeft op de vraag hoe deze statistiek verbeterd kan worden. 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 opsplitsen in subonderdelen

Door LCP's van afbeeldingen op te splitsen in hun meest cruciale subonderdelen, kunnen specifieke aanbevelingen en best practices worden toegepast om elk onderdeel te optimaliseren.

De LCP-beeldonderdelen worden in vier afzonderlijke meeteenheden weergegeven:

• 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

Belangrijk punt: Omdat de afbeeldingsonderdelen geaggregeerde gegevens van meerdere paginaweergaven vertegenwoordigen, worden ze weergegeven op het 75e percentiel. De som van de onderdelen zal daarom naar verwachting niet gelijk zijn aan het algehele LCP-75e percentiel. LCP-afbeeldingsonderdelen dienen om een ​​indicatie te geven van het relatieve belang van de onderdelen, en niet om een ​​exacte uitsplitsing van de LCP-waarde op het 75e percentiel te geven.

Deelonderdelen zijn alleen opgenomen voor afbeeldingen en dit omvat niet de eerste videoframes, omdat deze iets complexer zijn doordat we de volledige downloadtijd niet kunnen meten (merk op dat de eerste videoframes wel zijn opgenomen in de LCP-resourcetypemetriek, waar deze complicatie niet relevant is).

Tekstonderdelen worden ook niet meegenomen, omdat ze minder nuttig zijn en de LCP-cijfers voor afbeeldingen zouden vertekenen. Voor sites die grotendeels uit tekst-LCP's bestaan, zijn de algemene TTFB- en FCP- statistieken wel nuttige uitsplitsingen, maar let op: deze zijn gebaseerd op alle LCP's en niet specifiek op tekst-LCP's.

Opmerking: LCP-afbeeldingsonderdelen worden alleen verzameld bij het volledig laden van een pagina, in tegenstelling tot de LCP-metriek zelf, die ook wordt verzameld bij navigatie van en naar de vorige pagina en bij vooraf gerenderde pagina's.

Voor meer informatie kunt u het blogbericht over de lancering van de LCP-beeldsubonderdelen raadplegen.

Navigatietypen

De statistiek 'navigatietypen' geeft een uitsplitsing van het percentage paginaweergaven van de volgende navigatietypen:

Type	Beschrijving
navigate	Een pagina die geladen wordt en die in geen van de andere categorieën past.
navigate_cache	Een pagina die geladen is, waarbij de hoofdbron (het belangrijkste HTML-document) vanuit de HTTP-cache werd geleverd. Websites maken vaak gebruik van caching voor subbronnen, maar het belangrijkste HTML-document wordt doorgaans veel minder vaak gecached. Wanneer dit wel mogelijk is, kan het cachen van zowel het lokale als het CDN-bestand merkbare prestatieverbeteringen opleveren.
reload	De gebruiker heeft de pagina opnieuw geladen, bijvoorbeeld door op de vernieuwknop te klikken, door op Enter in de adresbalk te drukken of door een tabblad te sluiten. Het opnieuw laden van een pagina resulteert vaak in een hercontrole door de server om te verifiëren of de hoofdpagina is gewijzigd. Een hoog percentage paginavernieuwingen kan wijzen op frustraties bij de gebruiker.
restore	De pagina werd opnieuw geladen na een herstart van de browser, of na het verwijderen van een tabblad vanwege geheugenproblemen. In Chrome op Android wordt dit in plaats daarvan als 'herladen' weergegeven.
back_forward	Een navigatiegeschiedenis betekent dat de pagina recent is bekeken en opnieuw is bezocht. Met de juiste caching zou dit een redelijk snelle ervaring moeten opleveren, maar het vereist nog steeds dat de pagina wordt verwerkt en JavaScript wordt uitgevoerd – beide processen worden door bfcache vermeden.
back_forward_cache	Een geschiedenisnavigatie die werd aangeboden vanuit de bfcache. Door uw pagina's te optimaliseren om te profiteren van de bfcache, door blokkades te verwijderen, zou dit moeten leiden tot snellere gebruikerservaringen, waardoor websites er beter uit zouden moeten zien.
prerender	De pagina werd vooraf gerenderd , wat – net als bfcache – kan resulteren in vrijwel onmiddellijke laadtijden.

In sommige gevallen kan een paginalading een combinatie zijn van meerdere navigatietypen. In dat geval rapporteert CruX de eerste overeenkomst in omgekeerde volgorde van de tabel (van onder naar boven).

Meer informatie is te vinden in het aankondigingsbericht over navigatietypen .

Onload

"De laadgebeurtenis wordt geactiveerd wanneer de pagina en de bijbehorende bronnen volledig zijn geladen."

MDN

Reistijd heen en terug

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 was voor de voorheen gebruikte Effective Connection Type (ECT) -dimensie.

Kernpunt: De retourtijd is een maatstaf voor de bezoekers aan uw site (gebaseerd op hun recente internetactiviteit), en niet voor de site zelf.

Voor meer informatie kunt u het blogbericht over de lancering van de LCP-resourcetypen raadplegen.

Experimentele meetwaarden

Experimentele statistieken zijn beschikbaar in de CrUX-dataset via BigQuery , en sommige zijn ook beschikbaar via de CrUX API . Deze statistieken zullen waarschijnlijk regelmatig veranderen naarmate ze evolueren op basis van feedback van gebruikers. Raadpleeg de release notes om op de hoogte te blijven van de laatste wijzigingen.

Tijd tot eerste byte

Opmerking: "Time to First Byte (TTFB) is een fundamentele meetwaarde voor het meten van de verbindingsopbouwtijd en de responsiviteit van webservers, zowel in het lab als in de praktijk. Het helpt vaststellen wanneer een webserver te traag reageert op verzoeken. In het geval van navigatieverzoeken – dat wil zeggen, verzoeken om een ​​HTML-document – ​​gaat het vooraf aan alle andere relevante prestatiemetingen voor het laden." web.dev/articles/ttfb

De TTFB-waarde in CrUX wordt alleen gemeten bij volledige paginaladingen, in tegenstelling tot andere timers (zoals LCP ) die ook worden gemeten bij navigaties met de back/forward-cache (bfcache) en bij vooraf gerenderde pagina's . Daardoor kan de steekproefomvang van TTFB kleiner zijn dan die van andere statistieken en is deze niet per se direct vergelijkbaar. De TTFB-waarde in CrUX omvat zowel koude paginaladingen, gecachede paginaladingen als paginaladingen via een bestaande verbinding (bijvoorbeeld paginaladingen binnen dezelfde site).

TTFB is geen directe maatstaf voor de reactietijd van de server, omdat het ook metingen van vóór die tijd omvat, zoals de omleidingstijd, en beïnvloed wordt door de vraag of een reactie vanuit de cache, een CDN of rechtstreeks van de server komt. Dit is met name merkbaar bij velddata zoals CruxU, terwijl laboratoriumtests doorgaans minder door deze factoren worden beïnvloed, omdat de uiteindelijke URL wordt getest en vaak herhaaldelijk wijzigingen in de cache teniet worden gedaan.

Populariteit

The popularity rank metric is a relative measure of site popularity within the CrUX dataset, measured by the total number of navigations on the origin. Rank is on a log10 scale with half steps (eg top 1k, top 5k, top 10k, top 50k, top 100k, top 500k, top 1M, etc.) with each rank excluding the previous (eg top 5k is actually 4k URLs, excluding top 1k). The upper limit is dynamic as the dataset grows.

Populariteit dient als leidraad voor een brede analyse, bijvoorbeeld om de prestaties per land te bepalen voor de 1000 meest voorkomende herkomstlanden.

Meldingsrechten

Opmerking: "De Notifications API stelt webpagina's in staat om de weergave van systeemnotificaties aan de eindgebruiker te beheren. Deze meldingen bevinden zich buiten het hoofdvenster van de browsercontext en kunnen daarom worden weergegeven, zelfs wanneer de gebruiker van tabblad is gewisseld of naar een andere app is overgeschakeld. De API is ontworpen om compatibel te zijn met bestaande notificatiesystemen op verschillende platformen." MDN

Voor websites die toestemming vragen om gebruikers meldingen te tonen, geeft deze statistiek de relatieve frequentie weer van de reacties van gebruikers op de prompts: accepteren, weigeren, negeren of wegstoppen.