WordPress’te İlk Sunucu Yanıt Süresi (TTFB) Nasıl Azaltılır?
WordPress'te TTFB'yi azaltmak için önce önbellekli ve önbelleksiz istekleri ayırın; ardından sayfa önbelleği, PHP ve OPcache, nesne önbelleği, ağır sorgular, otomatik yüklenen veriler ve barındırmayı kontrol edin. Eşikler, teşhis tablosu ve 12 maddelik kontrol listesiyle.
WordPress’te ilk sunucu yanıt süresini (TTFB) azaltmak için önce sorunun önbellekli mi yoksa önbelleksiz isteklerde mi olduğunu ayırın. Önbellekli sayfalar yavaşsa sorun genellikle mesafe, yönlendirme ya da önbelleğin hiç devreye girmemesidir. Önbelleksiz sayfalar yavaşsa PHP sürümü, nesne önbelleği, ağır eklenti sorguları, otomatik yüklenen veriler ve barındırma kaynakları incelenmelidir. Hedef, web.dev’in önerdiği 0,8 saniye veya altıdır.
Kısaca:
- TTFB yönlendirme, DNS, bağlantı ve sunucunun sayfayı hazırlama süresinin toplamıdır; tek bir ayar değildir.
- En büyük kazanç genellikle tam sayfa önbelleğinin gerçekten çalışmasından gelir.
- Önbelleği atlayarak da ölçün: önbellek, yavaş bir altyapıyı gizleyebilir.
Bu yazı hızın yalnızca sunucu tarafını ele alır. Görseller, eklentiler ve JavaScript dahil genel sıralama için WordPress sitesi nasıl hızlandırılır kontrol listemize bakın.
TTFB nedir, neden önemlidir?
TTFB (Time to First Byte), tarayıcının sayfaya gitmeye başladığı andan sunucudan ilk baytın geldiği ana kadar geçen süredir. web.dev’e göre şu aşamaların toplamıdır:
- Yönlendirmeler
- Varsa service worker’ın başlaması
- DNS sorgusu
- Bağlantı kurulması ve TLS el sıkışması
- İsteğin gönderilip yanıtın ilk baytının gelmesi
TTFB bir Core Web Vitals metriği değildir. Ama sayfadaki her şey ilk bayttan sonra başladığı için yüksek bir TTFB, LCP’yi (ana içeriğin görünme süresi) doğrudan geciktirir.
Hangi değer “iyi” sayılır?
Farklı araçlar farklı eşik kullanır; çünkü ölçtükleri şey de biraz farklıdır.
| Araç | Ne ölçer | Eşik |
|---|---|---|
| web.dev (TTFB) | Yönlendirme ve DNS dahil toplam süre | 0,8 sn veya altı iyi, 1,8 sn üstü zayıf |
| Lighthouse / PageSpeed Insights | Ana belge için sunucu yanıt süresi (yönlendirme ve DNS hariç) | 600 ms üstü uyarı |
| WordPress Site Sağlığı | Sunucunun yanıt süresi | Varsayılan kabul edilebilir eşik 600 ms |
Kaynaklar: Lighthouse sunucu yanıt süresi denetimi ve WordPress 6.1 ile gelen Site Sağlığı önbellek kontrolleri. Lighthouse’un 600 ms sınırı, yönlendirme ve DNS süresini içermediği için web.dev’in 800 ms önerisinden daha sıkıdır.
TTFB nasıl ölçülür?
- PageSpeed Insights: Saha verisinde (son 28 günün gerçek kullanıcıları) TTFB ayrı bir satır olarak görünür. Laboratuvar raporunda ana belge isteğinin gecikmesi ayrıca listelenir.
- Chrome Geliştirici Araçları: Ağ (Network) sekmesinde ilk HTML isteğine tıklayın; Zamanlama (Timing) bölümündeki “Waiting for server response” satırı sunucunun sayfayı hazırlama süresidir.
- Search Console: Önemli Web Verileri raporu, yeterli trafik varsa gerçek kullanıcı verisini gösterir.
- WordPress Site Sağlığı: Araçlar > Site Sağlığı ekranı sayfa önbelleğinin algılanıp algılanmadığını ve yanıt süresini kontrol eder.
Doğru ölçüm için iki kural: Yönetici olarak giriş yapmışken ölçmeyin; çoğu önbellek oturum açmış kullanıcılara önbelleksiz sayfa verir. Ve aynı sayfayı hem önbellekten hem de önbelleği atlayarak ölçün. Pek çok kurulumda adrese bir sorgu parametresi eklemek (ör. ?nocache=1) önbelleği atlatır; önbellek eklentinizin bu adresleri gerçekten hariç tuttuğunu yanıt başlıklarından doğrulayın. İki sonuç arasındaki fark, önbelleğin ne kadar iş yaptığını ve sunucunun asıl hızını gösterir.
Önce teşhis: TTFB nerede kayboluyor?
| Belirti | Olası neden | İlk bakılacak yer |
|---|---|---|
| Önbellekli sayfa da yavaş (0,8 sn üstü) | Önbellek çalışmıyor, ziyaretçi uzak, yönlendirme zinciri | Yanıt başlıklarında önbellek durumu, CDN, yönlendirmeler |
| Önbellekli hızlı, önbelleksiz çok yavaş | PHP, veritabanı, eklenti sorguları | PHP sürümü, OPcache, nesne önbelleği, Query Monitor |
| Sadece bazı sayfalar yavaş | O sayfadaki eklenti, ağır sorgu ya da dış servis çağrısı | Query Monitor ile o sayfa |
| Belirli saatlerde yavaşlıyor | Paylaşımlı sunucu yoğunluğu, zamanlanmış görevler | Hosting kaynak kullanım grafikleri, WP-Cron |
| Yönetim paneli de yavaş | Sunucu kaynakları, otomatik yüklenen veriler | Site Sağlığı, hosting paneli |
1. Tam sayfa önbelleğinin gerçekten çalıştığını doğrulayın
Önbellekten verilen bir sayfa PHP ve veritabanını tamamen atlar. Bu yüzden TTFB’deki en büyük düşüş genellikle buradan gelir. WordPress.org’un önbellek rehberine göre önbellek eklentileri sayfaları statik dosya olarak saklayıp sunucunun işini azaltır.
- Tarayıcının ağ sekmesinde HTML yanıtının başlıklarına bakın. Önbellek eklentileri ve sunucular genellikle “hit” ya da “miss” bilgisini bir başlıkta gösterir.
- Aynı sayfayı ikinci kez açtığınızda hâlâ “miss” görüyorsanız önbellek devrede değildir.
- Adreslere eklenen kampanya parametreleri, çerezler ya da “her sayfayı önbellekten hariç tut” gibi kurallar önbelleği boşa çıkarabilir.
- Tek bir sayfa önbelleği kullanın. İki önbellek eklentisi çakışabilir.
- Sepet, ödeme ve hesap sayfaları önbellekten hariç kalmalıdır; bu sayfaların TTFB’si sunucu hızına bağlıdır.
2. PHP sürümünü ve OPcache’i kontrol edin
Önbelleğe girmeyen her istekte PHP çalışır.
- PHP sürümü: WordPress.org PHP 8.3 veya üstünü öneriyor. PHP.net’e göre 8.2’nin güvenlik desteği 31 Aralık 2026’da bitiyor. Sürüm değişikliğini önce test ortamında deneyin.
- OPcache: Derlenmiş PHP kodunu bellekte tutar. WordPress.org’un önbellek rehberi, opcode önbelleğinin PHP performansını ciddi ölçüde artırdığını belirtir. Çoğu hostingte açıktır; panelde ya da hosting desteğinde kontrol edin.
- Bellek: WordPress’in ön yüz bellek isteği varsayılan olarak 40 MB’dır (WP_MEMORY_LIMIT). Bellek yetmezliği hatası görüyorsanız sınır artırılabilir; ama yüksek bellek kullanımı çoğu zaman ağır bir eklentinin işaretidir.
3. Kalıcı nesne önbelleği ekleyin
WordPress bir istek içinde aynı veriyi tekrar okumamak için nesne önbelleği kullanır, ama varsayılan olarak bu önbellek istek bitince silinir. Redis veya Memcached gibi kalıcı bir nesne önbelleği, sorgu sonuçlarını istekler arasında saklar. Bu, özellikle önbelleğe alınamayan sayfalarda (sepet, hesap, yönetim paneli) ve trafiği yüksek sitelerde fark yaratır.
- Sunucuda Redis veya Memcached hizmeti ve WordPress tarafında uyumlu bir eklenti gerekir.
- Site Sağlığı, WordPress 6.1’den beri kalıcı nesne önbelleği önerisini kendisi gösterir.
- Paylaşımlı hostinglerde bu hizmet her pakette bulunmayabilir.
4. Yavaş sorguları ve ağır eklentileri bulun
Ücretsiz Query Monitor eklentisi; yavaş, tekrarlanan ve hatalı veritabanı sorgularını, bunlara hangi eklentinin ya da temanın yol açtığını ve dış servislere yapılan HTTP isteklerini süreleriyle gösterir.
- Eklentiyi kurun ve yavaş sayfayı yönetici olarak açın.
- Sorgular bölümünde bileşene göre gruplamaya bakın: en çok süreyi hangi eklenti harcıyor?
- HTTP API çağrıları bölümünde sayfa yüklenirken dış servise giden istekleri kontrol edin. Bir lisans kontrolü ya da sosyal medya sayacı her sayfa açılışında saniyeler harcayabilir.
- Sorunlu eklentiyi test ortamında devre dışı bırakıp yeniden ölçün.
- İş bitince Query Monitor’ü kapatın; teşhis aracı olarak kullanılır.
5. Otomatik yüklenen verileri temizleyin
WordPress, ayarlar tablosundaki (wp_options) “otomatik yüklenen” verileri her sayfa isteğinde tek sorguda yükler. Kaldırılan eklentilerden kalan büyük ayarlar bu yükü gereksiz yere büyütür. WordPress 6.6 ile 150 KB’tan büyük yeni ayarlar varsayılan olarak otomatik yüklenmiyor ve toplam otomatik yüklenen veri 800 KB’ı aşarsa Site Sağlığı kritik bir uyarı veriyor.
- Site Sağlığı’nda “Otomatik yüklenen seçenekler” uyarısı varsa hangi ayarların büyük olduğunu inceleyin.
- Kullanmadığınız eklentileri yalnızca devre dışı bırakmayın, kaldırın; bazıları kaldırılırken verisini temizler.
- Veritabanında değişiklik yapmadan önce mutlaka yedek alın.
6. WP-Cron’u sistem zamanlayıcısına taşıyın
WP-Cron, zamanlanmış görevleri sayfa ziyaretleri sırasında kontrol eder. WordPress geliştirici dokümantasyonu, görevlerin sunucunun kendi zamanlayıcısıyla çalıştırılmasını ve ardından wp-config.php dosyasına define( ‘DISABLE_WP_CRON’, true ); satırının eklenmesini anlatır. Böylece WordPress her sayfa yüklemesinde görev kontrolü yapmaz. Sistem zamanlayıcısını kurmadan bu satırı eklemeyin; aksi hâlde zamanlanmış yazılar ve yedekler çalışmaz.
7. Mesafe, yönlendirme ve barındırma
- Yönlendirmeler: web.dev’in TTFB optimizasyon rehberi, sizin kontrolünüzdeki aynı alan adı içindeki yönlendirmeleri (http → https, www → www’siz, sondaki eğik çizgi) ilk temizlenmesi gerekenler olarak sayar. Menü ve içerik linkleri doğrudan son adresi göstermeli.
- CDN: Ziyaretçileriniz sunucunuzdan uzaktaysa bir içerik dağıtım ağı, önbelleğe alınmış sayfaları ve dosyaları onlara yakın noktalardan verir. web.dev, CDN kullanmayan siteler için bunu öncelikli bir adım olarak görür.
- Barındırma: web.dev, TTFB’de diğer optimizasyonlardan önce barındırmanın düşünülmesi gerektiğini söyler. Önbelleksiz istekler kodu iyileştirdikten sonra da sürekli yavaşsa, sorun büyük olasılıkla paketin CPU ve bellek kaynaklarıdır. Paket değiştirmeden önce hosting firmasından kaynak kullanım raporunu isteyin.
Kontrol listesi
| # | Kontrol | Tamam mı? |
|---|---|---|
| 1 | Oturum kapalıyken, mobilde ölçüm yapıldı | |
| 2 | Önbellekli ve önbelleksiz TTFB ayrı ayrı ölçüldü | |
| 3 | HTML yanıtında önbellek “hit” görünüyor | |
| 4 | Tek bir sayfa önbelleği çalışıyor, kişisel sayfalar hariç | |
| 5 | PHP 8.3 veya üstü, OPcache açık | |
| 6 | Kalıcı nesne önbelleği (Redis/Memcached) değerlendirildi | |
| 7 | Query Monitor ile yavaş sorgu ve dış HTTP isteği kontrol edildi | |
| 8 | Site Sağlığı’nda otomatik yüklenen veri uyarısı yok | |
| 9 | WP-Cron gerekiyorsa sistem zamanlayıcısına taşındı | |
| 10 | Yönlendirme zinciri yok, linkler son adresi gösteriyor | |
| 11 | CDN ihtiyacı ziyaretçi konumuna göre değerlendirildi | |
| 12 | 28 gün sonra saha verisi yeniden kontrol edildi |
Sık yapılan hatalar
- Yönetici olarak giriş yapmışken ölçüp önbelleği hiç görmemek.
- Sadece önbellekli sonuca bakıp yavaş sunucuyu fark etmemek.
- Aynı anda iki önbellek eklentisi çalıştırmak.
- Sistem zamanlayıcısı kurmadan WP-Cron’u kapatmak.
- Yedek almadan veritabanı tablolarını temizlemek.
- Sorunu bulmadan doğrudan daha pahalı bir hosting paketine geçmek.
Sık sorulan sorular
“İlk sunucu yanıt süresini azaltın” uyarısı neden çıkıyor?
Lighthouse, tarayıcı ana HTML için sunucudan 600 ms’den uzun süre yanıt beklediğinde bu uyarıyı verir. Lighthouse 13 ile bu denetim “belge isteği gecikmesi” başlığı altına taşındı. En sık nedenler önbelleğin çalışmaması, eski PHP sürümü ve ağır eklenti sorgularıdır.
TTFB SEO’yu doğrudan etkiler mi?
TTFB kendisi bir Core Web Vitals metriği değildir. Ama yüksek bir TTFB, Core Web Vitals’tan biri olan LCP’yi geciktirir ve sayfa deneyimini kötüleştirir.
Paylaşımlı hostingte iyi bir TTFB mümkün mü?
Çoğu zaman önbellekli sayfalar için evet. Önbelleğe girmeyen sayfalarda ise paylaşımlı sunucunun kaynakları belirleyici olur; bu sayfalar yoğunsa daha güçlü bir pakete ihtiyaç duyulabilir.
CDN TTFB’yi her zaman düşürür mü?
Hayır. CDN, önbelleğe alınabilen içerikte ve sunucudan uzak ziyaretçilerde fayda sağlar. Ziyaretçilerin çoğu sunucuyla aynı ülkedeyse ve sorun önbelleksiz isteklerdeyse asıl çözüm sunucu tarafındadır.
Sonuç
TTFB’yi azaltmak, önce sorunun önbellek mi, sunucu mu, yoksa mesafe mi olduğunu ayırmakla başlar. Ardından önbelleğin gerçekten çalıştığını doğrulamak, PHP ve nesne önbelleğini düzeltmek, ağır sorguları ve gereksiz otomatik yüklenen verileri temizlemek çoğu sitede belirgin bir fark yaratır. Bu teşhisi ve kurulumu bir ekibe bırakmak isterseniz web site hızlandırma hizmetimizi inceleyebilir ya da ücretsiz ön analiz isteyebilirsiniz.