Gepubliceerd: 11 februari 2025
De release van februari 2025 van het Chrome User Experience Report (CrUX) bevat een aantal opwindende nieuwe (en gewijzigde!) Statistieken:
- Grootste Contentful Paint (LCP) afbeeldingssubonderdelen en brontypen
- Details van de heen- en terugreistijd (RTT).
- Verwijdering van de dimensie Effectief verbindingstype (ECT).
Elk van deze biedt meer inzicht in de prestatiestatistieken van oorsprong en URL's die beschikbaar zijn in Crux en in dit bericht leggen we uit waarom.
Diagnostische informatie over LCP
We hebben het concept van LCP-subonderdelen oorspronkelijk geïntroduceerd in Google I/O 2022 als een effectieve techniek om de LCP-tijd voor pagina's met afbeeldings-LCP's op te splitsen in kleinere componenten, zodat u uw inspanningen kunt besteden aan het optimaliseren van de juiste oorzaak(en) van een hoge LCP.
Uit analyse van de HTTP Archive-labgegevens tijdens die lezing bleek dat de downloadtijd van afbeeldingen vaak het kleinste deel van de LCP-tijd vormde. Veel laboratoriumtools (waaronder Google's eigen Lighthouse) concentreerden zich vaak op advies om afbeeldingsformaten en -grootte te optimaliseren om de downloadtijden te verkorten en de prestaties te verbeteren. Hoewel nog steeds correct, toonde de analyse aan dat het advies mogelijk te veel nadruk had gelegd en dat een groter probleem de vertragingen waren voordat de afbeelding door de browser werd gevonden en begon te worden gedownload.
Hoewel het analyseren van laboratoriumgegevens nuttig kan zijn, kan de manier waarop het internet in de praktijk wordt gebruikt vaak verschillen. Daarom is het van cruciaal belang dat u deze subonderdelen voor veldgegevens kunt zien. Een vorig jaar gepubliceerd bericht bevestigde deze veel voorkomende misvatting over het optimaliseren van LCP met veldgegevens.
Subonderdelen van LCP-afbeeldingen
Met deze release kunnen site-eigenaren hun eigen sites controleren op de subonderdelen voor afbeeldings-LCP, op bron- of URL-niveau.
Subonderdelen zijn alleen beschikbaar voor afbeeldingen en dit omvat niet de eerste videoframe-afbeeldingen (die iets ingewikkelder zijn omdat we de volledige downloadtijd niet kunnen meten). Tekstsubonderdelen zijn ook niet opgenomen, omdat deze minder nuttig zijn en de nummers van afbeeldings-LCP's zouden vervormen. Voor sites die grotendeels uit tekst-LCP's bestaan, zijn de algemene TTFB- en algemene FCP-statistieken nuttige uitsplitsingen. Houd er echter rekening mee dat deze voor alle LCP's gelden en niet specifiek zijn voor tekst-LCP's. Ten slotte worden subonderdelen van afbeeldingen alleen verzameld bij het laden van een volledige pagina, in tegenstelling tot de LCP-statistiek zelf, die ook wordt verzameld bij achteruitnavigatie en vooraf gegenereerde pagina's.
Deze gegevens zijn vanaf februari 2025 toegevoegd aan de CrUX API en de CrUX History API (let op: niet BigQuery). De CrUX History API beschikt bij de lancering over twee weken aan gegevens, en dit zal in de loop van de tijd uitgroeien tot de volledige geschiedenis van 25 weken. De API's maken de gegevens beschikbaar als het 75e percentiel van elk subdeel, uitgedrukt in milliseconden.
Om bijvoorbeeld de LCP-afbeeldingssubonderdelen voor https://web.dev/ voor PHONE paginaweergaven te verkrijgen, kunt u de volgende curl-opdracht gebruiken (waarbij u API_KEY vervangt door uw eigen sleutel ):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"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"]}'
En je krijgt zoiets terug:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
We hebben de CrUX Vis-tool bijgewerkt om deze gegevens op te nemen en verwachten dat andere tools van derden die de CrUX API's gebruiken deze waardevolle gegevens ook openbaar zullen maken:
In dit voorbeeld kunnen we zien dat voor een populaire mediasite de laadduur van de bronnen het kleinste onderdeel is. De echte mogelijkheden voor verbetering voor deze site liggen in TTFB en vertraging bij het laden van bronnen , met een kleinere kans op vertraging bij het renderen van elementen .
Hoge waarden in elk subonderdeel duiden op verschillende problemen:
- High Time to First Byte (TTFB) wijst meestal op server-, netwerk- of omleidingsproblemen, zoals uitgelegd in TTFB optimaliseren .
- Een hoge vertraging bij het laden van bronnen geeft aan dat de LCP-afbeelding te laat door de browser wordt ontdekt, bijvoorbeeld een LCP-afbeelding die wordt geïnjecteerd door JavaScript aan de clientzijde en die enige tijd nodig heeft om te worden uitgevoerd.
- Bij een hoge laadduur van bronnen moet u kijken naar het verkleinen van de downloadgrootte van afbeeldingen.
- Er is sprake van een hoge vertraging bij het renderen van elementen wanneer de afbeelding beschikbaar is (misschien via een
<link rel=preload>maar lange tijd niet is gebruikt - wederom vaak omdat JavaScript aan de clientzijde vereist is om de afbeelding weer te geven.
We hopen dat het beschikbaar maken van deze gegevens in CrUX op zowel herkomst- als URL-niveau (afhankelijk van de gebruikelijke geschiktheidscriteria ) het voor sites gemakkelijker zal maken om hun LCP-statistiek te optimaliseren.
LCP-resourcetypen
Omdat de subonderdelen het beste kunnen worden bekeken voor afbeeldings-LCP's, beperkt CrUX deze gegevens alleen tot pagina's met afbeeldingen. Daarom is het belangrijk om te begrijpen hoeveel van uw LCP's beeld-LCP's zijn en geen tekst-LCP's (zoals bijvoorbeeld <h1> -koppen en lange alinea's).
Naast de LCP-afbeeldingssubonderdelen bevatten de CrUX API's nu ook een overzicht van de bronnen, waarin de verdeling van het laden van LCP-pagina's tussen tekst en afbeeldingen wordt weergegeven.
Om bijvoorbeeld de LCP-brontypen voor https://web.dev/ voor PHONE paginaweergaven op te halen, kunt u de volgende curl-opdracht gebruiken (opnieuw, waarbij u API_KEY vervangt door uw eigen sleutel ):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
En je krijgt zoiets terug:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
CrUX Vis is ook bijgewerkt om deze gegevens weer te geven:
Voor de startpagina van web.dev kunnen we bijvoorbeeld zien dat 98,5% van de LCP's in feite tekst-LCP's waren, dus de LCP-afbeeldingssubonderdelen zijn minder nuttig voor deze pagina. In dat geval kunnen we de oorspronkelijke TTFB- en FCP-statistieken gebruiken als een potentieel betere diagnostische uitsplitsing.
LCP-brontypen zijn een ander nuttig diagnostisch hulpmiddel voor het begrijpen en verbeteren van LCP, vooral om te weten hoe nuttig de subonderdelen van LCP-afbeeldingen zijn.
RTT-diagnostische informatie
We hebben ook de RTT-statistiek uitgebreid, die voor het eerst werd geïntroduceerd in augustus 2024 .
RTT driebakken
We hebben tri-bins toegevoegd aan de CrUX API's die drie groepen RTT-dichtheden tonen:
| Netwerklatentie | Begin | Einde |
|---|---|---|
| Laag | 0 milliseconden | < 75 milliseconden |
| Medium | 75 milliseconden | < 275 milliseconden |
| Hoog | 275 milliseconden | ∞ |
Deze bakken zijn informatiever dan de vorige ECT-categorieën, die alles van minder dan 270 milliseconden in de 4g categorie omvatten. Door de vooruitgang op het gebied van netwerktechnologie sinds deze werd gelanceerd, zagen de meeste sites het grootste deel van hun verkeer in die categorie, waardoor deze categorisering minder bruikbaar werd.
Dit is de reden waarom we voorstellen om de labels low , medium en high distributies te gebruiken in plaats van de gebruikelijke labels goed , moet worden verbeterd en slecht . Het zijn geen statistieken die een site-eigenaar zelf rechtstreeks kan verbeteren. Het zijn daarom diagnostische statistieken om de andere statistieken te begrijpen en te begrijpen waarom deze anders kunnen zijn dan verwacht. Ze kunnen ook helpen verklaren waarom andere statistieken in de loop van de tijd veranderen, ondanks dat de site niet verandert als ze een verandering in het gebruikersbestand laten zien.
Deze bakken zijn beschikbaar in de CrUX API's, bijvoorbeeld voor web.dev voor PHONE paginaweergaven (opnieuw, waarbij API_KEY wordt vervangen door uw eigen sleutel ):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Wat ongeveer dit oplevert:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
De bakken worden weergegeven in Crux Vis wanneer distributies worden geselecteerd:
RTT in BigQuery
Naast het uitbreiden van de RTT-statistiek in de CrUX API's met de tri-bins, hebben we de gegevens ook beschikbaar gemaakt in de maandelijkse BigQuery-dataset, inclusief een volledig histogram in buckets van 25 milliseconden in de onbewerkte tabellen en tri-bins en p75-waarden in de gematerialiseerde tabellen .
Dit maakt een dieper inzicht mogelijk in de distributie van gegevens buiten de tri-bins die beschikbaar zijn in de CrUX API's. Het stelt ons ook in staat om de ECT-storing te reproduceren die vanaf deze maand uit CrUX is verwijderd (daarover later meer) – met de kleine verandering van een drempel van 275 milliseconden voor 4g in plaats van de vorige drempel van 270 milliseconden. De ECT-uitsplitsingen (nu afkomstig uit RTT-gegevens) blijven beschikbaar in de gematerialiseerde Crux BigQuery-tabellen, zodat tools zoals het Crux Dashboard deze uitsplitsing kunnen blijven tonen.
De BigQuery-dataset bevat ook gegevens per land (zoals gedefinieerd in ISO 3166-1 ). Dit maakt diepere analyses mogelijk, wat nuttig kan zijn om uit te leggen waarom prestatiestatistieken voor sommige gebruikers slechter zijn. We kunnen bijvoorbeeld de gegevens voor Google Phone-gebruikers bekijken door naar de gegevens voor https://www.google.com te kijken:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Vervolgens visualiseren we de gegevens op een Geo-kaart:
https://www.google.com( brongegevens met interactieve grafiek ).
We kunnen zien dat, terwijl het grootste deel van de wereld (vooral de “Westerse wereld”) zeer goede RTT’s heeft, Sub-Sahara Afrika, delen van het Midden-Oosten en delen van Azië het moeilijker hebben. In feite is de grafiek beperkt tot 500 milliseconden RTT, omdat het gebruik van de volledige gegevens de kleuren vertekend maakt – vooral met Eritrea op een 75e percentiel van 3.850 milliseconden!
Dit kan ook handig zijn als verkeerspatronen veranderen. Een groter deel van de gebruikers uit landen met hogere RTT's kan bijvoorbeeld de slechtere Core Web Vitals-statistieken verklaren, ondanks dat de site niets verandert.
Hoewel sites de RTT niet rechtstreeks kunnen verbeteren, zorgt het beschikbaar stellen van deze gegevens voor de bezoekers van een site voor een beter inzicht in de gebruikers van uw site over de hele wereld. Het biedt ook veel mogelijkheden voor analyse in de toekomst en we hopen dat onderzoekers interessante inzichten uit deze dataset zullen vinden.
Verwijdering van de ECT-dimensie
De laatste verandering in de release van februari 2025 is de stopzetting van de dimensie Effective Connection Type (ECT) uit BigQuery (we hadden RTT al vanaf september 2024 uit de API's verwijderd toen we de RTT-statistiek destijds als vervanging introduceerden).
Zoals eerder in dit bericht vermeld, biedt de RTT-statistiek een gedetailleerder beeld van de verbindingsgegevens van de bezoekers van een site. U kunt zelfs de ECT-buckets opnieuw maken op basis van die histogrammen. (Technisch gezien zou ECT een combinatie moeten zijn van RTT en downlinksnelheid , maar Chrome gebruikte alleen RTT .)
Een belangrijk verschil is dat ECT een CrUX-dimensie was, wat betekent dat de andere statistieken door ECT konden worden gesegmenteerd. RTT is een CrUX-statistiek in plaats van een dimensie, dus het is bijvoorbeeld niet mogelijk om LCP per RTT te bekijken, maar alleen om de RTT's te zien op basis van de andere dimensies (apparaattype en land).
Dit klinkt misschien beperkender, maar de overstap van dimensie naar statistiek ontgrendelt feitelijk meer gegevens in CrUX. Dit komt omdat CrUX bepaalde minimumdrempels heeft voordat we gegevens kunnen tonen. We hebben dimensies al optioneel gemaakt in 2022, wat betekent dat we ECT hebben verwijderd, of het apparaat waar nodig om op een hoger niveau te rapporteren, maar statistieken die niet op de meeste pagina's werden geladen ( Interaction to Next Paint (INP) , verschillende navigatietypen en nu LCP-afbeeldingssubonderdelen) waren vaak niet beschikbaar voor oorsprong in BigQuery.
Door het aantal dimensies te verminderen, worden de gegevens minder gesegmenteerd, waardoor het aantal herkomsten dat aan deze minimumvereisten voldoet, toeneemt. In januari rapporteren we INP voor 68,1% van de herkomsten, terwijl we voor de dataset van december slechts INP rapporteerden voor 64,5% van de herkomsten. Het mechanisme is ook van toepassing op navigatietypen, de LCP-subonderdelen en resourcetypen in deze release; ze profiteren allemaal van de verwijdering van de ECT-dimensie. In de CrUX API’s is de verhoogde dekking vanaf begin februari van kracht.
De ECT-kolommen blijven in BigQuery voor consistentie met eerdere datasets, en de ECT-gegevens in de gerealiseerde weergaven blijven beschikbaar, maar gebaseerd op de RTT-informatie (met een verschil van 5 milliseconden voor 3g en 4g zoals eerder opgemerkt) naast de nieuwe RTT p75 en tri-bins.
Conclusie
De toevoeging van meer statistieken aan de openbare CrUX-dataset geeft site-eigenaren en onderzoekers veel meer informatie om prestatieproblemen te helpen diagnosticeren en uiteindelijk op te lossen.
Als openbare dataset heeft CrUX bepaalde beperkingen wat betreft het detailniveau dat we kunnen weergeven. Individuele elementselectors zullen bijvoorbeeld nooit in CrUX kunnen worden weergegeven. Site-eigenaren die dit detailniveau zoeken, worden ten zeerste aangeraden een RUM-oplossing te implementeren, die niet zo beperkt zal zijn.
Geaggregeerde gegevens op een hoger niveau, zoals die in dit bericht worden beschreven, kunnen echter helpen de kloof te overbruggen tussen weten dat u een probleem heeft en waarom het probleem bestaat. We hopen dat deze extra gegevens nuttig zullen zijn. Laat het ons weten in de discussiegroep als je feedback of vragen hebt!