Web design responsive: una guida pratica
Il design responsive significa un solo sito che funziona a qualsiasi larghezza, non una versione mobile separata. In pratica quasi tutti i siti sono responsive sulla carta e rotti in punti precisi: una tabella che impone lo scorrimento orizzontale, una navigazione che si mangia un terzo dello schermo, un modulo che ingrandisce in modo imprevedibile su iOS.
Questa guida copre come affrontarlo, dove sono i guasti veri, e come collaudarli.
Progetta dall'estremità stretta#
Partire stretti costringe alle decisioni di priorità. A 320 pixel c'è spazio per una cosa alla volta, quindi devi decidere quale; allargare un design dopo è soprattutto una questione di dare più aria.
Andare al contrario — progettare a 1440 e poi togliere cose — produce impaginazioni mobili che sono la versione desktop con pezzi nascosti, ed è così che contenuti importanti finiscono in display:none sul dispositivo usato dalla maggioranza.
- Comincia le impaginazioni a 320–360 px, i dispositivi reali più stretti in uso comune.
- Non nascondere mai su mobile contenuti di cui un visitatore mobile ha bisogno; spostali o richiudili.
- Lascia che sia il contenuto a decidere i breakpoint: mettine uno dove l'impaginazione si rompe, non a nomi di dispositivi.
- Prova con la dimensione del testo del browser al 200 %: è un'impostazione di accessibilità diffusa e rompe più impaginazioni di qualsiasi telefono.
I breakpoint intitolati a dispositivi invecchiano male. «Tablet» ha significato sei larghezze diverse in dieci anni; «il punto in cui la griglia di schede diventa brutta» non cambia.
Gli elementi che si rompono davvero#
Una manciata di componenti spiega la maggior parte dei guasti responsive, e sono abbastanza prevedibili da controllare di proposito.
| Elemento | Guasto | Correzione |
|---|---|---|
| Tabelle | Scorrimento orizzontale di tutta la pagina | Contenitore con scorrimento, oppure riordino in schede con etichette di dato |
| Parole o URL lunghi | La pagina scorre di lato | overflow-wrap e min-width:0 sui figli flex e grid |
| Immagini | Debordano o spostano l'impaginazione | max-width:100 %, attributi width e height espliciti |
| Navigazione | Occupa un terzo dello schermo | Comprimere, o spostare le voci principali in una barra inferiore |
| Moduli | iOS ingrandisce e non torna indietro | Dimensione del carattere di almeno 16 px sui campi |
| Elementi fissi | Coprono il contenuto a cui si agganciano | Tenerne conto in scroll-padding e nel padding del body |
| Finestre modali | Non si riescono a chiudere su schermi piccoli | A schermo intero su mobile con un comando di chiusura visibile |
Immagini e media#
Le immagini sono di solito la cosa più pesante di una pagina e la fonte più comune di spostamento dell'impaginazione. Tre attributi risolvono quasi tutto e non costano nulla.
- Imposta sempre gli attributi width e height perché il browser riservi lo spazio prima che arrivi il file.
- Servi formati moderni — WebP o AVIF — con un ripiego dove serve ancora.
- Usa srcset e sizes perché un telefono scarichi un file di dimensione telefono, non un'immagine di testata da 2000 px.
- Carica in differita le immagini sotto la piega, e mai la più grande visibile: quello è il tuo elemento LCP.
- Dai all'immagine principale fetchpriority="high" perché non finisca in coda dietro risorse decorative.
- Per le immagini di sfondo fissa un rapporto d'aspetto perché il contenitore non collassi prima del caricamento.
Tattile, non solo larghezza#
Il responsive non riguarda solo l'impaginazione. Una finestra stretta di solito significa un dito anziché un mouse, e l'input tattile ha requisiti diversi che le media query sulla larghezza da sole non coprono.
- Bersagli tattili di almeno 44 × 44 px con spazio tra loro; link adiacenti da 30 px vengono sbagliati di continuo.
- Nulla di importante dietro l'hover: un menu solo in hover è irraggiungibile al tocco.
- Usa le media query pointer:coarse per togliere gli effetti hover che restano appiccicati dopo un tocco.
- Tieni le azioni principali a portata di pollice sui telefoni alti; l'angolo in alto a destra è il più difficile con una mano.
- Rispetta prefers-reduced-motion: parallasse e transizioni ampie causano un disagio reale ad alcune persone.
Domande frequenti
Quanti breakpoint mi servono?
Di solito tre-cinque, e dovrebbero venire dal tuo contenuto anziché da un elenco di dispositivi. Aggiungine uno dove l'impaginazione comincia a rendere male allargando la finestra, non perché esiste un certo telefono. I siti con una dozzina di breakpoint quasi sempre stanno compensando un'impaginazione che non era fluida in partenza.
Un sito mobile separato è mai la scelta giusta?
Di rado. Significa due basi di codice, due insiemi di URL, due deploy e una relazione canonica da mantenere, e di solito finisce con uno dei due che resta indietro in silenzio. I casi in cui accade ancora sono sistemi legacy che non si possono rendere responsive, e anche allora è un ripiego più che un piano.
Come si collauda bene il design responsive?
L'emulazione dispositivi del browser trova i problemi di impaginazione ma non il comportamento tattile, di rete o di piattaforma. Prova su almeno un Android reale di fascia medio-bassa e un iPhone, in rete mobile anziché con il wi-fi dell'ufficio. Poi ripeti le pagine chiave con la dimensione del testo del browser al 200 %, dove la maggior parte delle impaginazioni crolla davvero.
E le tabelle di dati su mobile?
Due opzioni valide: mettere la tabella in un contenitore a scorrimento orizzontale con un'indicazione visibile e la prima colonna fissa, oppure riordinare ogni riga come una scheda in cui ogni cella porta la propria etichetta di colonna. Il contenitore a scorrimento mantiene possibile il confronto; l'impilamento in schede si legge meglio. Scegli in base al fatto che i visitatori confrontino righe o le leggano una alla volta.
web design responsivesito adatto ai mobilebreakpointprogettazione mobile firstimmagini responsivebersagli tattili
