Site Hızı Testi Nasıl Yapılır? PageSpeed Insights Sonuçlarını Doğru Okuma

Site hızı testi, bir web sayfasının ne kadar sürede yüklendiğini, ne zaman kullanılabilir hale geldiğini ve yükleme sırasında ne kadar kararlı kaldığını ölçen analizdir. En pratik yolu, sayfa adresini Google'ın ücretsiz aracı PageSpeed Insights'a girip hem gerçek kullanıcı verisini hem de laboratuvar ölçümünü birlikte okumaktır. Doğru bir sayfa hızı testi tek bir puana bakmaz; saha verisini, şablon farklarını ve önceliklendirilmiş iyileştirme listesini birlikte değerlendirir.

Bu rehberde hız ölçmenin yollarını, PageSpeed Insights raporundaki her bölümün ne anlama geldiğini, puanın neden her testte değiştiğini, hangi önerinin önce ele alınması gerektiğini ve hız iyileştirmesinin dönüşüme etkisini GA4'te nasıl izleyeceğinizi adım adım anlatıyoruz. LCP, INP ve CLS metriklerinin ayrıntılı tanımları ve eşik değerleri için LCP Nedir? Core Web Vitals rehberimize bakabilirsiniz; burada bu metrikleri yeniden anlatmak yerine testin nasıl yapılıp okunacağına odaklanıyoruz.

Site hızını ölçmenin yolları

Hız ölçmek için tek bir araç yeterli değildir, çünkü her araç farklı bir soruya cevap verir. Bir kısmı "gerçek kullanıcılar sitemi nasıl yaşıyor?" sorusunu, bir kısmı "kontrollü ortamda bu sayfanın darboğazı ne?" sorusunu yanıtlar. Aşağıdaki dört kaynak birlikte kullanıldığında eksiksiz bir tablo verir.

1. PageSpeed Insights

PageSpeed Insights, tek bir URL için iki tür veri gösterir. Üst bölümde, Chrome kullanıcılarından toplanan gerçek deneyim verisi (Chrome Kullanıcı Deneyimi Raporu, kısaca CrUX) yer alır. Alt bölümde ise Lighthouse motoruyla yapılan anlık laboratuvar testi ve 0 ile 100 arasında bir performans puanı bulunur. Sayfanın yeterli trafiği yoksa üst bölümde yalnızca alan adının geneline ait veri görünebilir ya da hiç veri görünmeyebilir; bu durum bir hata değil, örneklem yetersizliğidir.

2. Lighthouse

Lighthouse, PageSpeed Insights'ın arka planda kullandığı açık kaynaklı denetim aracıdır ve Chrome'un geliştirici araçlarına gömülü olarak gelir. Avantajı, testi kendi bilgisayarınızda, giriş yapılmış sayfalarda, hazırlık (staging) ortamında ya da henüz yayına alınmamış bir sürümde çalıştırabilmenizdir. Dezavantajı, sonucun bilgisayarınızın gücünden, açık sekmelerden ve tarayıcı eklentilerinden etkilenmesidir. Bu yüzden Lighthouse'u gizli pencerede, eklentiler kapalıyken çalıştırmak daha tutarlı sonuç verir.

3. Chrome Geliştirici Araçları

Puanın neden düşük olduğunu anlamak için Chrome Geliştirici Araçları'ndaki Ağ (Network) ve Performans (Performance) panelleri vazgeçilmezdir. Ağ panelinde hangi dosyanın ne kadar büyük olduğunu, hangi isteğin diğerlerini beklettiğini ve sunucunun ilk yanıtı ne kadar sürede verdiğini görürsünüz. Performans panelinde ise sayfa yüklenirken ana iş parçacığını meşgul eden uzun JavaScript görevlerini, düzen kaymalarını ve en büyük içerik öğesinin ne zaman ekrana çizildiğini zaman çizelgesi üzerinde izleyebilirsiniz. Her iki panelde de ağ hızını ve işlemci gücünü yapay olarak düşürme seçeneği bulunur; mobil deneyimi masaüstünde taklit etmek için bunu kullanın.

4. Search Console Core Web Vitals raporu

Search Console'daki Core Web Vitals raporu, tek tek sayfalar yerine benzer URL'leri gruplayarak tüm sitenin durumunu gösterir. "Kötü", "iyileştirilmesi gerekiyor" ve "iyi" olarak sınıflanan URL grupları, sorunun site genelinde mi yoksa belirli bir şablonda mı olduğunu hızlıca anlamanızı sağlar. Bu rapor da CrUX verisine dayandığı için düşük trafikli siteler için boş görünebilir. Raporun genel kullanımı için Google Search Console rehberimize göz atabilirsiniz.

Çok konumlu test araçları

Bunlara ek olarak, sayfanızı farklı ülkelerdeki sunuculardan, farklı tarayıcı ve bağlantı profilleriyle test eden çok konumlu test araçları da vardır. Bu araçlar özellikle şelale (waterfall) grafiği, yükleme sürecinin kare kare görüntüsü ve tekrarlı test ortalaması gibi ayrıntılarda faydalıdır. Ancak hangi aracı kullanırsanız kullanın, test konumunu hedef kitlenize yakın seçin; Türkiye'deki kullanıcılarınız için yurt dışındaki bir sunucudan yapılan test, gerçek deneyimi yansıtmaz.

Saha verisi ile laboratuvar verisi: hangisine güvenmeli?

PageSpeed Insights raporunu okurken yapılan en yaygın hata, alt bölümdeki performans puanını sitenin "gerçek hızı" sanmaktır. Oysa iki bölüm tamamen farklı şeyleri ölçer.

Özellik	Saha verisi (CrUX)	Laboratuvar verisi (Lighthouse)
Kaynak	Gerçek Chrome kullanıcıları	Tek bir simüle edilmiş ziyaret
Zaman aralığı	Son 28 günün birikimi	Testin yapıldığı an
Cihaz ve bağlantı	Kullanıcıların gerçek cihazları ve ağları	Sabit bir cihaz ve bağlantı profili
Etkileşim ölçümü	INP gibi gerçek etkileşim metrikleri	Etkileşim yok; yerine dolaylı metrikler
Değişiklik sonrası tepki	Yavaş, haftalar içinde yansır	Anında
Kullanım amacı	Durum tespiti ve hedef takibi	Hata ayıklama ve hızlı doğrulama

Kısa cevap şudur: durumu saha verisiyle değerlendirin, sorunu laboratuvar verisiyle çözün. Google'ın sayfa deneyimi değerlendirmesinde esas aldığı veri, gerçek kullanıcı verisidir. Laboratuvar puanınız 55 olduğu halde saha verisinde tüm metrikler "iyi" görünüyorsa, kullanıcılarınız büyük olasılıkla hızlı bir deneyim yaşıyordur. Tersi de mümkündür: laboratuvarda 90 alan bir sayfa, kullanıcılarınızın çoğu eski telefonlar ve zayıf mobil bağlantılar kullanıyorsa sahada kötü sonuç verebilir.

Laboratuvar verisinin değeri, değişikliği yaptığınız anda etkisini görebilmenizdir. Saha verisi 28 günlük birikimle hesaplandığı için bir iyileştirmenin sahada tam yansıması yaklaşık dört hafta sürer. Bu yüzden iyileştirme döngüsü genellikle şöyle işler: saha verisinden sorunu tespit et, laboratuvarda nedenini bul ve düzelt, laboratuvarda doğrula, ardından saha verisinin dört hafta içinde düzelmesini izle.

Mobil ve masaüstü skorları neden bu kadar farklı?

PageSpeed Insights'ta mobil puanın masaüstünden belirgin biçimde düşük çıkması neredeyse her sitede görülür ve çoğu zaman beklenen bir durumdur. Mobil test, orta seviye bir telefonu ve yavaş bir mobil bağlantıyı simüle eder: işlemci yapay olarak yavaşlatılır, ağ gecikmesi artırılır, bant genişliği daraltılır. Masaüstü testi ise güçlü bir işlemci ve hızlı bir bağlantı varsayar.

Bu farkın pratik sonucu şudur: masaüstünde fark edilmeyen ağır bir JavaScript paketi, mobil simülasyonda ana iş parçacığını uzun süre kilitler ve puanı ciddi biçimde düşürür. Bu nedenle önceliği her zaman mobil sonuca verin. Google, siteleri mobil sürümleri üzerinden dizine ekler ve Türkiye'de pek çok sektörde trafiğin büyük kısmı mobil cihazlardan gelir. Kendi oranınızı GA4'teki cihaz kategorisi kırılımından kontrol edebilirsiniz.

Performans puanı neden her testte değişiyor?

Aynı sayfayı arka arkaya üç kez test ettiğinizde 62, 71 ve 66 gibi farklı puanlar görmeniz olağandır. Bu dalgalanmanın başlıca nedenleri şunlardır:

• Sunucu yanıt süresi: Sunucunuzun o anki yükü, önbelleğin dolu ya da boş olması ilk baytın gelme süresini değiştirir.
• Üçüncü taraf betikler: Reklam, sohbet, analiz ve sosyal medya betikleri her yüklemede farklı içerik ve farklı sürede yanıt verebilir.
• Ağ koşulları: Test sunucusu ile siteniz arasındaki ağ trafiği her an aynı değildir.
• Dinamik içerik: Rastgele değişen kampanya görselleri, kaydırıcılar (slider) veya kişiselleştirilmiş bloklar en büyük içerik öğesini testten teste değiştirebilir.
• A/B testleri ve çerez bildirimleri: Farklı varyasyonların veya izin pencerelerinin yüklenmesi düzeni ve süreyi etkiler.

Tek bir teste göre karar vermemek için aynı URL'yi en az üç ila beş kez test edin ve ortanca (medyan) değeri kaydedin. Ortalama yerine ortanca kullanmak, tek bir aşırı yavaş ya da aşırı hızlı ölçümün sonucu çarpıtmasını engeller. Puandaki birkaç puanlık oynamaya değil, metriklerdeki kalıcı değişime odaklanın.

Fırsatlar ve teşhisler bölümünü önceliklendirme

Laboratuvar raporunun alt kısmında iyileştirme önerileri yer alır. Arayüzün sürümüne göre bu öneriler "fırsatlar" ve "teşhisler" başlıkları altında ya da içgörü niteliğinde gruplanmış olarak gösterilebilir. Hangi düzende olursa olsun mantık aynıdır: bazı öneriler tahmini kazanç süresiyle birlikte gelir, bazıları ise doğrudan süre vermeyen ama sorunun kaynağına işaret eden tespitlerdir.

Bu listeyi yukarıdan aşağı uygulamak yerine şu sırayla önceliklendirin:

1. Saha verisinde sorunlu olan metriği belirleyin. Sahada LCP kötüyse, CLS ile ilgili önerilerle vakit kaybetmeyin. Raporun metrik filtresini kullanarak yalnızca ilgili metriği etkileyen önerileri görüntüleyebilirsiniz.
2. Tahmini kazancı yüksek olanları öne alın. Birkaç saniyelik kazanç vaat eden bir görsel optimizasyonu, birkaç milisaniyelik bir öneriden önce gelir.
3. Uygulama maliyetini tartın. Görselleri modern formata çevirmek ya da en büyük görsele öncelik ipucu eklemek genellikle düşük maliyetlidir. Tema veya çerçeve değiştirmek ise yüksek maliyetlidir.
4. Site geneline etki eden düzeltmeleri seçin. Ortak şablonda yapılan bir düzeltme yüzlerce sayfayı aynı anda iyileştirir.
5. Üçüncü taraf betikleri sorgulayın. Kullanılmayan pikselleri, eski etiketleri ve gereksiz sohbet eklentilerini kaldırmak çoğu zaman kod yazmadan kazanç sağlar. Etiketlerin nasıl yönetildiğini Google Tag Manager rehberimizde anlattık.

Sık karşılaşılan önerilerin pratik karşılıkları şöyledir:

Öneri türü	Ne anlama gelir?	Tipik çözüm
Oluşturmayı engelleyen kaynaklar	CSS veya JS dosyaları sayfanın çizilmesini bekletiyor	Kritik CSS'i satır içine al, betikleri defer ile yükle
Görselleri uygun boyutlandırma	Ekranda gösterilenden büyük görsel indiriliyor	srcset ile cihaza göre boyut sun
Modern görsel biçimleri	JPEG ve PNG gereğinden ağır	WebP veya AVIF'e dönüştür
Kullanılmayan JavaScript	İndirilen kodun önemli kısmı o sayfada çalışmıyor	Kodu sayfa bazında böl, gereksiz eklentileri kaldır
Sunucu yanıt süresi uzun	İlk bayt geç geliyor	Sayfa önbelleği, daha güçlü sunucu, içerik dağıtım ağı
Ana iş parçacığı çalışmasını azaltma	Tarayıcı JavaScript çalıştırmakla meşgul	Uzun görevleri böl, ağır betikleri ertele

Örneğin en büyük içerik öğesi ana görselse, o görsele tembel yükleme uygulanmamalı ve tarayıcıya öncelik ipucu verilmelidir:

<img src="/gorseller/kapak.webp" width="1200" height="600"
     fetchpriority="high" alt="Kampanya görseli">

Ekranın altında kalan görsellerde ise tersini yapın ve loading="lazy" kullanın. Görsellere genişlik ve yükseklik vermek, düzen kaymasını önlemenin de en basit yoludur.

Ana sayfa yerine şablon bazlı test yapın

Çoğu site sahibi hız testini yalnızca ana sayfada yapar. Oysa organik trafiğin büyük bölümü çoğu zaman ana sayfaya değil; ürün, kategori ve blog sayfalarına gelir. Bu sayfalar farklı şablonlardan üretildiği için hız sorunları da farklıdır: kategori sayfasında onlarca ürün görseli, ürün sayfasında görsel galerisi ve yorum eklentisi, blog sayfasında gömülü videolar ve reklam alanları performansı belirler.

Şablon bazlı test için şu yöntemi izleyin:

1. Sitenizdeki sayfa türlerini listeleyin: ana sayfa, kategori, ürün, blog yazısı, iletişim, arama sonuçları.
2. Her şablondan en çok organik trafik alan bir veya iki URL seçin. Bunu Search Console'daki Sayfalar raporundan ya da GA4'teki açılış sayfası raporundan bulabilirsiniz.
3. Her URL'yi mobil için üç ila beş kez test edin ve ortanca değerleri kaydedin.
4. Search Console Core Web Vitals raporundaki URL gruplarının hangi şablona denk geldiğini eşleştirin.
5. En kötü durumdaki ve en çok trafik alan şablondan başlayın.

E-ticaret sitelerinde kategori ve ürün sayfaları genellikle en kritik şablonlardır; bu sayfa türlerine özgü diğer teknik konular için E-Ticaret SEO rehberimize, hızın genel teknik SEO içindeki yeri için Teknik SEO yazımıza bakabilirsiniz.

Test öncesi ve sonrası karşılaştırma tablosu

Bir iyileştirmenin işe yarayıp yaramadığını anlamanın tek yolu, değişiklikten önce ve sonra aynı koşullarda ölçüm yapmaktır. Aşağıdaki gibi basit bir tablo, hem ekip içinde hem de müşteriye raporlamada işinizi kolaylaştırır. Tablodaki değerler örnek amaçlıdır; kendi ölçümlerinizle doldurun.

Şablon	Metrik	Önce (ortanca)	Sonra (ortanca)	Yapılan değişiklik
Ürün sayfası	LCP (laboratuvar)	4,8 sn	2,6 sn	Ana görsel WebP, öncelik ipucu eklendi
Ürün sayfası	Toplam engelleme süresi	900 ms	350 ms	Sohbet betiği etkileşime ertelendi
Kategori sayfası	CLS (laboratuvar)	0,24	0,04	Ürün kartı görsellerine boyut verildi
Blog yazısı	Performans puanı	48	79	Gömülü video tıklayınca yüklenir hale getirildi

Karşılaştırmanın güvenilir olması için şu kurallara uyun:

• Aynı aracı, aynı cihaz profilini (mobil) ve aynı URL'yi kullanın.
• Her ölçümde en az üç test yapıp ortanca değeri yazın.
• Değişiklik tarihini not edin; dört hafta sonra saha verisini ayrıca karşılaştırın.
• Aynı anda çok sayıda değişiklik yaparsanız hangisinin etkili olduğunu ayırt edemezsiniz; mümkünse değişiklikleri gruplar halinde yayına alın.
• Önbellek eklentisi veya içerik dağıtım ağı kullanıyorsanız, değişiklik sonrası önbelleği temizledikten sonra test edin.

Hız ile dönüşüm ilişkisini GA4'te izleme

Hız iyileştirmesinin asıl amacı puan değil, daha fazla satış, form ve arama trafiğidir. Bu ilişkiyi görmek için hız verisini davranış verisiyle aynı yerde izlemeniz gerekir.

Gerçek kullanıcı hız verisini GA4'e gönderme

GA4, Core Web Vitals metriklerini varsayılan olarak toplamaz. Bu metrikleri gerçek kullanıcılardan ölçmek için Google'ın açık kaynaklı web-vitals JavaScript kütüphanesini kullanabilir, her ölçümü özel bir etkinlik olarak GA4'e gönderebilirsiniz. Basitleştirilmiş bir örnek:

<script type="module">
import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
function gonder(metrik) {
  gtag('event', metrik.name, {
    value: Math.round(metrik.name === 'CLS' ? metrik.value * 1000 : metrik.value),
    metric_id: metrik.id,
    metric_rating: metrik.rating
  });
}
onLCP(gonder); onINP(gonder); onCLS(gonder);
</script>

Aynı kurulum Google Tag Manager üzerinden özel HTML etiketi ve veri katmanı ile de yapılabilir. Etkinlik parametrelerini GA4'te özel boyut ve metrik olarak tanımladıktan sonra raporlarda kullanabilirsiniz. GA4'ün genel yapısı ve etkinlik mantığı için Google Analytics rehberimize bakabilirsiniz.

Hangi raporlara bakmalı?

• Açılış sayfasına göre dönüşüm: Hızlandırdığınız şablonun açılış sayfası olduğu oturumlarda, değişiklik öncesi ve sonrası dört haftalık dönemi karşılaştırın.
• Cihaz kategorisine göre kırılım: Hız iyileştirmesinin etkisi genellikle mobilde daha belirgin olur; mobil ve masaüstü dönüşüm oranlarını ayrı izleyin.
• Metrik değerlendirmesine göre segment: "İyi" ve "kötü" LCP deneyimi yaşayan kullanıcıların etkileşim oranı ve dönüşüm oranı arasındaki farkı keşif raporunda karşılaştırın.

Burada dikkatli olun: dönemsel karşılaştırmada kampanyalar, mevsimsellik ve trafik kaynağı değişimleri de sonucu etkiler. Hız ile dönüşüm arasında net bir bağ kurabilmek için aynı dönemde büyük kampanya veya fiyat değişikliği olmamasına dikkat edin ve mümkünse "iyi" ile "kötü" deneyim yaşayan kullanıcıları aynı dönem içinde karşılaştırın. Dönüşüm oranının nasıl hesaplanıp yorumlanacağını Dönüşüm Oranı Nedir? yazımızda ayrıntılı ele aldık. Search Console, GA4 ve Tag Manager verisini tek panelde birleştirmek isterseniz seoanalytics.com.tr bu verileri açılış sayfası bazında yan yana gösterir; böylece hız iyileştirmesi yaptığınız sayfaların tıklama ve dönüşüm değişimini ayrı ayrı rapor çekmeden izleyebilirsiniz.

Site hızı testi kontrol listesi

• PageSpeed Insights'ta önce saha verisine bakıldı, sayfa ve alan adı geneli ayrı değerlendirildi.
• Mobil sonuç esas alındı.
• Her URL en az üç kez test edildi, ortanca değer kaydedildi.
• Ana sayfa dışında ürün, kategori ve blog şablonlarından en çok trafik alan sayfalar test edildi.
• Search Console Core Web Vitals raporundaki URL grupları şablonlarla eşleştirildi.
• Öneriler, sahada sorunlu metriğe ve tahmini kazanca göre sıralandı.
• Üçüncü taraf betikler gözden geçirildi, kullanılmayanlar kaldırıldı.
• Değişiklik öncesi ve sonrası karşılaştırma tablosu dolduruldu.
• Değişiklikten dört hafta sonra saha verisi yeniden kontrol edildi.
• Hız metrikleri GA4'e aktarılarak dönüşümle ilişkisi izlenmeye başlandı.

Sık sorulan sorular

PageSpeed Insights puanım düşük ama saha verisi iyi, ne yapmalıyım?

Saha verisindeki Core Web Vitals metrikleri "iyi" durumdaysa kullanıcılarınız hızlı bir deneyim yaşıyor demektir ve acil bir sorun yoktur. Laboratuvar puanını yükseltmeye çalışmak yine de faydalıdır, çünkü daha yavaş cihaz ve bağlantıya sahip kullanıcılar için güvenlik payı sağlar; ancak önceliği saha verisinde sorunlu olan sayfalara verin.

Site hızı testi ne sıklıkla yapılmalı?

Search Console Core Web Vitals raporunu ayda bir kontrol etmek çoğu site için yeterlidir. Bunun dışında yeni tema, eklenti, takip kodu veya büyük tasarım değişikliği yayına almadan önce ve aldıktan sonra mutlaka laboratuvar testi yapın; hız gerilemelerinin büyük kısmı bu değişikliklerle gelir.

Performans puanı 100 olmadan sıralama alınamaz mı?

Hayır. Sayfa deneyimi sıralamada dikkate alınan sinyallerden biridir, ancak içeriğin arama niyetine uygunluğu ve kalitesi çok daha belirleyicidir. 100 puan hedeflemek yerine saha verisinde tüm metrikleri "iyi" aralığa taşımayı hedeflemek daha gerçekçi ve daha anlamlıdır.

Giriş gerektiren veya yayında olmayan sayfaların hızını nasıl test ederim?

PageSpeed Insights yalnızca herkese açık URL'leri test edebilir. Giriş gerektiren panel sayfaları, sepet adımları veya hazırlık ortamındaki sürümler için Chrome Geliştirici Araçları içindeki Lighthouse'u kullanın. Testi gizli pencerede, eklentiler kapalıyken ve mobil cihaz simülasyonu seçiliyken çalıştırırsanız sonuçlar PageSpeed Insights'a daha yakın olur.