Statik site mi, içerik yönetim sistemi mi.

Statik site sayfaları önceden üretip dosya olarak sunar; içerik yönetim sistemi sayfaları istek anında veritabanından üretir.

Bu karar bir performans kararı gibi görünmüyor ama performansın en büyük tek belirleyicisi. İlk bayt süresi, ölçeklenme davranışı, güvenlik yüzeyi ve bakım maliyeti — dördü de bu tercihten türüyor. Ve karar proje başında verilip nadiren geri alınıyor.

Tartışma genelde yanlış eksende yapılıyor: hız karşısında kolaylık. Gerçek eksen farklı — içeriğin ne sıklıkla ve kim tarafından değiştiği.

Teknik fark

Bir içerik yönetim sistemi her istekte aynı işi tekrar yapar: veritabanını sorgular, şablonu işler, HTML üretir, gönderir. Statik bir site o işi bir kez yapar — yayın anında — ve sonrasında yalnız dosya gönderir.

Fark ilk bayt süresinde doğrudan görünüyor. Dosya göndermek, veritabanı sorgulayıp şablon işlemekten büyüklük mertebesinde ucuz. Bu sitenin canlı ölçümü 0,302 saniye ve yönettiği üç projede de değer 300 milisaniyenin altında.

İkinci fark ölçeklenmede: statik dosyalar kenar sunucularda sınırsız önbelleklenebilir çünkü her kullanıcı için aynıdır. Trafik on kat arttığında ölçeklenmesi gereken bir uygulama katmanı yok.

Üçüncüsü güvenlik: çalışan kod yoksa açık da yoktur. Veritabanı enjeksiyonu, eklenti açığı ve yönetim paneli saldırıları — üçü de statik bir sitede tanımsız.

Gerçek ödünleşim

Statik yaklaşımın bedeli kolaylıkta ve o bedel gerçek. İçerik değiştiğinde yeniden üretim gerekiyor; teknik olmayan bir editör için bu bir engel olabilir. Ve gerçekten dinamik içerik — oturum bazlı kişiselleştirme, canlı stok, kullanıcı yorumları — statik olamaz.

1. 01Statik uygun — tanıtım sitesi, belge, blog, vitrin, kampanya sayfası. İçerik seyrek değişir ve herkes için aynıdır.
2. 02Statik uygun değil — kullanıcı hesapları, sepet, canlı fiyat, kişiselleştirilmiş içerik.
3. 03Melez mümkün — sayfaların çoğu statik, yalnız değişen parçalar istemcide ya da kenar fonksiyonlarında.
4. 04Editör sorunu çözülebilir — üretim sürecine bağlanmış bir arayüz, editöre klasik panel deneyimi verebilir.
5. 05Karar ölçütü — içerik ne sıklıkla değişiyor ve kim değiştiriyor?

Üçüncü madde bugün en yaygın çözüm: sayfa gövdesi statik, yalnız gerçekten dinamik olan küçük parçalar ayrı ele alınıyor. Bu sitede tam olarak öyle — elli sekiz sayfa dosya olarak duruyor ve istek anında çalışan tek kod parçası iletişim formunun sunucu tarafı vekili.

Bakım tarafı

Uzun vadede en çok gözden kaçan fark bakım maliyeti. Bir içerik yönetim sistemi, sürekli güncellenmesi gereken bir yazılım yığınıdır: çekirdek, eklentiler, temalar, veritabanı ve çalışma ortamı. Her biri ayrı bir güncelleme ve ayrı bir kırılma riski.

Statik bir sitede yayına giden şey yalnız dosyalardır. Üretim aracı güncellenmezse bile yayındaki site çalışmaya devam eder — çünkü çalışan bir şey yok. Bu, üç beş yıl ayakta kalması gereken tanıtım siteleri için belirgin bir avantaj.

Bedeli ise şu: üretim zincirinin kendisi bir bağımlılıktır ve o zincir bozulursa yeni içerik yayımlanamaz. Zincirin basit ve az bağımlılıklı tutulması, bu riski küçültüyor.

Çalışan kod yoksa çöken kod da yoktur — ama üreten kod bozulursa yeni içerik de çıkmaz.

Geçiş: mevcut bir siteyi taşımak

Mevcut bir içerik yönetim sistemini statik yapıya taşımak, sanılandan sık karşılaşılan bir karar ve genelde kademeli yapılabiliyor. Tam geçiş yerine, sayfaların bir bölümünü statikleştirmek çoğu durumda faydanın büyük kısmını sağlıyor.

1. 01İçeriği dışa aktar — mevcut sistemin verisi yapılandırılmış bir biçime çevrilir.
2. 02URL yapısını koru — adresler değişirse birikmiş arama görünürlüğü kaybedilir; değişmek zorundaysa yönlendirme kurulur.
3. 03En çok trafik alan sayfalarla başla — kazanç oradan gelir.
4. 04Dinamik parçaları ayır — form, arama, yorum. Bunlar ayrı ele alınır.
5. 05Editör akışını çöz — teknik olmayan biri içerik değiştirebilmeli.
6. 06Ölçümü önce kur — geçişin işe yaradığını göstermek için öncesi ölçülmüş olmalı.

Son madde en çok atlananı ve en çok pişmanlık üretenidir: geçiş sonrası «daha hızlı oldu mu» sorusuna cevap verebilmek için öncesinin ölçülmüş olması gerekiyor. Sonradan kurulan bir ölçüm o karşılaştırmayı asla yapamaz.

İkinci madde ise geçişin en riskli tarafı. Adres yapısı değiştiğinde birikmiş dizinleme ve bağlantı değeri kaybolabiliyor; yönlendirme kurulsa bile bir kayıp yaşanıyor. Adresleri koruyabilmek, geçişin en değerli tasarım kısıtı.

Pratik kontrol listesi

Bu sayfanın anlattıklarını bir denetim adımına çevirmek gerekirse, mimari kararı için bakılacaklar şunlar. Liste kısa tutuldu çünkü uzun listeler yürünmüyor; altı madde bir oturumda tamamlanabilir.

1. 01İçerik ne sıklıkla değişiyor — günde mi, ayda mı?
2. 02Kim değiştiriyor — teknik biri mi, editör mü?
3. 03Gerçekten kişiselleştirilmiş içerik var mı?
4. 04Trafik dalgalanıyor mu — ölçeklenme bir sorun mu?
5. 05Bakım kapasitesi ne — güncelleme yükü kim taşıyacak?
6. 06Güvenlik yüzeyi ne kadar geniş olabilir?

İlk iki madde kararın büyük kısmını veriyor. Ayda birkaç kez, teknik olmayan biri tarafından değişen içerik için melez bir çözüm; günde defalarca, birçok kişi tarafından değişen içerik için klasik bir sistem daha uygun.

Kapanışta bir uyarı: bu karar bir ideoloji meselesi değil. Statik yaklaşımın savunucuları bazen onu her duruma uygun bir çözüm gibi sunuyor ve bu, kararı verecek kişiye zarar veriyor. Gerçekten dinamik bir sistemi statikleştirmeye çalışmak, ne performans kazandırıyor ne bakım kolaylaştırıyor — yalnız karmaşıklık ekliyor.

Doğru soru «hangisi daha iyi» değil, «benim içeriğim hangisine uyuyor». Cevap içeriğin değişim sıklığından ve kimin değiştirdiğinden çıkıyor; teknoloji tercihinden değil. Bu sitede cevap statikti çünkü içerik seyrek değişiyor ve değiştiren kişi teknik — başka bir projede aynı sorunun cevabı farklı olabilir ve olması da doğaldır.