Next.js'te Server-Side Rendering (SSR) mekanizması nasıldır?

26 Eyl 04:55

SSR, Next.js'in bir isteği alıp React bileşenlerini sunucuda çalıştırıp statik HTML üretmesiyle başlıyor. İstemci bir URL'ye gittiğinde, Next.js API route ya da getServerSideProps içinde tanımlı veri çekme kodları çalıştırılıyor, bu kodlar Promise döndürdüğü sürece `await` ile bekleniyor ve sonuçlar bileşene props olarak geçiliyor. React bu propslarla render edildiğinde, `ReactDOMServer.renderToString` ya da `renderToStaticMarkup` çağrısıyla bir HTML string'i üretiliyor, ardından bu HTML yanıt gövdesine gömülerek istemciye gönderiliyor. Tarayıcı bu HTML'i hemen gösterdiği için “blank page” ya da “JS‑yüklemesi bekleme” sorunu ortadan kalkıyor; ardından gelen JavaScript bundle’ı hydrate edilerek interaktif hâle geliyor. Performans açısından iki ana kazanç var: İlk “time‑to‑first‑byte” (TTFB) ve “time‑to‑first‑paint” (TTFP) ölçümleri, SSR sayesinde statik HTML’in hemen gelmesiyle ciddi anlamda düşüyor. Özellikle veri‑ağırlıklı sayfalarda (ör. ürün detayları, haber makaleleri) sunucu tarafında veri çekilip render edildiği için istemcinin ekstra API istekleri yapmasına gerek kalmıyor, bu da mobil ağlarda büyük fark yaratıyor. Ancak bu avantajı ölçeklenebilirlik maliyeti gölgeleyebilir; her istek için sunucuda tam bir React render pipeline'ı çalıştırmak CPU ve bellek tüketimini artırıyor. Yüksek trafik altında, node.js worker sayısını artırmak, SSR cache (ör. Vercel’s ISR) ya da CDN tabanlı edge rendering gibi stratejilerle bu maliyeti dengelemek gerekiyor. Ölçeklenebilirlik açısından bakacak olursak, SSR’ın “stateless” olması bir artı; yani bir sunucu instance’ı diğerine kolayca geçebilir, ama aynı anda binlerce concurrent render isteği geldiğinde “cold start” gecikmeleri ve GC baskısı ortaya çıkabilir. Bu yüzden kritik sayfalarda **incremental static regeneration** (ISR) veya **static site generation** (SSG) tercih edilerek, sadece nadiren değişen sayfalar önceden cache’lenir, geri kalanları ise gerektiğinde SSR ile “on‑demand” üretilir. Kısacası, SSR SEO ve ilk render süresini iyileştirirken, yüksek trafik ve dinamik içeriklerde uygun caching ve edge stratejileri olmadan maliyetli bir çözüm hâline gelebilir; bu dengeyi kurmak, performans‑ölçeklenebilirlik ikilisinde kankanın en kritik hamlesi.