Statik Site Üreticilerinin Hız Avantajı

Bir WordPress sayfası açıldığında arka planda şunlar olur: PHP yorumlayıcısı çalışır, onlarca eklenti yüklenir, veritabanına düzinelerce sorgu gider, şablon motoru HTML üretir ve ancak ondan sonra ilk bayt kullanıcıya yola çıkar. Statik bir sitede ise sunucunun tek işi diskteki hazır bir .html dosyasını okuyup göndermektir. Statik site üreticilerinin hız avantajı, karmaşık bir mühendislikten değil, tam olarak bu farktan doğar: yapılmayan iş, hiçbir zaman optimize edilmesi gerekmeyen iştir.

Bu yazıda statik üretimin hızı nereden aldığını somut sayılarla açıklayacak, popüler üreticileri karşılaştıracak, form ve arama gibi "ama bunlar dinamik" denen ihtiyaçların statik bir sitede nasıl çözüldüğünü göstereceğim. Ayrıca statik yaklaşımın gerçekten uygun olmadığı durumları da dürüstçe sıralayacağım; çünkü her siteyi statik yapmaya çalışmak, en az her siteyi dinamik yapmak kadar hatalıdır.

Statik Site Ne Demek#

Statik site, sayfaların ziyaretçi istediği anda değil, önceden üretildiği bir yaklaşımdır. İçeriğinizi genellikle Markdown dosyalarında ya da bir başsız (headless) içerik sisteminde tutarsınız; bir derleme (build) komutu bu içeriği şablonlarla birleştirip her sayfa için hazır HTML dosyaları üretir. Sunucuya çıkan şey bir uygulama değil, bir klasör dolusu dosyadır.

Bu, "eski usul HTML sitesi" demek değildir. Statik site üreticileri size şablon kalıtımı, kısmi bileşenler, otomatik site haritası, etiket ve kategori sayfaları, RSS, görsel işleme ve içerik koleksiyonları gibi modern araçlar sunar. Fark şurada: bu işlerin hepsi derleme zamanında bir kez yapılır, her ziyaretçi için tekrar tekrar değil.

Karar verirken üç mimariyi yan yana koymak faydalıdır:

Statik ile dinamik arasındaki ara katmanı merak ediyorsanız, sayfanın sunucuda ama istek anında üretildiği yaklaşımı sunucu tarafı render (SSR) nedir yazısında; istemci tarafıyla kıyaslamasını ise SPA ve SSR performans karşılaştırması yazısında bulabilirsiniz.

Hız Avantajı Tam Olarak Nereden Geliyor#

Statik sitenin hızı tek bir sihirli özellikten değil, birbirini besleyen dört etkiden gelir.

Birincisi: sıfıra yakın TTFB. İlk bayt süresi, sunucunun yanıt üretmek için harcadığı zamandır. Dinamik bir sayfada bu süre PHP çalıştırma ve veritabanı sorgularının toplamıdır; statik bir dosyada ise yalnızca diskten okuma ve ağa yazma süresidir. Farkı kendiniz ölçebilirsiniz:

# Aynı sunucuda dinamik ve statik bir sayfayı karşılaştır
curl -s -o /dev/null -w "dinamik ttfb: %{time_starttransfer}s\n" https://firmaniz.com/blog/ornek-yazi
curl -s -o /dev/null -w "statik  ttfb: %{time_starttransfer}s\n" https://firmaniz.com/statik/ornek.html

TTFB doğrudan LCP'nin içine girdiği için buradaki her yüz milisaniye, kullanıcının içeriği görme süresinden düşer.

İkincisi: tam CDN uyumluluğu. Statik bir dosyanın kişiye özel hiçbir yanı yoktur, dolayısıyla tamamı kenar sunucularda önbelleklenebilir. Ziyaretçi sayfayı kendi ülkesindeki bir düğümden alır ve kaynak sunucunuza hiç dokunmaz. Dinamik bir sayfada ise oturum, sepet ve kişiselleştirme yüzünden bu her zaman mümkün değildir. CDN'in ne zaman gerçekten fark yarattığını CDN mi daha iyi hosting mi yazısında karşılaştırdım.

Üçüncüsü: öngörülebilir performans. Dinamik sitede yanıt süresi yük altında bozulur; 10 eşzamanlı kullanıcıda 300 ms olan sayfa, 200 kullanıcıda 3 saniyeye çıkabilir çünkü PHP havuzu ve veritabanı doygunluğa ulaşır. Statik dosyada böyle bir eğri yoktur; Nginx tek çekirdekle binlerce statik isteği aynı hızda karşılar.

Dördüncüsü: agresif önbellekleme imkânı. Statik üreticiler varlık dosyalarına içerik özeti (hash) ekleyerek adlandırır. Dosya adı içeriğe bağlı olduğu için, dosyayı bir yıl boyunca önbelleklemek güvenlidir; içerik değişince dosya adı da değişir.

# İçerik özetli varlıklar: uzun ve değiştirilemez önbellek
location ~* "-[a-f0-9]{8,}\.(css|js|woff2|webp|avif)$" {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

# HTML: kısa önbellek, her zaman doğrulansın
location ~* \.html$ {
    add_header Cache-Control "public, max-age=0, must-revalidate";
}

Paylaşımlı hosting kullanıyorsanız aynı kuralları .htaccess ile de kurabilirsiniz; ayrıntısı htaccess önbellek ve sıkıştırma yazısında.

Popüler Statik Site Üreticileri#

Seçim yaparken "hangisi daha hızlı" sorusundan çok, hangi ekosistemde rahat çalıştığınız belirleyicidir. Üretilen HTML her durumda statiktir; fark derleme hızında ve geliştirici deneyimindedir.

Binlerce sayfalık bir arşiviniz varsa derleme hızı gerçek bir kriter olur; bu ölçekte Go tabanlı Hugo belirgin biçimde öne çıkar. Birkaç yüz sayfalık projelerde ise fark hissedilmez ve tercih tamamen rahatlığa kalır.

Hugo ile bir siteyi ayağa kaldırmak birkaç komuttur:

# Kurulum (Debian/Ubuntu) ve yeni site
sudo apt install -y hugo
hugo new site firmaniz-site && cd firmaniz-site

# İçerik ekle
hugo new content/blog/ilk-yazi.md

# Geliştirme sunucusu (canlı yenileme ile)
hugo server -D

# Üretim derlemesi: çıktı public/ klasörüne
hugo --minify --gc

Eleventy tarafında akış benzerdir:

npm init -y && npm install --save-dev @11ty/eleventy

# Geliştirme
npx @11ty/eleventy --serve

# Üretim derlemesi: çıktı _site/ klasörüne
npx @11ty/eleventy

Yayın Akışı: Derle ve Gönder#

Statik sitenin dağıtımı, dinamik bir siteye göre çok daha basittir çünkü sunucuda çalıştırılacak bir şey yoktur. En yalın akış şudur:

1. İçeriği ve şablonları bir sürüm kontrol deposunda tutun.
2. Derleme komutunu çalıştırıp çıktı klasörünü üretin.
3. Çıktıyı sunucudaki web köküne senkronize edin.
4. Gerekiyorsa CDN önbelleğini temizleyin.

Elle yapıyorsanız rsync bu iş için ideal aracıdır:

# Derle
hugo --minify --gc

# Sunucuya gönder; --delete silinen sayfaları hedefte de siler
rsync -avz --delete ./public/ [email protected]:/home/kullanici/htdocs/firmaniz.com/

# Yalnızca neyin değişeceğini görmek için önce prova yapın
rsync -avzn --delete ./public/ [email protected]:/home/kullanici/htdocs/firmaniz.com/

--delete bayrağı güçlü ama tehlikelidir: hedef yolu yanlış yazarsanız orada ne varsa siler. Bu yüzden gerçek gönderimden önce -n (prova) ile bir kez çalıştırmayı alışkanlık haline getirin.

Sunucu tarafında Nginx yapılandırması da sadeleşir; PHP-FPM, veritabanı bağlantısı ya da uygulama süreci yoktur:

server {
    listen 443 ssl;
    http2 on;
    server_name firmaniz.com;
    root /home/kullanici/htdocs/firmaniz.com;
    index index.html;

    # /hakkimizda -> /hakkimizda/index.html
    location / {
        try_files $uri $uri/ $uri.html $uri/index.html =404;
    }

    error_page 404 /404.html;

    gzip on;
    gzip_types text/css application/javascript application/json image/svg+xml;
}

Dinamik İhtiyaçları Statik Sitede Çözmek#

"Ama benim formum / aramam / yorumlarım var" itirazı en sık duyulanıdır ve çözülebilir bir itirazdır. Statik olmak, sitenin hiçbir dinamik yeteneği olmayacağı anlamına gelmez; dinamik parçaların sayfa üretiminden ayrılması anlamına gelir.

Formlar. İletişim ve talep formları, HTML formunu bir uç noktaya gönderecek şekilde kurulur. Bu uç nokta ya küçük bir sunucu betiği ya da harici bir form servisi olabilir. Sayfa yine statiktir, yalnızca gönderim dinamiktir.

Arama. Küçük ve orta ölçekli sitelerde arama, derleme zamanında üretilen bir JSON indeksi ile tarayıcıda yapılır. Birkaç yüz sayfalık bir site için indeks dosyası birkaç yüz kilobayttır ve arama anında, sunucuya hiç gitmeden çalışır.

# Derleme sırasında basit bir arama indeksi üretmek
# (başlık + açıklama + yol) — gövdeyi indekse koymayın, dosya şişer
find ./content -name "*.md" -exec head -20 {} \; > /tmp/ham-icerik.txt

Büyük arşivlerde ise indeksi tarayıcıya taşımak yerine harici bir arama servisi kullanmak daha doğrudur; birkaç bin sayfadan sonra istemci tarafı arama hem yavaşlar hem de gereksiz bayt indirtir.

Yorumlar. Yorumları harici bir servisle ya da kendi küçük API'nizle yükleyebilirsiniz; sayfa statik kalır, yorumlar sayfa açıldıktan sonra çekilir.

Sık değişen veri. Fiyat, stok durumu ya da döviz kuru gibi bilgiler sayfaya gömülmez; sayfa yüklendikten sonra küçük bir API isteğiyle güncellenir. Böylece sayfanın kendisi saatlerce önbellekte kalabilirken veri güncel olur.

Sınırlar, Maliyet ve Sık Yapılan Hatalar#

Statik yaklaşımın iki gerçek sınırı vardır ve bunları görmezden gelmek sonradan pahalıya patlar.

Birincisi ölçek. Sayfa sayısı arttıkça derleme süresi de artar. Yüz binlerce ürünlü bir kataloğu her küçük değişiklikte baştan üretmek pratik değildir. Bu ölçekte ya artımlı derleme (yalnızca değişen sayfaları üretmek) ya da statik ile sunucu tarafı üretimi karıştıran bir yaklaşım gerekir.

İkincisi kişiselleştirme. Her kullanıcıya farklı görünen bir sayfayı önceden üretemezsiniz. Giriş yapmış kullanıcı paneli, sepet içeriği ve kullanıcıya özel öneriler doğası gereği istek anında üretilmelidir.

Maliyet tarafında ise avantaj nettir: veritabanı yok, uygulama süreci yok, PHP havuzu yok. Aynı trafiği taşımak için gereken sunucu kaynağı belirgin biçimde düşer ve trafik zirvelerine karşı dayanıklılık artar. Güvenlik tarafında da yüzey daralır: çalıştırılabilir kod olmadığı için SQL enjeksiyonu, eklenti açığı ve yönetim paneli saldırısı gibi klasik vektörlerin çoğu kendiliğinden ortadan kalkar. Yine de bu "hiç güvenlik gerekmez" demek değildir; sunucunuzun kendisi, DNS'iniz ve derleme hattınız hâlâ korunmalıdır.

Sık yapılan hatalara gelince:

Derleme çıktısını sürüm kontrolüne eklemek. Üretilen HTML klasörünü depoya koymak, her derlemede devasa farklar üretir ve depoyu şişirir. Yalnızca kaynak dosyaları izleyin.

Yayınlanan HTML'de yorum bırakmak. Şablonlarınızdaki geliştirici yorumları üretilen HTML'e aynen geçer ve ziyaretçiye görünür hale gelir; iç dosya yolları ve altyapı ayrıntıları böyle sızar. Derleme adımında yorumları temizleyin.

Görselleri elle yönetmek. Statik üreticilerin çoğu derleme sırasında görselleri yeniden boyutlandırıp modern formata çevirebilir. Bunu kullanmayıp 3 MB'lık fotoğrafları olduğu gibi yayınlarsanız, kazandığınız TTFB avantajını görsel ağırlığıyla geri verirsiniz.

Yönlendirmeleri unutmak. Dinamik bir siteden statiğe geçerken eski URL yapınız değişiyorsa, her eski adres için 301 yönlendirmesi kurun. Statik sunucuda bunu web sunucusu yapılandırmasında ya da .htaccess içinde tanımlarsınız; kuralları htaccess yönlendirme üretici aracıyla hazırlayabilirsiniz.

Site haritasını ve lastmod değerlerini otomatikleştirmemek. Statik üreticiler bunu derleme sırasında üretebilir; elle yönetilen bir site haritası kaçınılmaz olarak bayatlar.

Sıkça Sorulan Sorular#

Statik site gerçekten dinamikten hızlı mı#

Sunucu tarafı için evet ve fark genellikle büyüktür: dinamik bir sayfanın ilk bayt süresi yüzlerce milisaniye olabilirken, statik bir dosyada bu değer onlarca milisaniyeye iner. Ancak toplam sayfa hızı yalnızca TTFB'den ibaret değildir; statik bir siteye 4 MB'lık görseller ve 500 KB JavaScript koyarsanız yine yavaş olur. Statik üretim size iyi bir başlangıç zemini verir, ön yüz disiplinini yerine getirmenizi gerektirir.

Statik site üreticisiyle blog yönetmek zor mu#

Alışma dönemi vardır. İçeriği bir yönetim panelinden değil, Markdown dosyaları olarak yazarsınız ve yayınlamak için bir derleme adımı gerekir. Teknik olmayan bir ekip için bu ilk başta yavaşlatıcı gelebilir. Çözüm, başsız bir içerik yönetim sistemi ya da Git tabanlı bir editör arayüzü eklemektir; yazar tanıdık bir arayüzde çalışır, arka planda derleme otomatik tetiklenir.

İçeriğimi güncellediğimde site ne kadar sürede yayına girer#

Derleme süresi kadar sürer ve bu, üreticiye ve sayfa sayısına göre değişir. Birkaç yüz sayfalık bir sitede Go tabanlı bir üreticiyle derleme genellikle saniyeler sürer; binlerce sayfalık Node tabanlı bir kurulumda bu birkaç dakikaya çıkabilir. Buna bir de dosyaların sunucuya gönderilmesi ve CDN önbelleğinin temizlenmesi eklenir. Anında güncelleme gereken içerikler için sayfayı statik tutup veriyi API'den çekmek daha doğrudur.

Statik site için nasıl bir hosting gerekir#

Çalıştırılacak bir uygulama olmadığı için ihtiyaç oldukça mütevazıdır: dosyaları servis edebilen herhangi bir web sunucusu yeterlidir. Paylaşımlı bir hosting paketi çoğu statik site için fazlasıyla yeter ve PHP/veritabanı kaynaklarını hiç kullanmadığınız için aynı pakette çok daha yüksek trafik taşırsınız. Derlemeyi kendi sunucunuzda otomatik yapmak isterseniz Node ya da Go çalıştırabileceğiniz bir sanal sunucu tercih edin.

Statik siteye form nasıl eklerim#

İki yaygın yol var. Birincisi harici bir form servisi kullanmak: HTML formunuzun action adresini servise yönlendirirsiniz, gönderim onların sunucusunda işlenip size e-posta olarak ulaşır. İkincisi kendi küçük uç noktanızı yazmak: bir sunucuda çalışan basit bir betik formu alır, doğrular ve e-postayla iletir. İkinci yol daha fazla kontrol verir; her iki durumda da sayfanın kendisi statik kalır ve hız avantajı korunur.

WordPress sitemi statik hale getirebilir miyim#

Evet, bunun için WordPress'i yalnızca yazı yazdığınız arka uç olarak tutup üretilen sayfaları statik HTML'e dönüştüren yaklaşımlar var. Böylece tanıdık editörü kullanmaya devam eder, ziyaretçilere ise statik dosya servis edersiniz; hem hız hem güvenlik ciddi biçimde artar. Sınırı şudur: yorum, üyelik, sepet gibi istek anında değişen özellikler bu modelde ya devre dışı kalır ya da harici bir servise taşınır. Sitenizde bu tür özellikler yoksa dönüşüm oldukça temiz ilerler.

Kapanış#

Statik site üreticilerinin hız avantajı, yeni bir teknolojiden değil, işi doğru zamanda yapmaktan gelir: sayfayı ziyaretçi beklerken değil, derleme sırasında bir kez üretirsiniz. Aklınızda kalması gereken dört madde: TTFB'yi onlarca milisaniyeye indirmek en büyük tek kazançtır; statik dosyalar tümüyle CDN'den servis edilebilir; içerik özetli dosya adlarıyla bir yıllık önbellek güvenle kullanılabilir; ve dinamik ihtiyaçlar sayfayı değil, yalnızca veriyi dinamik yaparak çözülür.

Statik bir siteyi yayınlamak için ağır bir altyapıya ihtiyacınız yok — web hosting paketlerimiz hazır HTML servisi için fazlasıyla yeterli ve PHP kaynağı harcamadığınız için aynı pakette çok daha yüksek trafik taşırsınız. Derleme adımını kendi sunucunuzda otomatikleştirmek isterseniz tam root erişimli VDS ve bulut sunucu paketlerimiz uygundur. Mevcut dinamik sitenizi bu yapıya taşırken yönlendirme ve DNS tarafında destek isterseniz site taşıma ve sunucu yönetimi hizmetlerimizden yararlanabilirsiniz.