--- title: "SSR nedir?" author: Androverse author_url: https://androverse.com.tr/yazar/androverse publisher: Androverse updated_at: 2026-10-15 url: https://androverse.com.tr/sozluk/ssr language: tr --- # SSR nedir? SSR, bir sayfanın HTML içeriğinin istek sırasında sunucuda oluşturulması yaklaşımıdır. Diğer adlar: Server-side rendering, sunucuda oluşturma. ## Nerede işine yarar? İlk yanıt metni tarayıcıya hazır gelebilir; kişiselleştirme veya istek bilgisi kullanılması da mümkün olur. İstek başına yapılan iş, önbellek ve veri kaynakları performansı etkiler. Yöntem seçimi yalnız SEO etiketi üzerinden yapılmaz. ## Bir cümlede uygulaması Kullanıcının yetkisine göre değişen bir panel yanıtını istek sırasında sunucuda hazırlamak. ## Neyle karıştırılmamalı? SSR istek zamanında; SSG önceden üretim zamanında HTML hazırlamayı ifade eder. ## Sayfa yola çıkmadan önce hazırlanıyor. Bir etkinlik sitesi düşün. Ziyaretçi aynı adresi açıyor, fakat etkinliğin durumu gün içinde değişiyor: kayıt açık, yer kalmadı veya program güncellendi. SSR yaklaşımında sunucu, isteğe karşılık sayfanın HTML çıktısını üretir. Tarayıcı temel içeriği alır; etkileşim için gereken kod daha sonra çalışabilir. Bu yöntem, ekranda ilk görünen bilginin hangi zamanda ve hangi veriyle oluşturulduğu sorusuna bir yanıt verir. SSR seçimini yalnız SEO etiketi üzerinden yapmayız. Sayfanın içeriği ne kadar sık değişiyor, her ziyaretçiye aynı bilgi mi gösteriliyor, verinin kaynağı ne kadar hızlı yanıtlıyor? Bir etkinlik başlığı seyrek değişirken kalan kontenjan anlık olabilir. İkisini tek bir büyük sunucu işlemine bağlamak yerine statik kabuk, sunucuda gelen içerik ve istemci etkileşimi ayrı değerlendirilebilir. Kullanıcının güncel bilgi ihtiyacı, mimari kararın başlangıcıdır. Sunucuda üretmek, sayfanın beklemeden geleceği anlamına gelmez. HTML hazırlamak için yavaş bir veri kaynağı beklendiğinde ilk yanıt gecikebilir. Önbellek, veri isteklerinin düzeni ve parçalı gönderim gibi seçenekler bu beklemeyi etkiler. Bir sayfanın üretim yeri ile hızlı hissedilmesi aynı ölçüt değildir. Görünen içerik, etkileşime hazır olma ve veri güncelliği farklı anlarda tamamlanabilir; tasarım bunları kullanıcıya anlaşılır biçimde taşımalıdır. Kişiye özel içerik varsa ortak önbellek ayrıca dikkat ister. Bir kullanıcının adı veya özel kaydı bütün ziyaretçilerin alacağı yanıtın içine karışmamalıdır. İstek bağlamı, yetki kontrolü ve önbelleğin hangi bilgiye göre ayrıldığı birlikte düşünülür. SSR, kişiselleştirme için kullanılabilir; fakat tek başına doğru erişim kontrolü sağlamaz. Sunucuda çalışması bir işlemi otomatik olarak yetkili veya güvenli yapmaz. Bir oturumlu sayfada aynı URL farklı kişilere farklı içerik verebilir. Bu, sunucuda render kararının önbellek politikasıyla birlikte ele alınmasını gerektirir. Herkese açık bir hizmet metniyle hesaba özel bir proje durumunu aynı paylaşım kuralına bağlamak uygun değildir. Hangi verinin kişisel olduğunu, hangi yanıtın ortak kullanılabileceğini ve hatalı veri kaynağında ne gösterileceğini belirle. SSR kullanmak bu kararları kendiliğinden çözmez. Ayrıca sunucuya taşınan bir hesaplama kaybolmaz; farklı bir yerde çalışır. Çok pahalı bir isteği her ziyaretçi için tekrar etmek yerine veri erişimi, tekrar kullanım ve hata yönetimi birlikte tasarlanır. Mimari karar, yalnız render etiketinden daha geniştir. ### Güncellik Sayfadaki her bilgi için ne kadar eski kalabileceğini belirle. Etkinlik açıklaması ile son kontenjan aynı toleransa sahip olmayabilir. Bütün sayfayı en hassas alanın hızında yeniden üretmek tek seçenek değildir. ### İlk yanıt Sunucu HTML göndermeden önce hangi kaynakları bekliyor? Birbirinden bağımsız istekler, gereksiz sıralama veya pahalı hesaplama ilk içerik süresini uzatabilir. İlk yanıtın gecikmesini yalnız görsel sıkıştırmayla çözemezsin. ### Etkileşim HTML ekranda görünürken düğmelerin davranışını hangi kod sağlıyor? Sunucuda gelen içerik ile tarayıcıda etkinleşen bileşenlerin sınırını açık tut. Görünür bir kontrolün kullanılabilirliği de açılış deneyiminin parçasıdır. ## Üretim zamanı ile etkileşim zamanı. ### İstek anında HTML Sunucu isteği alır, ilgili veriyi okur ve sayfanın çıktısını oluşturur. Bu yaklaşım güncel veya isteğe bağlı bilgi için kullanılabilir. Ancak yanıtın hazırlanması kaynakların hızına bağlıdır. Aynı HTML önbelleğe alınırsa sonraki ziyaretler farklı bir yoldan servis edilebilir; SSR ve önbellek birbirini dışlayan kavramlar değildir. ### Tarayıcıdaki davranış Sayfayı aldıktan sonra menü, filtre veya form etkileşimi tarayıcı koduyla etkinleşebilir. HTML’in sunucuda oluşturulması bu kodun maliyetini ortadan kaldırmaz. Çok büyük bir istemci paketi, içerik hazır görünse bile etkileşimi geciktirebilir. Bu yüzden sunucuda üretim ve istemciye gönderilen davranış miktarı iki ayrı karardır. ## Sunucuda üretim kararının etkileri SSR'da istek sırasında HTML üretmek güncel veya isteğe bağlı içerik sunmayı kolaylaştırabilir. Bunun karşılığında sunucu yanıt süresi ve veri kaynaklarının davranışı önem kazanır. Uygun önbellekleme, hata yönetimi ve yük altında ölçüm yapılmadan yalnız render yöntemi adına bakılarak performans kararı verilmez. - Hangi içeriğin gerçekten her istekte değiştiğini belirle. - Veri kaynağı yavaş veya erişilemezken dönen yanıtı dene. - Sunucu süresiyle tarayıcıdaki etkileşime hazırlığı ayrı ölç. ## SSR varsa JavaScript gereksiz mi? Hayır. HTML sunucuda hazırlanabilir; etkileşimli bileşenler tarayıcıda JavaScript kullanmaya devam edebilir. İlk içeriğin görünmesi ile düğmelerin çalışır hale gelmesi aynı aşama değildir. ## Bu karar, işinin neresinde? SSR kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) ## Karar masası ### SSR bütün sayfalarda gerekli mi? Hayır. Seyrek değişen bir stüdyo tanıtımı veya yayınlanmış yazı önceden üretilebilir. Oturumla değişen bir hesap ekranı ise farklı ihtiyaç taşır. Aynı site farklı sayfalarda ve bölümlerde farklı üretim yöntemleri kullanabilir. Tercihi teknoloji modasına göre değil, güncellik, kişiselleştirme, veri maliyeti ve kullanıcı beklentisine göre yapmak gerekir. Basit bir içerik için gereksiz sunucu işi eklemek daha iyi deneyim garantisi değildir. ### SSR kullanınca JavaScript azalır mı? Kendiliğinden azalmaz. Tarayıcıya hangi bileşenlerin ve bağımlılıkların gönderildiği önemlidir. Bütün sayfayı etkileşimli bir istemci ağacına dönüştürmek, sunucuda hazırlanmış HTML’in yanında büyük kod indirmesi doğurabilir. Gerçekten davranış isteyen küçük parçaları ayırmak daha kontrollü bir yapı sağlar. Bunun nasıl yapıldığı kullanılan çerçeveye bağlıdır; SSR adı tek başına istemci paketinin boyutunu söylemez. ### Sunucu hatasında kullanıcı ne görmeli? Verinin niteliğine göre karar verilir. Güncelliği kesin gereken bir rezervasyon durumunda eski bilgiyi doğruymuş gibi göstermek sakıncalıdır. Bir yayın listesinde ise açıkça belirtilmiş son geçerli kopya işe yarayabilir. Hata ekranı, tekrar deneme ve destek yolu içerik tasarımının parçasıdır. Bütün bağımlılıkların aynı anda çalıştığı varsayımıyla hazırlanmış bir SSR sayfası, gerçek kullanımda gereksiz kırılganlık taşır. ## Bir sayfanın zaman çizelgesi. Bir etkinlik detay sayfasını al ve içindeki verileri ayrı ayrı yaz: başlık, açıklama, program, kontenjan ve kullanıcı kaydı. Her parçanın ne zaman üretileceğini ve ne zaman güncelleneceğini belirleyen bir taslak hazırla. Koddan önce veri ihtiyacını görünür kıl. - [ ] Her alanın kaynağını ve güncellik ihtiyacını not et. Açıklamanın birkaç dakika eski kalmasıyla kontenjanın eski kalması aynı sonucu doğurmaz. Kullanıcıya verilecek söz, bu toleransla uyumlu olmalı; bütün alanları yalnız dinamik diye etiketleme. - [ ] İlk HTML’in oluşmasını bekleten istekleri çiz. Bir kaynağın yanıt vermediği durumda diğer içeriğin sunulup sunulamayacağını tartış. Kritik bilgi ile yardımcı bilgi arasındaki ayrım, ekrandaki bekleme tasarımını da değiştirebilir. - [ ] Kullanıcıya özel alanları işaretle. Ortak önbelleğe girmemesi gereken veriyi ve yetkinin nerede kontrol edildiğini yaz. Başka bir kişinin tarayıcısından aynı adres açıldığında hangi bilgilerin farklı olması gerektiğini açıkla. - [ ] Sayfanın göründüğü an ile etkileşimin hazır olduğu anı ayrı tarif et. Form henüz çalışmıyorsa kullanıcı bunu nasıl anlayacak? Üretim yöntemi kararının yalnız sunucu yükünü değil, ekrandaki güven hissini de etkilediğini düşün. SSR bir kalite etiketi değil, HTML’in hangi koşulda üretildiğine dair mimari tercihtir. Doğru seçim, güncel bilginin doğru kişiye anlaşılır ve dayanıklı biçimde ulaşmasını destekler. ## Bağlantılı kavramlar - [SSG](https://androverse.com.tr/sozluk/ssg) — SSG, sayfa içeriğinin kullanıcı isteğinden önce oluşturulup hazır HTML olarak sunulması yaklaşımıdır. - [Hydration](https://androverse.com.tr/sozluk/hydration) — Hydration, önceden oluşturulmuş HTML üzerine tarayıcıda uygulamanın etkileşimli davranışlarının bağlanması sürecidir. - [Önbellek](https://androverse.com.tr/sozluk/onbellek) — Önbellek, daha önce elde edilmiş bir yanıtı veya kaynağı uygun koşullarda yeniden kullanarak tekrar işi azaltmaktır. ## Konuyu uygulamaya taşı - [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) — SSR kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. - [Sunumda “disruptive”. Çıktıda aynı şablon.](https://androverse.com.tr/blog/sunumda-disruptive-ciktida-ayni-sablon) — SSR ile ilgili tasarım kararını Androverse’nin uygulama örnekleri ve değerlendirme sorularıyla birlikte düşün. ## Kaynaklar - [Next.js — Sunucu ve istemci bileşenleri](https://nextjs.org/docs/app/getting-started/server-and-client-components) [Androverse profili](https://androverse.com.tr/yazar/androverse) · [Yayın ilkeleri](https://androverse.com.tr/yayin-ilkeleri)