Server Components vs Client Components in Next.js: guida pratica

Il tuo sito Next.js funziona, ma non sai se quel componente deve essere server o client? Ti è già capitato di importare un hook in un componente che non lo supporta e vedere un errore a schermo? Bene, è ora di fare chiarezza. Noi di Meteora Web lavoriamo con Next.js su progetti reali — piattaforme proprietarie, e-commerce, dashboard. E la scelta tra Server e Client Components non è un dettaglio tecnico: è la differenza tra un'app che vola e una che arranca.

Perché esistono due tipi di componenti?

React Server Components (RSC) non sono una moda. Nascono da un'esigenza concreta: ridurre il JavaScript inviato al browser. Prima di RSC, ogni componente React veniva eseguito lato client. Anche se serviva solo a stampare HTML statico, il browser doveva scaricare, parseare ed eseguire tutto il codice di quel componente. Con RSC, i componenti server vengono eseguiti una volta sola sul server. Il risultato è HTML puro, zero KB di JavaScript.

I Client Components, invece, girano ancora nel browser. Servono per tutto ciò che richiede interattività: click, input, animazioni, effetti collaterali. Ma non tutti i componenti hanno bisogno di tutto questo.

Un esempio concreto

Immagina una pagina prodotto di un e-commerce: hai l'intestazione, la descrizione, il prezzo, un pulsante "Aggiungi al carrello". La descrizione e il prezzo sono statici: possono essere Server Components. Il pulsante con lo stato del carrello deve essere un Client Component. Risultato: meno JS, pagina più veloce. Semplice, vero? Eppure vediamo ancora troppi progetti che marcano tutto come 'use client' per comodità. Pagano in performance.

Quando usare i Server Components

Un componente dovrebbe essere server se non ha bisogno di interattività nel browser. In particolare:

Visualizzazione di dati: fetch di dati da database o API, rendering di liste, tabelle, contenuti statici.
Componenti di layout strutturale: header, footer, sidebar, griglie che non cambiano stato.
Componenti che leggono risorse sensibili (token, chiavi API): il server può accedere a variabili d'ambiente o database senza esporle al client.
Qualsiasi componente che non usa hook React (useState, useEffect, useReducer, useContext) o eventi del browser (onClick, onChange).

Vantaggi concreti dei Server Components

0 JavaScript bundle: il componente non viene incluso nel pacchetto inviato al client.
Accesso diretto a backend: puoi fare query al database senza API intermedie.
Sicurezza: logica sensibile (es. calcolo prezzi, sconti) non arriva mai al client.
SEO migliore: HTML già renderizzato, Google lo vede subito.

// Server Component (di default)
export default async function ProductList() {
  const products = await db.query('SELECT * FROM products');
  return (
    
      {products.map(p => (
        {p.name} - €{p.price}
      ))}
    
  );
}

Nessun 'use client', nessun fetch lato client. Veloce, sicuro, semplice.

Quando usare i Client Components

Un componente deve essere client se ha bisogno di interattività o di API del browser. Ecco i casi classici:

Eventi utente: onClick, onChange, onSubmit, onScroll.
Hook di stato ed effetti: useState, useEffect, useReducer, useCallback.
Context e provider: se usi React Context (tema, autenticazione), il provider deve essere client.
API del browser: localStorage, navigator, window, document.
Componenti di terze parti: molti widget, slider, mappe, editor di testo richiedono il client.

Come si dichiara un Client Component

Basta aggiungere 'use client' all'inizio del file, prima di qualsiasi import.

'use client';

import { useState } from 'react';

export default function AddToCartButton({ productId }: { productId: number }) {
  const [loading, setLoading] = useState(false);

  const handleClick = async () => {
    setLoading(true);
    await fetch('/api/cart/add', { method: 'POST', body: JSON.stringify({ productId }) });
    setLoading(false);
  };

  return (
    
  );
}

Attenzione: ereditarietà del client

Se importi un Client Component dentro un Server Component, quel punto di import diventa il confine. Il Server Component può contenere un Client Component, ma non può passargli funzioni o oggetti non serializzabili (tranne props semplici). Next.js ti avviserà con errori chiari se provi a passare un callback a un Client Component direttamente — dovrai usare Server Actions o passare solo dati.

La regola pratica: parte dall'esigenza

Non iniziare chiedendoti "questo componente è server o client?". Inizia chiedendoti: ha bisogno di interattività?

No → Server Component. Fine.
Sì → Client Component. Ma solo quello. Cerca di tenere la logica interattiva in componenti piccoli e specifici, e tutto il resto (layout, dati, markup statico) fuori dal client.

Noi di Meteora Web applichiamo questa regola su ogni progetto. Un tipico errore dei principianti è mettere 'use client' su un'intera pagina. Così tutto il JavaScript della pagina finisce nel bundle. Molto meglio avere un Server Component per la pagina e annidare solo i componenti interattivi come Client.

Esempio di composizione corretta

// page.tsx (Server Component)
import ProductList from './ProductList';
import AddToCartButton from './AddToCartButton';

export default async function ProductPage() {
  const products = await getProducts();
  return (
    <>
      
      {/* AddToCartButton è Client, ma lo importiamo qui */}
      
    
  );
}

// ProductList.tsx (Server Component - nessun 'use client')
export default function ProductList({ products }) {
  return products.map(p => {p.name});
}

// AddToCartButton.tsx (Client Component)
'use client';
// ...

Eccezioni e situazioni borderline

Componenti che sembrano server ma usano contesto

Se un componente deve leggere un Context (es. tema, lingua), non può essere server perché Context è disponibile solo nel client. Dovrai renderlo client o passare i dati via props dal server.

Data fetching ibrido

Puoi fare fetch lato server con async in un Server Component, ma se hai bisogno di mutazioni (es. form) senza ricaricare la pagina, usa Server Actions. Le Server Actions sono funzioni eseguite lato server, chiamabili da Client Components. Così mantieni la logica server senza esporla.

'use client';
import { addToCart } from './actions';

export default function AddToCart({ productId }) {
  return (
    
      
      
    
  );
}

La funzione addToCart (Server Action) viene eseguita sul server senza esporre logica sensibile nel bundle.

Componenti di terze parti

Molte librerie UI (es. Shadcn/ui, MUI, Chakra) richiedono il client. Controlla la documentazione: se usano use client internamente, non puoi importarle direttamente in un Server Component senza avvolgere in un Client Component wrapper.

Misure di performance: cosa controllare

Bundle size: usa strumenti come next/bundle-analyzer per vedere quanto JavaScript stai inviando.
Waterfall di caricamento: Server Components riducono il tempo di primo rendering (TTFB migliora).
Interactivity: il primo input ritardato (FID) migliora con meno JS client.

In sintesi — cosa fare adesso

Controlla ogni file: se non ha hook o eventi, rimuovi 'use client'. Inizia con i componenti di presentazione.
Sposta il fetching dei dati: dai client al server. Usa async nei Server Components.
Isola l'interattività: crea componenti piccoli e focalizzati solo per la parte interattiva, lascia il resto server.
Verifica le dipendenze: se importi una libreria, controlla se è client-only. In caso, crea un wrapper.
Usa Server Actions per le form: evita API routes superflue, mantieni logica server sicura.

Per approfondire, leggi la documentazione ufficiale di Next.js sui Server Components: React Server Components.