Dimensione Core/Dash: Tipo di Dispositivo

Dimensione: Tipo di Dispositivo (d)

La dimensione Tipo di Dispositivo suddivide i dati del tuo Real User Monitoring in due categorie: mobile e desktop. Questo è il primo e più importante filtro in qualsiasi indagine sulle prestazioni, poiché mobile e desktop sono ambienti informatici fondamentalmente differenti. CPU diverse, condizioni di rete diverse, dimensioni della viewport diverse, motori del browser diversi.

Se analizzi i Core Web Vitals aggregati senza filtrare per tipo di dispositivo, stai facendo la media tra 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). Tuttavia, le prestazioni su mobile sono costantemente inferiori a quelle su 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 limitazioni che i desktop non hanno:

• CPU throttling: Un telefono Android di fascia media ha circa 3-5 volte meno potenza di calcolo rispetto a un desktop. Il JavaScript che viene eseguito in 50ms su desktop potrebbe richiederne 200 su mobile, spingendo l'INP oltre la soglia del valore "buono".
• Latenza di rete: Le connessioni mobile (4G/5G) hanno tempi di round-trip più elevati e maggiore varianza 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 restringersi sotto un blocco di testo su mobile, cambiando completamente l'obiettivo di ottimizzazione.

Distribuzione dei Tipi di Dispositivo su CoreDash

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

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

Analisi Specifica per Metrica

Largest Contentful Paint (LCP)

Il LCP su mobile è quasi sempre peggiore rispetto a quello su desktop. La causa principale è il Load Delay: i browser mobile scoprono l'immagine 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é. È la pipeline di distribuzione.

Interaction to Next Paint (INP)

È qui che il divario tra i dispositivi colpisce più duramente. I gestori di eventi JavaScript che sembrano istantanei su un i7 desktop possono bloccare il thread principale per oltre 300ms su uno Snapdragon 665. Filtra per mobile, ordina per impatto sull'INP e troverai le esatte interazioni che si interrompono 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 i tipi di dispositivo di solito risalgono al responsive design. Gli slot pubblicitari che riservano spazio su desktop potrebbero collassare o ridimensionarsi su mobile. Le metriche di fallback dei font che si allineano su desktop causano spostamenti visibili su viewport più piccole. I web font vengono renderizzati in modo diverso sui browser mobile e desktop e la densità fisica dei pixel influisce sull'arrotondamento dei sub-pixel.

Flusso di Lavoro di Debugging

1. Inizia ogni indagine con il filtro del dispositivo: Prima di guardare qualsiasi altra dimensione, suddividi 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/richiede miglioramento/scadente (good/needs-improvement/poor) per ogni tipo di dispositivo. Un desktop con l'85% di valori buoni e un mobile con il 45% di valori buoni 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 rivela se il divario mobile è globale o concentrato in regioni con reti più lente. Tipo di Dispositivo + Tipo di Navigazione mostra se le navigazioni avanti-indietro (back-forward) su mobile vengono memorizzate correttamente nella cache.

Regola Pratica di Ingegneria

• LCP su mobile inferiore a 2,5s: Questa è la soglia che Google usa per un valore "buono". Se il tuo desktop la supera 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 funzione interattiva su un vero dispositivo Android di fascia media. Il CPU throttling (4x) nei Chrome DevTools lo approssima, ma testare su un dispositivo reale è meglio.
• 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 ranking di ricerca. Google utilizza i dati CrUX mobile per il ranking.

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