Bir web sitesinin mimarisi, yalnızca sayfaların nasıl organize edildiğiyle değil, bu sayfaların nasıl üretildiğiyle de şekillenir. Jamstack ve statik site oluşturucular, son yıllarda bu üretim katmanını köklü biçimde dönüştürdü. Geleneksel sunucu taraflı render sistemlerinde her istek ayrı bir hesaplama tetiklerken, statik oluşturma yaklaşımı içeriği önceden derleyerek dağıtır.

Mimarı ilgilendiren soru şu: bu yaklaşım ne zaman doğru tercih, ne zaman gereksiz karmaşıklık, ne zaman sorun kaynağı? Next.js, Gatsby ve Astro gibi araçlar farklı tasarım öncelikleri taşır; hangisinin seçileceği sitenin sayfa yapısını, URL derinliğini ve içerik yönetim akışını doğrudan etkiler.

Bu sorunun cevabı araçların teknik özelliklerinde değil, sitenin içerik modelinde ve ziyaretçi davranışında gizlidir. Mimarı şekillendiren karar budur.

Jamstack'ın mimari vaadi: dağıtık içerik, merkezi olmayan sunucu

Jamstack, "JavaScript, API, Markup" kelimelerinin baş harflerinden oluşur; ancak mimari açıdan asıl belirleyici olan "Markup" katmanıdır. Sayfalar önceden derlenerek HTML dosyaları haline getirilir ve bir CDN ağından dağıtılır. Sunucu bir istek aldığında dinamik hesaplama yapmaz; önceden hazırlanmış dosyayı gönderir.

Bu tasarım, sitenin URL yapısı açısından kesin bir özellik getirir: her URL, derleme sırasında üretilmiş bir dosyaya karşılık gelir. /urunler/ayakkabi/ ve /urunler/canta/ sayfaları ayrı HTML dosyaları olarak var olur. URL hiyerarşisi yalnızca kavramsal değil, dosya sistemi düzeyinde gerçektir. Statik sitede bir sayfanın var olabilmesi için derleme sırasında bilinmesi gerekir; çalışma zamanında üretilmez.

Crawl bütçesi açısından bu yapının önemli bir sonucu vardır. Sunucu kaynağı tüketmeden yanıt veren sayfalarda bot davranışı değişir; CDN'den gelen hızlı yanıtlar tarama frekansını olumlu etkiler. Ama bu avantaj, yalnızca sayfa sayısı ve URL yapısı derleme mantığıyla tutarlıysa geçerlidir. Yüzlerce benzer parametre kombinasyonuyla dinamik URL üreten bir yapı, statik dosya üretme hızını aşar ve mimari avantajı tersine döner.

Statik site oluşturucuların URL ve hiyerarşi üzerindeki etkisi

URL yapısı, Jamstack projelerinde genellikle dosya ve klasör hiyerarşisiyle belirlenir. /blog/yazi-basligi/ gibi bir adres, çoğu araçta doğrudan blog/yazi-basligi/index.html dosyasına karşılık gelir. Bu örtüşme site mimarisini şeffaf hale getirir; klasör yapısı navigasyon hiyerarşisini yansıtır.

Ama bu şeffaflık bir kısıt da getirir. Dinamik bir sistemde URL yeniden yazma kuralları veya veritabanı sorguları aracılığıyla URL yapısı içerik modelinden bağımsız tutulabilir. Statik yapıda URL değişikliği yeniden derleme ve yeniden yayınlama gerektirir; çalışma zamanında yapılamaz. Büyük bir mimari değişiklik, binlerce sayfayı yeniden derlemek anlamına gelebilir.

Derleme süresi bu noktada stratejik bir değişkene dönüşür. On binlerce sayfası olan bir site için tam derleme saatler alabilir. Gatsby ve Next.js artımlı derleme özelliğini farklı biçimlerde sunar; yalnızca değişen içerik yeniden derlenir. Astro ise daha küçük ölçekli siteler için optimize edilmiş, daha basit bir derleme modeli kullanır.

Sayfa derinliği kararları da aracın paradigmasıyla şekillenir. Üç tıklama kuralı statik sitede de geçerliliğini korur; ancak her tıklama katmanı birer dosya klasörü anlamına geldiğinden, hiyerarşiyi düzleştirme ya da derinleştirme kararları aynı zamanda dosya organizasyonu kararıdır.

SSG, SSR ve hibrit mod: karar noktaları

Statik site oluşturucular yalnızca tam statik çözüm sunmaz. Next.js, sayfa bazında farklı render stratejisi seçmeye izin verir: bazı sayfalar derleme zamanında üretilirken (getStaticProps), bazıları her istekte sunucu tarafında render edilir (getServerSideProps), bazıları ise istemci tarafında dinamik içerik yükler.

Derleme zamanı üretimi değişmez içerik için güçlü seçimdir. Belge sayfaları, ürün katalog sayfaları, blog yazılarının büyük çoğunluğu bu kategoriye girer. İçerik günde birkaç kez güncelleniyor ve kişiselleştirme gerekmiyorsa, SSG (Static Site Generation) tam burada anlam kazanır: sunucu hesaplaması yoktur, CDN'den anında yanıt gelir, SEO tarama botları için bekleme süresi sıfıra yakındır.

Sunucu taraflı render gerektiren durumlar farklıdır. Kullanıcıya özgü içerik (hesap sayfaları, sipariş geçmişi), gerçek zamanlı değişen veri (fiyat, stok, hava durumu) veya kişiselleştirilmiş öneri sistemleri bu kategoriye girer. Bu sayfaları statik üretmek imkânsız değildir; "yeterince sık yeniden derleme" ile çalışılabilir, ama bu çözüm aracı yanlış kullanmak demektir.

Hibrit model, çoğu gerçek dünya sitesinin cevabıdır. Marketing sayfaları ve blog yazıları SSG, kullanıcı hesap bölümü SSR, arama sonuçları sayfası ise istemci taraflı render. Bu ayrımı tasarım aşamasında yapmak, sonradan düzeltmekten çok daha az maliyetlidir.

Next.js, Gatsby ve Astro: mimari seçim nasıl farklılaşır?

Araç seçimi yalnızca teknik tercih değildir. Her araç farklı bir mimari önceliği temsil eder.

Next.js, hibrit render için tasarlanmıştır. Sayfa bazında SSG, SSR ve ISR (Incremental Static Regeneration) arasında geçiş yapılabilir. Büyük ve karmaşık siteler için esnektir; ancak bu esneklik yapılandırma karmaşıklığı da getirir. Routing sistemi dosya tabanlıdır: pages/blog/[slug].js yapısı, /blog/herhangi-bir-slug/ adreslerini otomatik yönetir. Uygulama ağırlıklı siteler, e-ticaret platformları ve SaaS arayüzleri için doğal seçimdir.

Gatsby, içerik odaklı siteler için grafik tabanlı veri katmanı sunar. Farklı kaynaklardan (CMS, Markdown, API) gelen içerik tek bir veri grafiğiyle yönetilir. URL yapısı içerik modeline bağlıdır; ancak plugin sistemi bu bağı gevşetebilir. Binlerce statik sayfadan oluşan yayıncılık siteleri Gatsby ile iyi çalışır; derleme süreleri ise büyük sitelerde ayrıca planlanmalıdır.

Astro farklı bir yol izler. "Varsayılan sıfır JavaScript" prensibiyle sayfalar büyük ölçüde HTML olarak gönderilir; JavaScript yalnızca açıkça talep edildiğinde yüklenir. Bileşenler "ada" (island) modeliyle çalışır: sayfa içeriğinin büyük bölümü statik, yalnızca etkileşimli parçalar istemciye JavaScript gönderir. İçerik ağırlıklı siteler, dokümantasyon ve pazarlama sayfaları için hız açısından güçlü bir tercihdir.

Mimari seçim açısından kritik ayrım şudur: sitenin uygulama mantığı mı yoksa içerik yayıncılığı mı ağır basıyor? Uygulama ağırlıklıysa Next.js, saf içerik yayınıysa Astro ya da Gatsby düşünülebilir; ikisi birlikte varsa Next.js veya hibrit bir kurulum daha sağlam durur.

CDN katmanı ve tarama botları için anlamı

Statik içerik CDN üzerinden dağıtıldığında coğrafi dağılım otomatik hale gelir. Sunucu yanıt süresi (TTFB) sabit bir değer yerine, kullanıcının ağ altyapısına en yakın düğümden gelen süreyle belirlenir. Bu durum sayfa hızını etkiler; sayfa hızı da hem kullanıcı deneyimini hem tarama frekansını doğrudan etkiler.

Hız avantajı gerçektir. Ama koşula bağlıdır.

CDN cache politikası, içerik güncellemelerinde geçersiz kılma stratejisiyle uyumlu olmalıdır; aksi halde SEO tarama botları eski içeriği tarar. Büyük Jamstack sitelerinde derleme tetiklerinin yönetimi de dikkat ister. Headless CMS bir içerik değişikliğinde webhook aracılığıyla yeniden derleme başlatır; bu döngü küçük içerik değişiklikleri için derleme ve CDN cache temizleme süresini bekletir. Anlık içerik güncellemesi gerektiren yayın ortamları için bu gecikme kabul edilemez olabilir; ISR veya SSR daha uygun olur.

Sayfa derinliği ve tıklama sayısı statik sitelerde de aynı öneme sahiptir. Bir sayfaya ulaşmak için gereken tıklama sayısı crawl bütçesini etkiler; hiyerarşinin derinlerinde kalan sayfalara bot daha az ulaşır. Bu kural sunucu taraflı veya statik üretim fark etmeksizin geçerlidir.

Jamstack'ın avantaj getirmediği durumlar

Statik oluşturma her site için doğru değildir. Bazı durumlarda ekstra karmaşıklık getirir ama mimariye katkı sağlamaz.

Çok sık değişen içerik bu kategorinin başında gelir. Haber siteleri, borsa verileri veya canlı etkinlik sayfaları için yeniden derleme döngüsü anlamsız hale gelir. Her birkaç dakikada güncellenen bir sayfa için derleme ve yayınlama akışı işe yaramaz; sunucu taraflı render veya istemci taraflı veri çekme çok daha pratiktir.

Kişiselleştirme yoğun siteler de bu kategoriye girer. Kullanıcıya özgü içerik gösteren platformlarda statik sayfa üretimi yalnızca kabuk görevi görür; gerçek içerik istemci tarafında veya sunucuda doldurulur. Jamstack'ın CDN avantajı yalnızca HTML kabuğuna uygulanır; içerik yine dinamik kaynaktan gelir.

Arama ve filtreleme ağırlıklı siteler de dikkat gerektirir. Binlerce filtre kombinasyonu için statik sayfa üretmek mümkün değildir; istemci taraflı arama veya API tabanlı sonuçlar kullanılır. Ancak bu durum URL yapısını karmaşıklaştırır: filtrelenmiş sonuçların adresi çoğunlukla indekslenemez hale gelir ya da özel yapılandırma gerektirir. Veritabanı yazma işlemleri de ayrıca ele alınmalıdır; form gönderme, yorum ekleme, sepete atma gibi işlemler sunucu taraflı API gerektirir, bu da "statik site" kavramını genişletir.

Büyüyen site ve içerik yönetimi: ölçekleme kararları

Küçük bir site için başlangıçta seçilen araç, içerik arttıkça sorun çıkarabilir. Yüz sayfa için hızlı çalışan derleme süreci, on bin sayfada darboğaz haline gelebilir. Bu riski baştan yönetmek, araç seçiminin ötesinde içerik mimarisi kararları gerektirir.

Sayfa türlerini açıkça ayırmak bu kararların başında gelir. Hangi sayfalar statik üretilmeli, hangileri çalışma zamanında render edilmeli, hangileri CDN'de uzun süre cache'de tutulabilir; bu soruların cevabı içerik modeli tamamlanmadan verilmemelidir.

Headless CMS tercihinin de mimari sonuçları vardır. İçerik modeli CMS tarafında ne kadar karmaşık tanımlanırsa, derleme sırasında veri çekme ve dönüştürme süreci de o kadar ağırlaşır. Sade içerik modelleri derlemeyi hızlandırır; ancak içerik ihtiyaçları büyüdükçe model karmaşıklığı kaçınılmaz olur. Bunu yönetmenin yolu, içerik türlerini bağımsız yapıda tutmak ve gereksiz ilişkiler kurmamaktır.

Çok dilli siteler için ölçek kararı daha kritik bir hal alır. Her dil için ayrı sayfa seti üretmek derleme süresini çarpar; [lang]/[slug]/ gibi URL yapıları hem çoklu dil yönetimini hem hiyerarşiyi karmaşıklaştırır. Küçük bir sitede bu sorun görünmez; büyüdükçe mimari baskı haline gelir.

Araç seçimi başlangıç noktasıdır, asıl belirleyici değildir. Doğru araç, iyi tanımlanmış bir içerik modeliyle ölçeklenir; kötü tanımlanmış model ise en güçlü araçla bile şişer ve yavaşlar. Jamstack'ın mimari katkısı, içerik yapısına getirdiği disiplinde yatar; bu disiplin olmadan avantaj da yoktur.