Türk Hosting Şirketlerinde TTFB Karşılaştırması

TTFB'nin bileşenleri ve hosting karşılaştırmasındaki yeri

TTFB tek bir sayı gibi görünse de birden fazla katmanın toplamıdır. DNS çözümleme, TCP bağlantı kurma, TLS el sıkışması ve sunucunun yanıt üretmesi - bu aşamaların tamamı ölçüme girer. Chrome DevTools'un Network sekmesinde bir kaynağa tıklayınca gördüğünüz "Waiting (TTFB)" satırı, sunucunun isteği almasından ilk byte'ı göndermesine kadar geçen süreyi gösterir.

Hosting karşılaştırması yapılırken bu bileşenlerin ayrıştırılması gerekir. DNS çözümleme süresi, kullanılan nameserver altyapısına bağlıdır; ikisi arasında büyük fark olmadığı sürece karşılaştırmayı çok etkilemez. TLS el sıkışması sertifika zinciri uzunluğuna ve sunucunun TLS yapılandırmasına göre değişir. Asıl farkın oluştuğu yer "sunucu işleme süresi" kısmıdır: PHP'nin çalıştığı, veritabanı sorgularının tamamlandığı ve HTML çıktısının oluşturulduğu aşama.

Önbellek durumu TTFB'yi kökten değiştirir. Önbelleklenmiş bir yanıt döndüren istek ile dinamik olarak üretilen bir yanıt birbirleriyle kıyaslanamaz. Bir sağlayıcıda sunucu tarafı önbellekleme aktifken diğerinde yoksa, aslında hosting değil önbellek karşılaştırılmış olur. TTFB düşük ama FCP yüksek kaldığında render zincirini incelemenin yöntemi farklı bir konu olmakla birlikte, önbellekleme durumu her iki soruyu da etkileyen ortak değişkendir.

Bazı hosting sağlayıcılarının kontrol panelleri "sunucu yanıt süresi" olarak gösterdiği değer, gerçek TTFB'den farklı olabilir. Panel içindeki iç ağ üzerinden ölçülen değerler, gerçek kullanıcıların deneyimlediği ağ yolculuğunu yansıtmaz. Karşılaştırma için bağımsız bir konumdan yapılan HTTP istekleri çok daha güvenilir sonuç verir.

Aynı WordPress kurulumu neden farklı TTFB üretir?

Özdeş bir WordPress kurulumunu iki farklı sağlayıcıya taşıdığınızda TTFB'yi belirleyen şey donanım kapasitesi değil, teknik yapılandırmanın bütünüdür. Bu yapılandırmayı oluşturan dört ana değişken vardır.

PHP sürümü ve OPcache yapılandırması birinci sıradadır. PHP 8.1 veya üstü, 7.4 ile kıyaslandığında aynı yükü çok daha kısa sürede işler; fakat sürüm tek başına yeterli değildir. OPcache etkin ve doğru boyutlandırılmış değilse PHP her istekte betikleri yeniden ayrıştırır. OPcache yanlış yapılandırılmış bir PHP 8.2 ortamı, doğru ayarlanmış bir PHP 8.0 ortamından daha yavaş çalışabilir.

İkinci değişken veritabanı katmanıdır. WordPress, her sayfa yüklemesinde onlarca sorgu gönderebilir. Paylaşımlı ortamda MySQL sunucusu aynı anda onlarca müşterinin yükünü taşır; bu sunucunun yapılandırması, sorgu önbellekleme (query cache) durumu ve depolama motoru seçimi TTFB'ye doğrudan yansır. Bazı sağlayıcılar MariaDB kullanır, bazıları MySQL'in daha güncel sürümlerini tercih eder; bu seçim de işlem süresini etkiler.

Üçüncü değişken web sunucusu yazılımıdır. Nginx ile Apache arasındaki fark yoğun trafik altında belirginleşir; ama paylaşımlı hosting ortamında LiteSpeed Enterprise kullanan sağlayıcılar, Apache üzerinde çalışan .htaccess tabanlı yapılandırmalara kıyasla çoğu durumda daha düşük TTFB üretir. LiteSpeed Cache eklentisinin sağladığı avantaj büyük ölçüde bu sunucu katmanıyla doğrudan entegrasyondan kaynaklanır.

Dördüncüsü kaynak tahsis politikasıdır. Paylaşımlı hosting, tanımı gereği aynı sunucuda birden fazla hesabın çalışması demektir. Bazı sağlayıcılar her hesaba CPU ve bellek üst sınırı uygular; sınır aşılınca işlemler yavaşlar. Bu sınırın nerede çizildiği ve sağlayıcının sunucuyu ne kadar kalabalık tuttuğu, gece yarısı ile iş saatleri arasındaki TTFB farkını belirleyen başlıca etkendir.

Geçerli bir karşılaştırma testi için metodoloji

Karşılaştırmanın geçerliliği, test koşullarının tutarlılığına bağlıdır. Farklı sağlayıcılardaki iki siteyi ölçerken tek bir değişken farklılaşmalıdır: hosting altyapısı. Tema, eklenti listesi, WordPress sürümü, içerik hacmi ve önbellek yapılandırması özdeş olmalıdır.

Önbellek meselesini net çözmek gerekir. Karşılaştırmayı önbelleksiz (dinamik) yanıtlar üzerinden yapmak istiyorsanız her iki sitede de sunucu tarafı önbelleklemeyi devre dışı bırakmanız ve isteği önbelleksiz göndermeniz gerekir. HTTP isteğine Cache-Control: no-cache başlığı eklemek veya URL'ye rastgele bir sorgu parametresi eklemek önbellek atlatmanın yaygın yöntemidir. Önbellekli yanıtları karşılaştırıyorsanız her iki sitede de önbelleğin soğuk değil ısınmış durumda olduğundan emin olun; ilk istek her zaman daha yavaştır.

Ölçümü tek seferlik değil, tekrarlı yapın. Medyan değer, ortalamadan daha güvenilirdir; uç değerler ortalamayı bozar. Beş veya on tekrarlı ölçümün medyanı, gerçek tablo hakkında çok daha net bilgi verir.

Ölçüm konumu Türkiye'den olmalıdır. Yerli sağlayıcıların veri merkezleri çoğunlukla İstanbul veya Ankara'dadır; bir Avrupa sunucusundan yapılan test bu coğrafi avantajı gizler. Curl komutuyla İstanbul'daki bir sunucudan ölçüm yapabilir ya da Türkiye lokasyonu sunan ağ test hizmetlerini kullanabilirsiniz.

Zaman dilimi de önemlidir. Türk hosting sağlayıcılarının paylaşımlı planları, öğle saatlerinde ve akşam yoğun saatlerinde gece yarısına göre farklı TTFB üretebilir. Karşılaştırmayı yalnızca bir zaman dilimine dayandırmak yanıltıcı olur; birden fazla saatte alınan ölçümler daha sağlam bir tablo oluşturur.

Web sunucusu yazılımının TTFB üzerindeki etkisi

Apache, Nginx ve LiteSpeed Enterprise, Türk hosting sağlayıcılarının yaygın kullandığı üç web sunucusudur. Bu yazılımlar arasındaki fark, statik dosya sunumunda değil dinamik PHP işlemede belirginleşir.

Apache, her istek için .htaccess dosyalarını disk üzerinde arar. Derin klasör yapılarında bu arama zincirlenir; her dizin katmanında bir disk okuma gerçekleşir. Nginx'te böyle bir yapı yoktur; yapılandırma belleğe yüklenir ve disk erişimi olmadan çalışır. Bu fark, eklenti yoğun WordPress kurulumlarında ölçülebilir bir etki yaratır.

LiteSpeed Enterprise, Apache yapılandırmasıyla uyumlu çalışırken kendi önbellek katmanını sunucu seviyesinde uygular. Sayfa önbelleği eklentiye ihtiyaç duymadan LiteSpeed üzerinde çalışabilir; bu katman PHP sürecini tamamen devre dışı bırakır ve statik dosya hızında yanıt üretir. Eklenti tabanlı önbellekleme çözümleriyle karşılaştırıldığında sunucu tarafı entegrasyon çoğu durumda daha tutarlı sonuç verir. Reverse proxy katmanının performansa etkisi de benzer bir mantıkla çalışır: PHP işlemini bypass etmek TTFB'yi küçük değil, ciddi biçimde azaltır.

Paylaşımlı hosting bağlamında web sunucusu seçimi müşteriye bırakılmaz; sağlayıcı ne kullanıyorsa onu alırsınız. Bu nedenle sağlayıcı seçerken teknik sayfada veya forumda web sunucusu bilgisini aramak mantıklıdır. "cPanel + Apache" yazan bir sağlayıcıyla "LiteSpeed Enterprise" yazan bir sağlayıcı arasında TTFB açısından anlamlı fark oluşabilir.

PHP ve veritabanı katmanının rolü

PHP sürümü, WordPress performansını etkileyen en kolay test edilebilir değişkendir. Hosting sağlayıcınız cPanel veya Plesk üzerinden PHP sürümü seçmenize izin veriyorsa farklı sürümler arasında kıyaslamayı kendiniz yapabilirsiniz. PHP 8.0 ile 8.2 arasındaki fark çoğu WordPress kurulumunda 30-80 milisaniye aralığında gözlemlenebilir; ama bu değer kurulumun ağırlığına ve eklenti listesine bağlı olarak değişir.

OPcache, PHP dosyalarının derlenmış sürümlerini bellekte saklar ve her istekte yeniden derlemeyi önler. OPcache'in etkin olup olmadığını phpinfo() çıktısından görebilirsiniz. Etkin olsa bile yanlış yapılandırılmış bir OPcache (bellek sınırı düşük, yeniden doğrulama sıklığı çok yüksek) performans kazancını engelleyebilir.

Veritabanı katmanında ise farklı sağlayıcıların kullandığı MySQL veya MariaDB sürümleri, yapılandırma değerleri ve en önemlisi paylaşılan sunucunun o anki yükü belirleyicidir. WordPress'in wp_options tablosunda otomatik yüklenen (autoloaded) veri hacmi arttıkça her sayfa yüklemesindeki veritabanı süresi uzar. WordPress performans optimizasyonuna başlarken autoloaded veri temizliği sıklıkla atlanan ama TTFB üzerinde ölçülebilir etkisi olan bir adımdır.

Bazı sağlayıcılar paylaşımlı planlarda Redis veya Memcached nesne önbellekleme sunmaz. Bu özellik VPS veya bulut sunucu planlarında daha yaygındır. Nesne önbellekleme etkin olduğunda WordPress her veritabanı sorgusunu tekrar çalıştırmak yerine bellekten okur; bu, dinamik yanıtlarda bile TTFB'yi belirgin biçimde düşürür.

Coğrafi konum ve ağ altyapısı

Türkiye'de hizmet veren sitelerin büyük çoğunluğu için veri merkezinin İstanbul veya Ankara'da olması, Frankfurt veya Amsterdam'a kıyasla önemli avantaj sağlar. İstanbul'dan Frankfurt'a gidiş-dönüş ağ gecikmesi genellikle 40-60 milisaniye aralığındadır; bu değer TTFB'nin sabit bir tabanını oluşturur. Sağlayıcının sunucusu Türkiye'deyse bu gecikme 5-15 milisaniyeye iner.

Ağ altyapısı yalnızca coğrafi mesafeden ibaret değildir. Sağlayıcının peering anlaşmaları, kullandığı transit bağlantılar ve veri merkezinin bant genişliği kapasitesi de gecikmeli veya paket kaybı yaşandığında TTFB'yi etkiler. Türkiye'deki büyük yerli sağlayıcıların çoğu Türk Telekom veya birden fazla ISP üzerinden bağlantı sağlar; ama bu altyapının kalitesi sağlayıcıdan sağlayıcıya değişir.

Veri merkezi konumunu sağlayıcının teknik sayfasından öğrenebilirsiniz. IP adresini bir IP coğrafi konum servisinde sorgulayarak doğrulama yapmak da mümkündür. Bazı sağlayıcılar "Türkiye sunucu" derken aslında Frankfurt'taki bir kolokasyon hizmetini kastetmektedir; bu durumda ağ gecikmesi Türkiye merkezli bir veri merkeziyle kıyaslandığında farklı çıkar.

Paylaşımlı hosting sınırları ve ne zaman yetersiz kalır?

Paylaşımlı hosting, düşük trafikli siteler için makul bir seçenektir. Aylık birkaç bin ziyaret alan, eklenti listesi kısa tutulan ve içeriği statik ağırlıklı olan bir WordPress sitesi, kaliteli bir paylaşımlı planda 400-600 milisaniye TTFB ile çalışabilir. Bu değer iyi sayılmaz ama ciddi bir sorun da yaratmaz.

Sorun üç koşulda derinleşir. Trafik artışı olduğunda paylaşımlı sunucunun kaynak havuzu hızla dolabilir; ani ziyaretçi artışında TTFB birkaç saniyeye çıkabilir. E-ticaret gibi dinamik ve kişiselleştirilmiş içeriğin yoğun olduğu yapılarda önbelleğin işe yaramaması, her isteğin PHP ve veritabanını tam yük altında çalıştırmasına neden olur. E-ticaret sitelerinde performans için öncelikli adımlar incelendiğinde hosting katmanının ne kadar erken belirleyici olduğu görülür.

Üçüncü koşul sunucu komşuluğudur. Paylaşımlı ortamda aynı sunucudaki başka bir hesap kaynak tüketen bir süreç çalıştırdığında tüm hesaplar yavaşlar. Bu durum kontrol edilemez ve tahmin edilemez. TTFB ölçümlerinizde açıklanamayan ani yavaşlamalar yaşıyorsanız bu olasılığı dışlamak için VPS veya bulut sunucuya geçici test yapabilirsiniz.

Paylaşımlı plandan ne zaman çıkılmalı? TTFB medyanı tutarlı biçimde 800 milisaniyenin üzerinde kalıyor, önbellek yapılandırması zaten optimize edilmiş ve PHP sürümü güncelse, sonraki adım hosting katmanıdır. Performans sorununu düzeltirken neye önce bakılacağı sorusu, hosting değişikliğinin gerçekten gerekip gerekmediğini belirlemeye yardımcı olur.

TTFB izleme ve zaman içinde takip etme

Tek seferlik ölçüm yeterli değildir. TTFB'yi hosting sağlayıcısı bağlamında anlamlandırmak için zaman serisi gerekir. Sabah, öğlen ve akşam saatlerinde alınan ölçümler günlük profili ortaya koyar; haftalık karşılaştırma ise sağlayıcının sunucu yükünü ne kadar iyi yönettiğini gösterir.

Düzenli TTFB izlemesi kurarsanız yavaşlamanın ne zaman başladığını ve hangi saatlerde yoğunlaştığını görebilirsiniz. Aylık site hızı takibi sürecinde TTFB, izleme listesine girmesi gereken birincil metrikler arasındadır. Hosting değişikliği sonrası karşılaştırma da ancak düzenli takiple anlamlı hale gelir: değişiklik öncesi ve sonrası medyan değerleri karşılaştırmak, farkın gerçek olup olmadığını gösterir.

Curl komutunu kullanarak zaman bileşenlerine ayrılmış ölçüm yapabilirsiniz. curl -o /dev/null -s -w "%{time_starttransfer}\n" https://orneksite.com komutu TTFB değerini saniye cinsinden döndürür. Bu komutu betik haline getirip farklı saatlerde çalıştırarak veri toplayabilirsiniz. Böylece ücretli izleme aracına ihtiyaç duymadan temel bir ölçüm altyapısı oluşturulabilir.

Search Console'un Core Web Vitals raporunda TTFB doğrudan görünmez; ama alan verisindeki LCP ve FCP değerleri, sunucu yanıt süresiyle bağlantılı sorunların izini taşır. Lab verisinden farklı olarak alan verisi gerçek kullanıcıların deneyimini yansıtır. Bu nedenle izleme sürecinde her iki kaynağı birlikte değerlendirmek, tek bir veri noktasına güvenmekten çok daha sağlam sonuç verir.