Next.js usato come va usato, senza riti.
App Router, Server Components, ISR, rendering in streaming. Strumenti potenti, spesso adottati perché sono di moda e non perché risolvono un problema. Noi partiamo dal problema.
Sviluppiamo siti e applicazioni web in Next.js, il framework React per la produzione: pagine renderizzate sul server, quindi veloci e leggibili da Google, e una strategia di cache decisa all’inizio invece che scoperta alla fine. Seguiamo anche migrazioni al nuovo App Router. Il sito che state leggendo è costruito con Next.js.
Aggiornato novembre 2026
Next.js rende facili le cose difficili, e facilissimo fare quelle sbagliate.
Next.js permette di decidere pagina per pagina come e quando generare il contenuto: sul server a ogni richiesta, una volta in fase di build, o rigenerato ogni tanto. È questo che lo rende veloce e adatto ai motori di ricerca. È anche il motivo per cui un progetto fatto in fretta finisce con pagine lente, dati vecchi in cache e bollette di hosting che nessuno sa spiegare.
Per questo il lavoro che conta si fa prima del codice: quali pagine devono essere sempre aggiornate, quali possono essere generate una volta, dove sta la cache e come si svuota. Lo scriviamo, lo concordiamo e lo misuriamo.
Il sito che state leggendo è costruito con Next.js. Un progetto Next.js lo pubblichiamo su Vercel, su Cloudflare o su un vostro server, a seconda di costi e vincoli, non per abitudine.
Che cosa sviluppiamo.
Siti istituzionali e di marketing
Veloci, leggibili dai motori di ricerca e dagli assistenti IA, con i contenuti gestiti da un CMS che il vostro team sa usare.
Migrazione all’App Router
Dal vecchio Pages Router al nuovo App Router, una sezione alla volta, senza fermare il sito e senza perdere posizionamento.
Strategia di cache e ISR
Quali pagine si generano una volta, quali si rigenerano e ogni quanto, come si svuota la cache quando cambia un prezzo. Deciso e scritto, non lasciato al caso.
Streaming e rendering vicino all’utente
Le parti lente della pagina arrivano dopo senza bloccare il resto. Usato dove serve, non ovunque perché è possibile.
Front end per e-commerce headless
Next.js sopra Shopify o un altro motore di e-commerce, quando un tema non basta più.
Applicazioni con area riservata
Accesso, ruoli e dati per utente nella stessa base di codice delle pagine pubbliche.
Pubblicazione su Vercel, Cloudflare o server vostri
Scegliamo dove pubblicare in base a costi, traffico e vincoli sui dati, con anteprime per ogni modifica.
Prestazioni misurate
Core Web Vitals misurati su pagine reali e connessioni mobili reali, prima e dopo.
Quattro modi di generare una pagina in Next.js.
La scelta va fatta pagina per pagina. Sbagliarla è il motivo più comune per cui un sito Next.js è lento o mostra dati vecchi.
| Statica (build) | ISR (rigenerata) | Server (a ogni richiesta) | Client (nel browser) | |
|---|---|---|---|---|
| Velocità per il visitatore | Massima | Massima | Buona | Dipende dal dispositivo |
| Dati aggiornati | Solo al prossimo rilascio | Entro un intervallo deciso | Sempre | Sempre |
| Leggibile da Google | Sì | Sì | Sì | In parte |
| Costo del server | Minimo | Basso | Più alto | Basso |
| Adatta per | Pagine istituzionali, documentazione | Cataloghi, articoli, schede prodotto | Pagine personali, prezzi in tempo reale | Cruscotti dopo l’accesso |
Dove lo usiamo.
Il sito di brainiac/studio, in quattro lingue oltre all’inglese, è costruito con Next.js e TypeScript. Potete misurarne la velocità da soli.
Per i negozi che hanno superato i limiti di un tema, Next.js è il front end che usiamo sopra Shopify.
Portali clienti e strumenti interni in cui la stessa base di codice serve pagine pubbliche e aree riservate.
Quando è la scelta giusta.
Un sito che deve farsi trovare
Contenuti renderizzati sul server, metadati e dati strutturati: la base per Google e per gli assistenti IA.
Un progetto Next.js che è diventato lento
Spesso il problema è la cache o il punto in cui si caricano i dati, non il framework. Si sistema senza riscrivere tutto.
Pagine pubbliche e area riservata insieme
Un solo progetto per il sito e per il portale clienti, invece di due sistemi da tenere allineati.
Non fa per voi se il vostro team deve solo pubblicare pagine
Per un sito di poche pagine aggiornato da persone non tecniche, WordPress o un costruttore di siti costano meno da gestire. Next.js ha senso quando c’è un motivo tecnico per sceglierlo, e ve lo diciamo.
Come lavoriamo.
Partiamo dalle pagine
Elenco delle pagine e, per ciascuna, quanto spesso cambiano i dati e chi le deve vedere. Da qui nasce il modo di generarle.
Decidiamo cache e hosting
Dove si pubblica, che cosa si mette in cache, come si aggiorna. Scritto prima del codice.
Progettiamo le schermate
Prototipi cliccabili prima di sviluppare, così si cambia il design quando costa poco.
Sviluppiamo in blocchi di due settimane
Un link di anteprima per ogni modifica, che potete aprire e provare.
Misuriamo
Velocità su dispositivi e reti reali, indicizzazione, errori. Prima del lancio, non dopo le prime lamentele.
Consegniamo
Documentazione, codice nel vostro repository e una sessione con chi lo manterrà.
Sviluppo Next.js
6 domande con risposta. Ne avete un’altra? Scriveteci.
Perché React da solo genera la pagina nel browser, e questo rende più lento il primo caricamento e più difficile il lavoro dei motori di ricerca. Next.js genera le pagine sul server o in anticipo, gestisce instradamento, immagini e cache. Per un sito pubblico o un’applicazione con pagine indicizzabili è quasi sempre la scelta più sensata.
Sette categorie. Quarantacinque servizi.
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.