Client JS bundle boyutu
RSC lehine en güçlü, ölçülebilir argüman burada. react.dev'in kendi örneği: markdown render eden statik bir sayfa, Server Component olmadan marked + sanitize-html kütüphanelerinin 75K gzip'li ekstra bundle'ını client'a gönderiyor; Server Component ile bu kütüphaneler hiç client bundle'a girmiyor, yalnız render edilmiş HTML gidiyor. Ancak sınır net değil: 'use client' bir dosyayı işaretlediğinde o dosyanın TÜM transitive import'ları client bundle'a dahil oluyor — yani sınırı yanlış çizmek (büyük bir wrapper'a 'use client' koymak) kazancı sessizce yok edebilir.
Client-first SPA'da (Vite tabanlı projelerde) ise bundle zaten tek parça bir uygulama mantığına yakındır; Next.js'in Turbopack chunking analizi bunun tam da neden sorunlu olduğunu gösteriyor: tek chunk her sayfada gereksiz kod taşır, sayfa-başı chunk paylaşılan kodu (ör. footer) tekrar tekrar indirtir, modül-başı chunk ise yüzlerce network isteği yaratır. Turbopack bu üçünü chunk-group + navigasyon-olasılığı ağırlıklandırmasıyla birleştiriyor — bu optimizasyon RSC'den bağımsız, saf client bundle sorunu; yani SPA tarafı da bu problemi framework tooling'iyle (Vite'ın Rollup code-splitting'i dahil) çözmek zorunda.
LCP / TTI ve ilk yükleme davranışı
Next.js dokümantasyonuna göre ilk yükte sıra HTML → RSC Payload → JS hydration şeklinde işliyor — yani kullanıcı JS hiç çalışmadan anlamlı HTML görüyor. Saf client-side SPA'da ise ilk yük genelde boş <div id="root"> + JS bundle indirilip çalışana kadar boş ekran/skeleton'dur; bu yüzden TTI ile FCP birbirine yakınsar (JS olmadan hiçbir şey görünmez).
Next.js 16.3, bu ikisini birbirine yaklaştırmaya çalışıyor: Instant Navigations paketiyle server-driven modelin avantajlarını kaybetmeden client-driven SPA'nın duyarlılığını (responsiveness) hedefliyor — bu, sektörün RSC ile SPA arasındaki LCP/TTI farkının hâlâ gerçek ve aktif çözülmeye çalışılan bir problem olduğunun resmi kanıtı. React 19.2'nin <Activity> bileşeni de aynı boşluğu React seviyesinde kapatıyor: navigasyon öncesi hedef sayfayı arka planda hazırlayıp (data/css/image preload) 'hidden' tutarak, SPA'daki anlık geçiş hissini server-driven mimaride simüle ediyor. Buna karşılık, React 19.3 (9 Eylül 2026) View Transitions API'sini React'e taşıyarak client-first tarafında da benzer akıcı geçişleri framework'ten bağımsız hale getirdi — yarış tek yönlü değil, iki taraf da birbirinin avantajını kopyalıyor.
RSC payload (flight) boyutu ve serileştirme tuzakları
Bu, kriterler arasında en teknik ve en riskli olanı. Resmi kaynak doğruluyor: 'use client' sınırından geçen değerler ya React component ya da desteklenen serileştirilebilir prop değerleri olmalı, aksi halde React exception fırlatıyor — yani tip güvenliği derleme zamanında değil, çoğunlukla çalışma zamanında yakalanıyor. Server Components sayfası ayrıca RSC Payload'ın neyi içerdiğini tanımlıyor: render edilmiş Server Component sonucu, Client Component placeholder'ları, JS dosya referansları ve Server'dan Client'a geçen props.
Pratik sonuç: bir DB satırını olduğu gibi client component'e prop olarak geçirmek, o objenin kullanılan her alanını flight payload'a yazdırır — objeyi sunucuda daraltıp yalnız gereken alanları geçirmek gerekiyor. Client-side SPA'da böyle bir 'payload serileştirme' katmanı yok — state doğrudan JS objesi olarak tarayıcıda yaşıyor, bu tuzak da yok, ama karşılığında her state client'ta yeniden hesaplanıyor veya ayrıca fetch ediliyor. Ayrıca RSC'nin alttaki API'leri React minörleri arasında semver izlemiyor — framework/bundler spesifik sürüme pinlenmek zorunda, bu da versiyon yükseltmelerini SPA'ya göre daha kırılgan yapıyor.
Veri çekme modeli ve waterfall riski
react.dev'in Note/Author örneği klasik SPA waterfall'ını gösteriyor: Note component useEffect ile fetch ediyor, o bitince Author component kendi useEffect'inde ikinci bir fetch başlatıyor — sıralı, yavaş. Server Component versiyonunda ikisi de await ile sunucuda, veri kaynağına yakın, doğrudan render sırasında okunuyor; RSC mimarisi bunu server-centric request/response modeliyle client-centric SPA'nın interaktifliğini birleştiren yeni bir mimari olarak tanımlıyor.
Ancak bu avantaj yalnızca sunucu tarafı ilk render için tam geçerli — client-side navigasyonlarda RSC Payload prefetch/cache ediliyor ve Client Component'lar tamamen client'ta, sunucu HTML'i olmadan render ediliyor. Yani 'waterfall'ı öldürme' argümanı en çok ilk sayfa yükünde, ISR/SSR sayfalarında güçlü; saf client route navigasyonlarında SPA ile RSC arasındaki fark küçülüyor. Next.js'in ISR mekanizması da bunu destekliyor: revalidate süresi dolunca eski (stale) sayfa anında servis edilirken arka planda yeniden üretiliyor — yüksek revalidate (ör. 1 saat) önerilerek waterfall riski daha da azaltılıyor.
İnteraktivite sınırı: 'use client' sınırının nereye çekildiği
Bu, RSC mimarisinde en çok mühendislik kararı gerektiren nokta. Kural açık: bir modül 'use client' ile işaretlenince o modül ve tüm transitive bağımlılıkları client'ta çalışır; ama Next.js ayrıca büyük UI parçalarını değil, spesifik interaktif bileşenleri işaretlemeyi tavsiye ediyor — örnek olarak bir <Layout> içindeki sadece <Search /> bileşenini client yapmak, geri kalan statik logo/nav'ı server'da bırakmak. Server Component'lar context oluşturamaz ve useState gibi interaktif API kullanamaz; React context da Server Component'ta desteklenmiyor.
Client-side SPA'da böyle bir sınır yok — her component varsayılan olarak interaktif olabilir, karar mimari değil, kullanım anında verilir. Bu basitlik, RSC'nin öğrenme eğrisini ve kod-inceleme yükünü artıran asıl sebep: yeni bir ekip üyesi 'bu component nerede çalışıyor, hangi API'leri kullanabilirim' sorusuyla RSC'de sürekli karşılaşırken, SPA'da bu soru hiç sorulmuyor.
Framework bağımlılığı ve güvenlik yüzeyi
RSC'yi benimsemek, pratikte bir framework'e (çoğunlukla Next.js App Router) bağımlı olmak demek — RSC alttaki API'leri semver izlemediği için doğrudan React üzerine kendi RSC bundler'ını yazmak önerilmiyor. Bu bağımlılığın somut bedeli var: 3 Aralık 2025'te RSC'de kritik bir unauthenticated RCE açığı bulundu (React 19.0.1/19.1.2/19.2.1 ile yamalandı), 11 Aralık 2025'te ek DoS ve kaynak kodu ifşası açıkları kapatıldı; Next.js da ayrıca 25 Ağustos 2026'da 16.3.3 ve 15.5.24 sürümlerinde iki Critical önem dereceli açık kapattı — ikisi de RSC'ye özgü değil (AVIF image-optimization ve Windows-hosted RCE) ama framework bakım yükünün örneği.
Client-side SPA'da (Vite + React Router v7) RSC'yi açmadığın sürece bu sunucu-tarafı bundler yüzeyi devreye girmiyor — dikkat et, resmi duyuru RSC kullanıldığında react-router ve @vitejs/plugin-rsc'yi de etkilenen sayıyor; RSC'siz saf SPA'da saldırı yüzeyi klasik REST/GraphQL API güvenliğine iniyor. Karşılığı var: React Router v7'nin RSC desteği hâlâ deneysel, yani SPA'da RSC'nin bundle/LCP kazanımlarından tam yararlanamıyorsun. Özetle: RSC = daha güçlü kazanç, daha büyük bakım/güvenlik yükümlülüğü; SPA = daha az kazanç, daha sade bakım yüzeyi.
Cache / ISR ile etkileşim ve ekip öğrenme eğrisi
Next.js'in ISR (Incremental Static Regeneration) mekanizması RSC ile doğal olarak entegre çalışıyor: revalidate süresi dolunca istek eski (stale) sayfayı anında alırken arka planda yeni sürüm üretiliyor; resmi doküman yüksek revalidate süresi (1 saniye yerine 1 saat gibi) öneriyor. Bu, RSC'nin cache katmanıyla derin entegrasyonunun bir sonucu — Partial Prefetching ve Instant Insights (Next.js 16.3) da aynı cache-first felsefeyi navigasyon deneyimine taşıyor.
Client-side SPA'da cache katmanı genelde ayrı bir kütüphaneye (TanStack Query gibi) devredilir — framework kendisi bir cache stratejisi dayatmaz, ekip kendi cache invalidation kurallarını yazar. Öğrenme eğrisi açısından bu iki yaklaşım taban tabana zıt: RSC ekibi framework'ün cache/ISR sözleşmesini öğrenmek zorunda (ne zaman revalidate olur, hangi veri statik hangi veri dinamik), SPA ekibi ise kendi cache kütüphanesini seçip yapılandırmak zorunda. İkisi de 'ücretsiz' değil — sadece öğrenme yükü farklı yerde: RSC'de framework sözleşmesinde, SPA'da kütüphane seçimi ve yapılandırmasında.