Doküman isteğiyle ilgili gecikme uyarısı nasıl giderilir?
Sayfa daha ilk baytı almadan geçen süre — tarayıcı tarafındaki hiçbir optimizasyonun düzeltemediği tek kalem. Sürenin nerede geçtiği, dört sebebi ve düzeltme sırası.
Uyarı ne diyor?
Rapordaki başlık: "Doküman isteğiyle ilgili gecikme". Eski sürümlerde "İlk sunucu yanıt süresi" olarak da geçiyor.
Ölçtüğü şey şu: tarayıcı sayfa isteğini gönderiyor ve sunucudan ilk baytın gelmesine kadar geçen süre.
Bu süre boyunca ekranda hiçbir şey yok. Sayfa daha başlamamış durumda.
Ölçünün tanımı ve eşikleri web.dev üzerinde yayımlanıyor.
Neden diğer uyarılardan farklı?
Bu uyarının özel bir yeri var ve anlaşılması öncelik sırasını doğrudan değiştiriyor.
Tarayıcı tarafında yapılan hiçbir iş bu süreyi düşürmüyor.
Görselleri küçültebilirsiniz, betikleri erteleyebilirsiniz, stil dosyalarını birleştirebilirsiniz — hepsi bu süre dolduktan sonra devreye giriyor.
Yani sunucu ilk yanıtı 1,5 saniyede veriyorsa, sayfanız en iyi ihtimalle 1,5 saniyeden sonra görünmeye başlıyor. Bunun altına inmek mümkün değil.
Bu yüzden bu uyarı varsa, öncelik listesinde diğer her şeyin üstüne çıkıyor.
İpucu — Rapordaki LCP dökümüne bakın. İlk parça — sunucu yanıtı — diğer üçünün toplamından büyükse çalışma kesinlikle bu tarafta. Dökümü LCP yazısında açıkladık.
Nerede geçiyor bu süre?
İlk bayt gelene kadar dört şey oluyor.
1. Ağ turu. İstek sunucuya gidiyor. Sunucu coğrafi olarak uzaktaysa bu süre uzuyor.
2. Sunucu işlemesi. Sayfa hesaplanıyor: veritabanı sorgulanıyor, şablon işleniyor, çıktı üretiliyor.
3. Varsa yönlendirmeler. Her yönlendirme yeni bir tur demek.
4. Yanıtın dönüşü. İlk bayt tarayıcıya ulaşıyor.
İkinci madde çoğu sitede en uzun olan. Ve düzeltilmesi de en mümkün olan.
Ölçülerin genel tanımı web.dev üzerinde bulunuyor.
En yaygın sebep — önbelleklenmeyen sayfa
Dinamik bir site her istekte sayfayı yeniden hesaplıyor: veritabanına gidiyor, içeriği çekiyor, şablona yerleştiriyor, HTML üretiyor.
Bu iş her ziyaretçi için tekrarlanıyor. Oysa içerik aynı.
Sayfa önbelleği bu işi bir kez yapıp sonucu saklıyor. Sonraki ziyaretçiler hazır çıktıyı alıyor ve süre büyük ölçüde düşüyor.
Kendi sitemizde sayfalar önceden üretiliyor ve belirli aralıklarla yenileniyor; ziyaretçi geldiğinde hesaplama yapılmıyor.
Yapı | İlk bayt süresi |
|---|---|
Her istekte hesaplanan dinamik sayfa | Yüksek |
Sayfa önbellekli dinamik sayfa | Orta |
Önceden üretilmiş statik sayfa | Düşük |
İçerik dağıtım ağından sunulan statik | Çok düşük |
İkinci sebep — barındırma
Paylaşımlı barındırmada sunucu kaynakları çok sayıda site arasında paylaşılıyor. Komşu sitelerdeki yoğunluk sizin yanıt sürenizi etkiliyor.
Belirtisi net: site normal saatlerde hızlı, yoğun saatlerde çok yavaş.
Bu durumda kod tarafında yapılacak optimizasyonların sınırı var. Barındırma değişikliği gerekiyor.
Aynı şey e-ticaret sitelerinde daha belirgin yaşanıyor; ürün sayısı ve eş zamanlı ziyaretçi arttıkça sınır erken geliyor. WooCommerce yazısında bu tarafı ayrıca ele aldık.
Üçüncü sebep — yönlendirme zincirleri
Sık atlanan ve düzeltmesi ucuz olan kalem.
Her yönlendirme ayrı bir istek turu demek. Kullanıcı bir adrese geliyor, sunucu "şuraya git" diyor, tarayıcı yeni istek gönderiyor.
İki adımlık bir zincir süreyi iki kat artırabiliyor.
Zincirler genellikle zamanla oluşuyor: sayfa taşınıyor, sonra yeniden taşınıyor, eski kural güncellenmiyor. Konuyu bağlantı değeri ve htaccess yazılarında ele aldık.
Dikkat — www ve HTTPS yönlendirmeleri de bu kapsamda. Kullanıcı www'suz adrese geliyor, www'luya yönlendiriliyor, oradan HTTPS'e — üç tur. Tek bir kuralla tek adımda çözülebiliyor.
Dördüncü sebep — coğrafi mesafe
Sunucunuz Türkiye'deki kullanıcılara hizmet veriyorsa ve fiziksel olarak uzaktaysa, her istek o mesafeyi kat ediyor.
Çözüm içerik dağıtım ağı: içerik kullanıcıya coğrafi olarak yakın noktalardan sunuluyor.
Bu, statik dosyalar için doğrudan çalışıyor. HTML sayfalar için de çalışıyor ama sayfa önbelleklenebilir olmalı — kişiye özel içerik gösteren sayfalarda kısıtlı.
Nasıl ölçülür?
Rapordaki değere ek olarak iki kontrol yapılabiliyor.
Tarayıcının ağ sekmesi. İlk isteğin zamanlama ayrıntısında "bekleme" süresi görünüyor; aradığınız değer o.
Farklı saatlerde ölçüm. Aynı sayfayı sabah, öğlen ve akşam ölçün. Aradaki fark büyükse sorun sunucu kapasitesinde.
İkinci kontrol, barındırma değiştirme kararı için en somut kanıt.
Örnek senaryo — Bir sitede aylardır hız çalışması yapılıyor: görseller optimize edildi, betikler ertelendi, stil dosyaları birleştirildi. Skor 58'den 64'e çıktı ve orada takıldı. İlk bayt süresi ölçüldüğünde 1,8 saniye çıkıyor. Yapılan bütün optimizasyonlar bu sürenin üstüne biniyordu. Barındırma değiştirildiğinde skor tek adımda 82'ye çıkıyor ve daha önceki hiçbir çalışma boşa gitmiş olmuyor — sadece görünür hâle geliyor.
Sıralama
Bu uyarı varsa yapılacaklar sırası şu:
- Yönlendirme zincirlerini temizleyin. En ucuz ve en hızlı kazanç.
- Sayfa önbelleği kurun. Dinamik sitelerde en büyük tek kazanç.
- Veritabanı sorgularını ölçün. Yavaş bir sorgu tek başına süreyi ikiye katlayabiliyor.
- Barındırmayı değerlendirin. İlk üç adım yeterli gelmiyorsa altyapı sınırında demektir.
- İçerik dağıtım ağı ekleyin. Coğrafi mesafe belirleyiciyse.
İlk iki adım çoğu sitede sorunun büyük kısmını çözüyor.
Ne zaman kod tarafına bakılmalı?
Önbellek kurulu ve barındırma yeterliyken süre hâlâ yüksekse sorun uygulamada.
En sık görülenler:
- Her sayfa yüklemesinde çalışan ağır bir sorgu
- Dış bir servise yapılan ve yanıtı beklenen istek
- Gereksiz yere büyük veri çeken listeleme sorguları
- Her istekte yeniden kurulan bağlantılar
Bunlar geliştirici müdahalesi gerektiriyor ve ölçüm olmadan tahminle düzeltilemiyor.
Önbelleğin çalışmadığı durumlar
Sayfa önbelleği kurulu olmasına rağmen sürenin düşmediği durumlar var ve sebebi genellikle aynı.
Oturum açmış kullanıcılar. Çoğu önbellek sistemi, giriş yapmış kullanıcılar için önbelleği atlıyor. Yönetici olarak test yapıyorsanız gerçek durumu görmüyorsunuz.
Kişiye özel içerik. Sepet, öneri listesi ve karşılama mesajı gibi öğeler sayfanın önbelleklenmesini engelliyor.
Sorgu parametreleri. Takip parametresi taşıyan adresler ayrı sayfa sayılıp önbellekten kaçabiliyor.
Kontrol yöntemi: gizli sekmede ölçüm yapmak. Fark varsa önbellek çalışıyor ama sizin oturumunuzda atlanıyor demektir.
Ölçümü doğru yapmak
İlk bayt süresi gün içinde değişiyor ve tek bir ölçüm yanıltıcı olabiliyor.
Yapılacak iş: aynı sayfayı farklı saatlerde en az üç kez ölçmek. Sabah, öğlen ve akşam.
Aradaki fark küçükse sorun sabit bir yapısal gecikme — kod ya da yapılandırma. Fark büyükse sorun kapasite ve barındırma tarafında.
Bu ayrım, barındırma değiştirme kararı için en somut kanıt.
İpucu — Ölçümü ziyaretçilerinizin bulunduğu bölgeden yapın. Farklı kıtadan alınan ölçüm, hiçbir gerçek kullanıcınızın yaşamadığı bir gecikmeyi rapora yazıyor.
Sonuç — Bu uyarı, hız çalışmasının tavanını belirliyor. Sunucu ilk yanıtı geç veriyorsa tarayıcı tarafında yapılan her iş o sürenin üstüne biniyor; sıralamada diğer her şeyin önüne geçmesi gereken tek kalem bu.
Sunucu ve altyapı tarafındaki işleri teknik SEO ve web sitesi geliştirme kapsamında yürütüyoruz; uygulama katmanındaki optimizasyonlar özel yazılım geliştirme tarafında.
Rapordaki diğer uyarılar için PageSpeed uyarıları yazısına bakabilirsiniz.
Bu konuyla ilgili
- önbellek süreleri — Tarayıcı tarafındaki karşılığı.
