Dimensione CoreDash: Tipo di Dispositivo

Dimensione: Tipo di Dispositivo (d)

La dimensione Tipo di Dispositivo suddivide i tuoi dati RUM (Real User Monitoring) in due categorie: mobile e desktop. Questo è il primo filtro in assoluto più importante in qualsiasi indagine sulle prestazioni perché mobile e desktop sono ambienti di elaborazione fondamentalmente diversi. CPU diverse, condizioni di rete diverse, dimensioni della viewport diverse, motori dei browser diversi.

Se guardi i Core Web Vitals aggregati senza filtrare per tipo di dispositivo, stai calcolando la media di due popolazioni che non hanno quasi nulla in comune. Quella media, nella migliore delle ipotesi, è fuorviante.

Il divario di prestazioni mobile

I dispositivi mobile rappresentano circa il 62% del traffico web globale secondo Statista (2025). Eppure il mobile ottiene costantemente prestazioni inferiori rispetto al desktop. Secondo il Web Almanac 2025, solo il 48% delle origini mobile supera tutti e tre i Core Web Vitals rispetto al 56% su desktop. Si tratta di un divario di 8 punti percentuali.

Il divario esiste perché i dispositivi mobile affrontano tre vincoli che i desktop non hanno:

• Limitazione della CPU (CPU throttling): un telefono Android di fascia media ha una potenza di elaborazione circa 3-5 volte inferiore rispetto a un desktop. Il codice JavaScript che viene eseguito in 50ms su desktop potrebbe impiegare 200ms su mobile, spingendo l'INP oltre la soglia "buona".
• Latenza di rete: le connessioni mobile (4G/5G) hanno tempi di andata e ritorno (round-trip time) maggiori e una varianza superiore rispetto alle connessioni cablate. Questo gonfia il TTFB e il Load Delay del LCP.
• Dimensioni della viewport: schermi più piccoli cambiano quale elemento diventa il LCP. La tua hero image su desktop potrebbe rimpicciolirsi sotto un blocco di testo su mobile, cambiando completamente il target di ottimizzazione.

Distribuzione per Tipo di Dispositivo in CoreDash

Tra i progetti CoreDash, la tipica suddivisione del traffico è 65% mobile e 35% desktop. I siti e-commerce pendono maggiormente verso il mobile (70-75%), mentre i prodotti SaaS B2B vedono spesso una divisione 50/50 o persino una predominanza del desktop.

Il divario di prestazioni nei dati CoreDash rispecchia la tendenza globale. Il LCP p75 su mobile ha una media di 2,8s rispetto agli 1,9s su desktop. Per l'INP, il divario è ancora più ampio: il p75 su mobile si aggira intorno a 220ms mentre su desktop oscilla vicino a 120ms.

Analisi Specifica delle Metriche

Largest Contentful Paint (LCP)

Il LCP su mobile è quasi sempre peggiore che su desktop. La causa principale è il Load Delay: i browser mobile scoprono l'immagine del LCP più tardi perché l'HTML impiega più tempo ad arrivare (TTFB più alto) e il preload scanner compete con una maggiore contesa di risorse su una CPU più lenta. Se il tuo LCP su desktop è inferiore a 2,0s ma su mobile supera i 3,0s, il problema è raramente il file immagine in sé. Si tratta della pipeline di distribuzione.

Interaction to Next Paint (INP)

Qui è dove il divario del dispositivo colpisce più duramente. I gestori di eventi JavaScript che sembrano istantanei su un i7 desktop possono bloccare il main thread per oltre 300ms su uno Snapdragon 665. Filtra per mobile, ordina per impatto sull'INP e troverai le esatte interazioni che si rompono sui telefoni reali. Lo vedo costantemente: gli sviluppatori testano su MacBook Pro e rilasciano interazioni che sono inutilizzabili sui dispositivi che il 65% dei loro utenti porta effettivamente con sé.

Cumulative Layout Shift (CLS)

Le differenze di CLS tra tipi di dispositivi di solito risalgono al responsive design. Gli slot pubblicitari che riservano spazio su desktop potrebbero collassare o ridimensionarsi su mobile. Le metriche dei font di fallback che si allineano su desktop causano spostamenti visibili su viewport più piccole. I web font vengono renderizzati in modo diverso tra i browser mobile e desktop, e la densità dei pixel fisici influisce sull'arrotondamento dei sub-pixel.

Flusso di Lavoro di Debugging

1. Inizia ogni indagine con il filtro del dispositivo: prima di guardare a qualsiasi altra dimensione, dividi per Tipo di Dispositivo. Se il tuo LCP aggregato è 2,5s, potresti trovare il desktop a 1,8s e il mobile a 3,1s. Il "problema" è esclusivamente mobile.
2. Confronta le distribuzioni, non solo il p75: controlla la distribuzione buono/da-migliorare/scadente (good/needs-improvement/poor) per ogni tipo di dispositivo. Un desktop con l'85% di "buono" e un mobile con il 45% di "buono" raccontano una storia completamente diversa rispetto al solo p75.
3. Combina con altre dimensioni: una volta isolato il tipo di dispositivo, aggiungi un secondo filtro. Tipo di Dispositivo + Paese (Country) rivela se il divario mobile è globale o concentrato in regioni con reti più lente. Tipo di Dispositivo + Tipo di Navigazione (Navigation Type) mostra se le navigazioni avanti-indietro (back-forward) su mobile sono memorizzate correttamente nella cache.

Regole Empiriche di Ingegneria

• LCP su mobile inferiore a 2,5s: questa è la soglia che Google usa per "buono". Se il tuo desktop passa ma il mobile fallisce, concentrati sulla riduzione del Load Delay (fetchpriority, preload) e del TTFB (edge caching, CDN).
• INP su mobile inferiore a 200ms: testa ogni funzionalità interattiva su un vero dispositivo Android di fascia media. La limitazione della CPU (CPU throttling 4x) di Chrome DevTools lo approssima, ma i test su dispositivi reali sono migliori.
• Mai ottimizzare solo per desktop: se il tuo traffico mobile supera il 50% (e quasi certamente lo fa), le prestazioni su mobile sono il tuo segnale di posizionamento nella ricerca. Google utilizza i dati CrUX mobile per il posizionamento.

Il Tipo di Dispositivo non è un filtro opzionale. È la prima domanda che ti poni: "È un problema mobile o un problema desktop?" Ogni decisione di ottimizzazione deriva da questa risposta.