Yavaş site teşhisi: sunucu, ağ ve tarayıcı

Ziyaretçinin neyi beklediğini bulun

Yavaş bir sayfa DNS, bağlantı, HTML üretimi, font veya meşgul tarayıcıyı bekleyebilir. Bu beklemeyi bulmadan daha büyük sunucu satın almak sorunu çözmeyebilir. Tam genel URL'yi, cihazı, ağı, zamanı ve ilk ya da tekrarlı ziyaret koşulunu kaydedin. Kişisel hesap cevabı yerine anonim genel sayfayı ölçün.

Altyapıyı değiştirmeden HTTP sürelerini okuyun

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Bu Linux/macOS shell örneği GET gönderir ve gövdeyi atar. Windows'ta curl.exe kullanıp çıktı hedefini uyarlayın. Süreler başlangıçtan itibaren birikimli saniyelerdir: basit doğrudan HTTPS bağlantısında connect eksi DNS yaklaşık TCP süresidir; TLS eksi connect yaklaşık TLS süresidir. İlk bayt zamanı önceki bağlantı adımlarını da içerir; yalnızca PHP veya veritabanı süresi değildir. Bağlantı yeniden kullanımı, proxy ve yönlendirmeler yorumu değiştirir. Yönlendirmeleri ayrı inceleyin ve son URL'yi ayrıca ölçün.

Etkilenen konumdan ve başka bir konumdan birkaç karşılaştırılabilir örnek alın. En hızlı sonucu seçmek yerine medyanı ve değişkenliği karşılaştırın. Ping ICMP kullanır ve filtrelenebilir veya farklı işlenebilir; sabit ping ya da jitter eşiği HTTPS sorununu tek başına teşhis etmez.

İlk bayt geç geliyorsa

• Yavaş rotayı aynı host'taki küçük statik dosyayla karşılaştırın. Hızlı dosya ve yavaş dinamik sayfa uygulama incelemesini düşündürür; log ve istek süreleriyle doğrulayın.
• Sorun anındaki CPU, çalışmayı bekleyen görevler, kullanılabilir bellek, swap etkinliği ve disk gecikmesini inceleyin. Mevcut top, vmstat ve iostat araçları yardımcıdır. Cache belleği otomatik olarak bellek baskısı değildir; disk kullanım yüzdesi de tek başına evrensel doygunluk kanıtı değildir.
• Yavaş sorguları ve yürütme planlarını inceleyin. İndeks gerçek bir sorgu desenine hizmet etmeli ve yazma maliyeti hesaba katılmalıdır. Küçük bir tabloda tam tarama mutlaka hata değildir.
• Yalnızca bazı ağlar etkileniyorsa IPv4/IPv6 ve DNS cevaplarını karşılaştırın. Kayıt değiştirmeden DNS doğrulamasını yapın.

Önce salt okunur kontrolleri kullanın. Yük testi izinli, kontrollü ortamda sınırlar ve izlemeyle yapılmalıdır; üretime tahmini bir istek patlaması göndermek mevcut kullanıcıları etkileyebilir.

HTML hızlı geliyor ama görünüm gecikiyorsa

Tarayıcının Performance ve Network panellerini veya mobil PageSpeed raporunu açın. Gerçek LCP öğesini ve bağımlılıklarını bulun. Metinde engelleyici CSS veya geç font, resimde keşif zamanı, aktarım boyutu veya öncelik etkili olabilir. Ekranın üstündeki ana resmi lazy-load etmeyin. Resim boyutlarını ayırın ve font değişiminin kayma üretmediğini doğrulayın.

Yavaş etkileşimlerde ana iş parçacığı görevlerini; giriş gecikmesi, handler işi ve sonraki çizim olarak inceleyin. Sunucu yükseltmesi uzun JavaScript görevini kaldırmaz. Gereksiz işi azaltıp ağır işlemi bölün ve işlevi koruduğunuzu test edin. LCP sayısını düşürmek için ana içeriği gizlemek yararlı bir iyileştirme değildir.

Ölçülmüş bir ServerNet örneği

10 Ekim 2026'da ServerNet ana sayfasının bir mobil laboratuvar testi LCP 2,762 saniye, TBT 71 milisaniye ve CLS 0,001 ölçtü. Önceki asenkron CSS denemesi CLS 0,538 üretti ve reddedildi. Bu, test koşullarındaki tek sayfa sonucudur; her ziyaretçi veya sıralama değişimi için garanti değildir. Kaydedilmiş rapor birkaç ölçütün birlikte izlenmesinin nedenini gösterir.

Geri alınabilir değişiklikle döngüyü tamamlayın

Şüpheli darboğazı ve beklenen etkiyi yazın. İlgili tek etkeni değiştirin, önceki yapılandırmayı tutun ve aynı ölçümleri tekrarlayın. Hızla birlikte işlev ve kaymaları kontrol edin. Fayda tutarsızsa veya davranış bozulursa geri alın. İlk ziyareti tarayıcı cache tekrarından ayırın; uzun dönem eğilimini gerçek kullanıcı verileriyle değerlendirin.

Kaynaklar: curl süre değişkenleri ve LCP teşhisi.