IlnostrostarterNext.js+Sanity

Nel nostro Journal ti abbiamo già raccontato cos'è un CMS headless e perché abbiamo scelto Sanity come piattaforma di riferimento. In questo articolo, invece, spieghiamo cosa succede quando su quella scelta costruisci anni di lavoro, progetto dopo progetto.

Quando si costruiscono prodotti digitali, il modo in cui si inizia dice molto su come lo si finirà. Configurare da zero ogni volta lo stesso ambiente, reimpostare le stesse integrazioni, riorganizzare le stesse cartelle... tutto questo è tempo sottratto a ciò che conta davvero, ovvero costruire qualcosa di valore per chi ci sceglie come partner.

Per questo motivo abbiamo creato (e manteniamo) un repository template proprietario basato su Next.js e Sanity. Non si tratta di uno starter generico, ma del risultato accumulato di decine di progetti reali, scelte testate sul campo, problemi già risolti e workflow affinati nel tempo.

Ogni nuovo progetto che costruiamo eredita tutto questo.

Perché non bastava il template ufficiale

Sanity e Next.js offrono template di partenza eccellenti per chi vuole esplorare lo stack. Ma quando si lavora in produzione, su progetti reali con requisiti reali, quegli stessi starter mostrano presto i loro limiti.

Il primo punto critico è la gestione delle lingue. I plugin standard funzionano bene in scenari semplici, ma quando un progetto richiede mercati separati − contenuti diversi per lingua, editor diversi per mercato − le cose si complicano in fretta.

Quello che abbiamo fatto è stato sviluppare una vista personalizzata di Sanity Studio in cui ogni editor vede solo i contenuti nella propria lingua. Nessun rischio di modificare per errore qualcosa in un altro mercato, nessun rumore visivo, nessuna formazione aggiuntiva necessaria. L'interfaccia è progettata attorno al flusso di lavoro reale di chi la usa ogni giorno.

Tutto modificabile dal CMS

Uno dei principi fondanti del nostro starter è che nessun testo, link o impostazione visibile all'utente finale è scritto nel codice. Ogni elemento che potresti voler cambiare − dal testo del bottone principale ai link social, dai metadati SEO agli script di analytics − è modificabile dal CMS senza coinvolgere il developer.

Il meccanismo che rende possibile tutto questo si chiama PageBuilder, un sistema a blocchi con cui si costruiscono pagine complesse riordinando sezioni nell'editor, proprio come si farebbe con un page builder visuale, ma con tutta la potenza e la flessibilità di un CMS headless.

Ogni blocco − un hero, una sezione testo, una gallery, una call to action − ha il suo schema nel CMS e il suo componente React nel front-end. La corrispondenza è diretta e prevedibile: chi gestisce i contenuti lavora in autonomia, lo sviluppatore interviene solo quando serve aggiungere nuovi blocchi al catalogo.

Internazionalizzazione nativa, non aggiunta in corsa

Il multilingua è una di quelle funzionalità che, se non pensata dall'inizio, diventa un problema enorme da integrare in seguito.

Nel nostro starter è un elemento strutturale. Ogni contenuto esiste come documento indipendente per ogni lingua, con URL internazionali generati automaticamente. La lingua di default non ha prefisso (/); le lingue aggiuntive ottengono il loro prefisso in automatico (/en, /es, e così via).

In pratica, aggiungere una nuova lingua a un progetto richiede pochi minuti di configurazione. Non giorni di refactoring, non interventi sull'architettura. Si aggiunge la lingua in un file di configurazione e il resto si adatta.

SEO gestita dal CMS

Uno degli aspetti che più spesso genera attriti tra studi digitali e clienti è la SEO: chi la aggiorna? In che tempi? Bisogna aspettare il developer per cambiare un meta title?

Nel nostro starter la risposta è no. Ogni pagina espone i propri metadati − titolo per i motori di ricerca, descrizione, immagine per i social − come campi editabili nel CMS. Il responsabile marketing può aggiornarli in autonomia, in qualsiasi momento, senza deploy, senza passare dallo studio. Le modifiche vanno online immediatamente.

Il sito genera anche una sitemap automatica, sempre sincronizzata con i contenuti pubblicati. Non c'è rischio di dimenticare di aggiornarla manualmente dopo ogni nuova pagina, perché è il codice stesso a tenerla allineata.

Aggiornamenti in tempo reale senza rebuild

Pubblicare una modifica e vederla online dopo minuti di attesa − o peggio, dover aspettare che qualcuno lanci un deploy − è un'esperienza frustrante per chi gestisce contenuti.

Nel nostro starter questa attesa non esiste. Quando un editor pubblica una modifica su Sanity, il sito la riceve e la mostra in tempo reale, senza ricostruzioni, senza webhook da configurare, senza attese.

La stessa tecnologia abilita un'anteprima live durante l'editing: chi gestisce i contenuti vede la pagina aggiornarsi mentre scrive, prima ancora di pubblicare.

Dal punto di vista delle performance, il sito si comporta come se fosse completamente statico: veloce, efficiente, ottimizzato per i Core Web Vitals. Ma i contenuti sono sempre attuali.

Performance che è anche impatto ambientale

C'è un aspetto dell'architettura headless di cui si parla poco: l'impatto ambientale.

Il nostro sito, costruito con lo starter che ti stiamo raccontando, consuma solo 0,10 grammi di CO2 a visita, dieci volte meno della media globale. Non è ottimizzazione di facciata, è una conseguenza diretta di come è costruito il sito.

Nel modello tradizionale il server costruisce ogni pagina nel momento in cui qualcuno la richiede, consumando energia a ogni visita. In un'architettura headless quel lavoro si fa una volta sola, al momento della pubblicazione: poi le pagine vengono distribuite via CDN già pronte.

Su scale ridotte è marginale. Su un sito enterprise con migliaia pagine e traffico costante, diventa una voce reale nel bilancio di sostenibilità.

Accessibilità come punto di partenza

L'accessibilità se affrontata solo alla fine genera debito tecnico difficile da ripagare − e in alcuni contesti è anche un requisito normativo.

Nel nostro starter le fondamenta corrette sono incluse dall'inizio: struttura semantica dell'HTML, livelli di heading gestiti correttamente, navigazione da tastiera funzionante, attributi per i lettori di schermo dove necessario.

Non è un sistema perfetto o definitivo. L'accessibilità è un percorso, non una destinazione. Ma partire da una base corretta significa non dover rimediare a scelte architetturali sbagliate a progetto avanzato.

I benefici per tutto il team

Il vantaggio meno visibile di avere uno starter proprietario è quello che succede internamente al team.

Ogni nuovo collaboratore trova un ambiente familiare: stessa struttura delle cartelle, stesse convenzioni, stesso modo di aggiungere blocchi, query e tipi di pagina. Il codice è commentato per guidare ogni estensione, non c'è bisogno di spiegare dove vanno i componenti o come funziona il fetch dei dati.

Questo abbatte i tempi di onboarding e riduce il margine di errore nelle fasi iniziali, che sono storicamente quelle in cui si prendono le decisioni più difficili da correggere in seguito.

Un repository in continua evoluzione

Il repository non è una fotografia di un momento nel tempo. È un progetto vivo, che viene costantemente aggiornato.

Ogni volta che risolviamo un problema complesso su un progetto specifico − una gestione particolare dei metadati, un pattern più efficiente, un componente che si rivela riutilizzabile − quella soluzione torna nel template e diventa lo standard per tutti i progetti futuri.

Questo significa che ogni nuovo sito che costruiamo eredita mesi, e a volte anche anni, di ottimizzazioni accumulate sul campo.

Cosa significa tutto questo per chi ci sceglie

I problemi che abbiamo già risolto

• Configurazioni da reimpostare da zero a ogni nuovo progetto.
• Plugin standard che non reggono scenari multi-lingua complessi.
• Routing rigido che richiede intervento del developer per ogni nuova sezione.
• SEO e accessibilità affrontate come ripensamento tardivo.
• Tempi di onboarding lunghi per i nuovi collaboratori.
• Bug di integrazione scoperti troppo tardi, in fase avanzata.

I vantaggi che portiamo a casa

• Ogni progetto eredita mesi di ottimizzazioni accumulate sul campo.
• Gli editor sono autonomi: contenuti, lingue e pagine gestibili senza deploy.
• Il sito si aggiorna in tempo reale, senza rebuild.
• SEO, accessibilità e performance sono standard, non optional.
• Il team parla la stessa lingua tecnica, dal primo giorno.
• Il budget del cliente va sulla soluzione, non sull'assemblaggio.

Conclusioni

Uno starter proprietario non è un lusso tecnico: è un impegno verso la qualità che si ripercuote su ogni progetto che esce dal nostro studio. Chi ci affida un sito non paga per risolvere problemi che abbiamo già risolto altrove. Parte già da una base solida, testata, conforme ai nostri standard di performance, sicurezza e accessibilità.