Il mobile-first design significa progettare l'interfaccia partendo dagli schermi più piccoli (320-390px) e aggiungere complessità progressivamente per schermi più grandi — non il contrario. Questo approccio produce siti più veloci su mobile (meno codice di default), più facili da mantenere (le media queries aggiungono invece di sovrascrivere), e meglio allineati con il mobile-first indexing di Google che valuta la versione mobile per il ranking. Secondo i dati Audiweb 2025, il 68% delle sessioni web italiane avviene da dispositivi mobili.
Mobile-first indexing di Google: cosa significa concretamente
Dal 2019 Google usa la versione mobile del sito come versione primaria per l'indicizzazione e il ranking. Se la versione mobile ha meno contenuto, immagini diverse, o performance peggiori rispetto al desktop, il sito viene penalizzato. Questo ha reso il "design mobile-first" non solo una best practice UX ma un requisito SEO. Verifica in Google Search Console se il tuo sito è indicizzato correttamente con il mobile-first indexing.
Un errore frequente nei siti italiani: nascondere blocchi di contenuto su mobile con `display: none` per semplicità di layout, senza considerare che Google Googlebot non indicizza quel contenuto. Se hai sezioni nascoste su mobile che contengono keyword importanti, stai effettivamente rimuovendo contenuto dall'indice Google. La soluzione non è sempre mostrare tutto su mobile: ma quando nascondi contenuto, deve essere per motivi UX genuini (semplificazione), non per mancanza di pensiero sul layout mobile.
La differenza tra responsive design e mobile-first design
Il responsive design adatta il layout a diverse dimensioni di schermo: può essere progettato desktop-first o mobile-first. Il mobile-first è un approccio specifico: si scrivono prima le regole CSS base (senza media query) che valgono per mobile, e poi si usano `min-width` media queries per modificare il layout su schermi più grandi. L'approccio inverso (desktop-first) usa `max-width` per restringere il layout su mobile, producendo spesso CSS più complesso e pesante.
In Tailwind CSS il mobile-first è il default: le classi senza prefisso si applicano a tutti gli schermi (mobile per primo), e i prefissi `sm:`, `md:`, `lg:` aggiungono stili ai breakpoint progressivi. `flex-col md:flex-row` significa: colonna su mobile, riga su tablet e desktop. Questo è l'approccio corretto. L'errore da evitare: usare `sm:flex-col` per "tornare" a colonna su mobile — questo rompe la logica mobile-first e produce CSS più pesante.
Principi UX per il mobile: cosa cambia rispetto al desktop
- Tap target: ogni elemento cliccabile deve essere almeno 48x48px (linea guida Google/Apple), con 8px di spaziatura tra elementi adiacenti
- Gerarchia verticale: su mobile lo scroll è naturale — organizza il contenuto in singola colonna con gerarchia chiara verticale
- Thumb zone: i CTA principali vanno nella metà inferiore dello schermo, raggiungibili con il pollice destro senza cambiare grip
- Testo leggibile: minimo 16px base, mai sotto i 14px. Il pinch-to-zoom non è una soluzione UX accettabile
- Form semplificati: meno campi possibile, `inputmode="numeric"` per i campi numerici, `autocomplete` per nome/email/indirizzo
- Evita hover state come unico feedback: su touch non esiste hover, usa stati active/focus chiari
Performance mobile: le sfide specifiche
Lo stesso sito che performa bene su desktop può essere lento su mobile per tre motivi: CPU più lenta (il throttling di Lighthouse simula un Moto G4 che è ancora rappresentativo del parco globale), connessione variabile (3G/4G con picchi di latenza), e batteria (il browser limita le performance in modalità risparmio energetico). Queste limitazioni rendono ogni KB di JavaScript extra molto più costoso che su desktop.
I dati che raccogliamo mostrano che il parco smartphone degli utenti italiani ha una distribuzione molto più ampia rispetto al mercato nordeuropeo: una quota significativa di utenti usa ancora dispositivi con 2-4 GB di RAM e processori di fascia media del 2020-2022. Per questi dispositivi, un sito con 1 MB di JavaScript impiega 4-6 secondi per diventare interattivo, contro i 0,8-1,2 secondi di uno smartphone top di gamma. Progettare per il mid-range non è pessimismo: è realismo sul mercato italiano.
Viewport meta tag: la base imprescindibile
Il tag `<meta name="viewport" content="width=device-width, initial-scale=1">` è il punto di partenza di qualsiasi sito responsive. Senza di esso i browser mobile simulano una viewport da 980px e rimpiccioliscono la pagina per farla stare in 390px — rendendola illeggibile. Non usare mai `user-scalable=no` o `maximum-scale=1`: impedisce lo zoom agli utenti con difficoltà visive ed è considerato una violazione dell'accessibilità.
Google ha confermato che bloccare lo zoom dell'utente con `user-scalable=no` può impattare negativamente la valutazione di accessibilità del sito, che è uno dei segnali di ranking nell'algoritmo Page Experience. Oltre al ranking, è semplicemente una cattiva pratica UX: molti utenti over-50 (una fascia demografica rilevante per la maggior parte dei business italiani) usano abitualmente lo zoom per leggere il testo su mobile.
Immagini mobile: non caricare ciò che non si vede
Le immagini hero da 2000px di larghezza su un mobile 390px sono uno spreco di banda. Usa `srcset` e `sizes` per servire immagini dimensionate correttamente, o affida tutto a Next.js `<Image>` che genera automaticamente le varianti per ogni breakpoint. Le immagini decorative su desktop che non aggiungono valore su mobile si nascondono con CSS — ma ricorda che le `<img>` con `display: none` vengono comunque scaricate dal browser.
La soluzione corretta per nascondere immagini su mobile senza scaricarle: usa CSS background-image con media query. `@media (min-width: 768px) { .hero { background-image: url(large-bg.avif); } }` — il browser non scarica l'immagine su viewport più strette. Per immagini `<img>` decorative che vuoi nascondere su mobile, l'unica soluzione è non renderizzarle nel markup su mobile (via SSR condizionale o JavaScript) — nasconderle solo con CSS le scarica comunque.
Test su dispositivi reali, non solo emulatori
L'emulatore di Chrome DevTools è utile in sviluppo ma non sostituisce il test su dispositivo fisico. Le differenze: gestione del touch, comportamento dello scroll, tempi reali di rendering, e comportamento della tastiera virtuale. Usa BrowserStack o LambdaTest per test su dispositivi reali remoti. Per i siti che costruiamo testiamo sempre su almeno un iPhone mid-range e un Android mid-range prima del go-live, oltre che nell'emulatore durante lo sviluppo.
Un dettaglio spesso trascurato: il comportamento della tastiera virtuale su mobile. Su iOS la tastiera può far scorrere verso l'alto il contenuto o nascondere elementi `position: fixed`. Su Android il comportamento varia tra browser (Chrome, Samsung Internet, Firefox mobile). Se hai form importanti (checkout, login, newsletter), testali fisicamente su dispositivo iOS e Android: gli emulatori non replicano il comportamento reale della tastiera con sufficiente fedeltà.
Core Web Vitals su mobile: perché i punteggi divergono
In PageSpeed Insights è normale avere un punteggio desktop di 95 e mobile di 68. Le cause principali della divergenza: immagini LCP non ottimizzate per mobile, JavaScript che impega più tempo su CPU lenta, e layout che causa più CLS su viewport stretta. La priorità deve essere sempre migliorare il mobile: è la versione che Google usa per il ranking e quella che probabilmente vede la maggioranza dei tuoi utenti.
Una strategia efficace per chiudere il gap desktop-mobile: identifica le 3 metriche peggiori su mobile (quasi sempre TBT, LCP e CLS in quest'ordine) e affrontale separatamente. TBT alto → riduci JavaScript iniziale e long task. LCP alto su mobile → ottimizza immagini per mobile e verifica il preload sull'elemento LCP. CLS alto su mobile → verifica le dimensioni di font e immagini su viewport strette, e il comportamento del banner cookie su 390px. Nella nostra pratica il target minimo che impostiamo è 85/100 su mobile, con tutti i Core Web Vitals nella fascia "Good". Se il tuo sito è sotto questa soglia, contattaci per un audit.
