I Server Components di Next.js 14 riducono la dimensione del bundle di circa il 60% e portano i tempi di first-paint sotto i 200 ms su una tipica pagina di un blog, il che significa che gli utenti vedono i contenuti più velocemente e i motori di ricerca ricevono HTML completamente renderizzato.

L'ultima release ribalta il modello di esecuzione predefinito per le app React costruite con Next.js. Mentre in precedenza ogni componente veniva inviato al browser, ora gli sviluppatori possono contrassegnare parti della UI come “Server Components” in modo che vengano eseguite solo sul backend. Il codice di questi componenti non raggiunge mai il client, lasciando al browser solo le parti che necessitano di interattività.

Perché questo cambiamento è importante

Gli sviluppatori React combattono da tempo con tre problemi intrecciati: una raffica di richieste di rete, bundle JavaScript gonfi e caricamenti di pagina lenti. Questi problemi danneggiano anche la SEO perché l'HTML iniziale inviato ai crawler è spesso vuoto, costringendo i bot di ricerca ad attendere l'idratazione lato client. Next.js 14 affronta la causa principale spostando completamente il lavoro pesante relativo ai dati lontano dal client.

In cosa differiscono i Server Components dal vecchio modello

  • Server Components – Vengono eseguiti sul server, recuperano dati, comunicano con i database e restituiscono HTML semplice. Il loro JavaScript non viaggia mai sulla rete.
  • Client Components – Rimangono nel browser e gestiscono le interazioni della UI, come clic sui pulsanti, invio di moduli o qualsiasi componente che utilizzi lo stato o gli effetti di React.

Il framework impone questa divisione con una semplice direttiva. Aggiungere use client in cima a un file dice a Next.js di trattare quel componente come esclusivamente lato client. Tutto ciò che non presenta quel marker è, per impostazione predefinita, un Server Component.

Numeri reali

Un rapido esperimento su una pagina di un blog personale illustra l'impatto. Dopo aver spostato la fetch in un Server Component e aver lasciato che il server renderizzasse la lista come HTML statico, il bundle JavaScript si è ridotto del 60% e la pagina è stata renderizzata in meno di 200 ms.

Un modello di stratificazione pratico

  1. Livello inferiore (Server) – Recupera i dati da API o database. Mantieni qui qualsiasi logica privata; non lascerà mai il server.
  2. Livello intermedio (Server) – Trasforma i dati grezzi in puro markup HTML. Questo livello può ancora utilizzare la sintassi JSX di React, ma rimane esclusivamente lato server.
  3. Livello superiore (Client) – Inserisci piccoli widget isolati per l'interattività. Esempi tipici sono i pulsanti “like”, i moduli per i commenti o i menu a discesa che richiedono uno stato.

Seguire questa gerarchia mantiene la maggior parte dell'app leggera, preservando al contempo la sensazione di dinamicità che gli utenti si aspettano.

Passaggi che puoi provare oggi stesso

  1. Scansiona il tuo codebase alla ricerca di componenti che utilizzano useEffect solo per recuperare dati.
  2. Estrai la chiamata fetch in un nuovo Server Component e lascia che restituisca il markup renderizzato.
  3. Crea un componente client minimale (aggiungi use client in alto) per gli eventuali elementi interattivi rimanenti.
  4. Esegui nuovamente il tuo bundle analyzer; dovresti notare un calo significativo delle dimensioni.

Evita di spargere use client ovunque. Se un componente non dipende dallo stato di React, dal context o dagli hook del ciclo di vita, lascialo come Server Component. Più codice tieni lontano dal client, più piccolo sarà il download e più veloce sarà la pagina.

In sintesi: Spostando il recupero dei dati e il rendering pesante sul server, Next.js 14 ti permette di inviare molto meno JavaScript, fornire istantaneamente HTML completamente renderizzato e mantenere l'interattività dove conta davvero. Il risultato è un'esperienza web più veloce e snella che avvantaggia sia gli utenti che i motori di ricerca.