CSR (İstemci Taraflı Render) Nedir?
Kısa tanım
CSR (Client-Side Rendering, istemci taraflı render), sayfa içeriğinin sunucuda değil kullanıcının tarayıcısında JavaScript ile oluşturulduğu render yaklaşımıdır. Sunucu genellikle neredeyse boş bir HTML kabuğu ve JavaScript paketleri gönderir; tarayıcı bu kodu çalıştırır, veriyi API'lerden çeker ve arayüzü DOM'a yazar. Etkileşimli uygulamalarda akıcı geçişler sağlar, ancak ilk görüntülemeyi ve arama motorlarının içeriği görmesini JavaScript'e bağımlı kılar.
Diğer adları: Client-Side Rendering, istemci tarafında render, client rendering, tarayıcıda render
İlk istekten ilk piksele: CSR'ın zaman çizelgesi
Tamamen istemcide render edilen bir sayfada sunucunun döndürdüğü HTML çoğu zaman şundan ibarettir:
<body>
<div id="root"></div>
<script type="module" src="/assets/index-4f2a9c.js"></script>
</body>Kullanıcı bir şey görmeden önce sırasıyla şunlar olur:
- HTML iner; içinde gösterilecek içerik yoktur.
- JavaScript paketi indirilir, ayrıştırılır ve çalıştırılır.
- Uygulama, ihtiyaç duyduğu veriyi API'lerden ister ve yanıtı bekler.
- Veri geldikten sonra bileşenler DOM'a yazılır ve ana içerik ekrana çıkar.
Bu adımlar birbirini bekler. Paket büyükse veya veri isteği ancak kod çalıştıktan sonra başlıyorsa, ana içeriğin görüntülenme süresi yani LCP uzar. Sunucuda render edilen bir sayfada ikinci ve üçüncü adımın sonucu zaten HTML'in içinde gelir.
CSR nerede doğru tercih?
CSR'ın kendisi bir hata değildir; doğru yerde kullanıldığında mantıklı bir mimari karardır. Giriş yapılarak kullanılan yönetim panelleri, CRM ekranları, harita veya tasarım editörü gibi yoğun etkileşimli araçlar ve arama sonuçlarında görünmesi gerekmeyen iç uygulamalar tipik örneklerdir. Bu tür ekranlarda içeriğin dizine eklenmesi zaten istenmez; kullanıcı da uygulamayı bir kez yükleyip uzun süre içinde kalır, bu yüzden ilk yükleme maliyeti zamana yayılır. Sunucu tarafında render altyapısı gerektirmemesi, statik dosya barındırmayla yayına alınabilmesi de pratik bir avantajdır.
Arama ve yapay zekâ tarayıcıları açısından riskler
Pazarlama sayfası, blog, ürün veya kategori sayfası gibi bulunması gereken içerikte tablo değişir:
- Render'a bağımlılık: Google içeriği ancak JavaScript'i ayrı bir aşamada çalıştırdıktan sonra görür. Bir betik hatası, zaman aşımı veya engellenmiş bir API isteği sayfanın boş dizine eklenmesine yol açabilir. JavaScript çalıştırmayan botlar ise sayfayı hiç dolu görmez.
- Her adres 200 döner: Sunucu her rotaya aynı kabuğu gönderdiği için olmayan bir ürün bile 200 durum koduyla yanıtlanır; bu tipik bir soft 404 kaynağıdır.
- JavaScript ile yazılan meta etiketler: Başlık, açıklama, canonical ve hreflang ilk HTML'de yoksa veya sonradan değiştiriliyorsa ham yanıt ile render edilmiş sayfa farklı sinyaller verir.
Bu sorunların teşhisi ve çözümleri JavaScript SEO maddesinde ayrıntılı olarak ele alınıyor. Doruva'nın SEO Analiz Aracı, içeriğin ham HTML'de mi yoksa yalnızca render sonrasında mı bulunduğunu ayrı bulgu olarak raporlar.
İstemci tarafında render'ı hızlandırmak
- Paketi rotalara bölmek ve yalnızca açılan ekranın kodunu yüklemek
- Kritik veri isteğini JavaScript'in tamamının çalışmasını beklemeden başlatmak (örneğin
<link rel="preload">ile) - Yükleme iskeletlerini (skeleton) gerçek içerikle aynı boyutta tasarlamak; aksi hâlde içerik geldiğinde yerleşim kayar
- Uzun listeleri ve ağır bileşenleri ilk görüntülemeden sonraya ertelemek
Karma modeller: CSR artık tek başına değil
Modern framework'lerin çoğu CSR'ı sayfa düzeyinde değil bileşen düzeyinde kullanır. İlk yüklemede HTML sunucuda veya derleme sırasında üretilir (SSR ya da statik üretim), sonraki gezinmelerde ise sayfa yenilenmeden istemci tarafında güncellenir. Böylece arama motoru içeriği ilk yanıtta bulur, kullanıcı ise uygulama hissini kaybetmez. Tamamen istemci tarafında çalışan, tek HTML belgesiyle açılan uygulama modelinin ayrıntıları SPA maddesinde.