Site Hız Testi Neden Her Seferinde Farklı Sonuç Veriyor?

Haberci

SEO UZMANI
Yönetici
Katılım
21 May 2023
Mesajlar
528
Tepki
17
Puan
18
800




Aynı sayfayı bir hız testi aracına art arda iki kez verdiğinizde, aradan hiçbir kod değişikliği geçmemesine rağmen puanın gözle görülür şekilde oynadığını fark edebilirsiniz. Bir seferinde "iyi", bir sonrakinde "geliştirilmesi gerekiyor" etiketiyle karşılaşmak, hangi sayıya güveneceğinizi bilmemenize yol açar.

Bu yazı, aynı sayfanın neden farklı sonuçlar verdiğini ve karar verirken hangi ölçüme bakmanız gerektiğini gösteriyor.

İki farklı veri kaynağı var: lab ve saha​


web.dev'in kullanıcı merkezli performans metrikleri belgesine göre performans ölçümü iki ayrı kategoriye ayrılıyor: laboratuvar (lab) verisi ve saha (field) verisi. Lab verisi, kontrollü bir ortamda simüle edilen tek bir yüklemenin sonucudur; yeni bir özelliği yayına almadan önce gerilemeyi yakalamak için kullanılır. Saha verisi ise gerçek kullanıcıların kendi cihazlarında, kendi ağ koşullarında yaşadığı deneyimden toplanır.

Bu ayrım tek başına, aynı sayfanın neden iki farklı sayı üretebildiğini açıklıyor: bir araç sizin o anki bağlantınızla simülasyon yapıyor, bir diğeri aylar boyunca biriken gerçek ziyaretçi verisini özetliyor.

CrUX gerçek kullanıcılardan ne topluyor​


Chrome for Developers'ın CrUX (Chrome User Experience Report) belgesine göre bu veri seti, belirli uygunluk kriterlerini karşılayan gerçek Chrome kullanıcılarından dünya çapında toplanıyor. Yani CrUX bir simülasyon değil, sitenize gerçekten gelen ziyaretçilerin cihazında ölçülen yükleme deneyimi. Bu veri, Google'ın Web Vitals programının temel veri kaynağı ve arama sonuçlarındaki sayfa deneyimi sinyalini de besliyor.

Bir sayfanın CrUX'ta görünebilmesi için yeterli sayıda gerçek ziyaret alması gerekiyor; düşük trafikli bir sayfa bu eşiği geçemezse köken (origin) düzeyindeki toplu veriye düşülüyor. Bu da tek bir iç sayfanın neden bazen "veri yok" görünüp yalnızca lab sonucuyla değerlendirildiğini açıklıyor.

Aynı sayfada puan neden değişir​


web.dev'in belgesi, sayfa yüklemelerinin "her zaman deterministik olmadığını" doğrudan belirtiyor. Buna göre puan dalgalanmasının birkaç somut nedeni var:

  • Cihaz farkı: Test aracının çalıştığı makine ile gerçek ziyaretçinin telefonu veya bilgisayarı aynı işlem gücüne sahip olmayabilir.
  • Ağ koşulu: Lab testleri genelde sabit bir bağlantı simüle eder; gerçek kullanıcı değişken bir mobil ağdan bağlanıyor olabilir.
  • Kişiselleştirilmiş içerik: Reklam sunucusundan gelen gecikme veya A/B test varyasyonu, aynı URL'de farklı yük süreleri doğurabilir.
  • Sunucu tarafı dalgalanma: Aynı anda gelen başka isteklerin sunucu yanıt süresini değiştirmesi, ölçümü ölçüm anına bağlı kılar.

Etkileşim performansına giren metriklerde bu dalgalanma daha da belirgin: kullanıcının sayfayla ne zaman ve nasıl etkileşime girdiği testten teste değişir. Bir kullanıcı sayfa yüklenir yüklenmez bir düğmeye tıklarken bir başkası sayfayı sadece kaydırıyor olabilir; bu iki davranış aynı sayfa için tamamen farklı gecikme ölçümü üretir. Bu metriği ayrıntılı işleyen INP etkileşim performansı rehberimizde bu değişkenliğin hangi kullanıcı davranışlarından kaynaklandığını daha ayrıntılı görebilirsiniz.

CrUX tarafında da benzer bir değişkenlik var: veri seti tek bir günün trafiğini değil, belirli bir süre boyunca biriken toplu ziyaretleri özetliyor. Bu yüzden bugün baktığınız saha puanı ile birkaç gün sonra bakacağınız puan, sayfada hiçbir değişiklik yapmasanız bile veri penceresi kaydıkça farklı çıkabilir; bu durum lab testindeki anlık dalgalanmadan ayrı, saha verisine özgü bir başka değişkenlik kaynağıdır.

Hangi sayıya göre karar vermeli​


Tek bir lab testinin sonucunu yayın kararı için kullanmak, o anki tesadüfi koşulları genel bir hüküm gibi okumaya benziyor. Doğru sıralama şöyle işliyor: yayın öncesi regresyon kontrolü için lab verisi, canlıdaki sayfanın gerçek kullanıcı deneyimini görmek için ise saha verisi.

Bir sayfanın gerçekten iyi mi kötü mü performans gösterdiğine karar vermeden önce, o sayfanın belirli bir süre boyunca toplanmış saha verisini bütün olarak değerlendirmek, tek seferlik lab sonucundan çok daha güvenilir bir tablo veriyor. Bu konuyu Core Web Vitals özelinde derli toplu ele alan Core Web Vitals rehberimize de bakabilirsiniz; orada hangi metriğin hangi eşiği geçmesi gerektiği ayrıca anlatılıyor.

Kendi ölçümünüzü nasıl kontrol edersiniz​


Google Search Console'daki Core Web Vitals raporu doğrudan CrUX verisine dayanıyor ve sayfalarınızı iyi, iyileştirilmesi gereken ve kötü olarak kümeliyor. PageSpeed Insights ise tek bir ekranda hem lab hem saha sonucunu yan yana gösteriyor; ikisi arasındaki farkı görmek için bu ikisini karşılaştırmak yeterli.

Bu tür verilerin panelinize nasıl aktığını merak ediyorsanız, Site Kit'in PageSpeed Insights verilerini Analytics'e eklemesiyle ilgili haberimiz bu entegrasyonun nasıl çalıştığını gösteriyor.

Püf nokta' Alıntı:
Tek bir test sonucunu değil, aynı sayfanın birkaç günlük saha verisini karar noktası yapın.

Özetle​


Bir hız testi aracının her seferinde farklı sayı vermesi araç hatası değil; lab verisinin doğası gereği tek seferlik ve koşullara bağlı olmasından kaynaklanıyor. Yayın öncesi kontrol için lab, gerçek kullanıcı deneyimi için saha (CrUX) verisine bakmak, aynı sayfa için gördüğünüz çelişkili sayıları anlamlandırmanın en güvenilir yolu.

Siz hangi araçla ölçtüğünüzde, aynı sayfada en büyük fark ne kadar çıktı?

Güncelleme: 24 Ağustos 2026.



Dijital Dünyanıza Yön Veren Pusula
 

Ekli dosyalar

  • banner_01.jpg
    banner_01.jpg
    5.5 KB · Görüntüleme: 1
Geri
Üst