Next.js 13 ha introdotto un nuovo modello di componenti – Server Components (SC) e Client Components (CC). Sebbene coesistano, il loro funzionamento interno è diametralmente diverso, influenzando direttamente le prestazioni dei Next.js Server Components. In questo articolo esamineremo i meccanismi che determinano la dimensione del bundle, i tempi di caricamento e i costi di rendering, oltre a suggerire quando conviene scegliere SC e quando rimanere con i tradizionali CC.
Come funziona il rendering dei Server Components
I Server Components vengono renderizzati esclusivamente sul lato server. Il loro codice non arriva al browser, il che significa che non viene bundleato da Webpack (o Turbopack). Invece, Next.js genera HTML e un opzionale JSON con i dati, che vengono inviati al client. In questo modo il browser riceve solo il markup finale, non tutta la logica del componente.
Questo meccanismo elimina la necessità di caricare librerie UI sul lato client, riducendo in pratica la dimensione di bundle.js di decine di megabyte nelle grandi applicazioni. Allo stesso tempo il server può eseguire operazioni costose (ad es. accesso al database, elaborazione di immagini) prima di inviare il risultato, diminuendo il numero di round‑trip HTTP.
Differenze tra Server e Client Components in Next.js
- Ambiente di esecuzione: SC – Node.js sul server; CC – browser.
- Bundling: SC non è bundleato, CC sì.
- Stato ed effetti: SC non può usare
useState,useEffectné altri hook del browser. - Interazione: SC non gestisce eventi UI; CC è l’unico luogo in cui si definiscono gestioni di click, form, ecc.
In pratica ciò significa che ogni componente che non richiede interazione può essere trasformato in Server Component, mentre solo quelli che necessitano di stato o effetti rimangono Client Components.
Come i Server Components influenzano la dimensione del bundle
Il fattore principale che riduce la dimensione del bundle è l’esclusione del codice delle dipendenze utilizzate esclusivamente sul server. Ad esempio, la libreria node-fetch o prisma non verrà inclusa nel file client.js, il che in progetti di grandi dimensioni può far risparmiare centinaia di kilobyte.
// client-component.jsx
'use client';
import { useState } from 'react';
export default function Counter() {
const [count, setCount] = useState(0);
return setCount(c => c + 1)}>Count: {count};
}
// server-component.jsx
export default async function ProductList() {
const products = await prisma.product.findMany();
return (
{products.map(p => (
- {p.name}
))}
);
}
L’esempio sopra mostra che il codice di accesso al database (prisma) non verrà incluso nel bundle del browser, influenzando direttamente la riduzione della dimensione di client.js.
Ottimizzazione del rendering in Next.js 13 – costi SSR vs Server Components
Il tradizionale Server‑Side Rendering (SSR) genera HTML completo su richiesta, ma richiede la riesecuzione dell’intero albero dei componenti ad ogni cambiamento di dati. I Server Components, invece, possono essere parzialmente cacheati e utilizzare React.cache (o use nelle versioni future). Così, quando cambia solo una parte dei dati, viene aggiornato solo lo SC pertinente, mentre il resto dell’albero rimane invariato.
In pratica il costo di rendering degli SC è inferiore rispetto al SSR completo, a patto che l’applicazione sia suddivisa in piccoli componenti isolati. D’altro canto, un uso eccessivo degli SC combinato con frequenti query al database può aumentare il carico sul server se non si implementa un caching adeguato.
Quando usare i Server Components e quando no
- Usa SC quando:
- Il componente non richiede interazione UI (ad es. liste di prodotti, sezioni SEO statiche).
- Hai bisogno di accedere a risorse server (database, file system, API con chiave segreta).
- Vuoi ridurre la dimensione del bundle e accelerare il First Contentful Paint.
- Evita SC quando:
- Il componente deve reagire a eventi del browser (click, animazioni).
- Richiede stato locale o hook del browser.
- La logica è molto leggera e il costo di inviarla al client è trascurabile.
Tipiche trappole in produzione con l’uso dei Server Components
Uno degli errori più comuni è importare inconsapevolmente moduli client‑side nei Server Component. Anche una piccola dipendenza, come date-fns/format, può far sì che l’intero componente venga trattato come client‑side, aumentando il bundle. Lo strumento next lint con la regola react-server-components aiuta a individuare queste situazioni.
«I Server Components sono un meccanismo potente, ma il loro valore si manifesta solo quando manteniamo una netta separazione tra server e client.»
Un altro problema è fare eccessivo affidamento su query asincrone nei SC senza cache. Un alto tasso di richieste può portare a un calo delle prestazioni del server e all’allungamento dei tempi di risposta. La soluzione sono i layer di cache (Redis, Edge‑Cache) e la memoizzazione nel codice.
Checklist pratico – migrazione da Client Components a Server Components
- Identifica i componenti non interattivi – spostali in
.server.jsxo aggiungi'use server'all’inizio del file. - Controlla tutti gli import – rimuovi o sostituisci le librerie che richiedono l’ambiente del browser.
- Implementa la cache: aggiungi
revalidateofetch(..., { cache: 'force-cache' })dove possibile. - Esegui
next builde verifica la dimensione diclient.js– dovrebbe ridursi proporzionalmente ai SC spostati. - Monitora le metriche: TTFB, FCP, LCP e l’utilizzo CPU del server dopo la migrazione.
Riepilogo e invito alla collaborazione
Next.js Server Components offrono vantaggi significativi in termini di prestazioni e dimensione del bundle, a patto di una divisione consapevole della logica tra server e client. SC ben progettati riducono il First Contentful Paint, limitano il numero di dipendenze inviate e consentono un accesso efficiente alle risorse backend. È comunque necessario fare attenzione alle trappole legate a import errati e alla mancanza di cache. Se hai bisogno di assistenza per la migrazione, l’ottimizzazione o un audit delle prestazioni in Next.js, il team di Coderia.it è pronto a supportare il tuo progetto – contattaci subito.
