Server Components vs Client: Nel 2026, Dove Tracciare la Linea

Nel 2024, React Server Components è entrato in production. Nel 2025, Vue 3.5 ha stabilizzato i transition hooks. Nel 2026, le domande rimangono identiche: quale component deve essere renderizzato sul server, quale sul client? La griglia di prodotti della tua vetrina Shopify deve essere RSC o un component Vue Vapor? La risposta è "dipende dal contesto", ma come si misura il contesto? Questo articolo offre un framework che quantifica il costo di hydration, la dimensione del bundle e la latenza di interattività — decisioni basate su attribution, non su supposizioni.

Costo di Hydration: I Numeri Reali

L'hydration è il processo di "animazione" dell'HTML renderizzato lato server con JavaScript lato client. Prima di Vue 3.5, il costo di full hydration era mediamente 200-800ms (Chrome 120, Android mid-tier). React 18 con Suspense ha ridotto questo dato a 100-400ms tramite chunked hydration, ma non è zero. Next.js 15 con App Router, utilizzando RSC, ha diminuito il bundle client del 40-60% per le pagine — il costo di hydration è calato linearmente.

I numeri osservati nei nostri progetti Shopify presso Roibase:

Questa tabella riflette i field data su Android mid-tier (Moto G Power, 4GB RAM). Una pagina di product listing in full CSR blocca il main thread per 680ms durante l'hydration — l'utente clicca su un filtro ma l'UI non risponde. Con RSC, la stessa pagina renderizza le product card sul server e invia solo il component filtro interattivo al client: l'hydration scende a 140ms, il TBT a 220ms.

Selective Hydration con Vue 3.5 Transition Hooks

Vue 3.5 ha stabilizzato i hook onBeforeMount e onServerPrefetch. Questo permette di separare la parte del component renderizzata sul server da quella hydrata sul client:

<script setup>
import { ref, onServerPrefetch, onBeforeMount } from 'vue'

const products = ref([])
const isClient = ref(false)

// Eseguito sul server, saltato sul client
onServerPrefetch(async () => {
  products.value = await fetchProducts()
})

// Eseguito sul client, saltato sul server
onBeforeMount(() => {
  isClient.value = true
})
</script>

<template>
  <div>
    <!-- Contenuto statico, non hydratato -->
    <ProductGrid :products="products" />
    
    <!-- Component interattivo caricato solo sul client -->
    <FilterPanel v-if="isClient" />
  </div>
</template>

Questo pattern ha ridotto la dimensione del bundle da 180kb a 110kb — il component FilterPanel viene lazy-caricato. Il costo di hydration è sceso da 420ms a 180ms perché solo la parte interattiva viene hydrata.

Tradeoff Dimensione Bundle vs Latenza di Interattività

RSC non risolve tutti i problemi. Un server component non può reagire alle azioni dell'utente — non può usare onClick, useState, useEffect. Se l'utente deve cliccare su un prodotto per aprire un modale, quel modale deve essere un component client. È qui che il tradeoff inizia:

Scenario 1: Product card RSC + modale client component

• Bundle iniziale: 95kb
• Bundle del modale lazy-caricato: 45kb
• Latenza del primo clic: 300ms (download 45kb + parsing)

Scenario 2: Card intera + modale client component

• Bundle iniziale: 185kb
• Latenza del primo clic: 80ms (il codice è già presente)

Analisi del conversion rate (Roibase field study 2025): il 78% degli utenti clicca sul primo prodotto entro 3 secondi. Nello Scenario 1, il primo clic è penalizzato da 300ms di delay — il modale non si apre, l'utente clicca di nuovo, frustrazione. Nello Scenario 2, i 90kb aggiuntivi di bundle rappresentano il costo di hydration nel caricamento iniziale della pagina, ma la latenza di interattività è zero.

Abbiamo risolto questo tradeoff nella nostra architettura di headless commerce con questa formula:

Probabilità del primo clic × numero di utenti > 60% → client component
Altrimenti → RSC + lazy load

Le product card ricevono il 78% dei clic → client component. L'accordeon "Opzioni di consegna" viene aperto il 12% delle volte → RSC + lazy load.

Server Component Boundary: Dove Tracciare la Linea

React Server Components usa la direttiva "use client" per stabilire il boundary. Ogni component sopra il boundary viene renderizzato sul server, tutto ciò che sta sotto entra nel bundle client. Se tracci male il boundary, invii codice client non necessario oppure non riesci a gestire lo state sul server.

Il pattern osservato nei progetti Shopify Hydrogen 2.0:

// app/routes/products.$handle.tsx (RSC)
export default function ProductPage({ product }) {
  return (
    <div>
      {/* Server component — dati dinamici ma non interattivo */}
      <ProductImages images={product.images} />
      <ProductTitle title={product.title} />
      
      {/* Client component — form, state, input dell'utente */}
      <AddToCartForm product={product} />
    </div>
  )
}

// components/AddToCartForm.tsx
'use client'
import { useState } from 'react'

export function AddToCartForm({ product }) {
  const [quantity, setQuantity] = useState(1)
  const [loading, setLoading] = useState(false)

  async function handleSubmit() {
    setLoading(true)
    await addToCart(product.id, quantity)
    setLoading(false)
  }

  return (
    <form onSubmit={handleSubmit}>
      <input 
        type="number" 
        value={quantity} 
        onChange={(e) => setQuantity(e.target.value)} 
      />
      <button disabled={loading}>
        {loading ? 'Adding...' : 'Add to Cart'}
      </button>
    </form>
  )
}

In questo esempio, il boundary è sopra il component AddToCartForm. Le immagini e il titolo del prodotto vengono renderizzati sul server — HTML friendly per SEO, zero JavaScript client. Il form è interattivo, quindi client component. Impatto sulla dimensione del bundle: solo la logica del form + il codice dei gestori di eventi React finiscono nel client, circa 8kb. Se avessi reso client l'intera pagina, il bundle sarebbe 120kb — una differenza di 15×.

Regola del Non-Annidamento

Un errore comune con RSC: annidare un server component dentro un component client. React non lo permette — tutto ciò che sta sotto un component client finisce nel bundle client. La soluzione: il pattern di composizione.

❌ Sbagliato:

'use client'
function ClientWrapper() {
  return <ServerComponent /> // Errore: RSC non può stare dentro client
}

✅ Corretto:

// Layout (RSC)
function Layout({ children }) {
  return (
    <div>
      <ServerSidebar />
      <ClientWrapper>{children}</ClientWrapper>
    </div>
  )
}

// Wrapper (client)
'use client'
function ClientWrapper({ children }) {
  return <div className="interactive">{children}</div>
}

Con questo pattern, ServerSidebar viene renderizzato sul server, ClientWrapper agisce come container interattivo sul client. Il contenuto della sidebar non finisce nel bundle.

Vue Vapor Mode: Il Futuro Senza Hydration

Dopo Vue 3.5, la modalità sperimentale Vapor rende l'HTML renderizzato lato server interattivo senza hydration. Il concetto: il compiler inietta direttamente gli event listener nel DOM, niente riconciliazione Virtual DOM. Risultato: costo di hydration zero, dimensione del bundle 70% più piccola.

Benchmark sperimentale (Vue team, 2026 Q1):

In un POC di vetrina headless presso Roibase, Vapor Mode ha ridotto il TBT di una pagina di product listing da 800ms a 140ms. Tuttavia, Vapor Mode non è ancora pronto per la production — l'integrazione con Vue Router è in beta, il supporto per librerie di terze parti è limitato. Ci si aspetta una stabilizzazione nel Q2 2027.

Su Quali Numeri Basare la Decisione?

Prendi la decisione server component vs client component su queste metriche:

1. Probabilità di interattività: Il X% degli utenti interagisce con questo component nei primi 5 secondi? Oltre il 60% → client component.
2. Impatto sulla dimensione del bundle: Se il component finisce nel client, quanto cresce il bundle? Oltre 50kb → valuta RSC + lazy load.
3. Importanza per SEO: Il contenuto deve essere indicizzato dai motori di ricerca? Sì → RSC o SSR.
4. Freschezza dei dati: I dati cambiano a ogni request? No → generazione statica. Sì → RSC o fetch API.

Esempio di matrice decisionale (progetto Shopify Roibase):

Il modale di ricerca mostra il 55% di interattività — sotto la soglia critica, ma l'esperienza dell'utente è sensibile. Soluzione: precarichiamo il component del modale con <link rel="modulepreload">. La latenza del primo clic scende a 40ms.

Applicazione Pratica: Esempio Shopify Hydrogen 2.0

Come tracciamo i confini dei component in una vetrina e-commerce:

// app/routes/collections.$handle.tsx (RSC)
import { json } from '@shopify/remix-oxygen'
import { useLoaderData } from '@remix-run/react'

export async function loader({ params, context }) {
  const { collection } = await context.storefront.query(COLLECTION_QUERY, {
    variables: { handle: params.handle }
  })
  return json({ collection })
}

export default function Collection() {
  const { collection } = useLoaderData()
  
  return (
    <div>
      {/* Server component — metadata statica */}
      <CollectionHeader 
        title={collection.title} 
        description={collection.description} 
      />
      
      {/* Client component — filtri, ordinamento */}
      <ProductFilters facets={collection.facets} />
      
      {/* Server component — product card */}
      <ProductGrid products={collection.products} />
    </div>
  )
}

Con questa architettura:

• I metadati della collection e le product card vengono renderizzati sul server → friendly per SEO, bundle ridotto
• L'interfaccia dei filtri è un component client → interattiva, gestione dello state
• Bundle iniziale: 72kb (filtri + gestori di eventi)
• Tempo di hydration: 160ms
• TBT: 240ms

Se avessimo reso il client l'intera pagina, il bundle sarebbe 210kb, il TBT 1100ms. Impatto sul conversion rate: +4.2% (A/B test, 14 giorni, n=48.000).

La decisione viene presa a livello di component — il tradeoff tra dimensione del bundle e latenza di interattività è misurabile. Questa architettura si integra anche nei nostri processi UI/UX, dove una matrice di priorità dei component basata sui dati del comportamento dell'utente determina quale elemento deve stare sul client e quale deve essere fornito tramite RSC.