Core/Dash Dimension: 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 in modo diretto.

Device Memory (codice gruppo m) riporta il bucket di RAM che il browser restituisce da navigator.deviceMemory. La specifica arrotonda deliberatamente per difetto alla potenza di due più vicina e limita 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.

Client Capability Score (codice gruppo ccs) è un valore composito calcolato da CoreDash a partire da tre segnali esposti dal browser: la memoria del dispositivo, navigator.hardwareConcurrency (core logici della CPU) e il tipo di connessione effettiva dalla Network Information API. Il risultato è 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 dallo stesso dispositivo sotto Wi-Fi. Combinare memoria, core e tipo di connessione in un'unica scala ordinale ti permette di filtrare e confrontare i dati di performance senza dover eseguire un'analisi separata per ciascuna variabile.

Supporto del browser e copertura dei dati

navigator.deviceMemory è un'API esclusiva per Chromium. Firefox e Safari non la espongono, il che significa che quei browser riportano sempre Sconosciuto (CCS 0) per la componente di memoria. In pratica, Chrome e i browser basati su Chrome costituiscono la maggior parte del traffico Android, e i dispositivi Android sono proprio dove si concentrano le condizioni di scarsa memoria. Quindi il segnale è maggiormente disponibile esattamente 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 con 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é la capacità del dispositivo è importante per i Core Web Vitals

LCP è principalmente un problema di rete e di rendering. L'INP è principalmente un problema di CPU e memoria. Questa distinzione è il motivo per cui la dimensione CCS emerge più chiaramente nei dati dell'INP.

I task lunghi sul thread principale 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 tutti direttamente in durate dei task più lunghe. Un sito che supera l'INP su un telefono moderno a 180 ms può facilmente attestarsi a 400 ms su un dispositivo Vincolato.

Il capitolo sulle Performance del Web Almanac 2025 conferma la tendenza: i tassi di superamento dell'INP su mobile raggiungono il 77% complessivo, ma il divario tra i dispositivi ad alta potenza e quelli di fascia bassa in quella cifra è ampio. Circa il 29% degli utenti web mobili si trova su dispositivi tre volte meno potenti rispetto a un flagship attuale. Questi utenti non sono un'eccezione 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 shift quando i font o le immagini a caricamento ritardato causano reflow che vengono completati dopo che il browser ha già finalizzato un frame.

Come utilizzare CCS e Device Memory in CoreDash

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

Per prima cosa, apri l'analisi del tuo INP suddiviso per CCS. Se il tuo 75° percentile per l'INP è buono per i visitatori Molto Capace (CCS 1) e Capace (CCS 2) ma fallisce per quelli Limitato (CCS 3) e inferiori, hai un collo di bottiglia dovuto alla CPU o alla memoria piuttosto che alla rete. Questo esclude un'intera categoria di fix (preloading, connection hints, ottimizzazione della CDN) e concentra la tua attenzione sui tempi di esecuzione del 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 guidano i risultati peggiori. Se i dispositivi con 1 GB costituiscono una quota sproporzionata dei punteggi INP negativi, conosci la soglia. Gli script che sono accettabili a 4 GB possono diventare candidati per essere ritardati o rimossi basandosi solo su quel dato.

Per i siti con un pubblico globale, abbina il CCS alla dimensione Paese. I mercati del Sud e Sud-Est Asiatico, l'Africa subsahariana e parti dell'America Latina presentano alte concentrazioni di dispositivi Vincolati e Molto Limitati. Un'analisi del CCS filtrata per paese ti mostrerà dove il divario è più ampio e ti aiuterà a stabilire a quale mercato dare la priorità per primo.

Il bucket Sconosciuto (CCS 0) copre tutto il traffico Firefox e Safari più 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. Questo non significa che quegli utenti abbiano dispositivi scadenti; significa che il segnale non era disponibile. Tratta Sconosciuto come un segmento separato invece di inglobarlo nella tua baseline.

Cosa fare con i dati

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

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

CoreDash fa emergere le dimensioni CCS e Device Memory accanto a ogni metrica dei Core Web Vitals, così puoi confermare se un fix che ha migliorato l'INP sui dispositivi di fascia alta ha anche spostato i numeri per i tuoi visitatori Vincolati, e non solo per i tuoi utenti migliori.