Site hız testi: PageSpeed, Lighthouse ve CrUX farkı
Site hız testi sonuçları neden birbirini tutmaz? PageSpeed, Lighthouse ve CrUX'un ölçtüğü şey, alan ve laboratuvar verisi farkı, doğru okuma sırası.
Yazan Roozbeh Nazari · CEO
Site hız testi yapan herkes aynı şaşkınlığı yaşar: PageSpeed Insights 62 verir, Lighthouse 91 verir, Search Console'daki Core Web Vitals raporu "iyileştirme gerekiyor" der ve üçü de aynı sayfayı ölçmüş görünür. Bu bir tutarsızlık değildir; üç araç üç farklı şeyi ölçer ve her birinin cevabı farklı bir soruya aittir. Bu yazı, PageSpeed Insights, Lighthouse ve Chrome Kullanıcı Deneyimi Raporu'nun (CrUX) neyi, kimden, hangi koşulda ölçtüğünü açıklıyor; sonra bir site hız testinin hangi sırayla okunması gerektiğini ve hangi rakamın hangi karara dayanak olabileceğini anlatıyor. Amaç, "puanı yükseltmek" yerine kullanıcının gerçekten yaşadığı hızı iyileştirmek.
Laboratuvar verisi ile alan verisi
Temel ayrım şudur: laboratuvar (lab) verisi, tek bir sanal cihazda, sabit ağ koşuluyla, o anda çalıştırılan bir yükleme simülasyonudur. Alan (field) verisi ise gerçek kullanıcıların gerçek cihaz ve bağlantılarıyla, geçmiş bir dönemde yaşadığı deneyimin toplamıdır. Google'ın PageSpeed Insights dokümanı bu ayrımı açıkça yapar: alan verisi kullanıcıların FCP, INP, LCP ve CLS deneyimlerini geçmişe dönük derler; laboratuvar verisi ise standart bir cihazda simülasyondur ve bu yüzden ikisi farklı sonuç verebilir. Laboratuvar verisi tekrarlanabilir ve hata ayıklamaya uygundur; alan verisi ise kullanıcı gerçeğidir ve Google'ın sayfa deneyimi değerlendirmesinde kullandığı taraftır. Bir site hız testini okurken ilk soru bu olmalı: baktığım rakam simülasyon mu, kullanıcı mı?
Üç aracın ölçtüğü şey
Lighthouse, Chrome'un içine gömülü açık kaynaklı bir denetim aracıdır; sayfayı sıfırdan yükler, performansın yanında erişilebilirlik ve SEO gibi kategorilerde de puan üretir. Ürettiği performans puanı tamamen laboratuvar verisidir ve çalıştırdığınız cihaza, uzantılarınıza ve ağınıza göre değişir; aynı sayfada arka arkaya iki ölçüm farklı çıkabilir. CrUX, Chrome kullanıcılarının gerçek deneyiminden derlenen bir veri setidir; yalnızca kamuya açık ve yeterli trafiği olan kaynaklar ve sayfalar için veri içerir, bu yüzden yeni ya da düşük trafikli sayfalar için "yeterli veri yok" der. PageSpeed Insights ikisini tek ekranda gösterir: üstte CrUX'tan gelen alan verisi (varsa), altta o anda çalıştırılan Lighthouse laboratuvar sonucu. Yani PageSpeed'in üst kısmı Search Console'un Core Web Vitals raporuyla aynı kaynağa dayanır; alt kısmı ise Lighthouse'un ta kendisidir. Üç aracın "aynı sayfada üç farklı puan" vermesinin sebebi budur: aslında iki veri kaynağı ve iki farklı özet biçimi vardır.
Core Web Vitals eşikleri ve doğru okuma sırası
Alan verisinde bakılan üç ana metrik Core Web Vitals'tır. web.dev'in güncel tanımına göre iyi bir deneyim için LCP 2,5 saniye içinde olmalı, INP 200 milisaniye ya da altında kalmalı, CLS 0,1'i geçmemelidir; değerlendirme, kullanıcıların yüzde 75'lik dilimi üzerinden yapılır. Doğru okuma sırası şöyle: önce alan verisine bakın; sayfa CrUX'ta eşikleri geçiyorsa laboratuvar puanı düşük olsa da kullanıcı sorunu yoktur, iyileştirme önceliği başka sayfadadır. Alan verisi eşiği geçmiyorsa hangi metrikte kaldığına bakın; LCP sorunuysa büyük görsel, sunucu yanıt süresi ya da render engelleyen kaynak aranır; INP sorunuysa ana iş parçacığını meşgul eden betikler; CLS sorunuysa boyutsuz görseller ve geç yüklenen bloklar. Ancak bu noktada Lighthouse'a geçin: laboratuvar raporu, alan verisinin işaret ettiği metriği neyin bozduğunu satır satır gösterir. Ters sırayla, yani Lighthouse puanından başlayarak çalışan ekipler, kullanıcıların yaşamadığı sorunları düzeltmeye haftalar harcayabilir. Bir de üçüncü katman vardır: Search Console'un Core Web Vitals raporu, aynı CrUX verisini sayfa grupları hâlinde gösterir ve hangi şablonun (ürün sayfası, blog yazısı, kategori) sorunlu olduğunu tek bakışta ortaya çıkarır; tek tek sayfa testinden önce bu rapora bakmak, işi doğru şablona yönlendirir. Teknik SEO hizmetimizde hız denetimi bu sırayla yapılır ve raporda her bulgu "alan" ya da "laboratuvar" etiketiyle ayrılır.
Çok dilli ve mobil sitelerde ek notlar
CrUX verisi cihaz tipine göre ayrılır ve çoğu Türkiye sitesinde mobil dilim masaüstünden belirgin biçimde kötüdür; site hız testini yalnızca masaüstünde okumak, kullanıcının büyük kısmını görmezden gelmek demektir. Çok dilli sitelerde ikinci bir tuzak vardır: CrUX, kaynak (origin) düzeyinde ve sayfa düzeyinde veri verir; Arapça ve Farsça sayfalar ayrı font dosyaları ve sağdan sola düzen nedeniyle Türkçe sayfalardan farklı LCP ve CLS üretebilir, ama düşük trafikli oldukları için sayfa düzeyinde veri görünmeyebilir. Bu durumda kaynak düzeyi verisi Türkçe sayfaların ağırlığını taşır ve sorun gizlenir. Çözüm, dil bazlı sayfa gruplarını Search Console'un Core Web Vitals raporunda ayrı ayrı izlemek ve veri olmayan diller için laboratuvar ölçümünü aynı cihaz profiliyle düzenli tekrarlamaktır. Uluslararası hasta için Core Web Vitals yazımız bu ayrımı klinik siteleri örneğiyle ele alıyor.
Hangi rakam hangi karara dayanak olur
Yönetim raporuna giren rakam alan verisi olmalıdır: "LCP mobilde 2,5 saniyeyi geçen sayfa yüzdesi" gibi. Geliştirici görevine giren rakam laboratuvar verisidir: "bu sayfada render engelleyen 3 betik" gibi. Ajans ya da yazılımcı sizden "PageSpeed puanını 90'a çıkardık" diye onay istiyorsa hangi bölümden bahsettiğini sorun; laboratuvar puanı bir günde değişebilir, alan verisi ise 28 günlük pencerede birikir ve iyileşme ancak birkaç hafta sonra görünür. Bu gecikme bir kusur değil, ölçümün gerçek kullanıcıya dayanmasının bedelidir. Site hız testini bir puan yarışı olarak değil, iki katmanlı bir teşhis aracı olarak okuyan ekipler, hem kullanıcının hem de arama motorunun gördüğü hızı iyileştirir; puanı yükseltip kullanıcıyı aynı yerde bırakan ekipler ise yalnızca ekran görüntüsü üretir.
Beş dakikalık site hız testi protokolü
Bir sayfa için hızlı bir teşhis şöyle yapılır. PageSpeed Insights'a sayfanın adresini girin ve önce mobil sekmesindeki üst bölüme bakın: alan verisi varsa üç Core Web Vitals metriğinin geçti ya da kaldı durumunu not edin; yoksa kaynak düzeyi verisine geçin ve bunun sayfa değil site ortalaması olduğunu raporda belirtin. Sonra aynı ekranın alt bölümündeki Lighthouse denetimlerinden yalnızca kalan metriğe ait olanları okuyun; LCP için en büyük içerik öğesi ve sunucu yanıt süresi, INP için uzun görevler, CLS için boyutsuz öğeler. Bulguları geliştiriciye puanı yükselt diye değil, metrik ve öğe adıyla iletin. Düzeltme yayına alındıktan sonra Lighthouse'u aynı gün, alan verisini ise dört hafta sonra tekrar okuyun; ikisinin de iyileşmesi gerçek bir kazanımdır, yalnızca ilkinin iyileşmesi ise henüz kullanıcıya ulaşmamış bir değişikliktir.