Bir sayfanın nasıl üretildiği, kullanıcının ekranında ne gördüğünden çok önce biter. Sunucu, build süreci veya her ikisi birden devreye girer; çıkan HTML ya önbellekte bekler, ya her istekte yeniden yazılır, ya da ikisi arasında bir süreye bağlanır. SSR (Server-Side Rendering), SSG (Static Site Generation) ve ISR (Incremental Static Regeneration) bu üretim anını farklı biçimlerde yönetir - ve aralarındaki fark, doğru bağlamda kullanılmadığında hem performansı hem operasyonel maliyeti olumsuz etkiler.

Üç stratejinin de geçerli olduğu durumlar var. Hiçbiri evrensel doğru değil. Karar, içeriğin ne sıklıkla değiştiğine, sayfanın kullanıcıya özgü veri taşıyıp taşımadığına ve ilk bayt süresine (TTFB) verdiğiniz önem derecesine göre şekillenir. Bununla birlikte bu değişkenlerin her biri tek başına yeterli değil; üçü birlikte bir karar ağacı oluşturur.

Mimari seçimler genellikle projenin başında yapılır ve sonradan değiştirmek maliyet doğurur. Stratejiyi belirleyen soruları baştan sormak, gereksiz yeniden yapılandırmaların önüne geçer.

Üretim Zamanı: Üç Stratejinin Temel Farkı

SSG, HTML'yi build anında üretir. Sayfa bir kez derlenir ve bir CDN üzerinden statik dosya olarak sunulur. İstek geldiğinde sunucu tarafında hesaplama yoktur; TTFB milisaniyeler içinde kalabilir. Bedeli, içeriğin bir sonraki build'e kadar sabit kalmasıdır.

SSR, HTML'yi her HTTP isteğinde o an için üretir. Veritabanı sorgusu, oturum bilgisi veya kullanıcıya özgü içerik sayfaya bu aşamada eklenir. Esneklik artar, ancak her istek için sunucu kaynağı harcanır ve TTFB sunucu yanıt süresiyle doğrudan bağlantılıdır.

ISR, SSG'nin önbellek mantığını zamanla sınırlar. Build sonrası belirlenen bir süre dolduğunda - 60 saniye, 5 dakika veya 24 saat - bir sonraki istek yeni bir HTML üretimini tetikler. Eski sayfa o istek için sunulmaya devam eder, arka planda yeni sürüm hazırlanır. Stale-while-revalidate mantığıdır; güncel içerik ile hızlı yanıt arasında bir orta yol.

SSG zamanı build'e taşır, SSR zamanı request'e taşır, ISR ikisi arasında bir denge kurar. Bu denge her zaman avantaj değildir: bazı projelerde ISR'ın getirdiği karmaşıklık, sağladığı faydayı geçebilir.

SSG'nin Tartışmasız Çalıştığı Durumlar

İçerik değişmiyorsa veya nadiren değişiyorsa SSG'yi tercih etmek mantıklıdır. Belgeleme siteleri, blog yazıları, pazarlama sayfaları ve fiyatlandırma tabloları bunların başında gelir. Günde birkaç kez güncellenen içerik bile SSG ile yönetilebilir; bir CI/CD pipeline her commit'te veya belirli aralıklarla yeniden build başlatabilir.

SSG'nin performans avantajı, önbelleğin ne kadar temiz tutulabileceğiyle doğrudan ilişkilidir. Sayfa değişmediği sürece CDN aynı HTML'yi tekrar tekrar sunar ve sunucu hiç meşgul olmaz. Statik bir varlık olarak sunulan bir HTML dosyası, bir veritabanı sorgusu içeren SSR yanıtından her koşulda daha hızlı yanıt verir - bu fark ağ durumuna ve sunucu yüküne göre 100 ms ile 400 ms arasında değişebilir.

SSG işe yaramaz mı? Kullanıcıya özel içerik geldiğinde. Oturum açmış kullanıcının adını, sepet içeriğini veya kişiselleştirilmiş önerileri HTML içine build anında yazamazsınız - çünkü o anın kullanıcısı belli değildir. Bu bilgiler ya client-side JavaScript ile sonradan yüklenir ya da SSR devreye girer. Eğer kişiselleştirilmiş içerik sayfanın küçük bir parçasıysa, sayfa iskeletini statik bırakıp sadece o parçayı istemci tarafından çekmek daha ekonomik bir yaklaşım olabilir.

SSR'ın Kaçınılmaz Olduğu Senaryolar

Gerçek zamanlı veri. Kullanıcıya özel içerik. Oturum bağımlı sayfalar. Bu üçü bir arada geldiğinde SSR'dan başka seçenek kalmaz.

Bir kullanıcının dashboard'u, o kullanıcının veritabanındaki veriye bağlıdır. Sayfa build anında üretilemez, önbellekte tutulamaz; her istek, o kullanıcıya ait veriyle yeniden üretilmek zorundadır. Aynı durum ödeme özeti sayfaları, hesap ayarları ve kişiselleştirilmiş içerik akışları için de geçerlidir.

SSR'ın maliyeti TTFB'ye doğrudan yansır. Sunucu, veritabanını sorgulamadan önce yanıt üretemez; sorgu süresi, ağ gecikmesi ve sunucu yükü kullanıcıya etki eder. SSR sayfalarını sadece gerektiği yerlerde tutmak, gerekmediği sayfaları statik seçeneklere taşımak iyi bir mimari karardır.

Aynı uygulama içinde her iki stratejiyi birden kullanmak yaygın ve mantıklıdır. Ana sayfa statik, kullanıcı profil sayfası SSR - çoğu modern framework bu karma yapıyı destekler. Next.js'te her sayfa dosyası kendi render stratejisini ayrı ayrı belirleyebilir; bu esneklik, gereksiz SSR kullanımını önlemenin en pratik yoludur.

ISR Nerede Devreye Girer, Nerede Yanıltıcı Olur?

ISR'ın kullanım alanı şu soruyla başlar: içerik periyodik olarak değişiyor, ama her istekte yeniden üretmek fazla pahalı mı?

E-ticaret kategori sayfaları bunun somut bir örneğidir. Sayfada ürün fiyatları, stok durumları ve sıralamalar değişir - ama her saniye değil. Beş dakikada bir yenilenen bir ISR önbelleği, hem makul ölçüde güncel hem de performanslı bir sayfa sunar. Aynı sayfayı SSR ile her istekte üretmek, yüksek trafikte veritabanı üzerinde ciddi yük oluşturabilir.

ISR'ın yanıltıcı olduğu durum, güncelliğin kritik olduğu yerdir. Borsa verileri, canlı sonuçlar, anlık stok bilgisi - bunları ISR ile sunarsanız kullanıcılar eski veri görür. Yenileme aralığını çok kısaltırsanız, örneğin 10 saniyeye indirirseniz, SSG'nin temel avantajı olan önbellek tutarlılığı kaybolur; SSR kadar kaynak harcarsınız ama SSR'ın sağladığı anlık güncellik garantisine de sahip olmazsınız.

ISR'ın bir başka sınırı, önbelleğin geçersiz kılınmasıyla ilgilidir. Belirli bir içerik parçası değiştiğinde yalnızca o sayfanın önbelleğini temizlemek için ekstra altyapı gerekir. Next.js'teki revalidatePath veya revalidateTag gibi API'ler bu işlemi kolaylaştırır, ama yine de operasyonel bir maliyet taşır. Bunu görmezden gelerek kurulan ISR yapıları, zamanla stale içerik sorunlarına yol açabilir.

TTFB Dengesi: Hangisi Ne Kadar Hızlı?

Doğrudan bir sıralama yapılacak olursa: SSG en düşük TTFB'yi verir, iyi yapılandırılmış ISR bunu yakın takip eder, SSR en yüksek olabilir - ama bu sıralama koşulsuz değildir.

SSG sayfaları CDN edge'den sunulduğunda TTFB 20-50 ms civarında kalabilir. Sunucu hesaplama yoktur; dosya doğrudan teslim edilir. ISR sayfaları için önbellekten sunulan yanıt benzer bir hıza ulaşır; yalnızca önbellek yenilenirken kısa bir gecikme oluşur ve bu gecikme yalnızca yenilemeyi tetikleyen tek istek için geçerlidir, diğer kullanıcılar eski önbellekten yanıt almaya devam eder.

SSR'da TTFB, sunucu işlem süresine bağlıdır. Basit bir veritabanı sorgusu 20-30 ms alabilir; karmaşık bir aggregation veya birden fazla servis çağrısı bu süreyi 300 ms'nin üzerine taşıyabilir. SSR sayfası için CDN önbelleği kullanmak mümkündür, ancak kullanıcıya özel içerik varsa önbellekten yararlanılamaz.

TTFB tek başına yeterli bir metrik değildir. Bir sayfa 50 ms'de TTFB verip büyük bir JavaScript bundle yükleyerek client-side veri çekiyor olabilir; gerçek kullanıcı deneyimi o zaman kötüdür. Render stratejisi belirlenirken TTFB ile birlikte LCP (Largest Contentful Paint) ve INP (Interaction to Next Paint) de gözetilmelidir. SSG ile elde edilen hızlı TTFB, client-side hydration maliyetiyle silinebilir.

Karar Soruları: Hangisini Seçmeli?

Doğru strateji, genellikle üç soruya verilen yanıttan çıkar.

İçerik ne sıklıkla değişiyor? Değişmiyorsa veya bir CI tetikleyebilecek kadar nadirse SSG yeterlidir. Düzensiz aralıklarla ve çok sayıda sayfaysa ISR iyi bir seçenektir. Her istekte veya kullanıcıya özelleşmişse SSR kaçınılmazdır.

Sayfa kullanıcıya özgü veri taşıyor mu? Taşıyorsa SSR. Taşımıyorsa SSG veya ISR değerlendirilebilir.

Yüksek trafikte sunucu maliyeti kritik mi? Öyleyse statik veya ISR'ı tercih edin; SSR her istek için kaynak harcar ve trafik büyüdükçe bu maliyet doğrusal olarak artar.

Birkaç sınır durum da vardır. Sayfanın büyük bölümü statik, küçük bir kısmı kişiselleştirilmişse "partial hydration" veya "islands architecture" daha iyi bir seçenek olabilir - sayfa iskeleti statik kalır, kişiselleştirilmiş parça client-side render edilir. Başka bir sınır durum: içeriğin güncelliği önemli ama saniye hassasiyetinde değilse, ISR yenileme aralığını dikkatli ayarlamak yeterlidir. Yenileme aralığını iş gereksiniminden değil teknik alışkanlıktan belirlemek, ISR'ın en yaygın hata modelidir.

Framework Desteği ve Strateji Geçişi

Next.js, üç stratejiyi sayfa seviyesinde destekler. Pages Router'da getStaticProps ile SSG, getServerSideProps ile SSR, revalidate seçeneğiyle ISR elde edilir. App Router ile bu ayrım daha ayrıntılı bir hal aldı; cache: 'no-store' ile SSR, next: { revalidate: N } ile ISR davranışı elde edilir ve varsayılan davranış SSG'ye yakındır.

Nuxt.js ve SvelteKit de benzer yapıları sunar. Her iki framework'te sayfa veya route seviyesinde render stratejisi belirlenebilir; böylece uygulama genelinde tek bir strateji dayatmak zorunda kalınmaz.

Bir stratejiden diğerine geçmek mümkündür, ama bazı noktaları göz önünde bulundurmak gerekir. SSG'den SSR'a geçmek, altyapıda sunucu kapasitesi gerektirir; yalnızca CDN ile dağıtım yapılan bir yapı yeterli olmaz. ISR'dan SSR'a geçmek genellikle daha kolaydır; yenileme aralığını kaldırmak yeterlidir. SSR'dan SSG'ye geçmek ise kullanıcıya özel tüm veriyi sayfadan çıkarmayı veya client-side'a taşımayı zorunlu kılar - bu da çoğunlukla daha büyük bir refactoring anlamına gelir.

Üç strateji arasındaki seçim, tek bir doğrusal kurala bağlanamaz. Aynı uygulama içinde birden fazla strateji birlikte kullanılabilir ve bu karma yapı genellikle daha iyi bir sonuç verir. Ana sayfayı statik tutup kullanıcı panelini SSR ile üretmek, her şeyi SSR yapmaktan hem daha ucuz hem daha hızlıdır.

Karar, sonradan değişebilir. Başlangıçta SSG ile başlayıp, içerik güncelleme sıklığı arttıkça ISR'a geçmek makul bir yoldur. SSR'a geçiş gerektiren durumlar genellikle ürün büyümesiyle birlikte ortaya çıkar - kişiselleştirme ihtiyacı artar, statik çözümler yetersiz kalır. Mimariyi bu değişimlere hazır tutmak, başından doğru stratejiyi seçmek kadar önemlidir.

Hangi strateji seçilirse seçilsin, ölçüm olmadan iyileştirme olmaz. Sayfanın TTFB değeri, cache hit oranı ve kullanıcı deneyimi metrikleri, strateji kararının doğruluğunu zamanla gösterir. Statikten SSR'a geçildiğinde performans düşerse, seçimi gözden geçirmek için bu sinyal yeterlidir.