Sito Web Responsive: Guida Completa 2026

Cos'è un sito web responsive

Un sito web responsive è un sito che si adatta da solo alla dimensione dello schermo, all'orientamento e al dispositivo di chi lo sta guardando. Il responsive web design è l'approccio con cui si ottiene quel risultato: un solo progetto, un solo indirizzo, un solo set di contenuti che si riorganizza tra desktop, tablet e smartphone.

Fino a una decina di anni fa era normale mantenere due siti separati: quello "desktop" e una versione mobile su un sottodominio tipo m.esempio.it. Oggi quella scelta ha quasi sempre più costi che vantaggi — doppia manutenzione, contenuti che divergono nel tempo, segnali divisi su due indirizzi — ed è il motivo per cui il responsive è diventato lo standard di riferimento.

Responsive però non vuol dire "rimpicciolire". Un layout desktop compresso dentro 375 pixel resta un layout desktop: testi minuscoli, colonne strette, bottoni che si toccano male. Progettare in modo responsive significa ripensare gerarchia, navigazione e interazioni in base al contesto d'uso, non solo alla larghezza disponibile.

I tre principi fondamentali

La definizione tecnica del responsive web design poggia su tre elementi. Sono del 2010 e sono ancora validi, anche se gli strumenti per applicarli oggi sono molto più comodi.

• Layout fluido: unità relative (%, em, rem, fr) al posto dei pixel fissi, così la struttura si ridimensiona in proporzione invece di rompersi oltre una certa soglia.
• Immagini flessibili: media che non escono mai dal contenitore, mantengono le proporzioni e arrivano con un peso adeguato al dispositivo.
• Media query: regole CSS che applicano stili diversi in base a larghezza, risoluzione, orientamento e — oggi — anche alle preferenze di chi naviga.

Negli ultimi anni se n'è aggiunto un quarto: le container query, che permettono a un componente di adattarsi allo spazio che ha davvero a disposizione invece che alla finestra del browser. Le vediamo più avanti, sono il cambiamento più concreto degli ultimi dieci anni.

CSS e media query: il codice che serve davvero

Questa è la parte che nella maggior parte delle guide resta astratta. Qui sotto c'è il codice essenziale: copre la larga maggioranza dei casi reali.

Il meta viewport: senza questo non parte niente

Prima ancora del CSS. Se manca questo tag nel head, il browser mobile finge di essere largo 980 pixel e mostra la pagina rimpicciolita: le media query non scattano e il sito sembra non responsive anche se il CSS è scritto bene. È l'errore singolo più frequente sui siti che "non si vedono bene sul telefono".

<meta name="viewport" content="width=device-width, initial-scale=1">

Da evitare maximum-scale=1 e user-scalable=no: bloccano lo zoom e creano un problema di accessibilità per chi ha bisogno di ingrandire.

Media query mobile-first

Si scrive lo stile base per lo schermo piccolo, senza media query, e si aggiunge complessità salendo con min-width. Il CSS viene più corto e non si accumulano regole scritte solo per annullarne altre.

/* Base: mobile. Nessuna media query. */
.card-grid {
  display: grid;
  gap: 1.5rem;
  grid-template-columns: 1fr;
}

/* Da 48rem (768px) in su: due colonne */
@media (min-width: 48rem) {
  .card-grid { grid-template-columns: repeat(2, 1fr); }
}

/* Da 64rem (1024px) in su: tre colonne */
@media (min-width: 64rem) {
  .card-grid { grid-template-columns: repeat(3, 1fr); }
}

I breakpoint in rem invece che in px hanno un vantaggio pratico: se qualcuno alza la dimensione del carattere di default nel browser, il layout passa alla versione più semplice invece di restare stretto e illeggibile.

La griglia che si adatta senza nessuna media query

Nella maggior parte dei casi una griglia di card non ha bisogno di breakpoint scritti a mano. Questa riga fa tutto da sola: ogni colonna è larga almeno 280px, e il browser ne mette quante ne stanno.

.card-grid {
  display: grid;
  gap: 1.5rem;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
}

Con auto-fill al posto di auto-fit le colonne vuote restano riservate invece di collassare: utile quando vuoi che l'ultima riga si allinei con le precedenti.

Tipografia fluida con clamp()

clamp() prende tre valori — minimo, valore ideale, massimo — e sceglie da solo. Serve a far scalare i testi in modo continuo, senza scalini a ogni breakpoint.

h1 {
  /* mai sotto 1.75rem, mai sopra 3.5rem */
  font-size: clamp(1.75rem, 5vw, 3.5rem);
  line-height: 1.15;
}

body {
  font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
}

Un dettaglio che spesso sfugge: usare vw da solo nel valore centrale (per esempio clamp(1rem, 4vw, 2rem)) rende il testo insensibile allo zoom del browser in alcune combinazioni. Aggiungere una componente in rem, come nella riga del body qui sopra, mantiene lo zoom funzionante.

Container query: il breakpoint guarda il contenitore

Le media query guardano la finestra. Il problema è che lo stesso componente può trovarsi a tutta larghezza in una pagina e dentro una sidebar da 300px in un'altra: la finestra è identica, lo spazio disponibile no. Le container query risolvono esattamente questo.

.card-slot {
  container-type: inline-size;
}

/* Il breakpoint legge il contenitore, non il viewport:
   la stessa card funziona in sidebar e a tutta larghezza. */
@container (min-width: 30rem) {
  .card {
    display: grid;
    grid-template-columns: 8rem 1fr;
    gap: 1rem;
  }
}

Sono supportate da tutti i browser aggiornati. Su progetti a componenti — React, Vue, o qualsiasi design system — cambiano il modo di ragionare: il breakpoint diventa una proprietà del componente, non della pagina.

Breakpoint e griglie: quali valori usare

• Breakpoint guidati dal contenuto: vanno messi dove il layout inizia davvero a rompersi, non sui modelli di telefono in commercio. I dispositivi cambiano ogni anno, il punto in cui una riga di testo diventa troppo lunga no.
• Valori di partenza ragionevoli: orientativamente 576px, 768px, 992px e 1200px. Sono convenzioni, non regole: quasi tutti i framework partono da lì.
• Meno breakpoint, non più: tre soglie ben scelte reggono meglio di sette messe a rattoppare casi singoli.
• Il limite di lettura: oltre i 75 caratteri per riga il testo si legge peggio. Su schermi larghi conviene limitare la colonna di testo con max-width, non allargarla all'infinito.

Mobile-first o desktop-first?

1. Mobile-first: si parte dagli schermi piccoli e si aggiunge complessità salendo di dimensione. Favorisce semplicità, velocità e focus sui contenuti essenziali, perché sullo schermo piccolo si è costretti a decidere cosa conta davvero.
2. Desktop-first: si parte dal layout desktop e lo si riorganizza per schermi ridotti. Può avere senso su interfacce molto dense, tipo gestionali, dove la versione completa è quella "vera" e il mobile è una riduzione consapevole.

Nella maggior parte dei progetti mobile-first è il più pratico, dato che gran parte delle visite arriva da smartphone. Una precisazione utile: mobile-first non è sinonimo di responsive. Responsive descrive il risultato — il sito si adatta; mobile-first descrive l'ordine in cui lo si costruisce.

Layout responsive: quattro pattern che coprono quasi tutti i casi

I layout responsive che si incontrano nella pratica sono quasi sempre variazioni di quattro schemi. Riconoscerli evita di reinventare la ruota a ogni progetto.

1. Mostly fluid

La griglia si ridimensiona in proporzione fino a un certo punto, poi si ferma e resta centrata. Sotto la soglia minima le colonne vanno a capo una sotto l'altra. È il pattern più comune sui siti vetrina e sui blog.

.wrap {
  width: 100%;
  max-width: 72rem;   /* oltre questa soglia smette di allargarsi */
  margin-inline: auto;
  padding-inline: 1.5rem;
}

2. Column drop

Le colonne restano affiancate finché c'è spazio, poi cadono una alla volta sotto le altre. Con flexbox si ottiene senza scrivere una sola media query.

.layout {
  display: flex;
  flex-wrap: wrap;
  gap: 1.5rem;
}

/* Ogni colonna vuole almeno 18rem: quando non ci stanno più,
   vanno a capo da sole. */
.layout > * {
  flex: 1 1 18rem;
}

3. Layout shifter

Il layout non si limita a riordinarsi: cambia proprio struttura tra una larghezza e l'altra. È il più flessibile e anche il più costoso da mantenere, perché di fatto sono due impaginazioni diverse. Con CSS Grid si gestisce dichiarando le aree.

.page {
  display: grid;
  gap: 1.5rem;
  grid-template-areas:
    "hero"
    "main"
    "aside";
}

@media (min-width: 64rem) {
  .page {
    grid-template-columns: 2fr 1fr;
    grid-template-areas:
      "hero  hero"
      "main  aside";
  }
}

4. Off-canvas

Contenuti secondari — menu, filtri, carrello — vivono fuori dallo schermo e entrano quando servono. È lo schema standard della navigazione mobile.

.drawer {
  position: fixed;
  inset: 0 auto 0 0;
  width: min(85vw, 20rem);
  transform: translateX(-100%);
  transition: transform 0.25s ease;
}

.drawer[data-open="true"] {
  transform: translateX(0);
}

/* Rispetta chi ha disattivato le animazioni a livello di sistema */
@media (prefers-reduced-motion: reduce) {
  .drawer { transition: none; }
}

Interfaccia responsive e UX: cosa cambia oltre al layout

Un'interfaccia responsive non è solo un layout che si ridimensiona. Cambia il modo in cui la si usa: dal mouse alle dita, dallo schermo grande alla mano sola, dalla connessione stabile ai dati mobili in movimento. Questi sono i punti che fanno la differenza pratica.

• Thumb zone: su un telefono tenuto con una mano, il pollice raggiunge comodamente la fascia bassa e centrale dello schermo. Le azioni principali stanno bene lì; l'angolo in alto a sinistra è la zona peggiore.
• Aree touch: un bersaglio di almeno 44x44px (linea guida Apple) o 48x48px (Material Design) si tocca al primo tentativo. Vale anche per lo spazio fra due elementi: due link a un pixel di distanza sono un problema anche se singolarmente sono grandi.
• Navigazione: sotto una certa larghezza il menu orizzontale non ci sta. Hamburger e off-canvas sono la soluzione standard, ma vale la pena tenere fuori dal menu le due o tre voci che contano davvero.
• Hover non esiste: su touch non c'è stato intermedio. Tutto ciò che si rivela solo al passaggio del mouse — sottomenu, tooltip, azioni su una riga di tabella — va reso raggiungibile anche con un tap.
• Form: il tipo di input giusto (type="email", type="tel", inputmode="numeric") fa comparire la tastiera giusta e riduce gli errori. L'autocomplete compilato bene fa risparmiare mezzo modulo.
• Gerarchia visiva: su schermo piccolo si vede una cosa alla volta. L'ordine in cui gli elementi cadono in colonna è una decisione di contenuto, non un effetto collaterale del CSS.

.btn {
  min-height: 44px;
  min-width: 44px;
  padding: 0.75rem 1.25rem;
}

/* Su iOS un campo con testo sotto i 16px fa zoomare
   la pagina al focus, e poi resta zoomata. */
input, select, textarea {
  font-size: 16px;
}

Immagini e tipografia: le tecniche che pesano di più

1. srcset e sizes: servire il file giusto a ogni dispositivo invece di mandare a tutti l'immagine da desktop. È l'intervento con il rapporto sforzo/risultato migliore su mobile.
2. Art direction con picture: non ridimensionare la stessa foto, ma servirne una diversa — spesso più ravvicinata — quando lo spazio è poco.
3. width e height sempre dichiarati: senza, il browser non sa quanto spazio riservare e la pagina salta durante il caricamento. È una delle cause più comuni di CLS scadente (ne parlo nella guida ai Core Web Vitals).
4. Formati moderni: WebP e AVIF pesano molto meno del JPEG a parità di resa percepita.
5. Lazy loading: loading="lazy" su tutto ciò che sta sotto la prima schermata, mai sull'immagine principale in alto.

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w,
          hero-800.webp 800w,
          hero-1600.webp 1600w"
  sizes="(min-width: 64rem) 50vw, 100vw"
  width="1600" height="900"
  loading="lazy" decoding="async"
  alt="Descrizione utile dell'immagine">

L'attributo sizes dice al browser quanto spazio occuperà l'immagine prima che il CSS sia stato applicato. Se è sbagliato, il browser scarica il file della misura sbagliata anche se srcset è scritto bene.

Responsive nelle web app e nelle piattaforme

Il responsive web development su un'applicazione è un problema diverso da quello di un sito vetrina. Su un sito il contenuto scorre e si impila; su una dashboard ci sono tabelle dense, filtri, grafici e stati che non si possono semplicemente mettere in colonna.

• Breakpoint per componente, non per pagina: in un'interfaccia a componenti la stessa card compare in punti con spazi diversi. Le container query viste sopra sono il modo giusto di gestirlo: il componente decide da sé come impaginarsi.
• Tabelle dense: su mobile una tabella a dieci colonne non funziona in nessuna forma compressa. Le due strade praticabili sono lo scroll orizzontale con la prima colonna fissa, oppure la trasformazione di ogni riga in una card con le etichette accanto ai valori. La seconda si legge meglio, la prima permette il confronto fra righe.
• Altezza del viewport: 100vh su mobile include la barra del browser che compare e scompare durante lo scroll, quindi il contenuto finisce sotto il bordo. Le unità dinamiche risolvono il caso.
• Elementi fissi: header sticky, barre di azione e modali occupano spazio verticale che su un telefono è già poco. Su schermo piccolo conviene tenerne uno solo.
• Rendering lato client: in una SPA il layout viene calcolato dopo il caricamento del JavaScript. Su una connessione mobile lenta questo si traduce in una finestra in cui la pagina è visibile ma non ancora impaginata.

/* vh è l'altezza massima teorica; dvh segue quella reale,
   barra del browser inclusa. */
.app-shell {
  min-height: 100dvh;
}

/* Tabella che scorre invece di comprimersi */
.table-wrap {
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
}
.table-wrap table {
  min-width: 44rem;
}

Nei progetti su cui lavoro — React con Tailwind, e Next.js dove serve il rendering lato server — l'impostazione che regge meglio nel tempo è quella a componenti: ogni blocco sa come comportarsi nello spazio che riceve, e la pagina si limita a distribuire quello spazio. Costa un po' di più all'inizio e molto meno a ogni modifica successiva.

Framework responsive: Tailwind, Bootstrap o CSS puro?

Domanda frequente e con una risposta poco spettacolare: nessuno dei tre rende un sito più responsive degli altri. Il responsive sta in come è progettato il layout, non nella libreria. Quello che cambia è la velocità di scrittura e il costo di manutenzione.

Vale la pena notare che CSS puro oggi copre nativamente quasi tutto quello per cui vent'anni fa serviva un framework. Grid e container query hanno ridotto parecchio la distanza.

Responsive vs adaptive design: la differenza

I due termini vengono usati come sinonimi, ma descrivono due approcci diversi.

In pratica: il responsive si comporta bene anche su una larghezza che nessuno aveva previsto, l'adaptive si comporta molto bene su quelle previste e male sulle altre. Per un sito nuovo, oggi, la scelta ragionevole è quasi sempre la prima.

Come capire se il tuo sito è davvero responsive

La domanda "il mio sito è responsive?" ha una risposta più precisa di "si vede sul telefono". Questa è la verifica che faccio io, in ordine: se un punto non passa, il sito ha un problema di responsività reale, non estetico.

La checklist in dieci punti

1. Il testo del corpo si legge senza zoomare (indicativamente 16px o più).
2. A 320px di larghezza non compare nessuna barra di scorrimento orizzontale.
3. Le immagini restano dentro il contenitore e non si deformano.
4. Bottoni e link si toccano al primo tentativo, senza mirare.
5. Il menu si apre e si chiude tenendo il telefono con una mano sola.
6. I campi dei form non fanno zoomare la pagina quando li tocchi, e aprono la tastiera giusta.
7. Le tabelle scorrono o si riorganizzano, invece di comprimersi fino a diventare illeggibili.
8. Video e iframe mantengono le proporzioni a ogni larghezza.
9. Nessun contenuto importante è nascosto solo sulla versione mobile.
10. Con lo zoom del browser al 200% la pagina resta usabile.

Strumenti per testare la responsività di un sito

• Il tuo telefono: resta il test più affidabile. Meglio con la connessione dati e non con il wi-fi di casa, così vedi anche i tempi reali.
• Chrome DevTools: la modalità dispositivo (F12, poi l'icona del telefono) simula larghezze e densità di pixel. Utile la modalità "Responsive" con trascinamento libero: i problemi si trovano fra un breakpoint e l'altro, non sui valori esatti.
• Lighthouse: integrato in DevTools, misura prestazioni e accessibilità in condizioni mobile simulate e segnala testi troppo piccoli e bersagli troppo vicini.
• BrowserStack o simili: test su dispositivi reali da remoto, quando serve verificare un browser che non hai.
• Zoom del browser: portare la pagina al 200% con Ctrl++ è un test di trenta secondi che scopre più problemi di quanto ci si aspetti.

Problemi ricorrenti e come si risolvono

Alcuni difetti tornano praticamente su ogni sito che sistemo.

• Scroll orizzontale che non si spiega: quasi sempre è un singolo elemento che sfora — una larghezza fissa, un 100vw che non tiene conto della barra di scorrimento, un margine negativo, oppure un URL lungo senza spazi che non va a capo.
• Immagini che escono dal contenitore: si previene con una regola sola, valida per tutto il sito.
• Video e iframe deformati: aspect-ratio risolve il caso senza i vecchi trucchi con il padding percentuale.
• Immagini ad alta risoluzione servite a tutti: è la causa numero uno di lentezza su mobile. Si risolve con srcset, come visto sopra.
• Prestazioni: un sito responsive che ci mette otto secondi a caricare su rete mobile ha comunque un problema. Immagini ottimizzate, CSS e JS ridotti, caching.

/* Trova al volo l'elemento che sfora in larghezza:
   incolla in console e guarda quale bordo esce dallo schermo. */
* { outline: 1px solid rgba(255, 0, 0, 0.35); }

/* Le due regole che prevengono la metà dei problemi */
img, video, canvas, svg {
  max-width: 100%;
  height: auto;
}

.video-wrap {
  aspect-ratio: 16 / 9;
}
.video-wrap iframe {
  width: 100%;
  height: 100%;
  border: 0;
}

Far realizzare un sito responsive: cosa chiedere a chi lo sviluppa

Oggi nessun preventivo dice "non responsive", quindi la parola da sola non distingue più niente. Quello che distingue è il livello di dettaglio con cui viene descritta. Prima di firmare, vale la pena chiedere:

• Su quali larghezze e su quali browser viene testato il sito, scritto esplicitamente nel preventivo.
• Se il test è previsto anche su dispositivo reale o solo su simulatore.
• Come vengono servite le immagini: formati moderni e srcset, oppure lo stesso file per tutti.
• Se il progetto parte da un template, quanto è modificabile il comportamento responsive senza rifare tutto.
• Chi interviene, entro quanto e a quali condizioni se dopo la consegna emerge un problema di resa su un dispositivo.

Alla consegna, la verifica te la puoi fare da solo in dieci minuti con la checklist qui sopra: apri il sito dal tuo telefono, portalo a 320px sul desktop, zooma al 200%. Se i dieci punti passano, il lavoro è stato fatto.

Nel modo in cui lavoro io il responsive non è una voce a parte del preventivo: è compreso in ogni progetto, dalla landing page al sito professionale, insieme a dominio e setup dell'hosting. Se vuoi un riferimento sulle cifre, l'ho scritto nella guida ai costi di un sito professionale; se stai valutando a chi affidarti, può servirti quella su come scegliere un web designer freelance.

Domande frequenti

Quanto costa rendere responsive un sito che non lo è?

Dipende quasi interamente da com'è costruito il sito attuale. Se il layout usa già unità relative e la struttura è pulita, spesso si tratta di sistemare breakpoint e immagini: un intervento circoscritto. Se invece le larghezze sono fisse, o c'è un template molto personalizzato con anni di CSS stratificato sopra, rattoppare costa spesso più che rifare — e il risultato regge meno. L'unico modo per avere un numero sensato è far guardare il codice esistente prima di preventivare.

Responsive e mobile-first sono la stessa cosa?

No. Responsive descrive il risultato: il sito si adatta a qualsiasi schermo. Mobile-first descrive l'ordine in cui lo si costruisce: prima lo schermo piccolo, poi si aggiunge complessità salendo. Si può fare un sito responsive partendo dal desktop, è solo di norma più laborioso.

Serve ancora una versione mobile separata del sito?

Nella grande maggioranza dei casi no. Un sito separato su sottodominio significa due basi di codice da mantenere allineate, contenuti che divergono col tempo e segnali divisi su due indirizzi. Restano casi limite — applicazioni molto pesanti con esigenze mobile completamente diverse — ma per un sito aziendale o vetrina è una complicazione senza contropartita.

Un sito responsive è automaticamente veloce su mobile?

No, e i due aspetti si confondono spesso. Responsive vuol dire che il layout si adatta; la velocità dipende dal peso delle immagini, dalla quantità di JavaScript e da come è configurato l'hosting. Un sito perfettamente responsive che manda 4 MB di foto a uno smartphone in 4G resta un sito lento.

Come faccio a sapere se il mio sito è responsive?

Il test più rapido: aprilo dal tuo telefono e prova a leggere e a toccare le cose senza zoomare. Poi, dal computer, restringi la finestra fino a circa 320px e guarda se compare una barra di scorrimento orizzontale. Se il testo è leggibile, i bottoni si toccano al primo colpo e non c'è scroll laterale, i fondamentali ci sono. La checklist in dieci punti più sopra copre il resto.

In sintesi

Un sito responsive fatto bene è un sito che non fa notare la propria struttura: si legge ovunque e non obbliga a zoomare, ruotare o cercare. Le tecniche di base — layout fluido, immagini flessibili, media query — sono le stesse da quindici anni; quello che è cambiato sono gli strumenti, e oggi CSS Grid, clamp() e le container query permettono di ottenere con poche righe quello che prima richiedeva molto più codice.

È comunque un lavoro iterativo: i dispositivi cambiano, i contenuti crescono, e quello che funzionava due anni fa può iniziare a rompersi. Vale la pena rifare il giro della checklist ogni tanto. Se vuoi un parere sul tuo sito attuale, scrivimi e lo guardiamo insieme, senza impegno.