1. Mobile-first o desktop-first: la scelta ha conseguenze
Nel CSS, mobile-first significa scrivere lo stile di base per schermi piccoli e aggiungere regole via via che lo schermo si allarga (con min-width). Desktop-first fa il contrario: parte dal layout ampio e usa max-width per scalare verso il basso.
In un progetto con builder la distinzione è spesso più sfumata: i builder espongono le impostazioni responsive in modo visuale, non tramite CSS puro. Ma la logica di base resta: partire dal contesto più vincolato è quasi sempre più difficile e quasi sempre produce risultati più robusti.
2. Come si mappano i breakpoint del design
Il file di design definisce quasi sempre solo due breakpoint: desktop e mobile. Il problema è che tra 375px e 1440px ci sono tutti gli schermi che designer e sviluppatore non hanno mai guardato insieme.
Un approccio che funziona:
- Si parte dai breakpoint del design: 360–390px per mobile, 768px per tablet se specificato, 1280–1440px per desktop.
- Si aggiungono breakpoint dove il layout si rompe davvero, non dove lo indica un framework generico.
- Si usano unità relative (rem, em, %) per padding e tipografia dove il design lo permette.
- Si fissa in pixel solo ciò che deve restare fisso: altezze di barre di navigazione, bordi, ombre.
3. Dove i builder complicano il responsive
Elementor, Bricks e altri builder generano stili responsive in modo diverso. Il problema comune: ogni modifica visiva nel pannello mobile crea una regola CSS specifica per quel breakpoint, che poi diventa difficile da mantenere o sovrascrivere.
Due errori frequenti:
- Forzare ogni componente a un layout specifico per mobile quando basterebbe una griglia fluida.
- Usare pixel fissi per font e spaziatura nel pannello responsive invece di modificare i valori di base.
4. Tipografia e spazio su schermi diversi
La tipografia responsive è quella parte del CSS che meno sviluppatori fanno bene al primo tentativo.
L'approccio più pulito è clamp(): si definisce un valore minimo, uno massimo e una progressione fluida tra i due. Un titolo passa da 28px a 48px senza salti, senza scrivere font-size in cinque breakpoint separati.
Per lo spazio (padding, margin, gap) vale lo stesso principio: una scala coerente applicata con costanza. Su mobile la regola pratica è dimezzare i valori verticali rispetto al desktop e aumentare il padding orizzontale interno per non stringere il testo ai bordi.
5. Come si verifica il responsive prima di consegnare
DevTools di Chrome non basta. Servono dispositivi reali o emulatori che replicano browser reali.
Browser che vale sempre la pena controllare: Safari su iOS (ancora diverso da Chrome per scroll behavior, position fixed e zoom sui campi con font piccoli), Firefox, Edge.
Un controllo minimo ragionevole: 360px e 390px per mobile, 768px per tablet, 1280px e 1440px per desktop. Un sito che funziona bene a questi cinque punti copre il 95% degli utenti reali.
Domande frequenti
Bisogna progettare ogni componente per tutti i breakpoint?
No. Molti componenti funzionano già con un layout fluido senza regole responsive esplicite. I breakpoint servono solo dove il layout cambia davvero: navigazione, colonne, immagini hero, moduli di contatto.
I builder rendono il responsive più facile o più difficile?
Dipende. I builder accelerano il lavoro su desktop. Il responsive con un builder richiede però disciplina sulle classi e attenzione alle sovrascritture accumulate, altrimenti diventa difficile da mantenere nel tempo.
Prossimo passo
Hai un progetto WordPress con requisiti responsive precisi?
Sul servizio Design-to-WordPress puoi vedere come lavoro sulla conversione da design a build completa, responsive incluso.
Vai al servizio Design-to-WordPress