ISR vs SSR: Next.js'de Doğru Rendering Stratejisini Seçme Rehberi

Next.js ile çalışan her ekip eninde sonunda aynı soruyla karşılaşır: Bir sayfayı her istekte sunucuda mı üretmeli, yoksa önceden üretip belirli aralıklarla mı tazelemeli? Bu karar kulağa teknik bir ayrıntı gibi gelse de, sitenizin açılış hızını, sunucu faturanızı, arama motoru sıralamanızı ve hatta dönüşüm oranınızı doğrudan etkiler. İstanbul merkezli bir yazılım ajansı olarak yüzlerce Next.js projesi teslim ettik ve şunu net biçimde gördük: Yanlış rendering stratejisi seçen ekipler, ya gereksiz yere şişen bir sunucu maliyeti ya da bayatlamış içerik gösteren bir site ile baş başa kalıyor.

Bu rehberde Incremental Static Regeneration (ISR) ile Server-Side Rendering (SSR) arasındaki farkları, Static Site Generation (SSG) ile birlikte somut örnekler üzerinden açıklayacağız. Amacımız size ezbere bir "şunu kullan" listesi vermek değil; karar verirken hangi soruları sormanız gerektiğini öğretmek. Çünkü doğru cevap, projenizin trafiğine, içeriğin güncellenme sıklığına ve kullanıcı beklentilerine göre değişir.

Rendering Stratejisi Nedir ve Neden Bu Kadar Önemlidir?

Rendering, basitçe HTML'in nerede ve ne zaman üretildiğidir. Bir kullanıcı sitenize girdiğinde tarayıcısının gösterdiği o ilk anlamlı görüntü, bir yerlerde "render" edilmiştir. Bu işlem ya kullanıcının tarayıcısında (client), ya isteği karşılayan sunucuda (server) ya da siz daha siteyi yayınlamadan önce (build) gerçekleşir.

Bu "ne zaman" sorusunun cevabı, kullanıcının ekranda boş bir sayfaya kaç saniye baktığını belirler. Türkiye'de mobil internet hızları büyükşehirlerde iyi olsa da, taşıdığımız trafik genelde 3G/4G karışımıdır ve cihaz çeşitliliği çok yüksektir. Orta segment bir Android telefonda JavaScript'i ayrıştırmak (parse) ve çalıştırmak, üst segment bir iPhone'a göre üç dört kat uzun sürebilir. Bu yüzden "her şeyi tarayıcıda render edelim" yaklaşımı, kâğıt üzerinde modern görünse de pratikte birçok ziyaretçiyi kaybettirir.

Doğru strateji üç şeyi aynı anda dengeler: kullanıcı için hız, içerik için tazelik ve işletme için maliyet. Bu üçgenin her köşesini aynı anda maksimuma çıkaramazsınız; ama projenize göre hangi köşeye ağırlık vereceğinizi bilinçli seçebilirsiniz.

Next.js'deki Rendering Yöntemlerine Genel Bakış

Next.js dört temel yaklaşım sunar. Bunları net biçimde ayırmadan ISR ile SSR karşılaştırması havada kalır.

CSR (Client-Side Rendering)

Sunucu neredeyse boş bir HTML iskeleti gönderir, gerçek içerik tarayıcıda JavaScript çalıştıktan sonra oluşur. Eski klasik React (Create React App) uygulamaları böyle çalışırdı. Avantajı, sunucu yükünün çok düşük olmasıdır. Dezavantajı ise ilk yüklemenin yavaş olması ve arama motorlarının içeriği bazen geç görmesidir. Next.js'de tamamen CSR'a kalan kısımlar genelde panel arkası, dashboard gibi SEO'nun önemsiz olduğu alanlardır.

SSR (Server-Side Rendering)

Her istek geldiğinde sayfa sunucuda baştan üretilir ve hazır HTML kullanıcıya gönderilir. Kullanıcı içeriği anında görür, arama motoru da dolu sayfayı alır. Bedeli ise her isteğin sunucuda iş yaptırmasıdır; trafik arttıkça hesaplama maliyeti ve yanıt süresi (TTFB) yükselebilir.

SSG (Static Site Generation)

Sayfa, siz siteyi yayınlarken (build aşamasında) bir kez üretilir ve statik dosya olarak saklanır. Kullanıcı geldiğinde CDN'den hazır dosya servis edilir; bu, ulaşılabilecek en hızlı senaryodur. Sorun şu: İçerik değiştiğinde siteyi yeniden build etmeniz gerekir. Binlerce ürünü olan bir mağazada her fiyat değişiminde tam build almak gerçekçi değildir.

ISR (Incremental Static Regeneration)

ISR, SSG'nin hızını SSR'ın tazeliğiyle birleştiren melez bir yaklaşımdır. Sayfa statik olarak üretilir, ama belirlediğiniz süre dolduğunda arka planda sessizce yeniden üretilir. Kullanıcı her zaman hazır (cache'lenmiş) bir sayfa görür; ancak o sayfa periyodik olarak tazelenir. Next.js ekosisteminin son yıllardaki en önemli katkılarından biri budur.

App Router ile Pages Router arasındaki kavramsal farklar bu noktada devreye girer; ikisi arasındaki ayrımı Next.js App Router ve Pages Router karşılaştırması yazımızda detaylı ele aldık.

SSR'ın Çalışma Mantığı ve Tipik Kullanım Alanları

SSR'ı zihninizde "her ziyaretçiye taze pişmiş yemek" olarak canlandırabilirsiniz. Müşteri sipariş verir, mutfak o anda hazırlar. Lezzet hep tazedir ama mutfak her siparişte çalışır.

App Router'da bir sayfayı tamamen dinamik (yani SSR) hale getirmek için isteğin önbelleğe alınmamasını söylersiniz:

// app/hesabim/page.tsx
export const dynamic = "force-dynamic"

export default async function HesabimSayfasi() {
  const kullanici = await fetch("https://api.site.com/ben", {
    cache: "no-store",
  }).then((r) => r.json())

  return <Profil veri={kullanici} />
}

Buradaki "cache: no-store" ifadesi Next.js'e "bu veriyi asla saklama, her istekte tazele" der. SSR'ı şu durumlarda tercih ederiz:

• Kullanıcıya özel içerik: Giriş yapmış kişinin sepeti, bakiyesi, sipariş geçmişi.
• Anlık değişen veri: Borsa, döviz, canlı stok, açık artırma kalan süresi.
• Yetkilendirme gereken sayfalar: İçeriğin kim olduğunuza göre değiştiği her ekran.
• Kişiselleştirme: Konuma veya geçmiş davranışa göre değişen vitrinler.

SSR'ın zayıf noktası ölçeklenmedir. Saniyede yüzlerce istek alan bir kampanya sayfasını SSR ile sunarsanız, her istek sunucuya iş yaptırır ve hem yanıt süresi hem de bulut faturanız hızla büyür. Bu nedenle SSR'ı "gerçekten kişiye özel olan" sayfalara saklamak iyi bir disiplindir.

ISR'ın Çalışma Mantığı ve revalidate Kavramı

ISR'ı ise "büyük bir fırından çıkan ekmek" gibi düşünün. Ekmek raftadır, müşteri geldiğinde anında alır. Ama fırın belirli aralıklarla yeni parti pişirir; raf hiç boş kalmaz, ekmek de bayatlamaz.

App Router'da ISR'ı etkinleştirmenin iki yolu vardır. Birincisi sayfa düzeyinde revalidate süresi belirlemek:

// app/blog/[slug]/page.tsx
export const revalidate = 3600 // saniye cinsinden; sayfa en fazla saatte bir tazelenir

export async function generateStaticParams() {
  const yazilar = await getYazilar()
  return yazilar.map((yazi) => ({ slug: yazi.slug }))
}

export default async function YaziSayfasi({ params }) {
  const yazi = await getYazi(params.slug)
  return <Makale veri={yazi} />
}

İkincisi ise tek tek veri çağrılarına süre vermek:

const urunler = await fetch("https://api.magaza.com/urunler", {
  next: { revalidate: 120 },
}).then((r) => r.json())

Burada kritik nokta şudur: revalidate süresi dolduğunda bir sonraki ziyaretçi yine eski (cache'li) sayfayı görür, ama o ziyaret arka planda yeni üretimi tetikler. Sonraki ziyaretçi güncellenmiş sayfayı alır. Bu "stale-while-revalidate" yaklaşımı sayesinde hiçbir kullanıcı yeniden üretimi beklemek zorunda kalmaz. ISR'ın gücü tam olarak budur: kullanıcı her zaman anında yanıt alır, içerik ise arka planda kendini günceller.

ISR'a ayrıca olay bazlı tazeleme de ekleyebilirsiniz. Örneğin içerik yönetim sisteminizde bir yazı güncellendiğinde, ilgili yolu (path) hedefli biçimde yeniden ürettirebilirsiniz. Bu, zaman bazlı revalidate'in tahmin oyununa son verir ve "tam doğru anda" tazeleme sağlar.

ISR vs SSR vs SSG: Karşılaştırma Tablosu

Aşağıdaki tablo üç stratejiyi en sık sorulan başlıklar üzerinden yan yana koyuyor. Bunu bir karar pusulası olarak kullanabilirsiniz.

Özellik	SSG	ISR	SSR
Sayfa ne zaman üretilir	Build anında, bir kez	Build anında + arka planda periyodik tazeleme	Her istekte, anlık
İlk yanıt süresi (TTFB)	En hızlı	Çok hızlı (cache'li)	Trafik ve işe göre değişken
İçerik tazeliği	Yeni build alınana dek sabit	revalidate süresine bağlı	Her zaman güncel
Sunucu maliyeti	Çok düşük	Düşük	Trafikle birlikte artar
Kişiselleştirme	Yok	Sınırlı	Tam destek
Ölçeklenebilirlik	Mükemmel (CDN)	Çok iyi	Dikkat ister
SEO uyumu	Çok iyi	Çok iyi	Çok iyi
Tipik kullanım	Kurumsal sayfa, blog, dokümantasyon	Ürün listesi, kategori, haber	Sepet, panel, canlı veri

Tablodan çıkarılacak özet şudur: SSG en hızlısı ama en katı olanıdır; SSR en esneği ama en pahalısıdır; ISR ise çoğu içerik odaklı senaryo için ikisinin tatlı orta noktasıdır.

Performans ve Core Web Vitals Açısından Karşılaştırma

Arama motoru sıralamasında ve kullanıcı deneyiminde Core Web Vitals metrikleri belirleyicidir. Üç ana metriği kısaca hatırlayalım: LCP (en büyük içeriğin yüklenme süresi), INP (etkileşime yanıt gecikmesi) ve CLS (görsel kayma). Bu metriklerin neden bu kadar kritik olduğunu ve nasıl ölçüldüğünü Core Web Vitals ile LCP, INP ve CLS optimizasyonu rehberimizde ayrıntılı anlattık.

Rendering stratejisinin en doğrudan etkilediği metrik LCP'dir. SSG ve ISR, hazır HTML'i CDN üzerinden servis ettiği için LCP açısından genelde en güçlü sonuçları verir. Türkiye'deki bir e-ticaret müşterimizde, kategori sayfalarını SSR'dan ISR'a taşıdığımızda mobil LCP değeri 3,4 saniyeden 1,6 saniyeye düştü. Bu fark Google'ın "iyi" eşiği olan 2,5 saniyenin altına geçmek anlamına geliyordu ve organik tıklama oranında ölçülebilir bir artış getirdi.

SSR'da LCP, sunucunun yanıt süresine (TTFB) sıkı sıkıya bağlıdır. Sunucu veriyi üretmek için yavaş bir veritabanı sorgusu çalıştırıyorsa, kullanıcı o gecikmeyi doğrudan hisseder. ISR'da ise kullanıcı cache'li sayfayı aldığı için bu gecikme kullanıcı deneyiminden tamamen soyutlanır; ağır iş arka planda, kimse beklemeden yapılır.

INP ve CLS daha çok istemci tarafı kodun kalitesiyle ilgilidir; rendering stratejisi bunları dolaylı etkiler. Yine de hazır HTML ile gelen sayfalarda, hidrasyon (hydration) öncesi içeriğin görünür olması algılanan hızı artırır.

Maliyet ve Altyapı: Türkiye Pazarı İçin Pratik Bakış

Teknik tartışmaların çoğu performansa odaklanır ama işletmeyi asıl ilgilendiren toplam sahip olma maliyetidir. Burada üç strateji arasında ciddi fark vardır.

SSG ve ISR, sayfaları çoğunlukla CDN'den servis ettiği için sunucu hesaplama maliyetini minimumda tutar. Vercel, Cloudflare veya kendi altyapınız üzerinde olun, statik servis her zaman dinamik üretimden ucuzdur. SSR'da ise her istek bir fonksiyon çağrısı veya sunucu işi demektir; trafiğiniz ay sonunda iki katına çıktığında faturanız da çıkar.

Somut bir örnek: Aylık 500 bin sayfa görüntüleme alan bir içerik sitesi düşünün. Tüm sayfalar SSR ise, her görüntüleme sunucuda iş yaptırır. Aynı site ISR ile kurulduğunda, revalidate süresi 10 dakika olsa bile sunucu yalnızca dakikada birkaç kez yeniden üretim yapar; geri kalan tüm istekler cache'ten karşılanır. Hesaplama maliyeti yüzde 90'ın üzerinde düşebilir. Bu fark, küçük ve orta ölçekli işletmeler için aylık bütçede gözle görülür bir kalemdir.

Kendi sunucunuzu Türkiye'de barındırıyorsanız ISR'ın bir avantajı daha vardır: Trafik ani sıçramalarında (örneğin bir kampanya ya da basında çıkan bir haber) cache'li sayfalar yükü emer, sunucunuz çökmez. SSR'da aynı sıçrama doğrudan sunucuya yansır.

Doğru altyapı kararları, performanslı ve sürdürülebilir bir site kurmanın temelidir. Bu konuda profesyonel destek almak isterseniz web geliştirme hizmetlerimiz kapsamında projenize özel mimari kurguluyoruz.

App Router'da Rendering Davranışını Kontrol Etmek

App Router, rendering davranışını eskisinden çok daha ince ayarlanabilir hale getirdi. Birkaç temel kaldıraç vardır.

İlk olarak, varsayılan davranış statiktir. Yani veri çağrılarınıza özel bir ayar koymazsanız, Next.js mümkünse sayfayı build anında üretmeye çalışır. Sayfayı dinamik yapan şey, "cache: no-store" gibi bir ifade, çerez (cookie) ya da başlık (header) okumak veya açıkça "force-dynamic" demektir.

İkincisi, segment bazlı yapılandırma seçenekleridir:

export const dynamic = "auto"        // varsayılan; Next.js karar verir
export const revalidate = 60         // ISR penceresi (saniye)
export const fetchCache = "default-cache"

Üçüncüsü, aynı sayfa içinde farklı veri çağrılarına farklı tazeleme süreleri verebilmenizdir. Örneğin bir ürün sayfasında ürün açıklamasını saatte bir tazelerken, stok bilgisini her istekte taze çekebilirsiniz. Bu "parçalı tazeleme" yaklaşımı, tek bir sayfada hem hızdan hem de doğruluktan ödün vermemenizi sağlar.

Bu esneklik güçlüdür ama dikkatsiz kullanıldığında kafa karıştırır. En sık gördüğümüz hata, ekiplerin farkında olmadan sayfayı dinamik hale getiren bir çağrı kullanıp, ISR'ın avantajlarını tümden kaybetmesidir. Bu yüzden her sayfa için "bu sayfa gerçekten dinamik olmak zorunda mı?" sorusunu sormak değerlidir.

Hangi Senaryoda Hangi Stratejiyi Seçmeli?

Karar verirken kullandığımız pratik bir kontrol listesi paylaşalım. Sayfanız için sırayla şu soruları sorun:

1. Bu sayfa kullanıcıya özel mi? Eğer cevap evetse (sepet, panel, hesap) SSR'a yönelin.
2. Sayfa herkese aynı görünüyor ama içerik sık değişiyor mu? Cevap evetse ISR güçlü adaydır.
3. İçerik nadiren değişiyor mu (yılda birkaç kez güncellenen kurumsal sayfa)? O zaman SSG yeterli ve en hızlısıdır.
4. Veri saniyelik doğruluk gerektiriyor mu (canlı skor, borsa)? SSR ya da istemci tarafı canlı güncelleme düşünün.

Tipik proje türleri için önerilerimiz:

• Kurumsal tanıtım siteleri: Çoğunlukla SSG, dinamik formlar için seçici SSR.
• Blog ve haber siteleri: ISR; yeni içerik yayında olduğunda hedefli tazeleme.
• E-ticaret kategori ve ürün sayfaları: ISR; sepet ve ödeme adımları SSR.
• SaaS panelleri ve dashboard'lar: SSR ya da CSR ağırlıklı, SEO gereksiz olduğundan esnek.
• Pazar yeri ve ilan siteleri: Liste sayfaları ISR, ilan detayları ISR, kullanıcıya özel alanlar SSR.

E-ticaret özelinde rendering kararları, ürün sayısı ve fiyat güncelleme sıklığıyla doğrudan ilişkilidir. Bu dengeyi kurmakta zorlanıyorsanız e-ticaret çözümleri hizmetimiz kapsamında mağazanızın ihtiyacına göre hibrit bir mimari tasarlıyoruz.

Sık Yapılan Hatalar ve Bunlardan Kaçınma Yolları

Saha tecrübemizden derlediğimiz, en çok tekrar eden yanlışlar şunlardır:

İlk hata, her şeyi SSR yapmaktır. "Güvenli tarafta kalalım, hep taze olsun" düşüncesiyle tüm siteyi dinamik kurmak, gereksiz maliyet ve yavaş TTFB getirir. İçeriğin büyük kısmı aslında herkes için aynıdır ve ISR'a uygundur.

İkinci hata, ISR'da yanlış revalidate süresidir. Süreyi çok kısa tutmak (örneğin 5 saniye) ISR'ı pratikte SSR'a dönüştürür. Çok uzun tutmak ise bayat içerik gösterir. Doğru süre, içeriğin gerçek değişim ritmine göre belirlenmelidir; günde birkaç kez değişen bir kategori için birkaç dakikalık revalidate genelde dengelidir.

Üçüncü hata, dinamik fonksiyonların sayfayı sessizce SSR'a çevirmesini fark etmemektir. Bir bileşende çerez veya başlık okuduğunuzda, o sayfa artık statik üretilemez. Bu durumu Next.js'in build çıktısındaki rendering göstergelerinden kontrol etmek iyi bir alışkanlıktır.

Dördüncü hata, cache geçersiz kılmayı (invalidation) ihmal etmektir. İçerik güncellendiğinde ilgili yolu hedefli biçimde tazelemezseniz, kullanıcılar değişikliği revalidate süresi dolana kadar göremez. Yayın akışınıza bir tazeleme tetikleyicisi eklemek bu sorunu kökünden çözer.

Gerçek Bir Proje Örneği: Hibrit Mimarinin Sonuçları

İstanbul'da orta ölçekli bir mobilya markası için yenilediğimiz mağazayı örnek verelim. Eski sitede tüm sayfalar SSR ile çalışıyordu; sezon kampanyalarında sunucu yanıt süresi 2 saniyenin üzerine çıkıyor, hatta zaman zaman zaman aşımları yaşanıyordu.

Yaptığımız değişiklik şuydu: Ana sayfa, kategori sayfaları ve ürün detaylarını 5 dakikalık revalidate ile ISR'a taşıdık. Stok ve fiyat gibi anlık değişen alanları ise istemci tarafında küçük bir veri çağrısıyla tazeledik. Sepet, ödeme ve hesap sayfalarını SSR olarak bıraktık.

Sonuçlar üç ay sonunda şöyleydi: Mobil LCP ortalaması 3,1 saniyeden 1,5 saniyeye indi. Sunucu hesaplama maliyeti yaklaşık yüzde 70 azaldı. Kampanya günlerinde site artık hiç çökmedi. En önemlisi, mobil dönüşüm oranı yüzde 18 arttı. Bu sonuç, rendering stratejisinin yalnızca teknik bir tercih değil, doğrudan gelire dokunan bir iş kararı olduğunu net biçimde gösterdi.

Bu tür kazanımları kalıcı kılmak için teknik SEO ve performansı birlikte ele almak gerekir; SEO ve dijital pazarlama hizmetlerimiz ile sıralama ve dönüşümü aynı anda iyileştiriyoruz.

Sıkça Sorulan Sorular

ISR ile SSR arasındaki en temel fark nedir?

SSR her istekte sayfayı sunucuda yeniden üretir; kullanıcı her zaman güncel ama sunucu sürekli çalışır. ISR ise sayfayı statik olarak servis eder ve belirlediğiniz aralıklarla arka planda tazeler. Pratikte ISR çok daha hızlı ve ucuzdur; SSR ise kişiye özel, anlık doğruluk gerektiren içerikler için doğrudur.

ISR kullandığımda kullanıcılar bayat içerik görür mü?

Kısa süreli olarak görebilirler. revalidate süresi dolana kadar herkes son üretilen sürümü görür. Ancak süre dolduğunda bir sonraki ziyaret arka planda yeniden üretimi tetikler ve içerik tazelenir. İçeriğin saniyelik doğruluğu gerekmiyorsa bu kabul edilebilir bir takastır. Anlık doğruluk şartsa hedefli tazeleme veya SSR daha uygundur.

SEO açısından hangisi daha iyi?

SEO açısından SSG, ISR ve SSR'ın üçü de arama motorlarına dolu HTML sunduğu için CSR'a kıyasla avantajlıdır. Aralarındaki fark sıralama değil hız ve maliyettedir. ISR genelde en iyi dengeyi sunar: hem hızlı yüklenir hem de içerik makul aralıklarla güncellenir.

revalidate süresini kaç saniye yapmalıyım?

Tek bir doğru sayı yoktur; içeriğin gerçek değişim sıklığına bağlıdır. Günde birkaç kez güncellenen bir kategori için birkaç dakika, saatte değişmeyen bir blog yazısı için bir saat veya daha uzun süre mantıklıdır. Mümkünse zaman bazlı revalidate'i, içerik değiştiğinde tetiklenen hedefli tazeleme ile birleştirin.

Mevcut bir SSR projesini ISR'a taşımak zor mu?

Çoğu durumda kademeli yapılabilir. Önce herkese aynı görünen sayfaları (kategori, blog, ürün detayı) ISR'a alır, kullanıcıya özel sayfaları SSR bırakırsınız. Bu hibrit yaklaşım riski düşürür ve kazanımı hızlı görmenizi sağlar. App Router'a geçişle birlikte yapıldığında dönüşüm daha temiz olur.

Tek bir sayfada hem ISR hem SSR kullanabilir miyim?

Evet. App Router, aynı sayfa içinde farklı veri çağrılarına farklı tazeleme davranışı vermenize izin verir. Örneğin ürün açıklamasını ISR ile saatte bir tazelerken, stok bilgisini her istekte taze çekebilirsiniz. Bu parçalı yaklaşım çoğu e-ticaret senaryosu için idealdir.

Sonuç

ISR ile SSR arasındaki seçim, "hangisi daha iyi" sorusunun değil "projem için hangisi doğru" sorusunun cevabıdır. Herkese aynı görünen, periyodik güncellenen içeriklerde ISR size statik hızı ve makul tazeliği bir arada verir, üstelik maliyeti düşük tutar. Kullanıcıya özel, anlık doğruluk gerektiren ekranlarda ise SSR vazgeçilmezdir. En sağlıklı mimari çoğu zaman ikisini akıllıca harmanlayan hibrit bir kurgudur.

Doğru kararı vermek için sitenizin trafiğini, içerik ritmini ve iş hedeflerini birlikte değerlendirmek gerekir. Next.js projeniz için en uygun rendering stratejisini birlikte belirlemek isterseniz, KaliteliWebsite olarak ücretsiz keşif görüşmesi sunuyoruz. 10.000 TL'den başlayan fiyatlarla, projenize özel performans odaklı bir mimari kurgulayıp uçtan uca hayata geçiriyoruz. Bizimle iletişime geçin; sitenizi hem hızlı hem de sürdürülebilir hale getirelim.