Composants serveur vs client : tracer la bonne ligne en 2026

Les React Server Components sont passés en production en 2024. Vue 3.5 a stabilisé les hooks de transition en 2025. En 2026, les questions restent identiques : quel composant rendre sur le serveur, lequel rendre côté client ? Votre storefront Shopify doit-il utiliser RSC pour la grille de produits, ou un composant Vue Vapor ? La réponse « ça dépend du contexte » est vraie, mais comment mesurer ce contexte ? Cet article propose un framework qui quantifie le coût d'hydratation, la taille du bundle et la latence d'interactivité — pour décider sur la base d'attribution plutôt que de conjectures.

Coût d'hydratation : les vrais chiffres

L'hydratation transforme le HTML rendu côté serveur en interface interactive côté client via JavaScript. Avant Vue 3.5, le coût moyen était de 200 à 800 ms (Chrome 120, Android mid-range). Avec React 18 et Suspense, l'hydratation en chunks réduit ce chiffre à 100–400 ms, mais jamais à zéro. Avec Next.js 15 et App Router utilisant RSC, les pages voient leur bundle client diminuer de 40 à 60 % — le coût d'hydratation suit linéairement.

Les chiffres que nous avons observés chez Roibase dans les projets Shopify :

Ce tableau repose sur des données de terrain (Moto G Power, 4 Go RAM). Une page de listage de produits en CSR complet bloque le thread principal pendant 680 ms lors de l'hydratation — l'utilisateur clique sur un filtre mais l'interface ne répond pas. Avec RSC, les cartes de produits sont rendues côté serveur, seul le composant de filtre interactif est envoyé au client : l'hydratation tombe à 140 ms, TBT à 220 ms.

Hydratation sélective avec les hooks de transition de Vue 3.5

Vue 3.5 a stabilisé onBeforeMount et onServerPrefetch. Cela permet de séparer la partie du composant rendue côté serveur de celle hydratée côté client :

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

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

// S'exécute côté serveur, ignoré côté client
onServerPrefetch(async () => {
  products.value = await fetchProducts()
})

// S'exécute côté client, ignoré côté serveur
onBeforeMount(() => {
  isClient.value = true
})
</script>

<template>
  <div>
    <!-- Contenu statique non hydraté -->
    <ProductGrid :products="products" />
    
    <!-- Composant interactif chargé uniquement côté client -->
    <FilterPanel v-if="isClient" />
  </div>
</template>

Ce pattern réduit la taille du bundle de 180 kb à 110 kb — FilterPanel est chargé en lazy-load. Le coût d'hydratation baisse de 420 ms à 180 ms car seule la partie interactive est hydratée.

Compromis entre taille du bundle et latence d'interactivité

RSC ne résout pas tous les problèmes. Un composant serveur ne peut pas réagir aux actions de l'utilisateur — pas de onClick, useState, useEffect. Si l'utilisateur clique sur un produit pour ouvrir une modale, cette modale doit être un composant client. C'est ici que le compromis apparaît :

Scénario 1 : carte produit RSC + modale client

• Bundle initial : 95 kb
• Bundle modale (lazy load) : 45 kb
• Latence premier clic : 300 ms (téléchargement + parsing de 45 kb)

Scénario 2 : carte + modale en tant que composant client

• Bundle initial : 185 kb
• Latence premier clic : 80 ms (code déjà présent)

Selon notre analyse de conversion e-commerce (étude Roibase 2025) : 78 % des utilisateurs cliquent sur le premier produit dans les 3 secondes. Le scénario 1 pénalise ce premier clic avec 300 ms de délai — la modale ne s'ouvre pas, l'utilisateur reclique, frustration. Le scénario 2 ajoute 90 kb de bundle initial, ce qui se traduit par un coût d'hydratation, mais la latence d'interactivité est nulle.

Nous avons résolu ce compromis dans notre architecture headless en utilisant cette formule :

Probabilité premier clic × nombre d'utilisateurs > 60 % → composant client
Sinon → RSC + lazy load

Les cartes de produits reçoivent 78 % de clics → composant client. L'accordéon « Options de livraison » reçoit 12 % d'ouvertures → RSC + lazy load.

Limite des composants serveur : où tracer la ligne ?

React Server Components utilisent la directive use client pour définir les limites. Tout ce qui est au-dessus de la limite est rendu côté serveur, tout ce qui est en dessous entre dans le bundle client. Tracer cette limite au mauvais endroit signifie soit envoyer du code client inutile, soit être incapable de gérer l'état côté serveur.

Le pattern que nous avons observé dans les projets Shopify Hydrogen 2.0 :

// app/routes/products.$handle.tsx (RSC)
export default function ProductPage({ product }) {
  return (
    <div>
      {/* Composant serveur — données dynamiques mais non-interactif */}
      <ProductImages images={product.images} />
      <ProductTitle title={product.title} />
      
      {/* Composant client — formulaire, état, entrée utilisateur */}
      <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>
  )
}

La limite se situe au-dessus de AddToCartForm. Les images et le titre du produit sont rendus côté serveur — HTML compatible SEO, zéro JavaScript client. Le formulaire est interactif, donc composant client. Impact sur la taille du bundle : seule la logique du formulaire + les gestionnaires d'événements React vont au client, environ 8 kb. Si vous aviez rendu l'ensemble de la page comme composant client, le bundle aurait pesé 120 kb — un écart de 15×.

Règle de non-imbrication

L'erreur courante avec RSC : imbriquer un composant serveur à l'intérieur d'un composant client. React l'interdit — tout ce qui se trouve sous un composant client est inclus dans le bundle client. Solution : utiliser le pattern de composition.

❌ Incorrect :

'use client'
function ClientWrapper() {
  return <ServerComponent /> // Erreur : RSC ne peut pas être à l'intérieur d'un composant client
}

✅ Correct :

// 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>
}

Avec ce pattern, ServerSidebar est rendu côté serveur, ClientWrapper n'agit que comme conteneur interactif côté client. Le contenu de la barre latérale n'entre pas dans le bundle.

Mode Vapor de Vue : l'hydratation sans hydratation

Après Vue 3.5, le Mode Vapor expérimental rend le HTML rendu côté serveur interactif sans hydratation. Le concept : le compilateur injecte directement des écouteurs d'événements dans le DOM, pas de réconciliation du DOM virtuel. Résultat : coût d'hydratation zéro, taille du bundle 70 % inférieure.

Benchmark expérimental (équipe Vue, Q1 2026) :

Dans notre POC storefront headless avec Mode Vapor, la page de listage de produits a vu son TBT chuter de 800 ms à 140 ms. Cependant, Mode Vapor n'est pas encore production-ready — l'intégration Vue Router est en bêta, le support des bibliothèques tierces est limité. Stabilité attendue pour Q2 2027.

Sur quels chiffres fonder votre décision ?

Prenez la décision composant serveur vs composant client en vous basant sur ces métriques :

1. Probabilité d'interactivité : X % de vos utilisateurs interagissent-ils avec ce composant dans les 5 premières secondes ? Au-delà de 60 % → composant client.
2. Impact sur le bundle : Combien de kb supplémentaires si ce composant va côté client ? Au-delà de 50 kb → évaluer RSC + lazy load.
3. Importance pour le SEO : Le contenu doit-il être indexé par les moteurs de recherche ? Oui → RSC ou SSR.
4. Fraîcheur des données : Les données changent-elles à chaque requête ? Non → génération statique. Oui → RSC ou fetch API.

Exemple de matrice de décision (projet Shopify Roibase) :

La modale recherche affiche 55 % d'interactivité — sous le seuil critique, mais l'expérience utilisateur est délicate. Solution : précharger le composant modale avec <link rel="modulepreload">. La latence au premier clic tombe à 40 ms.

Application pratique : exemple Shopify Hydrogen 2.0

Comment nous traçons les limites des composants sur un storefront 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>
      {/* Composant serveur — métadonnées statiques */}
      <CollectionHeader 
        title={collection.title} 
        description={collection.description} 
      />
      
      {/* Composant client — filtrage, tri */}
      <ProductFilters facets={collection.facets} />
      
      {/* Composant serveur — cartes produit */}
      <ProductGrid products={collection.products} />
    </div>
  )
}

Cette architecture livre :

• Les métadonnées de collection et les cartes de produits rendues côté serveur → compatible SEO, bundle réduit
• L'interface de filtre comme composant client → interactivité, gestion d'état
• Bundle initial : 72 kb (filtres + gestionnaires d'événements)
• Temps d'hydratation : 160 ms
• TBT : 240 ms

Si vous aviez rendu l'ensemble de la page en CSR, le bundle aurait été 210 kb, TBT 1100 ms. Impact sur la conversion : +4,2 % (test A/B, 14 jours, n = 48 000).

La décision se prend au niveau du composant — le compromis entre taille du bundle et latence d'interactivité est mesurable. Cette architecture produit aussi une matrice de priorité des composants dans notre processus UI/UX, basée sur les données de comportement utilisateur — quel élément doit être côté client, quel élément peut être RSC ?