SSR, SSG ve CSR Performansı Nasıl Farklılaşır?

CSR'de tarayıcıya düşen yük

İstemci taraflı render'da sunucu yalnızca boş bir HTML kabuğu ve JavaScript dosyalarını gönderir. Asıl içerik, bu bundle indirilip parse edilip çalıştırıldıktan sonra tarayıcıda üretilir. Her işlem sırayla gerçekleşir: ağ isteği, parse, çalıştırma, veri isteği, DOM güncellemesi. Bu zincirin her adımı ana iş parçacığını meşgul eder.

Büyük bir JavaScript bundle söz konusu olduğunda bu sıralı akış kaçınılmaz bir gecikme yığını oluşturur. 300–500 KB ham JavaScript, parse aşamasında bile yüzlerce milisaniye ana iş parçacığını bloke edebilir. Tarayıcı hem içeriği işlemek hem de etkileşimleri yönetmek için aynı thread'i kullandığından, yoğun parse döneminde kullanıcı girişleri yanıtsız kalır. TBT ve INP bu dinamikten doğrudan beslenir.

SSR ve TTFB: sunucu süresi devreye giriyor

Sunucu taraflı render'da ilk bayt, sunucunun sayfayı oluşturup gönderdiği an ulaşır. TTFB bu nedenle sunucunun render süresini doğrudan içerir. Veritabanı sorguları, harici API çağrıları ya da hesaplama gerektiren içerikler bu süreyi uzatır; render tamamlanmadan hiçbir byte yola çıkmaz.

Tipik bir SSR sayfasında TTFB, sunucu konumu, önbellekleme durumu ve veri kaynağı yanıt süresine göre 200–800 ms arasında değişebilir. CSR'nin boş kabuk TTFB'siyle karşılaştırıldığında bu rakam yüksek görünür; ancak kullanıcının gördüğü içerik SSR'de çok daha erken hazırdır. Render süresini daraltmak için SSR genellikle sonuç önbellekleme ve streaming render tekniklerine başvurur. TTFB'nin nasıl oluştuğu ve nasıl optimize edileceği bu bağlamda ayrı bir tartışma gerektirir.

SSG'de TTFB neden farklı davranır

Statik site üretiminde HTML derleme zamanında hazırlanır, CDN'e yüklenir ve her istek doğrudan kenar sunucusundan yanıtlanır. Sunucu render adımı istek anında yoktur; bu nedenle TTFB genellikle 20–100 ms gibi değerlere düşer. Sunucu işleme gecikmesi neredeyse sıfıra yaklaşır.

SSG'nin bu avantajı içerik güncellenme sıklığıyla ters orantılı bir kısıta bağlıdır. Build alınmadan değişmeyen içerikler için ideal olan bu yaklaşım, gerçek zamanlı ya da kişiselleştirilmiş sayfalar için tek başına yeterli değildir. TTFB düşük olsa da eksik ya da bayat veri başka sorunlara kapı açar. Genel mimari tercihler ve statik sitenin hız avantajlarının kökeni önceki bir yazıda ele almıştık; burada odak nokta ölçülen metrikler.

LCP üzerinde belirleyici fark

LCP, görüntü alanındaki en büyük öğenin yüklendiği anı ölçer; bu öğe çoğunlukla bir hero görseli ya da büyük bir metin bloğudur. Her üç stratejide LCP farklı kanallardan beslenir ve farklı değerlere ulaşır.

CSR'de LCP, JavaScript bundle indirilip çalışana kadar ertelenebilir. DOM boş kabuk olduğunda tarayıcı neyi ölçeceğini bilmez; içerik JS ile eklendikten sonra ölçüm gerçekleşir. Bu gecikme zinciri, CSR'de LCP değerlerinin 3–4 saniyeye ulaşmasını kolaylaştırır. SSR'de ise LCP, HTML içinde gelen ve doğrudan tarayıcı tarafından işlenen öğeye bağlıdır; önbellekleme ve streaming ile birlikte makul değerler üretir. SSG ise hazır HTML ve CDN avantajıyla en tutarlı LCP performansını sağlar. LCP ile FCP arasındaki fark ve her birinin nasıl iyileştirildiği konusunu incelediğinizde SSG'nin bu metrikte neden öne geçtiği daha net görünür.

Hidrasyon maliyeti ve interaktivite gecikmesi

SSR ve SSG her ikisi de sunucuda veya derleme zamanında HTML üretir; bu HTML tarayıcıya ulaştığında kullanıcı içeriği görür. Ancak sayfa bu noktada interaktif değildir. Etkileşim için JavaScript'in yüklenmesi ve mevcut HTML yapısıyla eşleşmesi gerekir; bu süreç hidrasyon olarak adlandırılır.

Hidrasyon tamamlanana kadar butonlar, formlar ve dinamik bileşenler yanıt vermez. Büyük bir React ya da Vue uygulamasında bu gecikme yüzlerce milisaniye ile birkaç saniye arasında uzayabilir. Kullanıcı görsel olarak tam bir sayfa görür ama tıklamaları kuyrukta bekler. Bu durum özellikle INP üzerinde net bir baskı oluşturur: etkileşim başlatılır, yanıt gecikir ve bu gecikme metriğe doğrudan yansır.

TBT ve uzun görevler

TBT, FCP ile TTI arasında ana iş parçacığını 50 ms'yi aşan sürelerle bloke eden görevlerin toplam ağırlığını ölçer. CSR, JavaScript bundle'ı parse ve çalıştırma sırasında bu metriği en olumsuz etkileyen stratejidir; tüm sayfa mantığı istemci tarafında çalıştırılır, her görev ana thread üzerinde baskı kurar.

SSR ve SSG'de de JavaScript yüklenmesi gerekir; ancak içerik zaten HTML'de geldiğinden JS bağımlılığı daha seçici tutulabilir. Sayfa içerik açısından çalışır durumdayken JavaScript kademeli olarak yüklenebilir. Bununla birlikte büyük bir bundle SSR/SSG sayfalarında da TBT'yi yükseltir; stratejinin tek başına bu metriği çözmediğini göz önünde bulundurmak gerekir. Ana iş parçacığı blokajını azaltma yöntemleri ve Long Task kavramı bu konuyu derinlemesine ele alır.

INP açısından üç render stratejisi

INP, kullanıcının bir etkileşim başlatmasından tarayıcının bir sonraki çerçeveyi boyamasına kadar geçen süreyi ölçer. Ana iş parçacığının ne kadar meşgul olduğu bu metriği doğrudan belirler; uzun görevler kuyruğa girmek zorunda kalan etkileşimlerin geciktirilmesine yol açar.

CSR sayfalarında yoğun JavaScript çalıştırma INP'yi baskı altına alır; özellikle etkileşim sırasında arka planda başka görevler de çalışıyorsa sorun derinleşir. SSR sayfaları hidrasyon tamamlandıktan sonra CSR ile benzer bir INP tablosuna sahip olabilir; hidrasyon süresince ise etkileşimler kuyrukta bekler ve bu bekleme INP'ye yansır. SSG de hidrasyon sorununu yaşar; ancak genellikle daha az dinamik içerik barındırdığından toplam JavaScript yükü çoğunlukla daha düşüktür. INP'nin ne anlama geldiğini ve nasıl ölçüldüğünü ayrıca inceleyebilirsiniz.

Veri bağımlılığının render süresine katkısı

Her üç stratejide verinin nereden ve ne zaman alındığı performans profilini kökten değiştirir. SSR'de veri istek anında sunucudan çekilir; sunucu ile veri kaynağı arasındaki gecikme doğrudan TTFB'ye eklenir. Tek bir yavaş API çağrısı tüm sayfayı bloke edebilir; sonuç kullanıcıya gelmeden önce her şeyin hazır olması gerekir.

CSR'de veri tarayıcıdan istenir; bu bir waterfall oluşturur. Önce boş HTML, ardından JavaScript, ardından veri isteği, ardından render. Her adım öncekini bekler ve gecikme katlanır. SSG'de ise veri build anında çekilir ve statik HTML içine gömülür; istek zamanında ayrı bir veri çekimi olmaz. Statik içerik için bu yaklaşım veri gecikmesini tamamen sıfırlar, ancak güncel kalmak için yeni bir build gerektirir.

Cascade waterfall: CSR'nin görünmez yükü

CSR'nin en kritik performans sorunu tek bir gecikme değil, gecikmelerin birikimli yapısıdır. Tarayıcı önce HTML'yi alır, ardından JavaScript referanslarına ulaşır, bu dosyaları indirir ve parse eder, uygulama başladıktan sonra API çağrıları yapar, yanıtları bekler ve son olarak DOM'u günceller. İçerik en sona kalır.

Bu akış herhangi bir adımda yavaşlarsa sonraki her adım da gecikir; bant genişliği düşük ya da ağ gecikmesi yüksekse waterfall etkisi katlanarak büyür. 3 saniyeyi aşan LCP değerleri çoğunlukla bu birikimli zincirin ürünüdür. SSR ve SSG bu zinciri kısaltır; ilk yanıt içeriği zaten taşıdığından veri isteği adımı istemci tarafında kritik içerik için tekrar edilmez.

Kısmi hidrasyon ve adacık mimarisinin katkısı

Hidrasyon maliyetini azaltmak için geliştirilen yaklaşımların başında kısmi hidrasyon gelir. Tüm sayfayı değil, yalnızca etkileşim gerektiren bileşenleri hidrate etmek, geri kalanı statik HTML olarak bırakmak hem TBT hem de INP üzerinde olumlu etki yaratır. Kullanıcıya teslim edilen JavaScript miktarı da bu sayede önemli ölçüde düşebilir.

Adacık mimarisi bu fikri daha ileri taşır: sayfanın büyük bölümü statik, belirli "adacıklar" dinamiktir ve yalnızca bu bölümler JavaScript alır. Astro gibi çerçeveler bu modeli doğrudan destekler. SSG'yi temel alan bu yaklaşım, düşük TTFB ve erken LCP avantajlarını korurken INP sorununu da minimize eder. Mimari karmaşıklığı artırsa da içerik ağırlıklı siteler için ciddi bir performans getirisi sunar.

Streaming render ve ilk içerik geliş süresi

SSR'nin TTFB dezavantajını dengeleme yöntemlerinden biri streaming render'dır. Sunucu sayfanın tamamını hazırlamadan önce HTML'yi parça parça göndermeye başlar; tarayıcı ilk veriyle render etmeye başlar, geri kalanı akarken FCP erkene çekilir. Kullanıcı beklerken boş bir sayfa yerine kısmi içerik görür.

React 18 ile gelen Server Components modeli bu yaklaşımı daha da ayrıştırır: bileşen bazında sunucu/istemci ayrımı yapılır, yalnızca gerekli JavaScript istemciye gönderilir. Bu teknikler SSR'nin TTFB sorununu tamamen ortadan kaldırmaz ama FCP ve LCP için görünür iyileşme sağlar; gönderilen JavaScript miktarını azaltarak TBT üzerinde de olumlu etki yaratır.

Hangi metrik hangi stratejiyi öne çıkarır

Strateji seçiminin performans metriklerine yansıması tutarlı bir örüntü izler. TTFB açısından SSG en avantajlı noktadadır; CDN'den gelen statik dosya sunucu işleme adımını ortadan kaldırır. SSR makul TTFB değerleri üretebilir ama veri bağımlılıklarına göre değişkenlik gösterir. CSR boş kabuk teslimi nedeniyle düşük TTFB görüntüler; ancak bu rakam yanıltıcıdır çünkü içerik henüz gelmemiştir.

LCP'de SSG ve optimize edilmiş SSR genel olarak CSR'yi geride bırakır; CSR'nin içerik üretmesi için sıralı adımların tamamlanması gerektiğinden fark burada belirginleşir. TBT'de JavaScript bundle boyutu belirleyicidir; strateji tek başına değil, gönderilen JS miktarı da sorumludur. INP'de ise hidrasyon maliyeti ve ana iş parçacığı yoğunluğu birlikte etkili olur. CSR ile tam hidrasyonlu SSR/SSG benzer zorluklarla karşılaşabilir; kısmi hidrasyon veya adacık mimarisi bu noktada ayrışmayı sağlar.

Ne zaman hangi strateji

SSG; içerik güncellenmesi seyrek olan, kişiselleştirme gerektirmeyen ve geniş kitleye ulaşmak isteyen sayfalar için tutarlı performans sunar. Blog yazıları, dokümanlar ve pazarlama sayfaları bu kategoriye girer. Büyük içerik kataloglarında build süresi yönetim karmaşıklığı getirir; artımlı build desteği bu noktada kritik hale gelir.

SSR; içeriğin istek anında kişiselleştirildiği, kullanıcı oturumu veya gerçek zamanlı veri gerektiren sayfalar için anlamlıdır. Önbellekleme stratejisiyle birleştirildiğinde TTFB dezavantajı önemli ölçüde giderilebilir. Ürün sayfaları, arama sonuçları ve hesap panelleri bu profille örtüşür.

CSR; uygulamanın büyük bölümü kimlik doğrulaması arkasındaysa, SEO öncelik değilse ve sık değişen etkileşimli arayüzler söz konusuysa tercih edilir. Dashboard'lar ve web uygulamaları tipik CSR alanlarıdır. Ancak public SEO gerektiren hiçbir sayfa için CSR tek başına yeterli değildir; JavaScript olmadan içerik tarayıcıda görünemez.