Statik site mi, SSR mi

Varsayılan statik olmalı, SSR’ı seçmek için bir sebep gerekir. Doğru soru “içeriğim dinamik mi” değil, “cevap her ziyaretçi için farklı mı” sorusu.

Yanlış soru: içeriğim dinamik mi

Bir blog yazısı, dokümantasyon sayfası, kurumsal site ve çoğu katalog sayfası “dinamik” görünür çünkü veritabanından geliyor. Ama aynı sayfayı görüntüleyen iki ziyaretçi aynı HTML’i alıyorsa, o sayfa statik olarak üretilebilir. Veri kaynağının dinamik olması, yanıtın da her ziyaretçi için farklı olması gerektiği anlamına gelmiyor.

Asıl soru şu: aynı URL’e giden iki farklı kullanıcı farklı bir yanıt mı alıyor. Almıyorsa, build zamanında bir kez üretip herkese aynı dosyayı servis edebilirsiniz.

Statik olmanın getirdiği

Çalışan bir runtime yok, yani patlayacak, yamalanacak, güvenlik açığı çıkacak bir süreç yok. Yanıt süresi bir disk okuması, arka planda sorgu çalıştıran bir uygulama sunucusu değil. Cache basit, çünkü her şey zaten statik dosya. Rollback bir önceki immutable artifact’e geri dönmekten ibaret, veritabanı migration’ı geri almak gibi bir riski yok.

Bu blogu statik kurma kararını ve Coolify’da nasıl deploy ettiğimi bu blogu neden ve nasıl kurdum yazısında anlattım.

Rollback de aynı sadelikte. Statik sitede geri dönmek, bir önceki immutable imajı yeniden çalıştırmaktan ibaret; Coolify’da önceki deploy’u seçip yeniden başlatmak kadar basit ve veritabanı şeması değişmediyse saniyeler sürüyor. SSR’da aynı kolaylık yok: kod geri alınsa bile üzerinde çalıştığı veri modeli ileri gitmiş olabiliyor.

Statik olmanın bedeli

Yeni içerik yayımlamak bir rebuild gerektiriyor. Zamanlanmış bir içerik varsa, belirli bir saatte yayımlanacak bir yazı gibi, o saatte bir build tetiklenmesi lazım; cron ile ya da webhook ile. Sayfa sayısı arttıkça build süresi de artıyor, bin sayfalık bir site on sayfalıktan daha uzun sürede derleniyor.

Bu bedel çoğu blog ve dokümantasyon sitesi için küçük. On binlerce sayfalık bir e-ticaret kataloğunda ciddileşmeye başlıyor.

Cache farkı da gözden kaçmıyor. Statik dosya CDN’in edge’inde uzun süre tutulabiliyor, invalidation basit: yeni build, yeni dosya. SSR yanıtı varsayılan olarak cache’lenemez, çünkü her istek potansiyel olarak farklı. Cache eklemek isterseniz “hangi yanıt kaç saniye taze kalsın” sorusunu bu sefer SSR katmanında ayrıca çözmeniz gerekiyor.

SSR’ın gerçekten haklı olduğu yerler

Üç durum var: oturum açmış kullanıcıya özel bir alan, ziyaretçiye göre değişen kişiselleştirme, saniyesi saniyesine güncel olması gereken veri. Hesap sayfası ve sepet birinci gruba, fiyat ve stok kişiselleştirmesi ikinciye, canlı skor ya da anlık stok durumu üçüncüye giriyor. Bu üçünde yanıt gerçekten her istekte farklı, build zamanında üretilecek tek bir HTML yok.

Bunların dışında SSR seçmek, çözülmemiş bir performans ya da içerik güncelleme problemini runtime karmaşıklığıyla örtmek oluyor.

Astro’da bu bir ya hep ya hiç kararı değil

Astro’da site varsayılan olarak statik kalırken, sadece belirli route’lar prerender = false ile runtime’da render edilebiliyor:

export const prerender = false;

Bir e-ticaret sitesinde ürün sayfaları statik kalabiliyor, sepet ve ödeme sayfası runtime’da render edilebiliyor. Sitenin tamamını SSR’a taşımaya gerek yok, sadece gerçekten kişiselleştirilmiş sayfaları hedeflemek yeterli.

Karar tablosu

Özet

Statik ile başlayın. SSR’a geçmeden önce “bu sayfanın yanıtı ziyaretçiye göre değişiyor mu” sorusunu sorun, cevap hayırsa statik yeterli. Astro’da bu seçim site genelinde değil, route bazında yapılabilir.