Nel 2013, quando questo articolo è uscito la prima volta, il responsive web design era una scelta da discutere in riunione. Oggi è il pavimento su cui si costruisce, come l’HTTPS o il backup.
Il problema è che quasi tutti i siti che ci arrivano per un restyling si dichiarano responsive. Pochi lo sono fino in fondo. Il layout regge, il contenuto no.
Responsive non vuol dire solo “il layout non si rompe”
La definizione resta quella di sempre: un solo sito, un solo indirizzo, un foglio di stile che riorganizza il contenuto in base allo spazio. Fin qui ci arrivano anche i temi scaricati a caso. La parte che salta è un’altra. Adattare un sito a uno schermo da sei pollici significa ridecidere l’ordine delle informazioni, non solo impilare le colonne. Su desktop l’occhio coglie tre cose insieme; su telefono le vede in fila, una per volta, con una mano sola libera.
Un esempio. Uno studio tecnico ha in home quattro servizi affiancati e sotto i riferimenti. Da smartphone diventa una colonna da quattro schermate, con il telefono a 2.000 pixel di scroll. Chi arriva non legge, cerca il contatto: spostarlo in alto ha portato le chiamate dal 3% al 7% delle sessioni mobile, senza toccare una riga di testo.
I breakpoint non sono i dispositivi
Continuiamo a leggere fogli di stile organizzati per “iPhone”, “iPad”, “desktop”. Ha smesso di funzionare quando pieghevoli, split view e finestre ridimensionate a metà schermo sono diventati normali.
I breakpoint vanno messi dove il contenuto si rompe, non dove passa un modello di telefono. Si allarga la finestra finché una riga diventa troppo lunga da leggere o una tabella sborda: lì va il breakpoint. Con clamp() sulla tipografia e le container query sui componenti se ne scrivono molti meno di dieci anni fa.
Una cosa che non facciamo mai: nascondere contenuti da mobile con display: none per “semplificare”. Se un’informazione non serve al telefono, non serve nemmeno da desktop. Se serve, va riorganizzata.
Google guarda solo la versione mobile
Dal 2024 la scansione avviene solo con il crawler smartphone. Non c’è più una versione desktop da valutare in alternativa: quello che manca da telefono, per Google non esiste. Testi accorciati da mobile, dati strutturati caricati sopra una certa larghezza, link chiusi in un accordion mai renderizzato costano posizionamento senza dare nessun segnale evidente.
Vale anche per le AI Overviews e i motori conversazionali, che leggono la pagina come la vede un crawler mobile: se la gerarchia dei titoli si sfalda, quel contenuto non viene citato. Un dettaglio che confonde parecchi, poi, è che il report “Usabilità sui dispositivi mobili” è sparito da Search Console a fine 2023. Chi lo cerca per avere conferma non lo trova e conclude che vada tutto bene.
Prestazioni: dove il responsive si gioca davvero
Un sito può essere perfettamente adattivo e restare inutilizzabile in 4G in zona industriale. La differenza la fanno tre cose:
- immagini nella dimensione giusta, con
srcsete formati moderni: caricare un JPEG da 2.400 pixel dentro una card larga 340 resta l’errore numero uno che troviamo negli audit; - font web ridotti a due varianti con
font-display: swap, invece delle sei che arrivano con i temi commerciali; - script di terze parti sotto controllo, dai widget di chat ai caroselli: su un telefono di fascia media pesano molto più che sul portatile di chi ha approvato il progetto.
Sono anche i tre interventi che spostano di più LCP e INP. Su un ecommerce di articoli sportivi l’LCP mobile è sceso da 4,1 a 1,8 secondi con il solo lavoro su immagini e font, e le sessioni con più di una pagina vista sono salite di circa un quinto.
Il dito non è un puntatore del mouse
Qui il responsive incrocia l’accessibilità, dal 2025 anche un obbligo di legge per molte attività. Le WCAG chiedono aree tattili di almeno 24 pixel per lato, meglio 44. Sembra un dettaglio da sviluppatori, ed è la ragione per cui in un modulo preventivo la gente sbaglia checkbox e abbandona.
Contano anche il testo leggibile ingrandendo al 200%, i campi con la tastiera giusta, i pop up con un bersaglio di chiusura decente. Il quadro completo sta nell’articolo sull’European Accessibility Act e nella pagina sull’accessibilità dei siti web.
Come si verifica, in pratica
Il DevTools serve per lavorare, non per validare. La verifica seria si fa su due o tre telefoni veri, uno vecchio di qualche anno, con la rete a 4G lento, provando a completare l’azione che conta: chiedere un preventivo, trovare gli orari, aggiungere al carrello. Con una mano sola, in piedi. Gli attriti che emergono lì nessun test automatico li aveva segnalati.
Quando conviene rifare invece che adattare
Su un sito costruito negli ultimi anni, renderlo davvero adattivo è quasi sempre rifinitura: layout, immagini, navigazione. Su strutture più vecchie, con larghezze fisse e impaginazioni a tabella, ogni correzione ne apre un’altra e il risultato resta fragile al primo aggiornamento.
Partiamo sempre da un’analisi del codice esistente prima di dire quale strada costa meno fatica, dentro la progettazione del sito o in un restyling. Capita che un sito dato per irrecuperabile si sistemi in poche giornate, e capita il contrario. Deciderlo a occhio, senza aprire il codice, è il modo più rapido per sbagliare tempi.
