Sunucu tarafı render (SSR) ilk yükü hızlandırır, Core Web Vitals performansını iyileştirebilir ve arama motorlarının sayfaları daha güvenilir şekilde tarayıp indekslemesine yardımcı olabilir.
Sunucu tarafı render (SSR), sunucunun sayfanın ilk hâlini tarayıcıya ulaşmadan önce hazırladığı bir sayfa oluşturma yoludur.
Tipik bir JavaScript uygulamasında tarayıcınız genellikle kodu indirip çalıştırmak, veri almak ve sonra sayfayı monte etmek zorundadır. SSR ile sunucu bu işin çoğunu önden yapar ve gösterime hazır HTML gönderir. Tarayıcınız etkileşimler (butonlar, filtreler, formlar vb.) için JavaScript’i sonradan indirir, ama boş bir iskeleden değil, zaten dolu bir sayfadan başlarsınız.
Hissedilen en temel fark, içeriğin daha hızlı görünmesidir. Betikler yüklenirken boş bir ekran veya spinner izlemek yerine insanlar daha çabuk okumaya ve kaydırmaya başlayabilir—özellikle mobil ağlarda veya daha yavaş cihazlarda.
Bu daha erken ilk görünüm algılanan hızı artırabilir ve Largest Contentful Paint gibi önemli web performans sinyallerini olumlu etkileyebilir; bazen Time to First Byte üzerinde de etkisi olur. (SSR her şeyi otomatik olarak iyileştirmez; sayfalarınızın nasıl inşa edildiğine ve sunulduğuna bağlıdır.)
SSR web performansını iyileştirebilir ve JavaScript ağırlıklı sitelerde SEO’ya yardımcı olabilir, ancak ödünler de getirir: sunucuda daha fazla iş, önbellek gereksinimleri ve sayfanın tam etkileşimli hâle gelmesi için gereken "hydration" süresi.
Bu makalenin geri kalanında, basit bir dille SSR vs CSR karşılaştırması yapacağız, SSR’nin hangi performans metriklerini iyileştirebileceğine bakacağız, SSR’nin taranabilirlik ve indeksleme konusunda neden yardımcı olduğunu açıklayacağız ve gerçek dünya maliyetleri ile tuzaklarını—ve hız/SEO KPI’larıyla sonuçların nasıl ölçüleceğini—ele alacağız.
Server‑side rendering (SSR) ve client‑side rendering (CSR), bir sayfanın ilk HTML’inin nerede üretildiğini tanımlar: sunucuda mı yoksa kullanıcının tarayıcısında mı. Fark ince gibi görünse de bu, kullanıcıların ilk olarak ne gördüğünü ve ne kadar hızlı gördüğünü değiştirir.
SSR ile tarayıcı bir sayfa ister ve sayfanın ana içeriğini zaten içeren HTML geri döner.
Bu noktada sayfa “tamamlanmış” görünebilir, ama henüz tam olarak etkileşimli olmayabilir.
CSR ile sunucu genellikle minimal bir HTML iskeleti döner—sonra tarayıcı işi daha çok yapar.
Bu, kullanıcıların özellikle yavaş bağlantılarda veya cihazlarda boş bir alan veya yükleniyor durumuna daha uzun süre bakması anlamına gelir.
SSR sayfaları genellikle önce HTML gönderir, sonra JavaScript sayfayı "hydrate" eder—olay işleyicilerini bağlar ve statik HTML’i çalışan bir uygulamaya çevirir (butonlar, formlar, navigasyon).
Basit bir düşünce şekli:
Bir ürün sayfasını hayal edin.
SSR, tarayıcının anlamlı HTML’i ne zaman aldığına göre davranışı değiştirir. Bu kayma bazı kullanıcı odaklı performans metriklerini iyileştirebilir—ama sunucunuz yavaşsa tersine de dönebilir.
TTFB (Time to First Byte), sunucunun yanıt vermeye ne kadar çabuk başladığını ölçer. SSR ile sunucu daha fazla iş (HTML render) yapabileceği için TTFB iyileşebilir (daha az istemci turu) veya kötüleşebilir (ek render süresi).
FCP (First Contentful Paint), kullanıcının herhangi bir metin veya görsel ilk gördüğünde kaydedilir. SSR genellikle yardımcı olur çünkü tarayıcı hazır paint edilebilir HTML alır.
LCP (Largest Contentful Paint), ana içerik parçasının (hero başlık, afiş görseli, ürün fotoğrafı) görünür olma zamanıdır. LCP öğesi başlangıç HTML’inde yer alıyorsa SSR beklemeyi azaltabilir.
CLS (Cumulative Layout Shift), görsel stabiliteyi ölçer. SSR, görseller, fontlar ve bileşenler için tutarlı markup ve boyutlar üretilirse yardımcı olabilir; ancak hydration sonrasında layout değişirse zarar verebilir.
INP (Interaction to Next Paint), kullanıcı etkileşimleri sırasındaki duyarlılığı yansıtır. SSR INP’yi otomatik olarak düzeltmez çünkü JavaScript yine hydrate edilmelidir. Ancak daha az JS göndermek, bundle’ları bölmek ve kritik olmayan scriptleri ertelemek INP’yi iyileştirebilir.
Sayfa tam etkileşimli olmasa bile içeriğin daha erken görünmesi algılanan hızı artırır. Kullanıcılar okumaya ve içeriğin ne hakkında olduğunu anlamaya erken başlayabildiklerinde siteye güvenleri artar.
Eğer sunucu renderi pahalıysa—veritabanı çağrıları, ağır bileşen ağaçları, yavaş middleware—SSR TTFB’yi artırabilir ve her şeyi geciktirebilir.
Güçlü bir önbellekleme stratejisi sonucu dramatik şekilde tersine çevirebilir: anonim trafik için tam HTML’i önbelleğe alın, veri yanıtlarını önbelleğe alın ve mümkünse edge/CDN önbellekleme kullanın. Önbellekleme ile SSR hem hızlı TTFB hem de hızlı FCP/LCP sağlayabilir.
Sayfa sunucuda render edildiğinde tarayıcı hemen gerçek, anlamlı HTML alır—başlıklar, metin ve ana düzen zaten yerinde olur. Bu, ilk görüntü deneyimini değiştirir: JavaScript’in indirip sayfayı inşa etmesini beklemek yerine kullanıcılar neredeyse hemen okumaya başlayabilir.
Client-side rendering ile ilk yanıt sıklıkla büyük ölçüde boş bir iskelet içerir (<div id="app"></div> ve scriptler). Yavaş bağlantılar veya zayıf cihazlarda bu, insanların boş veya kısmen stilize edilmiş bir ekrana uzun süre bakmasına neden olabilir.
SSR, başlangıç HTML’i geldiğinde tarayıcının gerçek içeriği boyamasını sağlar. JavaScript daha uzun sürse bile sayfa canlı hisseder: kullanıcı başlık, ana metin ve yapıyı görür; bu algılanan bekleme süresini ve erken terkleri azaltır.
SSR JavaScript’i ortadan kaldırmaz—sadece ne zaman gerektiğini değiştirir. HTML gösterildikten sonra sayfa yine de JS ile hydrate edilip etkileşimli hale gelmelidir; örneğin:
Ama amaç, kullanıcıların tüm interaktivite hazır olmadan önce sayfayı görebilmesi ve anlamaya başlamasıdır.
İlk yükün hızlı hissetmesini istiyorsanız, üst katmanda kullanıcıların beklediği içeriği SSR ile önceliklendirin:
İyi yapıldığında SSR kullanıcılara hemen işe yarar bir şey verir—sonra JavaScript kademeli olarak cilayı ve etkileşimleri ekler.
Mobil performans sadece “masaüstü daha küçük hali” değildir. Birçok kullanıcı orta seviye telefonlar, eski cihazlar, güç tasarruf modları veya dalgalı bağlantılarla gezer. SSR bu senaryoları çok daha hızlı hissettirebilir çünkü en zor işi nerede yapıldığı değişir.
Client-side rendering ile cihaz genellikle JavaScript indirir, parse eder, çalıştırır, veri çeker ve sonra sayfayı son aşamada oluşturur. Yavaş CPU’larda bu “parse + execute + render” adımı zaman alabilir.
SSR, başlangıç içeriğini doğrudan içeren HTML döner. Tarayıcı anlamlı UI’ı daha erken boyamaya başlayabilir; JavaScript paralel olarak yüklenip hydration yapar. Bu, cihazın ilk olarak işe yarar bir şey görmeden önce yapması gereken ağır işleri azaltır.
Düşük seviye telefonlar şu konularda zorlanır:
Hazır render edilmiş HTML sağlayarak SSR, ana iş parçacığının ilk boya ve kilit içeriğin görünmesine kadar bloke olma süresini kısaltabilir.
Yavaş bağlantılarda her ek round trip ve her ekstra megabayt zarar verir. SSR, ilk ekran için kritik olan JS miktarını azaltabilir çünkü başlangıç görünümü çok kod çalıştırmaya bağlı değildir. Toplamda aynı JS miktarını gönderebilirsiniz, ama kritik olmayan kodu erteleyip ilk render’dan sonra yükleyebilirsiniz.
Sadece masaüstü Lighthouse sonuçlarına güvenmeyin. Mobil yavaşlatma (throttling) ve gerçek cihaz testleriyle deneyin; zayıf cihazlarda kullanıcı deneyimini yansıtan metriklere (özellikle LCP ve Total Blocking Time) odaklanın.
Arama motorları HTML okumada çok iyidir. Bir tarayıcı (crawler) sayfayı istediğinde anlamlı, metin tabanlı bir HTML (başlıklar, paragraflar, bağlantılar) hemen alırsa sayfanın neyle ilgili olduğunu anlayabilir ve indekslemeye başlayabilir.
SSR ile sunucu ilk istek için tam biçimlendirilmiş bir HTML döner. Bu, önemli içeriğin "view source" HTML’inde görünür olmasını sağlar; sadece JavaScript çalıştıktan sonra görünür hale gelmez. SEO için bu, tarayıcının önemli bilgileri kaçırma olasılığını azaltır.
CSR ile ilk yanıt genellikle hafif bir HTML kabuğu ve gerçek içeriğin görünmesi için indirilmeyi, çalıştırılmayı ve veri çekmeyi bekleyen bir JavaScript paketini içerir.
Bu şu sorunlara yol açabilir:
Google birçok sayfa için JavaScript render edebilir, ama düz HTML’i parse etmek kadar hızlı veya güvenilir olmayabilir. JavaScript render etme ekstra adımlar ve kaynak gerektirir; pratikte bu içerik güncellemelerinin keşfinin yavaşlaması, indekslemenin gecikmesi veya render yolunda bir şey bozulduğunda boşluklar anlamına gelebilir.
SSR bu bağımlılığı azaltır. JavaScript sayfayı yükledikten sonra etkileşimleri güçlendirse bile, crawler zaten temel içeriğe sahiptir.
Hızlı ve doğru indeksleme önemliyse SSR özellikle değerli olur:
Sayfanın temel değeri içeriğiyse, SSR arama motorlarının içeriği hemen görmesini sağlamaya yardımcı olur.
SSR yalnızca sayfaların daha hızlı yüklenmesine yardımcı olmaz—sayfaların kendilerini hemen doğru şekilde tanımlamasına da yardımcı olur. Birçok crawler, bağlantı önizleme aracı ve SEO sistemi başlangıç HTML cevabına bakarak sayfanın ne hakkında olduğunu anlamaya çalışır.
Her sayfa en azından doğru, sayfaya özel metadata ile gelmelidir:
SSR ile bu etiketler gerçek sayfa verisi (ürün adı, kategori, makale başlığı) kullanılarak sunucu tarafında render edilebilir; yalnızca JavaScript sonrası yerine koyma riskini azaltır.
Birisi link paylaştığında Slack, WhatsApp, LinkedIn, X veya Facebook gibi platformların scraper’ları sayfayı alıp Open Graph etiketlerine bakar (og:title, og:description, og:image).
Bu etiketler başlangıç HTML’inde yoksa önizleme rastgele bir şeyi kullanabilir veya hiç gösterilmeyebilir. SSR, sunucu cevabının o özel URL için doğru Open Graph değerlerini içermesini sağlar, böylece önizlemeler tutarlı ve güvenilir olur.
Yapılandırılmış veri—çoğunlukla JSON-LD—arama motorlarının içeriğinizi (makaleler, ürünler, SSS’ler, breadcrumb’lar) yorumlamasına yardımcı olur. SSR, JSON-LD’nin HTML ile birlikte gelmesini ve görünen içerikle tutarlı olmasını kolaylaştırır.
Tutarlılık önemlidir: yapılandırılmış veri ürün fiyatı veya stok bilgisi gibi şeyleri sayfada görünenle uyuşmazsa zengin sonuç uygunluğu riske girer.
SSR birçok URL varyasyonu (filtreler, izleme parametreleri, sayfalandırma) üretebilir. Çoğaltma sinyallerinden kaçınmak için her sayfa tipi için bir canonical URL belirleyin ve her render edilen route’ta doğru olduğundan emin olun. Birden fazla varyantı kasıtlı destekliyorsanız, net canonical kuralları tanımlayıp routing ve render mantığında tutarlılık sağlayın.
Server-side rendering, önemli işi tarayıcıdan sunucularınıza kaydırır. Bu amaçtır—aynı zamanda ödün demektir. Her ziyaretçinin cihazı JavaScript ile sayfayı inşa etmek yerine altyapınız artık HTML üretmekten sorumlu olur (çoğunlukla her istek için) ve uygulamanızın ihtiyaç duyduğu veri alımlarını da çalıştırır.
SSR ile trafik dalgalanmaları doğrudan CPU, bellek ve veritabanı kullanımında dalgalanmalara dönüşebilir. Sayfa basit görünse bile şablon renderleri, API çağrıları ve hydration için veri hazırlama maliyetleri toplanır. Ayrıca render yavaşsa veya üst hizmetler (veritabanı gibi) baskı altındaysa TTFB artışı görebilirsiniz.
Önbellekleme, SSR’nin her seferinde tam render maliyetini ödemeden hızlı kalmasını sağlar:
Bazı ekipler sayfaları “edge”de (ziyaretçiye daha yakın) render eder: merkezi bir sunucuya olan round-trip süresini azaltmak için. Fikir aynı: ziyaretçinin yakınına HTML üretin, tek bir uygulama kod tabanını koruyun.
Nerede mümkünse önbelleğe alın; sonra yükleme sonrası kişiselleştirin.
Hızlı bir önbelleğe alınmış kabuk (HTML + kritik veri) sunun; kullanıcıya özel ayrıntıları (hesap bilgileri, konuma göre teklif) hydration sonrası alın. Bu, SSR hız faydalarını korurken her benzersiz ziyaretçi için sunucularınızın yeniden render etmesini engeller.
SSR sayfaları daha hızlı ve daha indekslenebilir yapabilir, ama ayrıca yalnızca istemci-taraflı uygulamalarda görülmeyen hata modları getirir. İyi haber: çoğu sorun öngörülebilir ve düzeltilebilir.
Sunucuda HTML render etmek için veri çekip, hydration sırasında istemcinin aynı veriyi tekrar çekmesi sık yapılan bir hatadır. Bu bant genişliği israfına, yavaş etkileşime ve artan API maliyetlerine yol açar.
Bunu HTML içine gömülmüş başlangıç verisi (veya inlined JSON) ile önleyin ve istemcinin önbelleğini SSR yükünden başlatın. Birçok framework bu modeli destekler.
SSR anlamlı HTML gönderebilmek için veri bekler. Eğer backend veya üçüncü taraf API’ler yavaşsa TTFB sıçrayabilir.
Azaltıcılar:
Her şeyi sunucu tarafında render etmek cazip gelebilir, ama çok büyük HTML yanıtları indirmeyi yavaşlatır—özellikle mobilde—ve tarayıcının boyama yapma noktasını geriye iter.
SSR çıktınızı hafif tutun: üst katman içeriğini önce render edin, uzun listeleri sayfalayın ve aşırı veri inline etmeyin.
Kullanıcılar içeriği hızlı görse de büyük JS bundle’ları sayfayı “takılmış” hissettirebilir. Hydration, JS indirilip parse edilip çalışana kadar tamamlanamaz.
Hızlı düzeltmeler: route/bileşen bazında kod bölme, kritik olmayan scriptleri erteleme ve kullanılmayan bağımlılıkları kaldırma.
Sunucu bir şeyi renderleyip istemci başka bir şey renderlarsa hydration uyarıları, layout kaymaları veya bozuk UI ortaya çıkabilir.
Uyuşmazlıkları önlemek için deterministik render sağlayın: sunucuya özgü zaman damgaları veya rastgele ID’ler kullanmayın, aynı yerel ayar/tarih formatını kullanın ve her iki tarafta da aynı feature flag’lerin çalıştığından emin olun.
Yanıtları sıkıştırın (Brotli/Gzip), görselleri optimize edin ve açık bir önbellekleme stratejisi (CDN + sunucu cache + istemci cache) benimseyin ki SSR’nin faydalarını sorun yaşamadan alın.
SSG, SSR ve CSR arasında seçim yapmak "hangi en iyi" sorusundan ziyade sayfanın işine uygun render stilini seçmekle ilgilidir.
SSG HTML’i önceden üretir. Sunması en basit, hızlı ve güvenilirdir ama sık değişen içerikte zorluk çıkarabilir.
SSR HTML’i her istek için (veya edge/sunucu önbelleğinden) üretir. Sayfanın en güncel kullanıcı- veya istek-özgü veriyi yansıtması gerektiğinde iyidir.
CSR minimal bir HTML kabuğu gönderir ve UI tarayıcıda render edilir. Çok etkileşimli uygulamalar için uygun olabilir, fakat başlangıç içeriği ve SEO zarar görebilir.
Pazarlama sayfaları, dokümanlar ve blog yazıları genellikle SSG’den en fazla faydayı alır: öngörülebilir içerik, mükemmel performans ve temiz taranabilir HTML.
Panolar, hesap sayfaları ve karmaşık uygulama araçları genellikle CSR (veya hibrit) eğilimindedir çünkü deneyim kullanıcı etkileşimleri ve özel verilere dayanır. Yine de birçok ekip başlangıç görünümü için SSR kullanıp hydration sonrası CSR’ye bırakır.
Sık güncellenen sayfalar (haber, listeler, fiyat/stok) için hibrit SSG + incremental regeneration veya SSR + önbellekleme düşünün ki her istek için yeniden hesaplama yapmayın.
| Sayfa tipi | Varsayılan tercih | Neden | Dikkat edilecekler |
|---|---|---|---|
| Landing sayfaları, blog, dokümanlar | SSG | Hızlı, ucuz, SEO-dostu | Güncelleme iş akışı |
| Sık değişen halka açık içerik | SSR veya SSG + incremental regeneration | İçeriği taze tutar | Önbellek anahtarları, invalidasyon |
| Kişiselleştirilmiş sayfalar (girişli) | SSR (güvenli önbellekleme ile) | İstek-özgü HTML | Özel veriyi önbelleğe almayın |
| Yüksek etkileşimli uygulama ekranları | CSR veya SSR + CSR hibriti | İlk yük sonrası zengin UI | Hydration maliyeti, yüklenme durumları |
Pratik yaklaşım karışık render’dır: pazarlama için SSG, dinamik halka açık sayfalar için SSR, ve uygulama panelleri için CSR/SSR-hibriti.
Eğer bu yaklaşımları prototiplemek istiyorsanız, Koder.ai gibi bir vibe-coding platformu React web uygulamasını Go + PostgreSQL backend ile sohbet içinde hızlıca kurmanıza, SSR/SSG seçimlerini denemenize, kaynak kodu dışa aktarmanıza ve dağıtmanıza yardımcı olabilir. Bu, tam yeniden yapılanmaya gitmeden önce performans ve SEO varsayımlarınızı doğrulamak için kullanışlıdır.
SSR ancak kullanıcı deneyimini ve arama görünürlüğünü ölçülebilir şekilde iyileştiriyorsa değerlidir. Bunu bir performans deneyi gibi ele alın: bir temel alın, güvenli şekilde yayınlayın ve uygulama sonrası aynı metrikleri karşılaştırın.
Hız tarafında Core Web Vitals ve destekleyici zamanlamalara odaklanın:
SEO tarafında crawl ve indeksleme değişimini ölçün:
Hız için hızlı bir yönlendirme almak üzere Lighthouse, tekrarlanabilir laboratuvar çalışmaları ve film şeritleri için WebPageTest, ve crawl/indexleme eğilimleri için Search Console kullanın. Kök neden analizi için sunucu logları/APM ile gerçek TTFB, önbellek isabet oranı ve hata yükselmelerini izleyin.
Tercih edilen yöntem: A/B testi (trafik bölme) veya kademeli yayın (ör. %5 → %25 → %100). Aynı sayfa şablonlarını ve cihaz/ağ profillerini karşılaştırın ki sonuçlar çarpıtılmasın.
SSR (server-side rendering), sunucunun sayfanın ana içeriğini içeren HTML’i doğrudan gönderdiği anlamına gelir.
Tarayıcınız bu HTML’i hemen render eder, ardından sayfayı “hydrate” etmek ve interaktiviteyi (butonlar, formlar, filtreler) etkinleştirmek için JavaScript indirilir ve çalıştırılır.
CSR (client-side rendering) genellikle minimal bir HTML iskeleti gönderir ve tarayıcının JavaScript çalıştırıp veri çekerek UI’yı oluşturmasına dayanır.
SSR ise anlamlı HTML’i baştan gönderir; böylece kullanıcılar içeriği daha erken görürken, CSR genellikle JavaScript tamamlanana kadar boş bir alan veya yükleniyor durumu gösterir.
Hydration, JavaScript’in sunucu tarafında render edilmiş HTML’e olay dinleyicilerini bağladığı ve sayfayı interaktif hale getirdiği adımdır.
Bir sayfa SSR sonrası “tamamlanmış” görünebilir, ancak büyük bir JS paketi varsa veya JS geç iniyorsa sayfa interaktif hissetmeyebilir; bu yüzden hydration önemlidir.
SSR şu metrikleri iyileştirebilir:
TTFB ise sunucu render maliyetine bağlıdır; bazen iyileşir, bazen kötüleşir.
SSR, gerçek HTML içeriğini hemen vererek “boş sayfa” evresini azaltır.
Sayfa henüz interaktif olmasa da kullanıcılar daha erken okumaya, kaydırmaya ve sayfanın amacını anlamaya başlayabildiği için algılanan hız ve erken terkler düşer.
Sunucu renderi yavaşsa (ağır bileşen ağaçları, yavaş API/DB sorguları, zorlayıcı middleware) TTFB artabilir ve performans kötüleşebilir.
Bunu önlemek için tam sayfa/fragment/CDN önbellekleme, zaman aşımı ve kritik olmayan veriler için geri dönüş mekanizmaları uygulayın.
SSR genellikle SEO için faydalıdır çünkü tarayıcılar veya arama motoru botları sayfayı ilk istekte anlamlı HTML ile alır (başlıklar, paragraflar, bağlantılar) ve JavaScript çalıştırılmasına bağımlılığı azaltır.
Bu, CSR ile sık görülen ince başlangıç içeriği, iç bağlantıların gecikmeli keşfi veya JS başarısız olursa indeksleme boşlukları gibi sorunları azaltır.
SSR, sayfa talebi yapıldığında sayfanın doğru meta verileriyle gelmesini kolaylaştırır. Bunlar arasında:
<title> ve meta descriptionBirçok paylaşım aracı ve bazı tarayıcılar JS çalıştırmadığı için SSR, sosyal önizlemelerin ve arama snippet’lerinin tutarlı olmasını sağlar.
Yaygın tuzaklar şunlardır:
SSG büyük ölçüde sabit içerikler için (blog, doküman, pazarlama) en hızlı ve en ucuz servis yöntemidir.
SSR isteğe özel veya sık güncellenmesi gereken içerikler için iyidir (listeler, fiyatlar, halka açık dinamik sayfalar).
CSR ise giriş yapılmış, yüksek etkileşimli uygulama ekranları için uygundur; SEO önceliği düşükse ya da interaktivite hükmediyorsa tercih edilir.
Çoğu proje için karışık bir yaklaşım uygundur: pazarlama için SSG, dinamik kamu sayfaları için SSR (+önbellekleme), uygulama içi ekranlar için CSR veya SSR+CSR hibriti.
Çözümler: SSR başlangıç verisini istemci önbelleğini doldurmak için kullanın, deterministik render uygulayın, JS’i bölün ve önbellekleme stratejileri planlayın.