Mimari ve Teslimat
Static Site Daha mı Hızlıdır?
"Statik site daha hızlıdır" cümlesi çoğunlukla doğrudur — ama mekanizması anlaşılmadan söylendiğinde beklentileri yanlış yönlendirebilir. Bir siteyi statik mimariye taşıyıp aynı görselleri, aynı üçüncü taraf script'leri ve aynı font yükleme stratejisini korursanız, Lighthouse skorunda ya da gerçek kullanıcı ölçümlerinde belirgin bir değişiklik görmeyebilirsiniz. Çünkü "statik" kelimesi teknik olarak sayfa üretim biçimini tanımlar; kullanıcının indirdiği dosyaların toplam boyutunu ya da tarayıcının bu dosyaları işleme süresini değil.
Statik sitenin performans avantajı belirli bir katmanda başlar ve orada kalır. Sunucu tarafında HTML üretim süresini ortadan kaldırır, bu da ilk bayt gecikmesini azaltır ve sunucu üzerindeki yükü hafifletir. Bu kazanım gerçektir ve ölçülebilir; ama hero görsel boyutu, JavaScript yükü ve render blocking kaynaklar gibi faktörler bu kazanımı kolayca gölgeleyebilir.
Bu avantajın nereden geldiğini, hangi koşullarda belirginleştiğini ve hangi içerik tiplerinde statik mimarinin sınıra dayandığını görmek, geçiş kararını gerçekçi bir zemine oturtmanın ön adımıdır.
Hız avantajının gerçek kaynağı
Statik bir sitede HTML dosyaları dağıtımdan önce üretilir. Kullanıcı sayfayı istediğinde sunucu veritabanına sorgu göndermez, şablon motorunu çalıştırmaz, oturum bilgisini doğrulamaz. Hazır dosyayı iletir. Bu süreç, dinamik bir sistemin istek başına yaptığı işlemlerin tamamını devre dışı bırakır.
Bu avantaj en çok yüksek eşzamanlı istek sayısında belirginleşir. Dinamik bir site yüzlerce eşzamanlı isteği işlerken veritabanı bağlantı havuzu dolabilir, sunucu bellek tüketimi artar, yanıt süresi uzar. Statik dosya sunmak ise neredeyse kaynak kullanmaz; ölçekleme problemi büyük ölçüde ortadan kalkar. Bu fark özellikle ani trafik artışlarında — bir haber sitesinin manşeti viral olduğunda ya da bir ürünün lansmanı gerçekleştiğinde — net biçimde gözlemlenir.
Önceden üretilmiş HTML ve teslimat zinciri
Statik üretim sürecinde tüm sayfalar build anında HTML dosyalarına dönüştürülür. Bu dosyalar bir CDN ağına yüklenir ve kullanıcıya en yakın edge düğümünden sunulur. Araya giren uygulama sunucusu katmanı yoktur.
Teslimat zinciri bu sayede kısalır: kullanıcı → CDN edge node → statik HTML dosyası. Dinamik sistemlerde bu zincir çok daha uzundur: kullanıcı → CDN (varsa) → load balancer → uygulama sunucusu → veritabanı → template engine → HTML üretimi → yanıt. İki zincir arasındaki fark, coğrafi olarak uzak kullanıcılar için ölçülebilir gecikme farkına dönüşür. Yakın kullanıcılar için ise bu fark daha çok yük altında kendini gösterir.
SSG ile SSR arasındaki temel ayrım
SSG (static site generation) sayfaları build anında üretir; SSR (server-side rendering) ise her istek için sunucuda render eder. İkisi de tarayıcıya HTML gönderir; fark üretim zamanındadır. SSG'de üretim maliyeti bir kez ödenir, dağıtımdan önce. SSR'de bu maliyet her istek tarafından ayrı ayrı taşınır.
Bu ayrım doğrudan ilk bayt gecikmesini etkiler. SSR'de sunucunun sayfayı render etmesi gerektiğinden gecikme SSG'ye kıyasla genellikle daha yüksektir. Ancak SSR'nin de vazgeçilmez avantajları vardır: gerçek zamanlı kişiselleştirme, istek anında güncel veri ve kullanıcıya özel içerik bunlar arasındadır. SSG build zamanı dışında bu özellikleri sunamaz. İkisi arasındaki seçim bir hız sorunudan çok bir içerik modeli sorunudur.
Edge dağıtımı ile statik sitenin ilişkisi
Statik sitenin performans avantajı, doğru dağıtım altyapısıyla katlanır. Statik dosyalar CDN edge düğümlerine dağıtıldığında edge cache mekanizması tam kapasitesiyle çalışır: HTML dahil tüm sayfa varlıkları coğrafi olarak dağıtılır ve origin'e hiç dönmeden yanıtlanabilir.
Dinamik bir sistemde aynı CDN kullanılsa bile her istek için origin'de HTML üretmek gerekiyorsa, CDN yalnızca ağ yolunu kısaltan bir katmana dönüşür. Edge'in asıl gücü — önbellekten yanıtlama — dinamik içerik için tam olarak devreye giremez. Statik dağıtım bu ikisini birleştirir ve CDN altyapısından alınabilecek maksimum kazanımı sağlar. Bu yüzden statik site ile CDN kombinasyonu performans açısından özellikle etkilidir.
İlk bayt gecikmesi üzerindeki doğrudan etki
TTFB — ilk baytın tarayıcıya ulaşması için geçen süre — statik mimariden en doğrudan etkilenen metriktir. Origin'de HTML üretimi olmadığında bu süre yalnızca ağ gecikmesine ve CDN edge yanıt süresine bağlıdır. İyi yapılandırılmış bir CDN ile bu değer küresel olarak 20–50 ms aralığına düşebilir.
Dinamik sistemlerde aynı metrik uygulama yanıt süresi, veritabanı sorgu süresi ve template render gecikmesinin toplamından oluşur. Optimize edilmiş bir dinamik sistem 100–200 ms'yi yakalayabilir; ama bu rakamla CDN üzerinden sunulan statik bir sayfanın rekabet etmesi güçleşir. Özellikle düşük bütçeli paylaşımlı sunucularda ya da veritabanı yoğun sayfalarda bu fark daha keskin biçimde ortaya çıkar.
Veritabanı ve uygulama katmanının devre dışı kalması
Statik mimaride çalışma zamanında veritabanı yoktur. Bu durum üç farklı performans kazanımı doğurur: istek başına sıfır veritabanı sorgu gecikmesi, bağlantı havuzu yönetimi maliyeti yok ve yüksek trafikte veritabanının tıkandığı senaryolar ortadan kalkar.
Bu kazanım özellikle içerik ağırlıklı sitelerde değerlidir: blog, belgelendirme portalı, pazarlama sayfaları, ürün katalogları. Bu sayfa tiplerinde içerik çoğunlukla değişmez ya da seyrek değişir; her istek için yeniden üretmek gereksizdir. Statik üretim tam da bu senaryolar için tasarlanmıştır ve bu kategori web'deki sayfaların büyük çoğunluğunu oluşturur.
Statik sitenin sınıra dayandığı nokta
Statik mimari her içerik problemi için geçerli değildir. Kullanıcıya özel içerik — sipariş geçmişi, kişiselleştirilmiş öneriler, oturum bazlı görünüm — build anında üretilemez. Anlık veri gerektiren içerikler de bu kapsamdadır: canlı stok bilgisi, gerçek zamanlı yorum akışı, anlık fiyat değişimleri.
Bu sınırı zorlamak için bazı ekipler statik sayfanın iskeletini sunup dinamik verileri istemci tarafında JavaScript ile sonradan yükler. Bu yaklaşım işe yarar ama bir trade-off getirir: LCP açısından sayfanın önemli içeriği JavaScript yüklenmesini bekleyebilir ve bu görünür içeriğin gecikmesine yol açar. Statik mimari seçiminin yalnızca sunucu tarafını değil, istemci tarafı render stratejisini de etkilediği bu noktada belirginleşir.
Kişiselleştirme ve oturum gerektiren içerik
E-ticaret sitelerinin büyük çoğunluğu bu sınırı somut biçimde yaşar. Ürün listeleme sayfası statik olarak üretilebilir; kullanıcının sepeti, önerilen ürünler ve indirim kuponları statik olarak üretilemez. Bu ayrımı doğru çizmek, hangi sayfaların statik mimari yerine SSR ya da istemci tarafı fetch gerektirdiğini belirler.
Bazı platformlar bu problemi edge fonksiyonlarıyla çözer: statik sayfa hızla sunulur, kişiselleştirme katmanı edge üzerinde çalışan küçük bir fonksiyon tarafından eklenir. Bu yaklaşım hem statik sitenin hız avantajını hem de kişiselleştirmeyi birlikte sunmayı hedefler. Ama karmaşıklığı artırır, her platform bu modeli eşit biçimde desteklemez ve hata ayıklaması daha zor hale gelir.
Hibrit yaklaşım: hangi sayfalar statik kalabilir
Çoğu gerçek site tam anlamıyla ne saf statik ne de tam dinamiktir. Hibrit mimariler belirli sayfa tiplerini statik, diğerlerini dinamik olarak işler. Ana sayfa, blog yazıları, ürün detay sayfaları statik; hesap, sipariş, arama sonuçları dinamik olarak yapılandırılabilir.
Bu yaklaşımı uygulamak için sayfa bazında üretim modelini kontrol eden bir routing katmanı gerekir. Next.js, Nuxt ve benzer framework'ler sayfa bazında SSG, SSR ve ISR (incremental static regeneration) arasında seçim yapılmasına izin verir. ISR özellikle dikkat çekicidir: statik sayfalar belirli aralıklarla ya da içerik değiştiğinde arka planda yeniden üretilir, kullanıcı her seferinde güncel bir statik sayfayla karşılaşır. Bu model TTFB avantajını büyük ölçüde korurken içerik güncellenme kısıtını da önemli ölçüde hafifletir.
Build süresi ve içerik güncellenme sıklığı dengesi
Statik üretimin en belirgin sınırlarından biri build sürecidir. Küçük bir blog için tüm sayfaları yeniden üretmek birkaç saniye alır. Binlerce ürün içeren bir katalog için aynı işlem dakikalar, hatta saatler sürebilir. Bu durum içerik güncellenme sıklığını doğrudan kısıtlar: saatte birkaç kez içerik güncellemesi planlıyorsanız ve build süreci 30 dakika alıyorsa, tam statik üretim bu ritmi karşılamaz.
Bu sorunu çözmek için ISR veya on-demand revalidation gibi mekanizmalar geliştirilmiştir. Yalnızca değişen sayfaların yeniden üretilmesi build süresini dramatik biçimde kısaltabilir. Ama bu mekanizmalar kendi yapılandırma karmaşıklığını getirir ve tam statik dağıtımın sadeliği kısmen kaybolur. Karar vermeden önce sitenin içerik güncellenme sıklığını gerçekçi biçimde değerlendirmek, hangi modelin uygun olduğunu büyük ölçüde belirler.
Araç ve altyapı seçimi
Statik site üretimi için onlarca araç bulunur: Hugo, Eleventy, Astro, Gatsby, Jekyll ve Next.js statik export bunların başında gelir. Bu araçların build süresi ve çıktı kalitesi birbirinden önemli ölçüde farklılaşır. Hugo binlerce sayfayı saniyelerde üretirken JavaScript ağırlıklı araçlar aynı içerik için çok daha uzun sürebilir. Araç seçimi yalnızca geliştirici deneyimini değil, CI/CD boru hattının pratikte ne kadar kullanışlı olacağını da etkiler.
Dağıtım altyapısı da sonucu doğrudan belirler. Statik dosyaları tek bir sunucudan sunan bir yapı, coğrafi avantajı büyük ölçüde kaybeder. Netlify, Vercel, Cloudflare Pages gibi platformlar otomatik CDN dağıtımı ve edge önbellek yönetimi sunduğundan statik sitenin performans potansiyelini kullanmayı kolaylaştırır. Bununla birlikte, CDN'in gerçek katkısı platforma bağlı değildir; TTL yapılandırması ve cache stratejisi burada da belirleyicidir.
Statik mimarinin LCP ve Core Web Vitals üzerindeki etkisi
Statik mimari TTFB'yi iyileştirir; ama bu iyileşmenin LCP üzerindeki etkisi her zaman orantılı değildir. LCP genellikle büyük bir görsel veya başlık bloğunun yüklenme süresine bağlıdır. HTML hızlı gelirse tarayıcı kaynakları erken keşfeder ve görselin yüklenmeye başlaması daha erken tetiklenebilir. Bu zincirleme etki gerçektir.
Ancak hero görseli 500 KB ise ve uygun formatta sunulmuyorsa, TTFB'deki 80 ms iyileşmesi LCP üzerinde yüzde birkaçlık bir kazanıma dönüşür. Lighthouse skorunu anlamlı biçimde iyileştirmek için statik mimariye geçiş tek başına yeterli değildir; görsel optimizasyonu, JavaScript yükü ve render blocking kaynaklar paralel olarak ele alınmalıdır. Mimari seçim performansın bir bileşenidir, tamamı değil.
Statik site, doğru senaryoda gerçek ve ölçülebilir bir hız kazanımı sağlar. Bu kazanım ağırlıklı olarak sunucu işlem süresinin ortadan kalkmasından ve edge dağıtımının tam kapasitesiyle çalışmasından gelir. İçerik ağırlıklı, seyrek güncellenen ve kişiselleştirme gerektirmeyen siteler için bu mimari büyük ölçüde uygundur.
Ama "statik site daha hızlıdır" önermesini evrensel bir kural olarak uygulamak yanıltıcıdır. Build süreci, içerik güncellenme sıklığı kısıtları ve kişiselleştirme gerektiren sayfalar için ek karmaşıklık — bunlar bu mimarinin gerçek maliyetleridir. Bu maliyetleri görmezden gelerek yapılan geçişler beklenen performans kazanımını getirmeyebilir, hatta geliştirme süreçlerini yavaşlatabilir.
En sağlıklı yaklaşım, sitenin içerik tiplerini ve güncelleme sıklığını değerlendirmek ve her sayfa türü için en uygun üretim modelini seçmektir. Tam statik, hibrit ya da tam dinamik — bu seçim bir prestij meselesi değil, içerik modelinin bir yansımasıdır.