Next.js o React puro: quale scegliere per la tua web app?
Next.js o React puro? È una delle prime domande in ogni nuovo progetto web, e la scelta sbagliata si paga in SEO, velocità e lavoro da rifare. Ecco una guida pensata per i founder su quando conviene l'uno e quando l'altro.
Shayan Jamil·8 giugno 2026·5 min di lettura
"Usiamo Next.js o solo React?" è una domanda che salta fuori in quasi ogni nuovo progetto web, di solito da parte di un founder che ha sentito entrambi i nomi e vuole essere sicuro che la decisione non venga presa alla leggera. È un buon istinto, perché questa scelta influenza silenziosamente il posizionamento del tuo prodotto sui motori di ricerca, la sua velocità di caricamento e quanto lavoro potresti dover rifare in futuro.
In breve: non sono davvero concorrenti. Next.js è costruito sopra React. Ma la decisione conta comunque, e scegliere in base ai tuoi obiettivi reali, non alle mode, fa risparmiare soldi veri. Ecco come la vedo.
Cosa sono davvero, in parole semplici
React è una libreria per costruire interfacce utente. Da sola, produce una web app che gira interamente nel browser: il dispositivo dell'utente scarica il codice e poi costruisce la pagina. È ottimo per prodotti in stile applicazione a cui le persone accedono con login, ma ai motori di ricerca e alle anteprime social offre all'inizio una pagina vuota.
Next.js è un framework completo attorno a React. Aggiunge ciò che serve comunque alla maggior parte dei prodotti reali: il rendering delle pagine sul server (così arrivano veloci e già complete), il routing integrato, l'ottimizzazione delle immagini e uno spazio per la logica di backend. Continui a scrivere React, Next.js si occupa semplicemente del lavoro pesante attorno.
Da sapere: lo stesso team di React oggi consiglia di avviare le nuove app con un framework come Next.js, e ha deprecato Create React App, il vecchio starter predefinito. Quando oggi dico "React puro", intendo React con un build tool moderno come Vite. Se qualcuno propone Create React App per un nuovo progetto, è segno che le sue conoscenze non sono aggiornate.
La domanda di business: dove conta davvero?
Di solito la decisione si riduce a una sola cosa: chi deve vedere i tuoi contenuti, e quanto in fretta?
Se il tuo prodotto è un sito pubblico (un sito marketing, un e-commerce, un blog, una directory), allora SEO e velocità di caricamento sono fatturato. Motori di ricerca e piattaforme social hanno bisogno di vero HTML da leggere e indicizzare, e ogni secondo in più di caricamento ti fa perdere visitatori. È esattamente qui che Next.js si guadagna il posto, ed è per questo che lo scelgo per i progetti ricchi di contenuti e rivolti ai clienti.
Se il tuo prodotto è una dashboard privata, in stile applicazione, a cui gli utenti accedono con login (uno strumento interno, un pannello di amministrazione, un'area riservata ai membri), allora la SEO conta poco, perché le pagine di valore sono comunque dietro un login. Qui React puro (o una configurazione più leggera) può andare benissimo.
La regola rapida che uso
Se degli sconosciuti devono trovarlo su Google o vedere una bella anteprima quando viene condiviso, propendi per Next.js. Se vive interamente dietro un login e nessuno lo cerca, spesso React puro basta. La maggior parte dei prodotti reali ha un po' di entrambe le cose, e Next.js le gestisce entrambe senza problemi: ecco perché è la mia scelta predefinita.
Perché incide su tempi e budget
Sbagliare non è fatale, ma costa in un modo ben preciso. L'errore classico è costruire un prodotto orientato al marketing come app React pura, lanciarlo e poi scoprire che le pagine non si posizionano e che le anteprime dei link risultano vuote. Aggiungere il rendering lato server in un secondo momento significa rimettere mano alle fondamenta, pagando due volte qualcosa che poteva essere giusto fin dal primo giorno.
L'errore opposto si recupera con meno fatica, ma resta uno spreco: introdurre un framework completo per un piccolo strumento interno usato da tre persone aggiunge una complessità di cui nessuno aveva bisogno.
Un esempio concreto
Tra i miei progetti, lo store di Convertible M&T è un buon caso per Next.js: è una piattaforma e-commerce dove i clienti sfogliano ricambi, cercano nel catalogo e devono trovare i prodotti tramite i motori di ricerca, quindi rendering lato server e velocità sostengono direttamente le vendite. Skalable, un sito marketing in ambito finanziario, è simile: deve caricarsi in fretta e presentarsi bene quando viene condiviso, territorio tipico di Next.js.
Al contrario, le dashboard di amministrazione dietro diversi di quei prodotti vivono interamente dietro un login. Lì la priorità è un'interfaccia veloce e reattiva per il team, non il posizionamento nelle ricerche, quindi i compromessi sono completamente diversi. Il punto non è che uno strumento sia "migliore", ma abbinare lo strumento a chi è destinata la pagina.
Errori comuni dei founder su questo tema
- Scegliere in base all'hype invece che al fatto che le pagine debbano essere trovate nelle ricerche.
- Costruire un prodotto pubblico e ricco di contenuti come app solo browser, per poi pagare l'adeguamento SEO dopo il lancio.
- Complicare troppo uno strumento interno con un framework completo di cui non ha bisogno.
- Ignorare la velocità di caricamento: le pagine pubbliche lente ti fanno perdere visitatori e posizionamento senza che te ne accorga.
- Considerare il framework l'intera decisione, quando il modello dei dati e API di backend pulite contano altrettanto per la crescita del prodotto.
Come affronto la scelta in un nuovo progetto
- Parto da chi sono i destinatari delle pagine. Pubbliche e indicizzabili, o private e dietro un login?
- Metto sulla bilancia SEO e velocità di caricamento rispetto al costo della complessità aggiuntiva.
- Scelgo Next.js come default per tutto ciò che è rivolto ai clienti, perché gestisce in modo pulito sia la parte pubblica sia quella applicativa di un prodotto.
- Mantengo le cose semplici dove la semplicità vince: non tutti gli strumenti interni hanno bisogno dell'intera cassetta degli attrezzi.
- Decido una volta sola, all'inizio, così le fondamenta non vanno ricostruite quando arriva il traffico.
Nella maggior parte dei casi, per un prodotto reale che mescola pagine pubbliche e funzionalità con login, Next.js è la scelta pragmatica. Ma decido in base ai tuoi obiettivi, non a una preferenza personale, e sarò ben felice di dissuaderti da una complessità che non ti serve.
Non sai quale sia adatto al tuo progetto?
Se stai pianificando una web app e vuoi una risposta chiara sulla configurazione giusta (una che si adatti ai tuoi obiettivi, al tuo budget e a come prevedi di crescere), è proprio il tipo di decisione su cui aiuto i founder prima ancora di scrivere una riga di codice.
Dai un'occhiata ai miei progetti, leggi qualcosa sul mio modo di lavorare e contattami raccontandomi cosa stai costruendo. Ti dirò onestamente cosa userei e perché.