Server Components vs Client: 2026'da Doğru Çizgiyi Çizmek

2024'te React Server Components production'a girdi. 2025'te Vue 3.5 transition hooks'u stable oldu. 2026'da sorular hâlâ aynı: hangi component server'da render edilmeli, hangisi client'ta? Shopify storefront'unuzda product grid RSC olmalı mı, Vue Vapor component mi? Cevap "bağlama göre değişir" ama bağlam nasıl ölçülür? Bu yazı hydration cost, bundle size ve interactivity latency'sini sayısal hale getiren bir framework sunuyor — karar verirken tahmin yerine attribution.

Hydration Cost: Gerçek Sayılar

Hydration server-side HTML'i client-side JS ile "canlandırma" işlemidir. Vue 3.5 öncesi full hydration cost ortalama 200-800ms (Chrome 120, mid-tier Android). React 18'de Suspense ile chunked hydration bu rakamı 100-400ms'ye düşürdü ama sıfır değil. Next.js 15'te App Router ile RSC kullanılan sayfalar client bundle'ı %40-60 azalttı — hydration cost lineer olarak düştü.

Roibase Shopify projelerinde gözlemlediğimiz sayılar:

Bu tablo Mid-tier Android (Moto G Power, 4GB RAM) üzerinde field data. Full CSR product listing sayfası hydration sırasında main thread'i 680ms bloke ediyor — kullanıcı filter'a tıklıyor ama UI yanıt vermiyor. RSC ile aynı sayfa product card'larını server'da render ediyor, sadece interaktif filter component'ini client'a gönderiyor: hydration 140ms'ye düşüyor, TBT 220ms.

Vue 3.5 Transition Hooks ile Selective Hydration

Vue 3.5 onBeforeMount ve onServerPrefetch hook'larını stable yaptı. Bu sayede component'in server'da render edilen kısmı ile client'ta hydrate edilen kısmı ayrıştırılabiliyor:

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

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

// Server'da çalışır, client'ta skip edilir
onServerPrefetch(async () => {
  products.value = await fetchProducts()
})

// Client'ta çalışır, server'da skip edilir
onBeforeMount(() => {
  isClient.value = true
})
</script>

<template>
  <div>
    <!-- Static içerik hydrate edilmez -->
    <ProductGrid :products="products" />
    
    <!-- İnteraktif component sadece client'ta yüklenir -->
    <FilterPanel v-if="isClient" />
  </div>
</template>

Bu pattern bundle size'ı 180kb'den 110kb'ye düşürdü — FilterPanel component'i lazy load ediliyor. Hydration cost 420ms'den 180ms'ye indi çünkü sadece interaktif kısım hydrate ediliyor.

Bundle Size vs Interactivity Latency Tradeoff'u

RSC her sorunu çözmüyor. Server component user action'a tepki veremez — onClick, useState, useEffect kullanamaz. Kullanıcı product'a tıkladığında modal açılacaksa o modal client component olmalı. Bu noktada tradeoff başlıyor:

Senaryo 1: Product card RSC + modal client component

• Initial bundle: 95kb
• Modal lazy load bundle: 45kb
• İlk tıklama latency: 300ms (45kb download + parse)

Senaryo 2: Tüm card + modal client component

• Initial bundle: 185kb
• İlk tıklama latency: 80ms (kod zaten var)

E-commerce conversion rate analysis (Roibase 2025 field study): %78 kullanıcı ilk product'a 3 saniye içinde tıklıyor. Senaryo 1'de ilk tıklama 300ms delay ile cezalandırılıyor — modal açılmıyor, kullanıcı tekrar tıklıyor, frustration. Senaryo 2'de 90kb fazla bundle ilk sayfa yüklemesinde hydration cost olarak dönüyor ama interactivity latency sıfır.

Bu tradeoff'u headless commerce mimarimizde şu formülle çözdük:

İlk tıklama olasılığı × kullanıcı sayısı > 60% → client component
Aksi halde → RSC + lazy load

Product card'lar %78 tıklama alıyor → client component. "Delivery options" akordiyon %12 açılıyor → RSC + lazy load.

Server Component Boundary: Nerede Çizgi Çekilir?

React Server Components "use client" directive ile boundary belirliyor. Boundary'nin üstündeki her component server'da render ediliyor, altındaki her şey client bundle'ına gidiyor. Boundary çizgisini yanlış çekerseniz ya gereksiz client kodu gönderiyor ya da server'da state yönetemiyorsunuz.

Shopify Hydrogen 2.0 projelerinde gözlemlediğimiz pattern:

// app/routes/products.$handle.tsx (RSC)
export default function ProductPage({ product }) {
  return (
    <div>
      {/* Server component — dynamic data ama interaktif değil */}
      <ProductImages images={product.images} />
      <ProductTitle title={product.title} />
      
      {/* Client component — form, state, user input */}
      <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>
  )
}

Bu örnekte boundary AddToCartForm component'inin üstünde. Product görselleri ve başlık server'da render ediliyor — SEO-friendly HTML, sıfır client JS. Form interaktif olduğu için client component. Bundle size impact: sadece form logic + React event handler kodu client'a gidiyor, yaklaşık 8kb. Alternatif olarak tüm sayfayı client component yaparsanız bundle 120kb olur — 15× fark.

Nest Etmeme Kuralı

RSC kullanırken yaygın hata: client component içine server component nest etmek. React buna izin vermiyor — client component'in altındaki her şey client bundle'ına gider. Çözüm: composition pattern.

❌ Yanlış:

'use client'
function ClientWrapper() {
  return <ServerComponent /> // Hata: RSC client içinde olamaz
}

✅ Doğru:

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

Bu pattern ile ServerSidebar server'da render ediliyor, ClientWrapper sadece interaktif kapsayıcı olarak client'ta çalışıyor. Sidebar içeriği bundle'a gitmiyor.

Vue Vapor Mode: Hydration'sız Gelecek

Vue 3.5 sonrası deneysel Vapor Mode server-side rendered HTML'i hydration olmadan interaktif hale getiriyor. Konsept: compiler DOM'a directly event listener inject ediyor, Virtual DOM reconciliation yok. Sonuç: hydration cost sıfır, bundle size %70 düşük.

Deneysel benchmark (Vue team, 2026 Q1):

Roibase headless storefront POC'sinde Vapor Mode ile product listing sayfası TBT 800ms'den 140ms'ye düştü. Ancak Vapor Mode henüz production-ready değil — Vue Router entegrasyonu beta, third-party kütüphane desteği sınırlı. 2027 Q2'de stable bekleniyor.

Kararı Hangi Sayılara Dayanarak Vermelisiniz?

Server component vs client component kararını şu metriklerle alın:

1. Interactivity olasılığı: Kullanıcıların %X'i bu component'le ilk 5 saniyede etkileşime giriyor mu? %60 üstü → client component.
2. Bundle impact: Component client'a gittiğinde bundle size kaç kb artıyor? 50kb üstü → RSC + lazy load değerlendir.
3. SEO önemi: İçerik search engine'ler tarafından indexlenmeli mi? Evet → RSC veya SSR.
4. Data freshness: Veri her request'te değişiyor mu? Hayır → static generation. Evet → RSC veya API fetch.

Örnek karar matrisi (Roibase Shopify projesi):

Search modal %55 interactivity gösteriyor — kritik eşik altı ama kullanıcı deneyimi hassas. Çözüm: modal component'i <link rel="modulepreload"> ile önceden yüklüyoruz. İlk tıklama latency 40ms'ye düşüyor.

Pratik Uygulama: Shopify Hydrogen 2.0 Örneği

Bir e-commerce storefront'ta component boundary'lerini nasıl çizdiğimiz:

// 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 — static metadata */}
      <CollectionHeader 
        title={collection.title} 
        description={collection.description} 
      />
      
      {/* Client component — filtering, sorting */}
      <ProductFilters facets={collection.facets} />
      
      {/* Server component — product cards */}
      <ProductGrid products={collection.products} />
    </div>
  )
}

Bu mimari ile:

• Collection metadata ve product card'lar server'da render ediliyor → SEO-friendly, bundle size düşük
• Filter UI client component → interaktif, state yönetimi var
• Initial bundle: 72kb (filters + event handlers)
• Hydration time: 160ms
• TBT: 240ms

Alternatif olarak tüm sayfayı CSR yapsaydık bundle 210kb, TBT 1100ms olacaktı. Conversion rate impact: %4.2 artış (A/B test, 14 gün, n=48,000).

Karar component seviyesinde alınıyor — bundle size ve interactivity tradeoff'u ölçülebilir. Bu mimari UI/UX süreçlerimizde de kullanıcı davranışı verisine dayalı component priority matrisi üretiyor — hangi element client'ta olmalı, hangi element RSC ile sunulmalı?