Site hız testi araçları ve sonuçları okuma

Site hız testi, kullanıcı deneyimini ve SEO'yu iyileştirmenin ilk adımıdır; ancak birçok site yöneticisi birkaç test yaptıktan sonra yorumlaması zor olan bir yığın sayı ve grafikle karşılaşır. Asıl soru "Sitemin hızı ne kadar?" değil, "Hangi sayıya güvenmeliyim ve hangi sorunu önce çözmeliyim?" Bu makalede, site hız testi araçlarına pratik bir bakışla laboratuvar ve saha verileri arasındaki farkı inceleyeceğiz ve iyileştirmeleri önceliklendirmek için net bir çerçeve sunacağız.

Site Hız Testi Neden Farklı Sonuçlar Verir?

Bir sayfayı farklı araçlarla birkaç kez test ederseniz, muhtemelen farklı sayılar görürsünüz. Bu fark doğaldır ve araçların topladığı iki tür veriden kaynaklanır: Laboratuvar Verisi (Lab Data) ve Saha Verisi (Field Data).

Laboratuvar Verisi Nedir?

Laboratuvar verisi, kontrollü ve simüle edilmiş bir ortamda test çalıştırılarak elde edilir. Lighthouse ve GTmetrix gibi araçlar, belirli donanım özellikleri ve ağ hızıyla başsız bir tarayıcı (Headless Browser) çalıştırır. Bu testin sonucu, aynı koşullarda tekrarlanabilir kesin bir sayıdır. Ancak sorun şu ki bu koşullar, kullanıcılarınızın gerçek koşullarından farklıdır.

Örnek: Lighthouse varsayılan olarak orta sınıf bir mobil cihazı (Moto G Power) ve simüle edilmiş bir 4G ağ bağlantısını (150ms gecikmeyle) varsayar. Kullanıcılarınız amiral gemisi telefonlar ve yüksek hızlı Wi-Fi ile giriyorsa, laboratuvar verisi gerçeklikten daha yavaş görünür ve bunun tersi de geçerlidir.

Saha Verisi Nedir?

Saha verisi, kullanıcılarınızın sitenizle gerçek etkileşimlerinden toplanır. Google bu verileri, sayfanızı açan kullanıcıların Chrome tarayıcısından alır ve PageSpeed Insights ile Search Console gibi araçlarda gösterir. Bu veriler geniş bir cihaz, ağ ve coğrafi konum yelpazesini içerir ve yüzdelik dilim (Percentile) olarak raporlanır.

Önemli not: Saha verisi yalnızca yeterli trafiğe sahip sayfalar için kullanılabilir (genellikle ayda birkaç bin ziyaret). Yeni veya az ziyaret edilen sayfalar için Google'ın saha verisi yoktur ve yalnızca laboratuvar verisini gösterir.

Ana Site Hız Testi Araçları ve Her Birinin Kullanımı

Her araç belirli bir amaç için tasarlanmıştır. Her iş için tek bir araç kullanmak, sonuç çıkarmada hatalara yol açar.

PageSpeed Insights (PSI)

Google'ın bu ücretsiz aracı, laboratuvar verisini (Lighthouse) ve saha verisini (CrUX) tek bir raporda birleştirir. Raporun üst kısmı, saha verisini üç ana Core Web Vitals metriğiyle gösterir: LCP (En Büyük İçerikli Boyama), INP (Sonraki Boyamayla Etkileşim) ve CLS (Kümülatif Düzen Kayması). Alt kısım, laboratuvar verisini 0-100 arası bir puan ve optimizasyon fırsatlarıyla gösterir.

PSI'nin ana kullanımı: Genel durumu kontrol etmek ve gerçek ile simüle edilmiş veriyi aynı anda görmek.

WebPageTest

Bu araç daha gelişmiştir ve test konumunu, tarayıcı türünü, bağlantı hızını ve hatta tekrar sayısını belirlemenize olanak tanır. Çıktısı, isteklerin zaman çizelgesini (Waterfall), yükleme sürecinin videosunu ve daha ayrıntılı analizleri içerir.

Ana kullanımı: Kaynak yükleme sırası, her isteğin gecikmesi ve üçüncü taraf scriptlerin etkisi gibi teknik detayları incelemek.

GTmetrix

Bu araç Lighthouse tabanlıdır ancak raporu tam yükleme süresi ve sayfa boyutuna odaklanarak sunar. Ücretsiz sürümünün test konumu sınırlaması vardır ancak hızlı kontrol ve değişikliklerden önceki/sonraki karşılaştırmalar için kullanışlıdır.

Ana kullanımı: Bir sayfanın farklı sürümlerini karşılaştırmak veya optimizasyon sonrası değişiklikleri izlemek.

Site Hız Testinde Temel Metrikler: Hangisini Önce İyileştirmeli?

Testi çalıştırdıktan sonra onlarca metrikle karşılaşırsınız. Doğru önceliklendirme, hızlı bir site ile optimizasyon raporlarıyla dolu bir site arasındaki farktır.

Core Web Vitals Metriklerini Önceliklendirin

Bu üç metrik, kullanıcı deneyimini ve Google sıralamasını doğrudan etkiler:

• LCP (En Büyük İçerikli Boyama): En büyük içerik öğesinin (ana görsel veya başlık gibi) görüntülenme süresi. Hedef: 2,5 saniyeden az.
• INP (Sonraki Boyamayla Etkileşim): Kullanıcı etkileşimlerine (tıklama, dokunma) yanıt gecikmesi. Hedef: 200 milisaniyeden az.
• CLS (Kümülatif Düzen Kayması): Sayfa öğelerinin istenmeyen hareket miktarı. Hedef: 0,1'den az.

Saha verisi bu metrikleri "zayıf" gösteriyorsa, önceliğiniz görsel boyutunu küçültmek veya CSS dosyalarını sıkıştırmak değil, bu sorunları düzeltmek olmalıdır.

Etki ve Maliyete Göre İyileştirme Sırası

Önceliklendirme için önerilen bir çerçeve:

1. Görsel Optimizasyonu: WebP veya AVIF formatına dönüştürme, gerçek görüntüleme boyutlarına yeniden boyutlandırma, sayfa altındaki görseller için loading="lazy" özelliğini kullanma. Bu genellikle en düşük riskle en büyük etkiyi sağlar.
2. Render'ı Engelleyen JavaScript'i Kaldırma: Ana render'dan önce yüklenen scriptleri defer veya async özelliğiyle yükleyin. Üçüncü taraf scriptleri (canlı sohbet veya analiz araçları gibi) sayfa tamamen yüklenene kadar erteleyin.
3. Tarayıcı ve Sunucu Önbelleğini Etkinleştirme: Statik kaynaklar için Cache-Control başlığını ayarlayın. Nginx sunucusunda görsel dosyaları için örnek:

location ~* \.(jpg|jpeg|png|webp|svg)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

1. CDN Kullanımı: Kullanıcılarınız İran'ın farklı bölgelerindeyse, yerel bir CDN ağ gecikmesini önemli ölçüde azaltabilir. Bu özellikle statik dosyalar ve görseller için etkilidir.
2. Font Optimizasyonu: WOFF2 formatını kullanın ve yalnızca gerekli font ağırlıklarını yükleyin. Metnin varsayılan fontla görüntülenmesi ve ardından ana fontun değiştirilmesi için font-display: swap özelliğini etkinleştirin.

Site Hız Testi Sonuçlarını Yorumlamada Sık Yapılan Hatalar

Birçok site yöneticisi optimizasyondan sonra laboratuvar puanının iyileştiğini ancak saha verisinin değişmediğini görür. Bu durumun belirli nedenleri vardır:

Birinci Hata: Lighthouse'ta 100 Puanı Kovalama

Lighthouse puanı bileşik bir göstergedir ve 100'e ulaşmak gerçek hız anlamına gelmez. Bazen bir analiz scriptini (Google Analytics gibi) kaldırmak puanı 10 birim artırır ancak saha verisini değiştirmez, çünkü bu script engelleyici olmayan şekilde yüklenir ve LCP üzerinde belirgin bir etkisi yoktur. Puanı kovalamak yerine Core Web Vitals metriklerine odaklanın.

İkinci Hata: Laboratuvar ve Saha Verisi Arasındaki Farkı Görmezden Gelme

Laboratuvar verisinin LCP'yi 1,8 saniye gösterdiğini ancak saha verisinin 4,2 saniye olduğunu varsayalım. Bu fark genellikle sorunun ön uç kodlarında değil, sunucu veya ağ tarafında olduğu anlamına gelir. Yaygın nedenler:

• Sunucu yoğun trafik saatlerinde yavaşlar (sunucu kaynak sorunu).
• Kullanıcıların sunucuya bağlantısı yoğun trafikli yollardan geçer.
• Görseller ve dosyalar CDN'den değil ana sunucudan yüklenir.

Bu durumda CSS ve JavaScript kodlarını optimize etmek yardımcı olmaz. Altyapıyı incelemeniz gerekir: sunucu kaynaklarını artırma, sunucu tarafı önbellek kullanma (Redis veya Varnish gibi) veya daha kaliteli bir hosting'e geçme.

Üçüncü Hata: Yalnızca Tek Bir Coğrafi Konumdan Test Etme

Sitenizin İran genelinde kullanıcıları varsa, tek bir konumdan (örneğin Tahran) yapılan test tam bir resim vermez. WebPageTest gibi araçları kullanın ve testi birkaç farklı şehirden (örneğin Tahran, Meşhed, Ahvaz) çalıştırın. Şehirler arasındaki ağ gecikmesi farkı birkaç yüz milisaniye olabilir ve bu doğrudan LCP'yi etkiler.

Gerçek Bir Senaryo: Raporlardan Eyleme

PageSpeed Insights raporunun ana sayfanız için şu sonuçları gösterdiğini varsayalım:

• Saha verisi: LCP = 3,8 saniye (zayıf), INP = 180ms (iyi), CLS = 0,05 (iyi)
• Laboratuvar verisi: Puan 45, önerilen fırsatlar: "Kullanılmayan JavaScript'i azaltın" ve "Görselleri doğru formatta sunun"

Önceliğiniz nedir? Yukarıdaki çerçeveye göre:

1. Önce görselleri inceleyin. Muhtemelen ana görsel (Hero Image) PNG formatında ve 2 MB boyutunda yükleniyor. %80 kaliteyle WebP'ye dönüştürmek ve boyutu 1200px'e yeniden boyutlandırmak LCP'yi 1-1,5 saniye iyileştirebilir.
2. Üçüncü taraf scriptleri inceleyin. Ana içerikten önce yüklenen bir canlı sohbet widget'ınız varsa, onu defer ile yükleyin veya koşullu yükleme kullanın (yalnızca kullanıcı etkileşiminden sonra).
3. Değişiklikleri uyguladıktan sonra tekrar test edin. Laboratuvar verisi iyileşti ancak saha verisi 28 gün sonra (CrUX toplama süresi) değişmediyse, sorun altyapısaldır ve sunucuyu veya CDN'yi incelemeniz gerekir.

Daha Derin Analiz İçin Tamamlayıcı Araçlar

Ana araçlara ek olarak, daha ayrıntılı analiz için birkaç araç daha faydalıdır:

• Chrome DevTools: Kaynak yükleme sırasını görmek için Network sekmesi ve sayfa render'ını kaydetmek ve analiz etmek için Performance sekmesi.
• Search Console: "İyileştirmeler" (Enhancements) bölümündeki Core Web Vitals raporu, saha verisini sayfa türüne (mobil/masaüstü) ve URL gruplarına göre gösterir.
• Pingdom Tools: Sunucu yanıt süresini (TTFB) kontrol etmek ve sunucu tarafındaki yavaşlığı belirlemek için.

Özet: Site Hız Testi İçin Pratik Bir Rutin

Site hız testini faydalı bir alışkanlık haline getirmek için şu rutini öneriyoruz:

1. İki haftada bir, ana sayfayı ve 2-3 popüler sayfayı PageSpeed Insights ile kontrol edin.
2. Saha verisi mevcutsa, önceliği Core Web Vitals metriklerini iyileştirmeye verin.
3. Saha verisi mevcut değilse, ana kullanıcılarınıza yakın bir test konumuyla WebPageTest kullanın.
4. Her değişiklikten sonra önceki ve sonraki testi yapın ve yalnızca LCP veya INP üzerinde olumlu etkisi olan değişiklikleri koruyun.
5. Belgeleyin: test tarihi, metrik değerleri, uygulanan değişiklikler ve sonuç. Bu, hataların tekrarlanmasını önler.

Unutmayın ki site hızı tek seferlik bir proje değil, sürekli bir süreçtir. Laboratuvar ve saha verilerini doğru anlayarak ve gerçek etkiye göre önceliklendirme yaparak, önemsiz konularda zaman kaybetmeden kullanıcı deneyimini belirgin şekilde iyileştirebilirsiniz. Barındırma altyapınız sınırlamalar oluşturuyorsa ve kaynak artırma veya CDN kullanımı planlarınızdaysa, kaliteli barındırma seçeneklerini incelemek iyi bir başlangıç noktası olabilir.