İçeriğe geç
Blog'a dön

Statik site + CMS: en hızlı mimarinin anatomisi

·5 dk okuma·Vucod

Statik site cms kombinasyonu — yani içeriğin bir panelden yönetildiği ama sitenin önceden üretilmiş dosyalar olarak sunulduğu mimari — bugün bir web sitesinin alabileceği en yüksek hızın tarifidir. "Statik" kelimesi kulağa eski gelir; akla 1998'in el yazması HTML sayfaları gelir. Oysa modern statik mimari bunun tam tersidir: en güncel araçlarla kurulan, ama ziyaretçiye en sade biçimde sunulan bir sistem. Bu yazıda bu mimarinin anatomisini parça parça açacağız: yayınla butonuna bastığınız anda ne olur, ziyaretçi sayfayı istediğinde ne olmaz, ve bu yaklaşımın sınırları nerededir.

Önce sorun: klasik sitede her ziyaret bir üretimdir

WordPress gibi veritabanı tabanlı bir sitede sayfa, ziyaretçi istediği anda pişirilir. İstek gelir; PHP çalışır, veritabanına sorgular gider, tema motoru içeriği şablona döker, eklentiler sırayla devreye girer ve ortaya HTML çıkar. Bu zincir her ziyarette yeniden koşar. Önbellek eklentileri bu yükü azaltır ama zinciri ortadan kaldırmaz — ve önbellek katmanının kendisi yeni bir karmaşıklık kaynağıdır.

Buradaki gariplik şu: İçeriğiniz günde belki bir kez değişiyor, ama site o içeriği günde binlerce kez yeniden üretiyor. Statik mimarinin çıkış noktası bu israfı tersine çevirmektir: Madem içerik nadiren değişiyor, sayfayı içerik değiştiğinde bir kez üret, sonra herkese aynı hazır dosyayı ver.

Anatominin parçaları

1. İçerik katmanı: CMS

İçerik, headless bir CMS'te durur — yazıların, ürünlerin, sayfaların yönetildiği panel. Editör için deneyim klasik CMS'ten farksızdır: giriş yapar, metni değiştirir, kaydeder. Fark, bu panelin siteyi doğrudan sunmamasıdır; yalnızca içeriği tutar ve API'den verir.

2. Üretim katmanı: build

"Yayınla" dediğinizde devreye giren adım budur. Bir üretim süreci (build) çalışır: CMS'ten tüm içerik çekilir, tasarım şablonlarıyla birleştirilir ve sitenin her sayfası hazır HTML, CSS ve JavaScript dosyaları olarak üretilir. Yüz sayfalık bir kurumsal sitede bu süreç tipik olarak saniyeler ile bir-iki dakika arasında sürer. Bu süre editörü etkilemez; arka planda akar.

3. Dağıtım katmanı: CDN

Üretilen dosyalar tek bir sunucuya değil, dünyanın dört bir yanındaki uç sunuculara (CDN) kopyalanır. İstanbul'daki ziyaretçiye yakındaki sunucudan, Frankfurt'takine oradakinden servis yapılır. Ziyaret anında çalışan uygulama kodu ve veritabanı sorgusu yoktur; olan şey, hazır bir dosyanın en kısa yoldan iletilmesidir. Sayfaların milisaniyelerle ölçülen sürelerde açılmasının sırrı da budur: hız bir optimizasyon hilesi değil, mimarinin doğal sonucudur.

4. Tetikleyici: webhook

Zinciri tamamlayan küçük ama kritik parça: CMS'te içerik değiştiğinde, CMS üretim sürecine "yeniden üret" sinyali gönderir (webhook). Editör kaydeder, build çalışır, yeni dosyalar CDN'e yayılır. Editörün bu zincirin hiçbir halkasını bilmesi gerekmez; onun gördüğü şey "kaydettim, birkaç dakika içinde yayında" deneyimidir.

"Ama benim sitemde form var" — dinamik parçalar ne olacak?

Statik mimariye dair en yaygın yanılgı, "statik" kelimesinin "hiçbir şey yapamayan site" anlamına geldiği sanısıdır. Gerçekte statik olan sayfanın iskeletidir; üzerine dinamik parçalar eklenir:

  • Formlar: Form sayfası statiktir; gönderilen veri küçük bir API ucuna gider. Ziyaretçi farkı hissetmez.
  • Arama: Küçük ve orta sitelerde arama dizini build sırasında üretilir ve tarayıcıda çalışır; büyük sitelerde bir arama servisine bağlanılır.
  • Kişiselleştirme ve canlı veri: Döviz kuru, stok durumu gibi gerçekten canlı veriler, sayfa yüklendikten sonra API'den çekilir. Sayfanın iskeleti yine anında gelir; canlı parça içine oturur.

Yani doğru soru "statik mi dinamik mi" değil, "neyin her ziyaretçi için aynı olduğu, neyin değiştiği"dir. Aynı olan her şey önceden üretilir; değişen küçük parçalar API ile konuşur.

Bu mimarinin yan etkileri: güvenlik ve bakım

Hız, bu anatominin en görünür çıktısı ama tek çıktısı değil.

Güvenlik tarafında denklem basitleşir: Ziyaretçiye açık olan şey çalışan bir uygulama değil, dosyalardan ibarettir. SQL enjeksiyonu yapılacak bir veritabanı bağlantısı, açığı bulunacak bir eklenti yığını ortada yoktur. Yönetim paneli ayrı bir adreste yaşar. Saldırı yüzeyi sıfır değildir — hiçbir sistemde değildir — ama klasik kuruluma göre kıyaslanmayacak kadar küçüktür.

Bakım tarafında ise haftalık eklenti güncellemesi, sürüm uyumsuzluğu, "güncelleme sonrası site bozuldu" nöbetleri büyük ölçüde ortadan kalkar. Statik dosyaların bakımı diye bir şey yoktur; bakım yalnızca içerik katmanında ve üretim hattında, yani kontrollü ve küçük bir alanda yapılır.

Dürüst kısım: bu mimari nerede zorlanır?

Her mimarinin bedeli var; bunun da var.

  • Çok sık değişen, çok büyük siteler. On binlerce sayfası olan ve dakikada birkaç kez içerik değişen bir haber sitesinde her değişiklikte tüm siteyi yeniden üretmek verimsizleşir. Bunun çözümleri var — yalnızca değişen sayfayı üretmek gibi — ama kurulum karmaşıklaşır.
  • Yayın gecikmesi. İçerik kaydedildikten sonra yayına yansıması build süresi kadar bekler; genelde birkaç dakikadır. Çoğu kurumsal site için önemsizdir; saniye hassasiyetli yayıncılık için değildir.
  • Kurulum bir mühendislik işidir. Bu anatomi kendi kendine kurulmaz. Tema kur-çalıştır dünyasından gelen biri için başlangıç eşiği daha yüksektir. Bedel baştadır; klasik kurulumda ise bedel sona, bakım yıllarına yayılmıştır.

Ve klasik dürüstlük notumuz: Kişisel blogunuz veya küçük portfolyonuz için bu mimariyi kurmaya değmeyebilir; WordPress ya da bir site kurucu işinizi görür. Bu anatomi, hızın, güvenliğin ve düşük bakım yükünün gerçekten para ettiği siteler için anlamlıdır.

Editör bu mimaride ne kaybeder, ne kazanır?

İçerik girenlerin bu mimariden korkması gereksizdir; günlük deneyim çoğu klasik panelden daha sakindir. Kazanılan şey nettir: panel yalnızca içerik işine odaklanır, eklenti bildirimleri ve güncelleme uyarılarıyla dolu bir yönetim ekranı yoktur. Kaybedilen şey ise anlıktır: "Kaydet" ile "yayında" arasına build süresi girer. İyi bir kurulumda bunun için önizleme çözümü bulunur — editör değişikliği yayınlamadan önce sitenin birebir kopyasında görür. Bu önizlemenin varlığını kurulum aşamasında şart koşun; sonradan eklemek mümkündür ama baştan istemek bedavadır.

Kendi sitenize bakarken sorulacak sorular

Mevcut sitenizin bu mimariden kazanıp kazanmayacağını anlamak için üç soru yeter:

  1. İçeriğiniz ne sıklıkla değişiyor — günde bir mi, dakikada bir mi? Nadirse statik üretim doğal adaydır.
  2. Sayfalarınız bugün kaç saniyede açılıyor ve bu sizin işinizde bir şeye mal oluyor mu? Reklam trafiği alan, Google'dan müşteri kazanan siteler için cevap neredeyse her zaman "evet"tir.
  3. Geçen yıl siteniz için kaç saat güncelleme, yama ve onarım yapıldı? O saatlerin çoğu bu mimaride yoktur.

Vucod'da kurumsal siteleri tam bu anatomiyle kuruyoruz: headless CMS, statik build, CDN ve kendi yönetim panelimiz. Sitenizin bu yapıdan ne kazanacağını konuşmak isterseniz yazın; her başvuruya 48 saat içinde net bir cevapla dönüyoruz: vucod.com

Etiketler:statik site cmsstatik siteheadless cmscdnsite hızı