Su un tema sviluppato prima dell’introduzione di theme.json, cambiare il colore primario del brand su richiesta del cliente significava cercare la stessa variabile CSS ripetuta in otto file diversi, e nella metà dei casi qualcuno la dimenticava in un componente secondario. Theme.json è il file di configurazione, in formato JSON, con cui un tema WordPress a blocchi dichiara i propri design token, colori, font, dimensioni, spaziature, generando automaticamente le CSS custom properties che ogni blocco nativo e ogni blocco custom possono consumare, senza duplicare gli stessi valori in decine di fogli di stile separati.

Il file vive nella root del tema e si divide in due macro sezioni: settings, che definisce cosa un utente può personalizzare nell’editor (palette colori disponibili, dimensioni font selezionabili, se abilitare i bordi custom), e styles, che applica valori di default a blocchi ed elementi HTML. WordPress legge questo file e genera automaticamente variabili CSS con il prefisso –wp–preset– per i valori dei preset e –wp–custom– per valori arbitrari definiti sotto la chiave custom.

Un esempio concreto di come funziona

{
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1A2B3C", "name": "Primary" },
        { "slug": "accent", "color": "#E8A530", "name": "Accent" }
      ]
    },
    "typography": {
      "fontSizes": [
        { "slug": "small", "size": "0.875rem", "name": "Small" },
        { "slug": "large", "size": "1.5rem", "name": "Large" }
      ]
    }
  },
  "custom": {
    "spacing": {
      "section-gap": "4rem"
    }
  }
}

Da questa configurazione, WordPress genera automaticamente var(–wp–preset–color–primary), var(–wp–preset–font-size–large) e var(–wp–custom–spacing–section-gap), utilizzabili in qualsiasi CSS del tema o di un blocco custom. Cambiare il colore primario del brand significa modificare un solo valore in un solo file: ogni blocco che referenzia quella variabile si aggiorna automaticamente, in tutte le pagine del sito, senza toccare un singolo file CSS aggiuntivo.

Cosa vede il cliente nell’editor grazie a questa configurazione

La sezione settings di theme.json non serve solo a WordPress internamente: determina anche cosa il cliente vede e può scegliere nel pannello Stili dell’editor, raggiungibile dall’icona a forma di mezzaluna nella schermata Aspetto > Editor. Se la palette dichiarata contiene cinque colori, il cliente vede esattamente quei cinque colori come opzioni per lo sfondo di un blocco o il colore di un testo, non l’intera ruota cromatica. Disabilitare esplicitamente alcune funzionalità, come i gradienti personalizzati o le dimensioni font arbitrarie, tramite le chiavi custom: false dentro settings, riduce ulteriormente lo spazio di scelta a quello che il design system del progetto prevede davvero.

"settings": {
  "color": {
    "custom": false,
    "customGradient": false
  },
  "typography": {
    "customFontSize": false
  }
}

Questa configurazione è particolarmente utile su progetti dove il cliente finale, non l’agenzia, gestisce i contenuti in autonomia dopo la consegna: meno opzioni libere significano meno probabilità che qualcuno, senza cattive intenzioni, scelga un colore o una dimensione font che rompe la coerenza visiva costruita durante lo sviluppo.

Perché elimina un’intera categoria di bug

Prima di theme.json, la coerenza visiva di un sito dipendeva dalla disciplina dello sviluppatore nel riusare le stesse variabili CSS ovunque. Con più persone che lavorano sullo stesso progetto, o con progetti ereditati da altri sviluppatori, questa disciplina si rompe quasi sempre: qualcuno scrive un valore hex diretto invece di richiamare la variabile, e quel colore smette di aggiornarsi quando il brand cambia palette.

Problema: modifica del colore primario del brand richiesta dal cliente, ma alcuni componenti del sito restano con il vecchio colore
Causa: quei componenti avevano il valore colore scritto direttamente in hex invece di richiamare la variabile CSS generata da theme.json
Soluzione Blurr: audit dei CSS custom del progetto per sostituire ogni valore hardcoded con la variabile corrispondente, e regola di sviluppo interna che vieta valori colore diretti nei blocchi custom, solo variabili da theme.json

L’altro beneficio, meno visibile ma altrettanto concreto, riguarda l’editor stesso. Con theme.json configurato correttamente, l’editor a blocchi mostra al cliente solo le opzioni di colore e font effettivamente previste dal design system del sito, invece del color picker completo che permette di scegliere qualsiasi tonalità RGB. Riduce drasticamente il rischio che un cliente, editando autonomamente una pagina, scelga un colore fuori dal brand senza nemmeno accorgersene.

Come lo usiamo per mantenere coerenza tra progetti diversi

Sui progetti che sviluppiamo per le agenzie partner, theme.json non è solo uno strumento tecnico, è diventato il punto di partenza di ogni nuovo tema. Prima ancora di scrivere un blocco custom, definiamo la palette colori, la scala tipografica e gli spazi in theme.json, così che ogni componente sviluppato dopo erediti automaticamente i valori corretti invece di doverli reimpostare uno per uno.

Un progetto per un’agenzia di Padova ci aveva chiesto di intervenire su un tema esistente dove la scala tipografica non era mai stata standardizzata: sei dimensioni di font diverse per titoli che avrebbero dovuto essere identici, causate da modifiche accumulate nel tempo da sviluppatori diversi. Migrando la configurazione tipografica dentro theme.json e sostituendo ogni valore hardcoded con le variabili generate, la manutenzione futura sulla tipografia è passata da una ricerca manuale in decine di file a una singola modifica centralizzata.

Un dettaglio tecnico che vale la pena conoscere riguarda i temi child: se il child theme include un proprio theme.json, WordPress unisce le due configurazioni invece di sostituire completamente quella del parent, dando priorità ai valori dichiarati nel child. È un comportamento utile per progetti che partono da uno starter theme condiviso tra più clienti, dove il child theme personalizza solo la palette colori specifica del brand del cliente, ereditando dal parent tutta la struttura di spaziature e tipografia già validata su decine di progetti precedenti.

Va detto con chiarezza che theme.json non risolve tutto da solo: richiede disciplina nello scriverlo bene fin dall’inizio e nel resistere alla tentazione di scrivere un valore diretto quando si ha fretta. Ma il framework che offre, una volta rispettato, elimina alla radice il problema della coerenza visiva che affligge molti siti WordPress sviluppati in modo incrementale nel tempo.

Per capire come questa configurazione si integra con lo sviluppo di componenti custom, leggi il nostro approfondimento su come funzionano gli ACF Blocks. Theme.json è anche la base su cui poggia il Full Site Editing: senza una configurazione solida di design token, un tema a blocchi produce un’esperienza di editing incoerente per il cliente. Se gestisci un tema con problemi di coerenza visiva accumulati nel tempo e vuoi valutare una migrazione a theme.json, su blurr.it/contatti/possiamo fare un audit del progetto.

Il 91,8% degli utenti dichiara di preferire la dark mode dove disponibile. È un dato reale, verificato, e giustifica la crescente richiesta che riceviamo dalle agenzie per implementarla sui siti dei loro clienti. Il problema è che implementarla correttamente è molto più complesso di quanto sembri, e un’implementazione fatta male produce risultati peggiori di non averla.

La domanda che ci facciamo prima di ogni implementazione non è “come aggiungo la dark mode” ma “questo sito è costruito in modo da supportarla senza rompersi?” Nella maggior parte dei siti WordPress sviluppati senza pensare alla dark mode dall’inizio, la risposta è no. E scoprirlo dopo il lancio è costoso.

Perché la dark mode non è “cambiare lo sfondo da bianco a nero”

Questa è la misconcezione più diffusa, e quella che produce le implementazioni peggiori. La dark mode non è un filtro che inverte i colori: è un sistema di design alternativo completo che richiede che ogni elemento visivo del sito sia stato progettato per funzionare in entrambe le modalità.

Considera cosa succede quando si passa da light a dark su un sito non preparato. I testi scritti in grigio scuro su sfondo bianco diventano illeggibili su sfondo scuro. I bordi e le ombre progettati per la luce spariscono o diventano troppo pesanti. Le immagini con sfondo bianco mostrano un bordo bianco stonato sul layout scuro. I colori del brand, scelti per funzionare su sfondo chiaro, perdono contrasto o diventano aggressivi su sfondo scuro. I form e i campi di testo, quasi sempre stilati solo per il tema light, appaiono con i colori di sistema del browser invece che con quelli del design.

Ognuno di questi problemi richiede una soluzione specifica e tempo di sviluppo. Un’implementazione dark mode fatta correttamente non è un plugin attivato in cinque minuti: è un lavoro di design e sviluppo parallelo che vale circa il 30-40% del tempo di sviluppo del sito originale.

I problemi che troviamo più spesso

Lavorando su siti WordPress per le agenzie partner, abbiamo sviluppato una lista di controllo specifica per le implementazioni dark mode basata su quello che troviamo regolarmente.

Problema: Immagini PNG con sfondo trasparente Causa: Le immagini PNG con sfondo trasparente mostrano il colore del container su cui sono posizionate. In light mode il container è bianco e l’immagine sembra corretta. In dark mode il container diventa scuro e l’immagine mostra uno sfondo scuro non previsto, rendendo loghi, icone e grafici illeggibili o esteticamente sbagliati. Soluzione Blurr: Audit sistematico di tutte le immagini PNG nel sito prima di attivare la dark mode. Per i loghi, produzione di una versione alternativa ottimizzata per sfondo scuro con attributo CSS content che la sostituisce automaticamente via prefers-color-scheme. Per le icone, sostituzione con SVG inline che ereditano il colore del testo e si adattano automaticamente.

Problema: Testi con colori hardcoded invece di variabili CSS Causa: Testi stilati con colori fissi nel CSS, ad esempio color: #333333, invece di variabili che cambiano in base al tema. In dark mode il colore rimane grigio scuro su sfondo scuro, rendendo il testo invisibile. Soluzione Blurr: Refactoring del CSS per usare variabili custom property (--color-text: #333) ridefinite nel blocco @media (prefers-color-scheme: dark). Su siti costruiti con page builder come Bricks, questo richiede di verificare che tutti i colori usino le variabili del design system e non colori statici.

Problema: Ombre e bordi che spariscono o diventano pesanti Causa: Le ombre sono progettate per simulare profondità su sfondo chiaro. Su sfondo scuro perdono senso o diventano troppo evidenti. I bordi chiari spariscono completamente. Soluzione Blurr: Ridefinizione delle ombre in dark mode con valori ridotti o con colori alternativi. Per i bordi, uso di variabili CSS con valore chiaro in light mode e scuro in dark mode.

Problema: Conflitti con plugin di terze parti Causa: Plugin come WooCommerce, form builder, plugin di chat e widget esterni hanno i propri stili CSS che non seguono il sistema di variabili del tema. Quando si attiva la dark mode, questi elementi rimangono nel loro tema originale creando isole visive incoerenti nel layout. Soluzione Blurr: Identificazione di tutti i plugin con stili propri prima dell’implementazione. Per ciascuno, verifica se supportano nativamente la dark mode o se richiedono override CSS manuali. Nei casi più complessi, isolamento dei widget in container light-mode fixed per non creare incoerenza visiva.

Il caso che ci ha insegnato a verificare prima di implementare

Qualche tempo fa un’agenzia con cui lavoriamo ha richiesto di aggiungere la dark mode al sito di uno studio fotografico che avevamo sviluppato l’anno precedente. Il sito aveva centinaia di immagini di prodotto, loghi di clienti in PNG e una galleria portfolio estesa.

Abbiamo fatto la verifica preliminare che facciamo sempre su questo tipo di richiesta: audit delle immagini, dei colori nel CSS, dei plugin attivi. Il risultato è stato che il 60% delle immagini del portfolio aveva sfondi bianchi non trasparenti che sarebbero diventati bianchi su layout scuro, rompendo completamente l’estetica del sito. I loghi dei clienti erano tutti PNG con sfondo bianco. Il CSS usava colori hardcoded su quasi tutti gli elementi.

La stima per un’implementazione corretta era di tre volte il tempo che il cliente aveva preventivato. La conversazione con l’agenzia è diventata un’opportunità per spiegare che la dark mode non è una funzionalità da aggiungere dopo: è una scelta di design da fare prima, quando si costruisce il sito, integrando le variabili CSS e il sistema di colori in modo che supporti entrambe le modalità dall’inizio.

Il cliente ha scelto di non implementarla in quel momento e di integrarla nel prossimo refactoring del sito. È la risposta più onesta che si possa dare quando il costo supera il beneficio atteso.

Quando implementare la dark mode e quando no

Non tutti i siti hanno bisogno della dark mode. La decisione deve essere presa in base all’obiettivo del sito e al profilo degli utenti, non alla moda del momento.

Ha senso implementarla per siti con molto consumo serale o notturno, come blog, piattaforme di lettura, SaaS e strumenti di produttività. Per siti con un’identità visiva molto forte basata su colori chiari, la dark mode rischia di diluire quella identità invece di arricchirla. Per siti ecommerce con molte fotografie di prodotto, i problemi tecnici delle immagini rischiano di superare i benefici.

La regola che applichiamo: se il sito è costruito con un design system basato su variabili CSS dall’inizio, la dark mode si aggiunge con uno sforzo contenuto. Se il sito è stato costruito con colori hardcoded e immagini non ottimizzate, il costo di una dark mode corretta quasi sempre supera il beneficio. In quel caso, meglio aspettare il prossimo refactoring e integrarla fin dall’inizio.

Per chi costruisce nuovi siti e vuole supportare la dark mode in futuro, la cosa più utile da fare adesso è usare CSS custom properties per tutti i colori e produrre i loghi in formato SVG invece che PNG. Non richiede tempo aggiuntivo significativo durante lo sviluppo, ma rende l’implementazione futura della dark mode una questione di ore invece che di giorni.

Su blurr.it/servizi/ trovi come gestiamo questi aspetti nei siti che sviluppiamo per le agenzie partner. Per approfondire come strutturiamo la SEO tecnica e le performance su ogni progetto, leggi l’articolo dedicato. Per capire come le scelte di design impattano i Core Web Vitals, leggi l’articolo dedicato.

Nike non ha bisogno di convincerti. Tu sai già cosa fa Nike. Quando entri sul loro sito, non stai cercando informazioni su cosa vendono o perché dovresti comprarli: stai già dentro il loro mondo. Il sito di Nike può permettersi di essere cinematografico, immersivo, full width fino ai bordi dello schermo, perché il suo obiettivo non è spiegarsi. È impressionare chi già conosce il brand.

Adesso pensa a una PMI italiana che produce componenti meccanici di precisione e vuole che il sito generi richieste di preventivo da buyer internazionali. Quel sito deve fare una cosa completamente diversa: convincere qualcuno che non ti conosce che sei il fornitore giusto per il suo problema specifico. Deve essere chiaro, leggibile, navigabile. Deve comunicare competenza in pochi secondi e rendere facilissimo il contatto.

Usare il layout di Nike per questo obiettivo è come usare una scenografia teatrale per un colloquio di lavoro. Bellissima, fuori contesto.

La differenza che quasi nessuno spiega

Quando un cliente guarda i siti dei grandi brand e dice “voglio qualcosa così”, sta guardando il risultato di investimenti milionari in brand awareness costruita nel corso di decenni. Quella libertà creativa è possibile perché il brand ha già fatto il lavoro più difficile: farsi conoscere, farsi riconoscere, farsi desiderare.

Per un’azienda che non ha quel riconoscimento immediato, il sito deve fare quel lavoro. Deve spiegare chi sei, cosa fai, perché sei diverso dai competitor, e cosa deve fare il visitatore adesso. Sono quattro domande che richiedono chiarezza, struttura e leggibilità. Non impatto visivo.

Il full width puro mette l’estetica al centro. Il boxed container mette il contenuto al centro. Quando il contenuto è il tuo unico strumento per convincere qualcuno che non ti conosce, il boxed vince quasi sempre.

Questa non è un’opinione: è la scelta che fa Apple. Apple potrebbe permettersi qualsiasi layout. Ha il brand, ha le risorse, ha il team di design più costoso al mondo. E ha scelto il boxed container, perché vuole che tu capisca i prodotti e li compri. La chiarezza del messaggio vale più dell’impatto estetico anche per il brand più riconoscibile al mondo nel settore consumer tech.

I tre profili di sito e il layout giusto per ciascuno

Negli anni di lavoro con agenzie su centinaia di progetti, abbiamo identificato tre profili di sito con esigenze di layout radicalmente diverse. Non sono categorie rigide: esistono sfumature e casi ibridi. Ma come punto di partenza per la conversazione con il cliente funzionano quasi sempre.

Il sito vetrina di brand Chi ce l’ha: agenzie creative, studi di architettura, fotografi, brand del lusso, aziende con riconoscimento immediato nel loro settore. Obiettivo del sito: impressionare, trasmettere identità, confermare una percezione già esistente. Layout consigliato: full width con attenzione ai breakpoint grandi, animazioni curate, spazio bianco generoso. Perché funziona: il visitatore conosce già il brand o è arrivato con intenzione precisa. Non deve essere convinto: deve essere confermato nella sua scelta.

Il sito di conversione Chi ce l’ha: PMI, professionisti, SaaS, ecommerce, studi professionali, qualsiasi attività che dipende dal sito per generare contatti o vendite. Obiettivo del sito: trasformare visitatori sconosciuti in contatti o clienti. Layout consigliato: boxed container con sezioni di sfondo full width per varietà visiva, navigazione chiara, call to action visibile senza scorrimento. Perché funziona: il visitatore non conosce l’azienda e deve capire rapidamente se è nel posto giusto. La struttura controllata del boxed riduce il carico cognitivo e facilita la decisione.

Il sito ibrido Chi ce l’ha: aziende con un brand riconoscibile nel proprio settore ma che dipendono ancora dal sito per generare lead. Obiettivo del sito: impressionare e convertire insieme. Layout consigliato: boxed container per le sezioni di contenuto e navigazione, full width per le sezioni hero e le immagini di impatto. Perché funziona: combina l’impatto visivo del full width nelle sezioni che non richiedono lettura con la leggibilità del boxed nelle sezioni che devono comunicare e convincere.

L’80% dei clienti delle agenzie italiane rientra nella seconda o terza categoria. Il full width puro è la minoranza.

La conversazione con il cliente che vuole il layout di Nike

Questa è la situazione più frequente: il cliente arriva con un riferimento visivo, quasi sempre un sito di un grande brand, e vuole qualcosa di simile. Non è una richiesta irragionevole: quel sito gli piace, e vuole che il suo sito abbia lo stesso effetto.

Il problema è che non sta guardando solo il layout: sta guardando il risultato di anni di brand building che il suo sito non può replicare con il layout da solo.

La risposta che funziona non è “quel layout non fa per te”. È una domanda: “Quando qualcuno arriva sul tuo sito per la prima volta, sa già chi sei?”

Quasi sempre la risposta è no. E da quel no si costruisce la spiegazione naturale: se il visitatore non ti conosce, il sito deve presentarti. Per presentarti bene serve chiarezza e struttura. Il full width puro è bellissimo quando chi arriva ti conosce già: diventa disorientante quando non ti conosce e deve capire in pochi secondi se sei la risposta al suo problema.

Non stai rinunciando all’estetica: stai scegliendo un’estetica che serve l’obiettivo invece di un’estetica che si serve da sola. Il sito può essere moderno, curato, visivamente di impatto anche con un boxed container. Apple lo dimostra ogni giorno.

Nelle presentazioni che facciamo alle agenzie partner, questo ragionamento si traduce quasi sempre in una sola domanda al cliente: “Vuoi che il tuo sito sembri bello o vuoi che porti clienti?” La risposta è quasi sempre la seconda. E da lì la scelta del layout diventa una conseguenza logica, non un’imposizione tecnica.

Per approfondire le differenze tecniche tra i due layout, leggi full width o boxed container: quale scegliere nel 2026. Per capire come presentare queste scelte al cliente in modo che le approvi, leggi come spiegare le scelte di design al cliente e farsele approvare. Per approfondire come strutturare una homepage che converte indipendentemente dal layout scelto, leggi l’articolo dedicato.

Su blurr.it/contatti/ puoi prenotare una chiamata per discutere la strategia di layout dei tuoi prossimi progetti con il team tecnico.

La scelta tra full width e boxed container è una delle decisioni di layout più frequenti nella progettazione di un sito web, e quasi sempre viene presa per ragioni estetiche invece che funzionali. Full width sembra più moderno. Boxed sembra più vecchio. Quindi si sceglie full width.

Il problema è che il layout deve servire l’obiettivo del sito, non l’estetica del designer. E nella grande maggioranza dei casi, per siti aziendali che devono convertire visitatori in clienti, il boxed container è la scelta più efficace. Non perché sia più bello: perché è più leggibile, più usabile e più controllabile su tutti i dispositivi, inclusi i monitor grandi che quasi nessuno testa durante lo sviluppo.

Nelle presentazioni ai clienti, usiamo quasi sempre la stessa tecnica per spiegarlo. Funziona nel 95% dei casi. La descriviamo più avanti.

Cosa significa davvero full width e cosa significa boxed

Partiamo dalle definizioni, perché la confusione su questi termini è frequente anche tra i professionisti.

Un sito full width adatta il contenuto alla larghezza dello schermo. Su un monitor da 27 pollici, il contenuto si espande fino ai bordi. Il testo, le immagini, i blocchi di layout si distribuiscono su tutta la larghezza disponibile. Il risultato visivo è cinematografico, immersivo, moderno. Il risultato in termini di leggibilità su schermi grandi è spesso problematico: righe di testo che si allungano troppo, menu che si separano in modo innaturale, spazi vuoti che compaiono dove non erano stati previsti.

Un sito boxed container mantiene il contenuto all’interno di una larghezza massima definita, tipicamente tra i 1.100 e i 1.400 pixel, centrata nello schermo. Su un monitor grande, i lati della pagina rimangono vuoti o con uno sfondo. Il contenuto rimane leggibile, denso e controllato indipendentemente dalla dimensione dello schermo. Questo non significa che tutto sia boxed: anche in un layout boxed si possono avere sezioni con sfondi che si estendono fino ai bordi per effetti visivi. Il contenuto, però, rimane dentro il container.

Il problema del menu su schermo grande

C’è un esempio pratico che usiamo spesso con i clienti che ci chiedono il full width perché “sembra più moderno”.

Immagina il menu di navigazione: logo a sinistra, voci di menu a destra. Su uno schermo da 24 o 27 pollici con un sito full width, il logo è nell’angolo in alto a sinistra e le voci di menu sono nell’angolo in alto a destra, separati da cinquanta o sessanta centimetri di spazio vuoto. Le persone leggono da sinistra a destra: vedono il logo, fanno scorrere gli occhi verso destra, e se la navigazione è troppo lontana la ignorano. Si perdono nel contenuto della pagina senza trovare facilmente la strada per muoversi nel sito.

Non è un problema estetico. È un problema di usabilità che impatta direttamente il numero di pagine visitate per sessione e il tasso di conversione. Su siti che dipendono dalla navigazione per guidare l’utente verso un’azione specifica, quella distanza non è accettabile.

Quando il full width ha senso e quando no

Non stiamo dicendo che il full width è sbagliato. Stiamo dicendo che va usato nelle situazioni giuste.

Il full width funziona bene per siti creativi e di design, portfolio di fotografi, agenzie creative, artisti, studi di architettura: sono contesti dove l’impatto visivo è il messaggio principale e la navigazione complessa non è necessaria. Funziona per i grandi brand come Nike o Coca-Cola, che non hanno bisogno di convertire: devono impressionare. Funziona per landing page con una sola azione possibile, dove il layout espansivo crea enfasi sull’unico elemento che conta.

Il boxed container funziona meglio per tutto il resto. Siti aziendali che devono comunicare servizi in modo chiaro. SaaS e prodotti digitali dove l’utente deve capire cosa fa il prodotto in pochi secondi. Ecommerce dove la navigazione tra categorie e prodotti deve essere fluida. Siti di professionisti e studi dove la credibilità e la leggibilità contano più dell’impatto visivo. Apple, che potrebbe permettersi qualsiasi scelta di layout, usa il boxed container perché ha scelto l’usabilità sull’estetica pura.

Nella nostra esperienza lavorando con agenzie su centinaia di siti, il 70-80% dei progetti richiede un approccio boxed o ibrido, dove le sezioni di contenuto sono boxed e alcune sezioni di sfondo sono full width per varietà visiva. Il full width puro è la minoranza.

La tecnica che convince il cliente nel 95% dei casi

Molti clienti arrivano al briefing con un’idea chiara: vogliono il full width perché hanno visto un sito che gli è piaciuto, quasi sempre un sito di un’agenzia creativa o di un grande brand. Spiegare a parole perché il boxed è meglio per il loro caso non funziona quasi mai: il cliente difende la sua preferenza estetica.

Quello che funziona è la dimostrazione diretta.

Apriamo il loro sito attuale su un monitor grande, spesso quello da 27 pollici in ufficio. Quasi sempre un sito full width costruito senza considerare i monitor grandi mostra immediatamente i problemi: contenuto che si sposta in posizioni strane, testo che diventa illeggibile perché le righe sono troppo lunghe, menu con spazi enormi, sezioni che si rompono visivamente.

Poi apriamo un sito boxed ben progettato sullo stesso schermo. Il confronto è immediato e non richiede spiegazioni tecniche.

Nel 95% dei casi il cliente cambia idea da solo. Non perché abbiamo vinto un’argomentazione: perché ha visto con i propri occhi cosa succede al suo sito su uno schermo grande. E spesso, in quel momento, realizza anche che lui stesso usa un monitor grande in ufficio ma non aveva mai pensato a come il suo sito apparisse su quello schermo.

Questo non vale solo per la scelta del layout: vale come principio generale. Mostrare è sempre più efficace che spiegare. Quando il cliente vede il problema, lo risolvi insieme. Quando lo spieghi senza mostrarlo, difende la sua idea originale.

I monitor grandi che nessuno testa

C’è un problema sistematico nello sviluppo web che questa scelta di layout porta in superficie: quasi nessuno testa i siti su monitor grandi durante lo sviluppo.

I developer lavorano su laptop da 13 o 15 pollici. I designer usano monitor da 24 pollici al massimo. I breakpoint responsive che si impostano coprono mobile, tablet e desktop standard. Ma i monitor da 27, 32 o 34 pollici, che sono sempre più diffusi sia negli uffici che a casa, spesso non vengono considerati.

Un sito full width su un monitor ultrawide da 34 pollici può diventare illeggibile. Le righe di testo superano i 150 caratteri, che è il doppio di quello che un occhio umano riesce a seguire comodamente senza perdere il filo. Gli spazi tra gli elementi si moltiplicano in modo non previsto. Il layout si rompe in modi che nessuno ha testato.

La regola tecnica che applichiamo su ogni progetto: definire una larghezza massima (max-width) anche sui siti full width per evitare che il contenuto si espanda oltre i 1.400-1.600 pixel. Non è un compromesso estetico: è la condizione che rende il sito usabile su tutti gli schermi, inclusi quelli che nessuno ha in mente durante lo sviluppo.

Per approfondire come la struttura del layout impatta le performance e i Core Web Vitals, leggi l’articolo dedicato. Per capire come strutturare una homepage che converte indipendentemente dal layout scelto, leggi l’articolo dedicato. Per approfondire cosa significa un sito web professionale nel 2026 dal punto di vista tecnico e di usabilità, leggi l’articolo dedicato.

Su blurr.it/contatti/ puoi prenotare una chiamata per discutere le scelte di layout dei tuoi prossimi progetti con il team tecnico.

C’è una categoria di dispositivo che quasi nessuna agenzia web testa sistematicamente durante lo sviluppo: il monitor da 27, 32 o 34 pollici. Non perché sia raro: è sempre più diffuso sia negli uffici che nelle case di chi lavora da remoto. Non perché sia difficile da testare: basta avere lo schermo. Il motivo è più banale. Developer e designer lavorano su laptop da 13 o 15 pollici. Il testing responsive copre mobile, tablet e desktop standard. I monitor grandi non sono nei breakpoint predefiniti di nessun framework. E nessuno ci pensa.

Il risultato è che decine di siti consegnati come “perfetti” si rompono visivamente su uno schermo da 27 pollici. Contenuto che si distribuisce in modo non previsto. Testo con righe troppo lunghe per essere lette comodamente. Menu che si separano fino agli angoli opposti dello schermo. Sezioni con spazi vuoti enormi che non erano nel design originale.

Il cliente quasi mai lo segnala, perché quasi mai guarda il suo sito su quel monitor. Lo usa per lavorare, non per controllare il sito. Il problema esiste ma rimane invisibile, finché qualcuno non lo mostra.

Il punto cieco sistematico del web design

I breakpoint responsive standard coprono tre categorie: mobile fino a 768px, tablet fino a 1024px, desktop da 1024px in su. Questa struttura è rimasta stabile per anni perché rifletteva la distribuzione reale degli schermi in uso.

Il problema è che il “desktop da 1024px in su” nel 2026 include tutto, dal laptop da 13 pollici con risoluzione 1280px al monitor ultrawide da 34 pollici con risoluzione 3440px. Sono schermi con proporzioni completamente diverse, e un sito ottimizzato per 1280px non è automaticamente ottimizzato per 2560px o 3440px.

I dati di distribuzione degli schermi mostrano che i monitor da 1920px di larghezza e oltre rappresentano ormai oltre il 40% delle sessioni desktop. Un monitor Full HD da 24 pollici, che è lo standard attuale anche per uso home, visualizza i siti a 1920px. Un monitor 4K da 27 pollici li visualizza a 2560px. Sviluppare e testare solo a 1280px significa consegnare siti non ottimizzati per quasi la metà degli utenti desktop.

Lavorando con agenzie italiane su centinaia di siti, troviamo questo problema con una frequenza che ormai non sorprende più. Quasi ogni sito che prendiamo in manutenzione ha almeno un problema visibile a 1920px o superiore che non è stato rilevato durante lo sviluppo.

I problemi più frequenti che troviamo sui grandi schermi

Dopo anni di analisi su siti reali, abbiamo identificato un set di problemi ricorrenti che quasi sempre emergono quando si guarda un sito su un monitor grande.

Problema: Righe di testo troppo lunghe Causa: Testo in un container full width senza max-width definita. Su schermi da 2560px, le righe di testo possono superare i 150-180 caratteri, che è il doppio di quello che un occhio umano riesce a seguire comodamente senza perdere il filo della riga. Soluzione Blurr: Definire una max-width sul container del testo, tipicamente tra i 65 e i 75 caratteri per riga per testi di corpo, indipendentemente dalla larghezza dello schermo. Non è un vincolo estetico: è il requisito minimo per la leggibilità.

Problema: Menu con spazi enormi tra logo e voci di navigazione Causa: Header full width senza max-width sul container interno. Su monitor grandi, il logo finisce nell’angolo sinistro e le voci di menu nell’angolo destro, separati da decine di centimetri di spazio vuoto. La navigazione diventa difficile da trovare e usare. Soluzione Blurr: Container interno dell’header con max-width definita e centrata, anche se il background dell’header si estende fino ai bordi dello schermo per l’estetica full width.

Problema: Sezioni con proporzioni distorte Causa: Sezioni hero o di presentazione con altezze definite in viewport height (vh) che su schermi 4K producono proporzioni mai previste nel design originale. Un’immagine hero da 80vh su un monitor 4K da 32 pollici è alta oltre 800 pixel, molto più di quello che era previsto. Soluzione Blurr: Altezze definite con min-height invece di height fissa, con valori massimi che impediscono la distorsione su schermi molto grandi. Test sistematico a 1920px, 2560px e 3440px prima della consegna.

Problema: Griglie che si allargano oltre il design originale Causa: Griglie CSS con colonne definite in frazioni o percentuali senza max-width sul container padre. Su schermi grandi le colonne diventano molto più larghe di quelle previste nel design, con contenuto che appare sproporzionato. Soluzione Blurr: Max-width sul container della griglia con centramento automatico, in modo che la griglia non si espanda oltre la larghezza prevista dal design.

La max-width: la soluzione tecnica che risolve quasi tutto

La soluzione tecnica a quasi tutti i problemi sui grandi schermi è una sola riga di CSS applicata nel posto giusto: max-width con un valore definito sul container del contenuto.

Definire una max-width non significa abbandonare il full width. Significa che il contenuto ha una larghezza massima ragionevole e rimane centrato sullo schermo quando questo supera quella larghezza. Lo sfondo, le immagini decorative, i colori di sezione possono continuare a estendersi fino ai bordi dello schermo per l’effetto visivo desiderato. Il contenuto, testo, immagini funzionali, bottoni, rimane in un container controllato.

I valori di max-width più usati nella nostra pratica:

• 1200-1280px per siti aziendali con molto testo, ottimale per leggibilità
• 1400-1440px per siti con layout a più colonne o molto contenuto visivo
• 1600px come massimo ragionevole per siti con elementi grafici molto espansi

Tutto sopra i 1600px inizia a creare problemi di leggibilità su monitor grandi. Non perché sia tecnicamente sbagliato: perché l’occhio umano non è progettato per seguire righe di testo di quella lunghezza.

Come integrare il test su grandi schermi nel processo di sviluppo

Non serve avere un monitor da 32 pollici per testare come si comporta un sito su quegli schermi. Bastano due strumenti gratuiti che ogni developer dovrebbe usare sistematicamente.

Il primo è il DevTools del browser, disponibile in qualsiasi browser moderno. Nella sezione di testing responsive è possibile impostare manualmente qualsiasi risoluzione, incluse le 1920px, 2560px e 3440px. Cinque minuti di testing a queste risoluzioni prima della consegna identificano il 90% dei problemi che emergerebbero poi su monitor reali.

Il secondo è il CSS di zoom del browser. Impostando lo zoom del browser al 75% o al 67% su un monitor standard si simula approssimativamente la densità di contenuto di uno schermo più grande. Non è un test preciso ma è sufficiente per identificare i problemi più evidenti senza strumenti aggiuntivi.

Su ogni progetto che gestiamo per le agenzie partner, il testing a 1920px è parte del processo di QA standard prima della consegna su staging. Non è un passaggio opzionale: è la condizione minima per consegnare un sito che funziona su tutti i dispositivi che i clienti reali usano. Per approfondire come strutturiamo il processo completo di sviluppo, leggi come funziona lavorare con Blurr.

Per capire come la scelta tra full width e boxed container impatta la gestione dei grandi schermi, leggi l’articolo dedicato. Per approfondire come i Core Web Vitals vengono impattati dalla struttura del layout su schermi diversi, leggi l’articolo dedicato.

Su blurr.it/contatti/ puoi prenotare una chiamata per discutere come gestiamo il testing su tutti i dispositivi nei progetti che sviluppiamo per le agenzie partner.