Server Side Rendering ve Client Side Rendering

Kısaca SSR ve CSR olarak isimlendirilen bu rendering tiplerini incelemek için, öncelikle rendering nedir onu bir konuşalım.

Hangi programlama dilini kullanırsak kullanalım, bir webapp ‘ın kullanıcıya ulaşan son hali HTML ve CSS ‘den ibarettir. Bütün PHP kodları, jsler, golang ve rust kod blokları bu basit html taglarını yaratmak için çalışırlar ve en nihayetinde ziyaretçinin browserında HTML ve CSS stil kodlarına dönüşürler. İşte bu sürece rendering diyoruz.

Şöyle biraz geriye dönüp bakarsak, serverdan kullanıcıya ulaşan rendering sürecinin eskiden çok komplike olmadığını hatırlayabiliriz. Bir eski usül web hosting içerisine yüklenen html dosyalar doğrudan download edilip, hiç bir işlemden geçmeden ziyaretçi tarafından görüntülenebilirdi.

Biraz daha komplike projelerde, PHP ya da ASP gibi popüler diller, doğrudan html ile entegre olmuş şekilde DATABASE çağrıları yapıp doğrudan html kod blokları yazırabilirdi.

Öte yandan bugün daha backend ve frontend arasındaki ilişki bir tık daha komplike hale gelmiş durumda. Elbette sadece kaporta altındaki ilişkiden bahsediyorum. Rendering sürecini anlamak ve üzerinde tam kontrol sağlamak için, o kaportayı biraz aralamamız gerekiyor. Otomobil jargonunu bir kenara bırakıp devam edelim o halde.

Server Side Rendering

Web uygulamamızın SSR yaptığımız bölümünde, bütün ameleliği yapan kısım serverın kendisidir. Tüm database okumaları, içerik oluşturmaları sunucu tarafında, backend üzerinde gerçekleştirilir ve ziyaretçiye herşeyiyle hazır, cillop gibi bir html+css kombosunu ekrana basmak kaldır.

“Peki bütün işi neden biz yapalım, enayimiz?” diye düşünebilirsin. Düşünme, ayıp. Elbette babamızın hayrına serverı yormuyoruz. Buradaki en büyük etken, SEO ‘yu güçlendirmek. Arama motorlarının modern crawlerları javascript kodlarımızı derleyip içeriğimize ulaşabilse de, bu işlemin hala SEO olarak negatif bir etkisi olduğu görülyor. Öte yadan SSR ile, bu crawler botlarını tertemiz bir içerik ile besliyoruz.

SEO haricinde, ziyaretçimiz de hazır derlenmiş bir içeriğe, daha hızlı ulaşmış oluyor. En azından teoride böyle. Yazının devamında, işlerin nasıl ters gidebileceğinden de bahsedeceğim.

Client Side Rendering

Javascriptimiz ile yazdık fetch kod bloklarını, HTMX ile gömdük requestlerimizi, artık gerisi ziyaretçinin sorunu dediğimiz renderlama biçimine CSR diyoruz. Serverdan ziyaretçinin bilgisayarına, html içeriğini nasıl oluşturacağını belirten kod blokları indiren web uygulama bölümleri oluyor yani.

Örneğin React ile yaptığımız içerik sayfaları birer CSR örneğidir. Ziyaretçi bir sayfaya girdiğinde, çeşitli olaylara bağlanmış fetch ya da axios gibi fonksiyonlar ile, backend den veri çekebilir. Tam olarak hangi backend sayfasından nasıl veri çekeceğini, bu fetch fonksiyonunun nasıl çalıştığını elbette biz programlarız ama sonuçta işi yapan ziyaretinin web browserıdır.

Adam hem uygulamamızı ziyaret etmiş, hem de bir ton iş yaptırıyoruz adama… Peki ama neden? Aslında cevap tıpkı CSR ‘de olduğu gibi performans.

Hangi rendering ne zaman lazım

İşte asıl soru bu. SSR, CSR ‘den daha iyi gibi bir sonuç çıkarmak için konuşmuyorum. İki rendering tipine de ihtiyacımız oluyor. Çok fazla teoriye girip boğulmadan, bu ihtiyaçlarımızı gerçek dünya örneklerinde çözelim.

Bir web uygulaması yaptığımızı düşünün. Örneğin bir e-ticaret sitesinin landing sayfasını programlıyoruz. İçerik olarak elimizde, bu sayfada göstereceğimiz şunlar olsun;

. Header menüleri . Slider grafikleri . Öne çıkarılmış kategorilerin popüler ürünleri . Müşterinin son ziyaret ettiği ürünler ve öneriler . Bazı alışveriş blogları . Eskiden sipariş verilmiş ve değerlendirme bekleyen ürünler . Footer bölümünde bir kaç sabit link

Bu içerik bölümlerini tek tek ele alıp, genel olarak landing sayfamızın en efektik şekilde ziyaretçiye gösterimi için rendering aşamalarına karar verelim.

Bu karar aşamasında öncelikle dikkat edeceğimiz unsur, içeriğin SEO bazlı olarak öncelik taşıyıp taşımadığı olacak. Web uygulamamız bir eticaret ürünü olduğu için, öncelikli hedefimiz satılan ürünlerin server tarafında renderlanıp, crawlerların sorunsuzca bunları taramasını sağlamak olmalı.

Header içeriği genel olarak önemli linkler, kategori alanları, site linkleri gibi bir çok öğe barındırabilir. Fakat bu içerikleri basit bir sitemap ile google ‘a sonradan da sunabiliriz. Bu sebeple SSR yerine CSR tercih etmemiz mantıklı.

Sliderlar sadece görsel grafikler olduğu için yine client tarafında renderlanmasında herhangi bir sakınca yok.

Öne çıkarılmış kategoriler ve ürünleri, landing sayfasındaki en önemli öğe olduğu için, bu içeriği SSR olarak renderlamamız önem teşkil ediyor.

Bazı alışveriş blogları SEO ‘yu gerçekten olumlu etkileyebilir, fakat blogların önemi tamamen yazılma stratejilerine göre değişebileceği için bu kesin bir şey söylemek doğru olmaz. Eğer blog yazıların, alışveriş kategorilerine, satış etkinlik alanlarını hedef alan içerikler sunuyorsa server tarafı renderlama doğru olacaktır.

Eski siparişler ya da özetle kullanıcıya özel içeriklerin tamamı CSR ile renderlanmalı. Botlar zaten bu içerikleri göremeyecekleri için gereksiz bekleme yapmanın bir manası yok.

Footer da keza sitemap ile google tarafına besleme olarak gönderilebileceği için CSR ‘in kullanılabileceği bir alandır.

Hepsinde SSR kullansam ne olur?

Ben uğraşmayayım, hepsini server renderlasın madem o kadar iyiyse diye düşündün değil mi, seni afacan.

Bir içerik server tarafında renderlanırken, ziyaretçinin bu süreç içerisinde boş bir beyaz ekrana baktığını unutmamak gerekiyor. SSR gereksiz içerikler için kullanıldığında oluşan senaryo, ziyaretçinin bir linke tıklayıp gereksizce 5-6sn beklemesi manasına geliyor.

Bu gibi performans ve SEO testlerini, Chrome browserlarda bulunan lighthouse geliştirme aracı ile rahatlıkla ölçebiliyoruz. Bir ara bu araç hakkında da yazmayı not alıyorum kenara. Kısaca bahsedecek olursam, İlk ekrana çizme süresi, SSR yükü ile doğru orantıda. Bu süre uzadıkça sitenin SEO ‘su da aynı oranda düşecektir

En doğru strateji

Başarılı bir rendering için aşağıdaki aşamaları öneririm.

. Önemli içerik titizlikle seçilerek 200 300ms gibi bir network süresini aşmadan SSR olarak renderlanmalı.

. CSR öğeleri yerine, yaklaşık genişlik ve yükseklik ölçülerinde geçici skeleton öğeleri ile içerik ziyaretçinin browserına gönderilmeli.

. Önem sırasına göre skeletonlar network istekleri ile gerçek içerikler ile değiştirilmeli.

Sonuç

Bir mantığa oturttuğumuz önem ve strateji süzgeçi ile rendering sıralamasını doğru yaparak, ziyaretçimize en düzgün deneyimi tasarladık. Ürünlerimiz server tarafında, %100 seo uyumu ile yarım saniyenin altında derlenerek indi ve müşteri daha göz kırpamadan landing sayfası karşısına çıktı. Hoş animasyona sahip skeleton içerikler bir kaç saniyede gerçek içeriklere dönüşerek sıkıcı olmayan bir deneyim yarattı.

E daha ne olsun?