Pubblicata: 11 febbraio 2025
La release di febbraio 2025 del Report sull'esperienza utente di Chrome (CrUX) include una serie di nuove (e modificate) metriche interessanti:
- Componenti secondari delle immagini e tipi di risorse per Largest Contentful Paint (LCP)
- Dettagli sul tempo di round trip (RTT)
- Rimozione della dimensione Tipo di connessione effettivo
Ognuna di queste fornisce informazioni più dettagliate sulle metriche sul rendimento delle origini e degli URL disponibili in CrUX e in questo post spiegheremo nel dettaglio il motivo.
Informazioni diagnostiche LCP
Abbiamo inizialmente introdotto il concetto di componenti LCP in Google I/O 2022 come tecnica efficace per suddividere il tempo LCP per le pagine con LCP delle immagini in componenti più piccoli per assicurarti di dedicare le tue risorse all'ottimizzazione delle cause corrette di un LCP elevato.
L'analisi dei dati del laboratorio HTTP Archive riportata nel talk ha dimostrato che il tempo di download delle immagini è spesso la parte più piccola del tempo LCP. Molti strumenti di laboratorio (incluso Lighthouse di Google) si concentravano spesso su consigli per ottimizzare le dimensioni e i formati delle immagini al fine di ridurre i tempi di download e migliorare le prestazioni. Sebbene sia ancora corretto, l'analisi ha dimostrato che il consiglio potrebbe essere stato enfatizzato eccessivamente e che un problema più grande riguardava i ritardi prima che l'immagine venisse trovata dal browser e iniziasse a essere scaricata.
Sebbene l'analisi dei dati di prova controllati possa essere utile, il modo in cui il web viene utilizzato nella vita reale può spesso variare, quindi è fondamentale poter vedere queste sottoparti per i dati sul campo. Un post pubblicato lo scorso anno ha confermato un equivoco comune su come ottimizzare l'LCP con i dati sul campo.
Componenti secondari dell'immagine LCP
Con questa release, i proprietari di siti possono controllare i propri siti per verificare la presenza di componenti secondari per l'LCP delle immagini, a livello di origine o di URL.
Le sottoparti sono disponibili solo per le immagini e non sono incluse le immagini del primo fotogramma del video (che sono un po' più complicate perché non possiamo misurare il tempo di download completo). Inoltre, non sono inclusi i componenti secondari di testo, in quanto sono meno utili e distorcerebbero i numeri LCP delle immagini. Per i siti costituiti in gran parte da LCP di testo, le metriche TTFB e FCP complessive sono suddivisioni utili, anche se tieni presente che si applicano a tutti i LCP e non sono specifiche per i LCP di testo. Infine, i componenti secondari delle immagini vengono raccolti solo durante i caricamenti completi della pagina, a differenza della metrica LCP stessa, che viene raccolta anche durante la navigazione avanti e indietro e nelle pagine sottoposte a prerendering.
Questi dati sono stati aggiunti all'API CrUX e all'API CrUX History a partire da febbraio 2025 (nota: non BigQuery). Al momento del lancio, l'API CrUX History contiene dati di due settimane, che aumenteranno nel tempo fino a includere la cronologia completa di 25 settimane. Le API rendono disponibili i dati come 75° percentile di ogni sottoparte espresso in millisecondi.
Ad esempio, per ottenere i componenti secondari dell'immagine LCP per https://web.dev/ per PHONE visualizzazioni di pagina, puoi utilizzare il seguente comando curl (sostituendo API_KEY con la tua chiave):
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"]}'
Riceverai una risposta simile alla seguente:
{
"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
}
}
}
}
Abbiamo aggiornato lo strumento di visualizzazione CrUX per includere questi dati e prevediamo che anche altri strumenti di terze parti che utilizzano le API CrUX mostrino questi dati importanti:
In questo esempio, vediamo che per un sito di media popolare la durata del caricamento delle risorse è il componente più piccolo. Le reali opportunità di miglioramento per questo sito riguardano il TTFB e il ritardo di caricamento delle risorse, con un'opportunità minore nel ritardo di rendering degli elementi.
I valori elevati in ogni sottoparte indicano diversi problemi:
- Un tempo per primo byte (TTFB) elevato in genere indica problemi di server, rete o reindirizzamento, come spiegato in Ottimizzare il TTFB.
- Un ritardo di caricamento delle risorse elevato indica che l'immagine LCP viene rilevata in ritardo dal browser, ad esempio un'immagine LCP iniettata da JavaScript lato client che richiede un po' di tempo per l'esecuzione.
- Se la durata del caricamento delle risorse è elevata, devi cercare di ridurre le dimensioni del download delle immagini.
- Si parla di ritardo nel rendering degli elementi elevato quando l'immagine è disponibile (ad esempio tramite un
<link rel=preload>), ma non viene utilizzata per molto tempo, di nuovo spesso a causa del fatto che è necessario JavaScript lato client per mostrare l'immagine.
Ci auguriamo che la disponibilità di questi dati in CrUX sia a livello di origine che di URL (in base ai soliti criteri di idoneità) aiuti i siti a ottimizzare più facilmente la metrica LCP.
Tipi di risorse LCP
Poiché le sottoparti sono più adatte per le LCP delle immagini, CrUX limita questi dati solo alle pagine con immagini. Pertanto, è importante capire quanti dei tuoi LCP sono LCP di immagini rispetto a LCP di testo (ad esempio <h1>titoli e paragrafi lunghi).
Oltre ai componenti secondari delle immagini LCP, le API CrUX ora includono anche un'analisi dettagliata delle risorse che mostra la suddivisione dei caricamenti di pagine LCP tra testo e immagini.
Ad esempio, per ottenere i tipi di risorse LCP per https://web.dev/ per PHONE visualizzazioni di pagina, puoi utilizzare il seguente comando curl (sostituisci ancora una volta API_KEY con la tua chiave):
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"]}'
e riceverai una risposta simile a questa:
{
"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
}
}
}
}
Anche la visualizzazione di CrUX è stata aggiornata per mostrare questi dati:
Ad esempio, per la home page di web.dev, possiamo vedere che il 98,5% delle LCP erano in realtà LCP di testo, pertanto le sottoparti di immagini LCP sono meno utili per questa pagina. In questo caso, possiamo utilizzare le metriche TTFB e FCP originali come un'analisi diagnostica potenzialmente migliore.
I tipi di risorse LCP sono un altro utile strumento di diagnostica per comprendere e migliorare il LCP, in particolare per sapere quanto sono utili le componenti secondarie dell'immagine LCP.
Informazioni diagnostiche sul RTT
Abbiamo inoltre esteso la metrica RTT introdotta per la prima volta ad agosto 2024.
Classificazione in tre intervalli di RTT
Abbiamo aggiunto tre intervalli alle API CrUX che mostrano tre raggruppamenti di densità RTT:
| Latenza della rete | Inizia | Termina |
|---|---|---|
| Bassa | 0 millisecondi | < 75 millisecondi |
| Medio | 75 millisecondi | < 275 millisecondi |
| Alta | 275 millisecondi | ∞ |
Questi intervalli sono più informativi delle categorie ECT precedenti, che includevano tutto ciò che durava meno di 270 millisecondi nella categoria 4g. Con i progressi della tecnologia di rete dal loro lancio, la maggior parte dei siti ha registrato la maggior parte del traffico in questa categoria, rendendo questa classificazione meno utile.
Per questo motivo, ti consigliamo di utilizzare le etichette Bassa, Media e Alta anziché le consuete Buona, Richiede miglioramento e Scadente. Non sono metriche che il proprietario di un sito può migliorare direttamente e sono quindi metriche di diagnostica per comprendere le altre metriche e il motivo per cui potrebbero essere diverse da quanto previsto. Possono anche aiutare a spiegare perché altre metriche cambiano nel tempo, nonostante il sito non subisca modifiche, se mostrano una variazione nella base utenti.
Questi intervalli sono disponibili nelle API CrUX, ad esempio per web.dev per PHONE visualizzazioni di pagina (di nuovo, sostituendo API_KEY con la tua chiave):
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"]}'
che restituisce qualcosa di simile al seguente:
{
"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
}
}
}
}
I bucket vengono visualizzati in CrUX Vis quando sono selezionate le distribuzioni:
RTT in BigQuery
Oltre ad aver ampliato la metrica RTT nelle API CrUX per includere i tri-bin, abbiamo reso disponibili i dati nel set di dati BigQuery mensile, tra cui un istogramma completo in bucket di 25 millisecondi nelle tabelle non elaborate e tri-bin e valori p75 nelle tabelle materializzate.
Ciò consente una comprensione più approfondita della distribuzione dei dati oltre i tri-bin disponibili nelle API CrUX. Ci consente inoltre di ricreare la suddivisione dell'ECT che è stata rimossa da CrUX a partire da questo mese (di seguito sono riportate maggiori informazioni in merito), con la leggera modifica di una soglia di 275 millisecondi per 4g anziché la precedente soglia di 270 millisecondi. Le suddivisioni ECT (ora ricavate dai dati RTT) continuano a essere disponibili nelle tabelle materializzate di BigQuery di CrUX, pertanto strumenti come la dashboard di CrUX possono continuare a mostrare questa suddivisione.
Il set di dati BigQuery include anche i dati per paese (come definito da ISO 3166-1). Ciò consente un'analisi più approfondita, che può essere utile per spiegare perché le metriche sul rendimento sono peggiori per alcuni utenti. Ad esempio, possiamo esaminare i dati degli utenti di Google Telefono esaminando i dati di https://www.google.com:
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
Poi visualizziamo i dati su una mappa geografica:
https://www.google.com(dati di origine con grafico interattivo).
Possiamo vedere che, mentre la maggior parte del mondo (in particolare il "mondo occidentale") ha RTT molto buoni, l'Africa subsahariana, alcune parti del Medio Oriente e alcune parti dell'Asia hanno più difficoltà. In effetti, il grafico è limitato a 500 millisecondi di RTT perché l'utilizzo dei dati completi ha alterato i colori, in particolare con l'Eritrea che ha un percentile del 75% di 3850 millisecondi.
Questa operazione può essere utile anche quando i pattern di traffico cambiano. Ad esempio, una percentuale maggiore di utenti provenienti da paesi con RTT più elevati potrebbe spiegare statistiche Core Web Vitals peggiori nonostante il sito non abbia subito modifiche.
Sebbene i siti non possano migliorare direttamente il tempo di risposta, la disponibilità di questi dati da parte dei visitatori di un sito consente di comprendere meglio gli utenti del sito in tutto il mondo. Inoltre, offre molte opportunità di analisi in futuro e ci auguriamo che i ricercatori trovino informazioni interessanti in questo set di dati.
Rimozione della dimensione ECT
L'ultima modifica nella release di febbraio 2025 è il ritiro della dimensione Tipo di connessione effettivo (ECT) da BigQuery (avevamo già rimosso il RTT dalle API a partire da settembre 2024 quando abbiamo introdotto la metrica RTT come sostituto).
Come accennato in precedenza in questo post, la metrica RTT consente una visualizzazione più granulare dei dettagli di connessione dei visitatori di un sito. Puoi persino ricreare i bucket ECT da queste tabelle di distribuzione. Tecnicamente, l'ECT dovrebbe essere una combinazione di RTT e velocità in downlink, ma Chrome ha sempre utilizzato solo RTT.
Una differenza importante è che l'ECT era una dimensione CrUX, il che significa che le altre metriche potevano essere segmentate in base all'ECT. Il tempo di risposta è una metrica CrUX anziché una dimensione, pertanto non è possibile visualizzare, ad esempio, il tempo di risposta in base al tempo di risposta, ma solo i tempi di risposta in base alle altre dimensioni (tipo di dispositivo e paese).
Potrebbe sembrare più limitante, ma il passaggio dalla dimensione alla metrica consente di accedere a più dati in CrUX. Questo perché CrUX ha determinate soglie minime prima che possiamo mostrare i dati. Abbiamo già reso facoltative le dimensioni nel 2022, il che significa che abbiamo rimosso ECT o il dispositivo, se necessario, per generare report a un livello superiore, ma le metriche che non erano presenti nella maggior parte dei caricamenti di pagine (Interazione fino al successivo paint (INP), diversi tipi di navigazione e ora componenti dell'immagine LCP) spesso non erano disponibili per le origini in BigQuery.
Riducendo il numero di dimensioni, i dati sono meno segmentati, pertanto il numero di origini che soddisfano questi requisiti minimi aumenta. A gennaio abbiamo registrato INP per il 68, 1% delle origini, mentre per il set di dati di dicembre abbiamo registrato INP solo per il 64, 5% delle origini. Il meccanismo si applica anche ai tipi di navigazione, ai componenti secondari LCP e ai tipi di risorse in questa release, che beneficiano tutti della rimozione della dimensione ECT. Nelle API CrUX, l'aumento della copertura è entrato in vigore all'inizio di febbraio.
Le colonne ECT rimarranno in BigQuery per garantire la coerenza con i set di dati precedenti e i dati ECT nelle visualizzazioni materializzate rimarranno disponibili, ma in base alle informazioni RTT (con una differenza di 5 millisecondi per 3g e 4g come indicato in precedenza) oltre ai nuovi intervalli RTT p75 e tri-bin.
Conclusione
L'aggiunta di altre metriche al set di dati pubblico CrUX offre ai proprietari di siti e ai ricercatori molte più informazioni per diagnosticare e risolvere i problemi di prestazioni.
In quanto set di dati pubblico, CrUX presenta alcune limitazioni al livello di dettaglio che possiamo mostrare. Ad esempio, i singoli selettori di elementi non potranno mai essere visualizzati in CrUX. I proprietari di siti che richiedono questo livello di dettaglio sono vivamente invitati a implementare una soluzione RUM, che non avrà le stesse limitazioni.
Tuttavia, i dati aggregati di livello superiore, come quelli descritti in questo post, possono aiutarti a colmare il divario tra sapere che hai un problema e sapere perché esiste. Ci auguriamo che questi dati aggiuntivi ti siano utili. Non esitare a contattarci nel gruppo di discussione se hai feedback o domande.