Sunucu yanıt süresi yavaş (TTFB > 800 ms)

ÖnemDüşük

KapsamSayfa başına

EmekOrta

DoğrulamaGörevi tamamlayınca yeniden tarama

Kural anahtarıttfb_slow

Kısa cevap

Time to First Byte (TTFB), tarayıcının HTML'in ilk baytı gelmeden önce ne kadar beklediğidir. Glimana'nın tarayıcısı bu sayfada 800 ms'den fazla ölçtü. TTFB bir Core Web Vital değildir ve web.dev 0,8 sn'yi "kaba bir rehber" olarak niteler; ama diğer tüm metrikler (özellikle LCP) onun üzerine biner, bu yüzden bir sayfa yavaşsa ilk bakılacak yer sunucu yanıtıdır. Olağan sebepler sayfa önbelleğinin olmaması, yavaş veritabanı sorguları, aşırı yüklenmiş bir PHP havuzu ya da HTML'i önbelleğe almayan bir CDN'dir.

Neden önemli

TTFB bir Core Web Vital değildir; web.dev 0,8 sn'yi "kaba bir rehber" olarak verir. Yavaşlığın kaynağını bulmak için bir ipucudur. HTML gelmeden hiçbir şey render edilemez; bu yüzden TTFB'si 1,5 sn olan bir sayfa, görselleri ne kadar optimize edilmiş olursa olsun iyi bir LCP'ye sahip olamaz. Tarayıcılar da site başına zaman bütçesi ayırır: yavaş sunucu, günde daha az taranan sayfa demektir.

Glimana bunu nasıl tespit eder

Tarama sırasında Glimana isteğin gönderilmesiyle ilk baytın alınması arasındaki süreyi kaydeder. Ölçülen ttfb_ms 800'ün üzerindeyse ve sayfa 200 döndüyse kural tetiklenir. Kanıtta ölçülen değer gösterilir. Tek bir yavaş ölçüm gürültü olabilir (soğuk önbellek, çalışan bir yedekleme); saha verisinin bununla uyuşup uyuşmadığını Anahtar kelimeler ve Hız sayfaları gösterir.

Not

Glimana bir Avrupa veri merkezinden tarar. Asya'da ya da Güney Amerika'da bulunan bir sunucu, yerel kullanıcılarınızın yaşadığından daha yüksek bir TTFB gösterir; sunucu çalışmasına yatırım yapmadan önce Hız sayfasındaki CrUX TTFB değeriyle karşılaştırın.

Nasıl düzeltilir

Etkilenen sayfaları Glimana'da bulun. Sorunlar › Sunucu yanıt süresi yavaş (TTFB > 800 ms) ekranını açın. Etkilenen her sayfa bir satırdır; Glimana'nın o sayfa için kaydettiği kanıtı (ölçülen değer, sorunlu öğe ya da hedef URL) görmek için birini açın. Aynı liste Görevler altındaki görev kartında da bulunur; sayfanın Sayfalar altındaki kendi ayrıntı görünümü ise tüm sinyallerini gösterir.
Düzeltmeyi platformunuzda uygulayın.

Zinciri bu sırayla ele alın; her adım bir sonrakinden daha ucuzdur.
1. Sayfa önbelleği. En ucuz kazanç: HTML'i önbellekten sunun (WordPress önbellek eklentisi, Nginx FastCGI cache, Varnish ya da CDN'in HTML önbelleği). Önbellekteki bir sayfa 200 ms'nin altında yanıt vermelidir.
2. Opcode önbelleği ve PHP-FPM. OPcache'in açık olduğundan ve PHP-FPM'in yeterli işçisi (pm.max_children) olduğundan emin olun; doymuş bir havuz istekleri sıraya sokar.
3. Veritabanı. Yavaş sorgu günlüğünü açın ve bu sayfanın arkasındaki sorgulara bakın. Eksik indeksler ve büyük tablolarda SELECT * olağan şüphelilerdir.
4. CDN. Cloudflare ya da başka bir CDN kullanıyorsanız HTML'in gerçekten önbelleğe alındığını (cf-cache-status: HIT) ve origin'in yavaş bir bölgenin arkasında olmadığını kontrol edin.
5. Barındırma. Yukarıdakilerin hepsi yerindeyse ve TTFB hâlâ 800 ms'nin üzerindeyse sunucunun kendisi yetersizdir.
WordPressShopifyÖzel kod

Bir sayfa önbelleği eklentisi kurun (WP Rocket, LiteSpeed Cache, W3 Total Cache) ve bu URL'yi önbelleğe aldığını doğrulayın (kaynak kodun sonunda eklentinin HTML yorumuna bakın). Yavaş sorguları bulmak için Query Monitor kullanın; WooCommerce filtreleri ve ilgili yazı widget'ları gibi eklentiler sık rastlanan sebeplerdir. Paylaşımlı barındırmada yönetilen bir barındırmayı ya da nesne önbelleğini (Redis) değerlendirin.

Sunucuyu Shopify yönetir; Shopify'da yavaş TTFB genellikle büyük koleksiyonlar üzerinde dönen tema Liquid kodundan ya da bir döngü içindeki çok sayıda {% render %} çağrısından gelir. Şablonu sadeleştirin, koleksiyonları sayfalayın ve sunucu tarafı blok ekleyen uygulamaları kaldırın.

Kullanıcıya göre değişmeyen her şey için yanıt önbelleği ekleyin (Laravel Cache::remember, Symfony HTTP cache, Rails fragment caching). İsteğin profilini çıkarın (Blackfire, Xdebug, New Relic) ve önce en yavaş aralığı düzeltin. Uçta HTTP/2 ya da HTTP/3 ve keep-alive'ı etkinleştirin.
Yayımlayın ve önbellekleri temizleyin. Dağıtın, CDN'i temizleyin, ardından laboratuvar değerinin değiştiğini doğrulamak için Lighthouse'u Hız sayfasından (ya da PageSpeed Insights'tan) yeniden çalıştırın. Alan verisi geriden gelir: CrUX değişikliği sonraki 28 gün içinde yansıtır.
Glimana'da doğrulayın. Görevler altındaki görevi açın ve Yaptım'a tıklayın. Etkilenen sayfalar birkaç saat içinde doğrulama taramasına alınır ve ölçülen TTFB 800 ms'nin altına indiğinde görev kapanır. Kontrol yine başarısız olursa görev bir notla Yeni durumuna döner; geçerse Etki raporlarında Giderilen teknik sorunlar altında listelenir. Daha erken kontrol etmek için sorun ekranındaki Etkilenen sayfaları yeniden tara düğmesini kullanın.

Düzeltme nasıl doğrulanır

Yeniden tarayın; ölçülen TTFB 800 ms'nin altına indiğinde görev kapanır. TTFB değişkenlik gösterdiğinden Glimana tek bir yeniden denemeye değil, bir sonraki taramaya bakar.

SSS

TTFB sıralamayı etkiler mi?

Doğrudan değil. Google sayfa deneyimi sinyalinde Core Web Vitals'ı (LCP, INP, CLS) kullanır; TTFB, LCP'nin girdilerinden biridir, bu yüzden yavaş bir sunucu LCP'yi eşiğin üzerine iter.