Site hızını doğru ölçmenin sırrı tek bir skora bakmak değil, doğru aracı doğru metrikle eşleştirmektir. Gerçek kullanıcı deneyimini saha verisi (Search Console, CrUX), olası sorunları ise lab verisi (Lighthouse, GTmetrix) gösterir. Bu yazıda hangi aracın ne işe yaradığını, hangi metriğin neyi ölçtüğünü ve düzenli bir ölçüm rutinini adım adım göreceksin.
Çoğu Türkçe kaynak "şu araçla test et, 90 üstü skor al" der ve orada kalır. Oysa yüksek bir Lighthouse skoru, gerçek ziyaretçilerinin hızlı bir deneyim yaşadığı anlamına gelmez. Bu ayrımı bilmeden yapılan optimizasyon çoğu zaman yanlış yere harcanmış emektir. Aşağıda işi temelinden ele alıyoruz.
Ölçüm araçları: hangisi ne verir?
Site hızı araçları kabaca iki gruba ayrılır ve bu ayrımı bilmek, hangi sonuca güveneceğini belirler. Bazı araçlar sentetik test yapar, yani sabit bir cihaz ve ağ koşulunda sayfanı bir kez çalıştırır. Bazıları ise gerçek ziyaretçilerinin tarayıcılarından toplanan verileri gösterir.
Lab (sentetik) araçlar
Lighthouse, GTmetrix ve WebPageTest gibi araçlar sayfanı kontrollü bir laboratuvar ortamında çalıştırır. Aynı testi tekrar tekrar yaptığında benzer sonuç alırsın, bu yüzden bir değişikliğin etkisini ölçmek ve hata ayıklamak için idealdirler. Avantajı tekrarlanabilir olmaları, sınırı ise tek bir cihaz ve bağlantıyı temsil etmeleridir.
Saha (RUM) verisi araçları
Google Search Console'un Core Web Vitals raporu ve Chrome User Experience Report (CrUX), sitene gerçekten giren kullanıcıların ölçümlerini toplar. Bu veriye RUM yani Gerçek Kullanıcı İzleme denir. Farklı cihazlar, farklı ağlar ve farklı kullanım alışkanlıkları bu rakamların içindedir, dolayısıyla deneyimin gerçek halini gösterir.
İkisini birden veren araç
PageSpeed Insights özel bir yerde durur: hem Lighthouse'a dayalı lab verisini hem de varsa CrUX'tan gelen saha verisini aynı ekranda gösterir. Sayfanın üst kısmındaki saha verisi gerçek deneyimi, alt kısmındaki lab sonuçları ise olası sorunların kaynağını anlamana yardımcı olur. Yeni başlayanlar için tek ekranda iki dünyayı görmek bu yüzden değerlidir.
Saha verisi mi, lab verisi mi?
Bu ayrım, Türk rakiplerin neredeyse tamamının atladığı ama en kritik konu. web.dev'in açıkladığına göre lab verisi sabit cihaz ve ağ koşullarında alınan sentetik bir ölçümdür; saha verisi ise gerçek kullanıcıların ölçümüdür ve ikisi önbellek, cihaz çeşitliliği ve kullanıcı davranışı nedeniyle farklılaşır (web.dev, "Why lab and field data can be different").
Pratikte bunun anlamı şudur: optimizasyon önceliğini saha verisine göre belirlemelisin, çünkü Google'ın değerlendirdiği ve ziyaretçinin gerçekten yaşadığı deneyim odur. Lab verisini ise hata ayıklamak ve yavaş ağ, düşük donanım gibi zorlu senaryoları yakalamak için kullanmalısın. Yani saha verisi "nerede sorun var" sorusunu, lab verisi "neden sorun var" sorusunu yanıtlar.
Kısa kural: Ne yapacağına saha verisi karar verir, nasıl yapacağını lab verisi gösterir.
Hangi metrik neyi gösterir?
Google Arama'ya göre kullanıcı deneyiminin omurgasını üç Core Web Vitals metriği oluşturur: LCP, INP ve CLS (Google Search Central, Core Web Vitals). Bu üçü sırasıyla yüklenme, yanıt verme ve görsel kararlılığı temsil eder. Hepsinin somut eşik değerleri vardır, dolayısıyla "hızlı" kelimesini tahminle değil rakamla ölçebilirsin.
LCP, yani Largest Contentful Paint (yüklenme)
LCP, görünür alandaki en büyük resim, metin bloğu veya videonun ekrana çizilme süresini ölçer; yani kullanıcının "sayfa yüklendi" hissettiği anı yakalar. web.dev'e göre eşikler şöyledir: İyi 2.5 saniye ve altı, Geliştirilmeli 2.5 ile 4.0 saniye arası, Kötü 4.0 saniyenin üzeri (web.dev, Largest Contentful Paint). Büyük görseller, yavaş sunucu yanıtı ve render engelleyen kaynaklar en sık LCP suçlularıdır.
INP, yani Interaction to Next Paint (yanıt verme)
INP, eski First Input Delay (FID) metriğinin resmî olarak yerini alan yanıt verme metriğidir. Aralarındaki fark önemli: FID yalnızca ilk etkileşimin gecikmesini ölçüyordu, INP ise sayfa ömrü boyunca tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini değerlendirir (web.dev, Interaction to Next Paint). Eşikler şöyle: İyi 200 ms ve altı, Geliştirilmeli 200 ile 500 ms arası, Kötü 500 ms üzeri. Hâlâ FID'den bahseden içerikleri gördüğünde güncel olmadıklarını anlayabilirsin.
CLS, yani Cumulative Layout Shift (görsel kararlılık)
CLS, sayfa yüklenirken öğelerin beklenmedik şekilde yer değiştirmesini, yani görsel kararlılığı ölçer. Tam tıklayacakken butonun kayması gibi sinir bozucu deneyimleri sayısallaştırır. web.dev'e göre eşikler: İyi 0.1 ve altı, Geliştirilmeli 0.1 ile 0.25 arası, Kötü 0.25 üzeri (web.dev, Cumulative Layout Shift). Boyutu belirtilmemiş görseller ve sonradan yüklenen reklamlar en yaygın nedenlerdir.
Destekleyici lab metrikleri
Core Web Vitals dışında, sorunun kökenini bulmana yardımcı olan birkaç lab metriği daha vardır. Bunlar doğrudan birer sıralama metriği değildir, ama hata ayıklarken sana yol gösterir ve hangi katmanın yavaş olduğunu söyler.
- TTFB (Time to First Byte): Sunucunun isteğe karşı gönderdiği ilk baytın süresidir. Yüksek TTFB genellikle yavaş bir LCP'nin habercisidir, çünkü tarayıcı içeriği çizmeye sunucu yanıt verene kadar başlayamaz. Sunucu yanıtı, barındırma kalitesi ve önbellekleme burada belirleyicidir.
- FCP (First Contentful Paint): Ekrana ilk metin veya görselin çizildiği andır. Kullanıcının "bir şeyler oluyor" hissetmesini sağlayan ilk işarettir.
- Speed Index: Görünür alanın ne kadar hızlı dolduğunu, yani içeriğin algılanan dolma hızını özetler.
- Total Blocking Time (TBT): Ana iş parçacığının uzun görevlerle ne kadar meşgul kaldığını ölçer. TBT yüksekse, sayfa görünse bile kullanıcı tıklamalarına geç yanıt verir; bu yüzden saha tarafındaki INP ile yakından ilişkilidir.
Bu metrikleri kendi başlarına bir hedef olarak görme. Onları, üç ana metrikten biri kötü çıktığında nedenini bulmak için kullanılan tanı araçları olarak düşün. Örneğin LCP yüksekse önce TTFB'ye bakarsın; INP kötüyse TBT ve uzun JavaScript görevleri ilk şüphelilerdir.
75. persentil: rakamı doğru okumak
Önemli bir ayrıntı: tüm Core Web Vitals eşikleri kullanıcı yüklemelerinin 75. persentilinde değerlendirilir (web.dev, LCP). Yani ortalama değil, ziyaretçilerinin dörtte üçünün yaşadığı deneyim baz alınır. Bu da en kötü yüzde 25'i göz ardı edemeyeceğin anlamına gelir; tek bir hızlı cihazda iyi sonuç almak yeterli değildir.
Mobil vs masaüstü
Aynı kaynağa göre eşikler mobil ve masaüstü için ayrı ayrı değerlendirilir. Bu, ölçüm rutininin de iki ayrı bacaklı olması gerektiği anlamına gelir. Masaüstünde harika görünen bir sayfa, daha zayıf işlemcili ve daha değişken ağ koşullarındaki bir telefonda çok farklı sonuç verebilir.
Bu yüzden ölçümü mobil öncelikli yapman akıllıca olur. Trafiğinin önemli bir kısmı büyük olasılıkla mobilden geliyor ve düşük donanımlı cihazlarla yavaş ağlar gerçek darboğazları daha net ortaya çıkarır. Masaüstü sonuçlarını ikincil bir kontrol olarak tutabilirsin, ama kararlarını mobil verisine göre verirsen gerçek kullanıcı kitlene daha yakın olursun.
Skor ile metrik aynı şey değil
Sık yapılan bir hata, Lighthouse'un 0 ile 100 arası performans skorunu tek gerçek sanmaktır. Bu skor lab koşullarında hesaplanan birkaç metriğin ağırlıklı bir özetidir. Yüksek bir skor güzeldir ama gerçek kullanıcıların saha verisi kötüyse, o skor sana yanlış bir güven verir. Tersi de mümkündür: skor orta olabilir ama saha verin gayet iyi olabilir.
Bu yüzden skoru bir rehber, saha metriklerini ise asıl karne olarak gör. Karar verirken "LCP saha verim 75. persentilde kaç saniye" sorusu, "skorum kaç" sorusundan çok daha anlamlıdır.
Hangi araç hangi veriyi verir? Hızlı özet
- PageSpeed Insights: Hem saha (CrUX) hem lab (Lighthouse) verisi. Tek ekranda genel resim için başlangıç noktası.
- Search Console Core Web Vitals raporu + CrUX: Saha verisi. Site genelinde hangi URL gruplarının sorunlu olduğunu gösterir.
- Lighthouse, GTmetrix, WebPageTest: Lab verisi. Değişikliklerin etkisini ölçmek ve sorunu izole etmek için.
Ölçüm rutini: ne zaman, neyle, neyi takip et
Tek seferlik testler yanıltıcıdır; site hızı yaşayan bir metriktir. Sürdürülebilir bir rutin, dağınık testlerden çok daha değerlidir. İşte sade bir akış:
- Geniş resim (aylık veya değişiklik sonrası): Search Console Core Web Vitals raporuyla başla. Hangi URL gruplarının "kötü" veya "geliştirilmeli" olduğunu saha verisinden gör.
- Tanı (sorunlu sayfa için): Problemli bir URL'yi PageSpeed Insights'a koy. Önce saha verisine bak, sonra lab bölümündeki uyarılarla nedenini araştır.
- Derin hata ayıklama: Lighthouse veya WebPageTest ile değişikliği test et, mobil profili kullan, bir öncesiyle karşılaştır.
- Doğrulama: Düzeltmeden sonra saha verisinin güncellenmesi zaman alır, çünkü gerçek kullanıcı ölçümleri belli bir pencerede birikir. Lab testiyle anında doğrula, saha verisinin oturmasını ise sabırla bekle.
Bu döngüyü mobil ve masaüstü için ayrı ayrı sürdür. Önemli bir yayın, tasarım değişikliği veya yeni bir eklenti sonrası ekstra bir kontrol eklemek de iyi bir alışkanlıktır.
Pratik bir öneri: bu adımları sade bir tabloya bağla. Her kontrolde tarih, ölçtüğün URL, cihaz tipi (mobil veya masaüstü) ve üç ana metriğin saha değerini not et. Böylece tek tek skorlara değil, zaman içindeki eğilime bakarsın. Bir metrik ay ay kötüleşiyorsa, bunu erken görmek sorunu büyümeden çözmeni sağlar.
Sık yapılan ölçüm hataları
Doğru aracı bilmek kadar, yaygın tuzaklardan kaçınmak da önemli. Aşağıdakiler en çok rastlananlardır:
- Tek teste güvenmek: Lab testleri çalıştığın ağa, o anki sunucu yüküne ve önbellek durumuna göre değişebilir. Tek bir ölçümü gerçek kabul etmek yerine birkaç kez ölç ve eğilime bak.
- Sadece masaüstünü test etmek: Geliştirme genellikle güçlü bir bilgisayarda yapılır, oysa ziyaretçilerin önemli bir kısmı daha zayıf telefonlardan girer. Mobil ölçümü atlamak gerçek sorunu görünmez kılar.
- Skoru saha verisiyle karıştırmak: Yüksek bir Lighthouse skoru, gerçek kullanıcı deneyiminin iyi olduğunu garanti etmez. Karar her zaman saha verisine dayanmalıdır.
- FID'de takılı kalmak: Yanıt verme artık INP ile ölçülüyor. Hâlâ yalnızca FID'ye bakan içerik veya panoları güncel referans olarak kullanma.
Özet
Site hızını ölçerken üç şeyi unutma: doğru aracı seç, saha ve lab verisini birbirine karıştırma, kararını LCP, INP ve CLS gibi gerçek metriklerin saha değerlerine göre ver. Skor güzel bir gösterge ama asıl karne, gerçek ziyaretçilerinin 75. persentildeki deneyimidir. Mobil öncelikli ölç, düzenli bir rutin kur ve her değişikliği doğrula.
VixSEO panelini Wix, Ikas veya özel sitende kullanıyorsan, Core Web Vitals takibini ve teknik SEO kontrollerini düzenli bir rutine bağlamak için araçlarımıza ve hizmetlerimize göz atabilirsin. Hız ölçümünü tek seferlik bir test değil, sürekli izlenen bir alışkanlık haline getirmen en kalıcı kazancı sağlar.