Site Hız Testi

Raporda Core Web Vitals değerlendirmesinin "Başarısız" görünmesi, gerçek Chrome kullanıcılarından gelen son 28 günlük veride üç temel metrikten en az birinin iyi eşiği geçemediği anlamına gelir. Değerlendirme yüzde 75'lik dilime göre yapılır; yani ziyaretlerin en az dörtte üçünün iyi deneyim yaşaması gerekir.

Laboratuvar puanınız yüksek olduğu halde değerlendirme başarısız olabilir. Bunun nedeni, gerçek ziyaretçilerin daha yavaş telefonlar ve bağlantılar kullanması, laboratuvar testinin ise etkileşimi (INP) ölçememesidir. Hangi metriğin sorunlu olduğunu raporda görüp ilgili düzeltmeleri yaptıktan sonra sonucun değişmesi zaman alır: gerçek kullanıcı verisi 28 günlük kayan pencereyle hesaplandığı için iyileşme birkaç hafta içinde kademeli olarak yansır. Search Console'daki Önemli Web Verileri raporu, sorunlu sayfaları gruplar halinde gösterir ve düzeltmeyi doğrulama özelliği sunar.

Site Hız Testi, ölçüm için Google PageSpeed Insights altyapısını kullanır; dolayısıyla performans puanı, Core Web Vitals verisi ve Lighthouse önerileri Google'ın kendi aracıyla aynı kaynaktan gelir. Fark, sonuçların sunuluş biçiminde ve ek ölçümlerdedir.

PageSpeed Insights'ın Google tarafından kontrol edilen sunucularda çalışması nedeniyle iki araçta aynı anda yapılan testler bile birkaç puan farklı sonuç verebilir; bu laboratuvar testlerinin doğal değişkenliğidir. Gerçek kullanıcı verisi ise her iki araçta da aynıdır.

Lighthouse, Google'ın geliştirdiği açık kaynaklı bir web sayfası denetim aracıdır. Bir sayfayı kontrollü bir tarayıcı ortamında yükler ve performans, erişilebilirlik, en iyi uygulamalar ve SEO başlıklarında puan üretir. PageSpeed Insights'ın laboratuvar bölümü ve bu araçtaki performans puanı Lighthouse ile hesaplanır.

• Simülasyon: Mobil testte orta seviye bir telefon ve yavaş bir mobil bağlantı taklit edilir; bu yüzden mobil sonuçlar masaüstünden düşüktür.
• Ölçümler: FCP, LCP, TBT, CLS ve Hız Endeksi ölçülür ve ağırlıklı olarak puana dönüştürülür.
• Denetimler: Kullanılmayan kod, büyük görseller, oluşturmayı engelleyen kaynaklar gibi sorunlar tahmini kazançlarıyla listelenir.
• Sürümler: Lighthouse düzenli olarak güncellenir; raporda testin hangi Lighthouse sürümüyle yapıldığı yazar.
• Erişim: Chrome geliştirici araçlarında Lighthouse sekmesi olarak, komut satırı aracı olarak ve PageSpeed Insights üzerinden kullanılabilir.

Lighthouse bir laboratuvar aracıdır ve gerçek kullanıcı deneyimini tam olarak yansıtmaz; özellikle etkileşim gecikmesini (INP) doğrudan ölçemez. Bu nedenle Lighthouse puanını optimizasyon için, Core Web Vitals verisini gerçek durumu değerlendirmek için kullanmak gerekir.

Mobil puanın masaüstünden düşük çıkması neredeyse her sitede görülür ve tek başına bir hata değildir. Lighthouse, mobil testi gerçek dünyadaki ortalama bir mobil kullanıcıyı temsil edecek şekilde zorlaştırılmış koşullarda yapar.

Mobil puanı yükseltmenin en etkili yolları JavaScript miktarını azaltmak, üçüncü taraf betikleri ertelemek, ana görseli küçültmek ve kritik olmayan kaynakları geciktirmektir. Google siteleri mobil öncelikli dizine ekleme ile değerlendirdiği ve ziyaretçilerin çoğu mobilden geldiği için optimizasyonda mobil sonuçları öncelikli tutmak gerekir. Gerçek kullanıcı verisinde mobil ve masaüstü değerleri ayrı ayrı değerlendirilir; mobil sonuçların iyi aralıkta olması asıl hedeftir.

Bu uyarı, Google'ın Chrome UX Raporu'nda test ettiğiniz sayfa veya site için yeterli gerçek kullanıcı verisi bulunmadığını gösterir. CrUX verisi, kullanım istatistiklerini paylaşmayı kabul etmiş Chrome kullanıcılarının ziyaretlerinden toplanır ve bir sayfanın listeye girebilmesi için belirli bir ziyaret yoğunluğuna ulaşması gerekir.

• Yeni siteler: Henüz yeterli trafik birikmemiştir.
• Az ziyaret alan sayfalar: Sayfa düzeyinde veri yoktur ama site geneli veri bulunabilir.
• Kapalı veya yeni adresler: Yönlendirilen, taşınan veya yeni yayınlanan sayfalar.
• Gizlilik eşiği: Google, kullanıcıların tanımlanamaması için belirli bir ziyaret sayısının altındaki verileri yayınlamaz.

Bu durumda rapor yalnızca laboratuvar sonuçlarını gösterir. Laboratuvar ölçümleri gerçek deneyimin birebir karşılığı değildir, ancak sorunları bulmak ve iyileştirmeleri test etmek için yeterlidir. Kendi sitenizde gerçek kullanıcı verisi toplamak isterseniz Google'ın web-vitals JavaScript kütüphanesini Google Analytics 4 ile birlikte kullanabilirsiniz. Trafik arttıkça CrUX verisi de oluşur ve raporda kendiliğinden görünmeye başlar.

TTFB (Time to First Byte), tarayıcının sayfa isteğini göndermesinden sunucudan ilk baytın ulaşmasına kadar geçen süredir. DNS çözümleme, bağlantı kurma, TLS el sıkışması, varsa yönlendirmeler ve sunucunun sayfayı hazırlama süresi bu değere dahildir. TTFB yüksekse sayfadaki diğer tüm metrikler de gecikir.

TTFB'yi düşürmek için şu adımları uygulayın:

1. Sayfa önbelleği kullanın: Dinamik sayfaların her istekte yeniden oluşturulması yerine hazır HTML sunulmasını sağlayın.
2. CDN kullanın: İçerik ziyaretçiye en yakın noktadan sunulur, mesafe kaynaklı gecikme azalır.
3. Sunucu yazılımını güncelleyin: Güncel PHP sürümü, veritabanı optimizasyonu ve nesne önbelleği sunucu süresini kısaltır.
4. Yönlendirmeleri azaltın: Her yönlendirme TTFB'ye eklenir.
5. Sunucu konumunu doğru seçin: Türkiye'deki ziyaretçiler için yakın bir veri merkezi tercih edin.
6. HTTP/2 ve HTTP/3'ü açın: Bağlantı kurulumu daha verimli hale gelir.

Raporun sunucu yanıtı bölümü, sürenin hangi aşamada harcandığını gösterir; bekleme süresi yüksekse sorun sunucu tarafındadır.

LCP, sayfadaki en büyük görsel veya metin bloğunun ekranda belirdiği andır ve genellikle ana görsel, banner veya ana başlık bu öğedir. Rapordaki "En büyük içerik öğesi" bölümü, LCP'yi belirleyen öğeyi ve sürenin nerede harcandığını gösterir.

1. Ana görseli küçültün: WebP veya AVIF kullanın, görseli gösterildiği boyutta sunun.
2. Önceliği artırın: LCP görseline fetchpriority="high" ekleyin.
3. Lazy-load'u kaldırın: İlk ekrandaki ana görsele loading="lazy" uygulamayın.
4. Erken keşfettirin: Görsel CSS arka planı veya JavaScript ile yükleniyorsa HTML'de doğrudan img etiketi kullanın ya da preload ile önceden bildirin.
5. Oluşturmayı engelleyen kaynakları azaltın: Kritik CSS'i satır içine alın, diğer stilleri ve betikleri erteleyin.
6. TTFB'yi düşürün: LCP'nin ilk bölümü sunucu yanıtıdır; önbellek ve CDN burada da etkilidir.
7. Yazı tiplerini optimize edin: LCP öğesi metinse web fontu yüklenirken metnin görünmesi için font-display: swap kullanın.

Raporda LCP süresi ilk bayt ile oluşturma gecikmesi arasında bölünmüş olarak gösterilir. Oluşturma gecikmesi büyükse sorun tarayıcı tarafındaki kaynaklarda, ilk bayt büyükse sunucudadır.

CLS, sayfa yüklenirken veya kullanıcı sayfadayken öğelerin beklenmedik şekilde yer değiştirmesini ölçer. Okuduğunuz metnin aşağı kayması veya tıklamak üzere olduğunuz düğmenin yerinin değişmesi tipik CLS sorunlarıdır. İyi değer 0,1 ve altıdır.

SEO Analiz raporundaki "Resimlerde genişlik/yükseklik" maddesi, boyut bilgisi eksik görselleri gösterir. Düzeltmeden sonra laboratuvar CLS değerini hemen görebilirsiniz; gerçek kullanıcı CLS değeri ise kullanıcıların sayfadaki tüm oturumunu kapsadığı için kaydırma sırasında oluşan kaymaları da içerir.

INP (Interaction to Next Paint), kullanıcının sayfada yaptığı tıklama, dokunma ve klavye etkileşimlerine sayfanın ne kadar hızlı görsel yanıt verdiğini ölçer. Mart 2024'te FID'in yerine Core Web Vitals metriği olmuştur. İyi değer 200 milisaniye ve altıdır.

INP sorunlarının neredeyse tamamı tarayıcının ana iş parçacığını meşgul eden JavaScript'ten kaynaklanır. Laboratuvar testinde INP doğrudan ölçülmez; ona en yakın gösterge TBT değeridir.

1. Uzun görevleri bölün: 50 milisaniyeyi aşan JavaScript görevlerini parçalara ayırın; tarayıcı aradaki boşluklarda kullanıcıya yanıt verebilir.
2. Kullanılmayan JavaScript'i kaldırın: Rapordaki iyileştirme fırsatları hangi dosyaların gereksiz kod içerdiğini gösterir.
3. Üçüncü taraf betikleri azaltın: Sohbet, reklam, ısı haritası ve takip kodları etkileşim gecikmesinin sık nedenlerindendir.
4. Olay işleyicilerini hafifletin: Tıklamada yapılan ağır hesaplamaları erteleyin, önce görsel geri bildirim verin.
5. DOM boyutunu küçültün: Çok sayıda öğe içeren sayfalarda her güncelleme daha uzun sürer.
6. Gereksiz yeniden çizimden kaçının: Etkileşim sırasında büyük sayfa bölümlerinin yeniden oluşturulmasını önleyin.

Raporun ana iş parçacığı bölümü, tarayıcının zamanının ne kadarının betik çalıştırmaya gittiğini gösterir.

Tek bir "açılış süresi" yerine sayfanın aşamalarına bakmak daha doğrudur; çünkü kullanıcı için önemli olan sayfanın tamamen yüklenmesi değil, içeriğin görünmesi ve sayfanın kullanılabilir hale gelmesidir. Google'ın eşikleri bu aşamalara göre belirlenmiştir.

Genel bir kural olarak ana içeriğin 2,5 saniye içinde görünmesi iyi bir hedeftir. E-ticaret sitelerinde hızın satışa etkisi daha belirgindir; ürün ve sepet sayfalarında daha da hızlı olmayı hedeflemek gerekir. Ölçümü yaparken masaüstü yerine mobil sonuçları esas alın ve yalnızca ana sayfayı değil, en çok ziyaret alan şablonları test edin. Tamamen yüklenme süresi ise reklam ve analiz kodları nedeniyle uzun görünebilir; kullanıcı deneyimini bu değer değil, yukarıdaki metrikler belirler.

Hayır, iki test farklı şeyleri ölçer ve sıkça karıştırılır.

Bir site sizin bilgisayarınızda yavaş açılıyorsa önce bağlantınızı kontrol etmek mantıklıdır; başka sitelerde de yavaşlık varsa sorun bağlantınızdadır. Yalnızca belirli bir site yavaşsa sorun büyük olasılıkla o sitededir ve Site Hız Testi nedeni gösterir. Site Hız Testi, kendi bağlantınızdan bağımsız olarak Google'ın test sunucularında ve R10.Net sunucularında çalıştığı için, sonucunuz evinizdeki internet hızından etkilenmez. Bağlantı gecikmesini ölçmekle ilgili bilgiler Ping Gönder sayfasındaki SSS bölümünde yer alır.