Dimensione Core/Dash: Capacità del Dispositivo e del Client

Cosa misurano queste dimensioni

CoreDash espone due dimensioni sotto la categoria Capacità del Dispositivo e del Client. Rispondono a domande diverse ma si completano a vicenda direttamente.

La Device Memory (codice gruppo m) riporta il bucket di RAM che il browser restituisce da navigator.deviceMemory. Le specifiche arrotondano deliberatamente per difetto alla potenza di due più vicina e limitano il risultato, quindi vedrai valori di 0.25, 0.5, 1, 2, 4 o 8+ GB piuttosto che cifre esatte. Questo arrotondamento è intenzionale: limita la precisione disponibile per gli script di fingerprinting, pur fornendo agli sviluppatori un segnale utilizzabile.

Il Client Capability Score (codice gruppo ccs) è un valore composito calcolato da CoreDash a partire da tre segnali esposti dal browser: memoria del dispositivo, navigator.hardwareConcurrency (core logici della CPU) e il tipo di connessione effettiva dalla Network Information API. Il risultato rientra in uno di sei bucket:

Il punteggio composito è più utile di qualsiasi singolo segnale preso isolatamente. Un dispositivo con 4 GB di RAM su una connessione 2G si comporta in modo molto diverso rispetto allo stesso dispositivo su Wi-Fi. La combinazione di memoria, core e tipo di connessione in un'unica scala ordinale ti consente di filtrare e confrontare i dati sulle prestazioni senza dover eseguire un'analisi separata per ogni variabile.

Supporto dei browser e copertura dei dati

navigator.deviceMemory è un'API esclusiva di Chromium. Firefox e Safari non la espongono, il che significa che questi browser riportano sempre Sconosciuto (CCS 0) per il componente della memoria. In pratica, Chrome e i browser basati su Chrome costituiscono la maggior parte del traffico Android, e i dispositivi Android sono il luogo in cui si concentrano le condizioni di scarsa memoria. Quindi il segnale è maggiormente disponibile proprio dove conta di più.

L'intestazione HTTP Device Memory (Device-Memory) è un meccanismo separato che consente a un server di leggere lo stesso valore da una richiesta negoziata tramite Accept-CH. CoreDash utilizza l'API JavaScript raccolta al momento del caricamento della pagina, in modo che il valore viaggi con il beacon RUM anziché richiedere la configurazione dell'intestazione lato server.

Perché le capacità del dispositivo sono importanti per i Core Web Vitals

L'LCP è principalmente un problema di rete e rendering. L'INP è principalmente un problema di CPU e memoria. Questa distinzione è il motivo per cui la dimensione CCS si manifesta in modo più evidente nei dati INP.

I task lunghi sul main thread bloccano la risposta agli input. Su un dispositivo con 1 GB di RAM, il browser è già sotto pressione per la memoria prima ancora che il tuo JavaScript venga eseguito: una garbage collection più aggressiva, scarti di schede più frequenti e meno margine per la compilazione JIT si traducono direttamente in durate dei task più lunghe. Un sito che supera l'INP su un telefono moderno a 180 ms può facilmente arrivare a 400 ms su un dispositivo Vincolato.

Il capitolo sulle Performance del Web Almanac 2025 conferma la tendenza: i tassi di superamento dell'INP sui dispositivi mobili raggiungono il 77% complessivamente, ma in questo dato il divario tra dispositivi ad alte prestazioni e dispositivi di fascia bassa è ampio. Circa il 29% degli utenti del web mobile utilizza dispositivi tre volte meno potenti rispetto a un flagship attuale. Tali utenti non rappresentano delle anomalie nella maggior parte dei mercati globali; sono il visitatore mediano.

Il CLS è meno sensibile alla classe hardware rispetto all'INP, ma i dispositivi con CPU lente possono comunque produrre layout shifts quando font o immagini a caricamento tardivo causano reflow che vengono completati dopo che il browser ha già eseguito il commit di un frame.

Come utilizzare CCS e Device Memory in CoreDash

Il flusso di lavoro più produttivo consiste nell'iniziare con il CCS come filtro e poi utilizzare Device Memory per confermare la tua ipotesi.

Per prima cosa, apri la tua analisi INP per CCS. Se il tuo INP al 75° percentile è buono per i visitatori Molto Capaci (CCS 1) e Capaci (CCS 2) ma fallisce per i Limitati (CCS 3) e inferiori, hai un collo di bottiglia dovuto a CPU o memoria, non un collo di bottiglia di rete. Questo esclude un'intera categoria di correzioni (preloading, suggerimenti di connessione, ottimizzazione CDN) e concentra la tua attenzione sul tempo di esecuzione di JavaScript: task lunghi, peso degli input handler e script di terze parti che vengono eseguiti a ogni interazione.

Quindi filtra per Device Memory per vedere quali bucket di RAM producono i risultati peggiori. Se i dispositivi da 1 GB rappresentano una quota sproporzionata di punteggi INP scarsi, conosci la soglia. Gli script che sono accettabili a 4 GB possono essere candidati per il differimento o la rimozione solo sulla base di quei dati.

Per i siti con pubblico globale, abbina CCS alla dimensione Paese. I mercati dell'Asia meridionale e del sud-est asiatico, l'Africa sub-sahariana e parti dell'America Latina presentano alte concentrazioni di dispositivi Vincolati e Molto Limitati. Un'analisi CCS filtrata per paese ti mostrerà dove il divario è maggiore e ti aiuterà a stabilire a quale mercato dare priorità per primo.

Il bucket Sconosciuto (CCS 0) copre tutto il traffico Firefox e Safari oltre a qualsiasi sessione in cui le API non hanno restituito alcun valore. Non ignorarlo. Sui siti con una quota significativa di Firefox o Safari, Sconosciuto può rappresentare un quarto o più di tutte le sessioni. Non significa che quegli utenti abbiano dispositivi scadenti; significa che il segnale non era disponibile. Tratta Sconosciuto come un segmento separato invece di incorporarlo nella tua baseline.

Cosa fare con i dati

Se i visitatori CCS 3, 4 o 5 costituiscono più del 15% del tuo traffico e il loro INP è costantemente superiore a 200 ms, l'insieme delle correzioni è specifico:

• Profila i tuoi task più lunghi su un dispositivo throttled in Chrome DevTools. La Task Attribution nel pannello Performance mostrerà quali script sono responsabili.
• Sposta gli script di terze parti non critici dietro un trigger di interazione o di visibilità in modo che non competano per il main thread durante la finestra di caricamento iniziale.
• Riduci le dimensioni dei bundle JavaScript sui percorsi critici. Ogni kilobyte parsato su un dispositivo con poca memoria costa di più rispetto a un flagship perché il compilatore JIT ha meno spazio per memorizzare nella cache il codice compilato.
• Usa scheduler.yield() o setTimeout(0) per frammentare i task lunghi e dare al browser la possibilità di elaborare gli eventi di input tra un blocco e l'altro.

CoreDash espone le dimensioni CCS e Device Memory accanto a ogni metrica dei Core Web Vitals in modo che tu possa confermare se una correzione che ha migliorato l'INP sui dispositivi di fascia alta ha anche migliorato i numeri per i tuoi visitatori Vincolati, non solo per i tuoi utenti nel caso migliore.