Google PageSpeed Insights, bir web sayfasının yüklenme performansını mobil ve masaüstü cihazlar için ayrı ayrı ölçen ücretsiz bir analiz aracıdır. Rapor yalnızca 100 üzerinden bir puan vermez. Gerçek kullanıcılardan toplanan deneyim verilerini, kontrollü bir test ortamındaki sonuçlarla birlikte sunar ve sayfayı hızlandırmaya yönelik somut önerileri listeler. Bu rehber, raporun her bölümünün ne anlama geldiğini, skorun nasıl hesaplandığını ve hangi metriğe hangi öncelikle müdahale edilmesi gerektiğini teknik doğruluğa dayanarak açıklar.

PageSpeed Insights Nedir ve Ne Ölçer?

Google, aracı 2010 yılında yayına aldı ve zaman içinde analiz altyapısını Lighthouse motoruna taşıdı. Bugün araç, sayfa hızı ve sayfa deneyimi konusunda iki ayrı veri kaynağını tek ekranda birleştirir. Bunlardan biri Chrome kullanıcılarından derlenen gerçek dünya verisi, diğeri Lighthouse’un sanal ortamda ürettiği test verisidir.

Analiz URL bazında çalışır. Yani bir ana sayfa için aldığınız skor, kategori ya da ürün sayfanız için geçerli olmayabilir. Yeterli trafik varsa araç, yalnızca sayfayı değil tüm alan adını da kapsayan bir “kaynak” (origin) değerlendirmesi gösterir. Sonuç ekranı mobil ve masaüstü olmak üzere iki sekmeye ayrılır. Arama sıralamalarında mobil deneyim ağırlık taşıdığı için çalışmalara mobil sekmeden başlamak doğru bir yaklaşımdır.

Saha Verisi ve Laboratuvar Verisi Arasındaki Fark

Raporu yorumlarken yapılan en yaygın hata, iki farklı veri tipini aynı şey sanmaktır. Üst bölümdeki saha verisi ile alttaki laboratuvar verisi farklı soruları yanıtlar ve çoğu zaman birbirinden farklı sonuçlar üretir.

Saha Verisi (Field Data)

Saha verisi, Chrome User Experience Report (CrUX) veri setinden gelir. Sitenizi ziyaret eden ve veri paylaşımını açık bırakan Chrome kullanıcılarının deneyimleri son 28 günlük dönem üzerinden toplanır ve metrikler kullanıcıların %75’lik dilimine göre değerlendirilir. Bu nedenle farklı cihazlar, farklı ağ koşulları ve farklı coğrafyalar tek bir ortalamada birleşir. Saha verisi, Google’ın sayfa deneyimi değerlendirmesinde esas aldığı veridir. Düşük trafikli sayfalarda yeterli örnek bulunmadığı için bu bölüm hiç görünmeyebilir.

Laboratuvar Verisi (Lab Data)

Laboratuvar verisi, Lighthouse’un sayfayı tek seferlik, kontrollü bir yüklemeyle test etmesiyle oluşur. Mobil testte orta seviye bir cihaz ve yavaş bir mobil ağ koşulu simüle edilir. Böylece sonuçlar tekrarlanabilir ve hata ayıklamaya uygundur. Buna karşılık gerçek kullanıcı çeşitliliğini yansıtmaz. Aynı sayfayı arka arkaya test ettiğinizde skorun birkaç puan oynaması normaldir. Çünkü sunucu yanıt süresi, üçüncü taraf betikler ve ağ dalgalanmaları sonucu etkiler.

Performans Skoru Nasıl Hesaplanır?

PageSpeed Insights’ın gösterdiği 0 ile 100 arasındaki puan, laboratuvar ölçümlerinden elde edilen metrik skorlarının ağırlıklı ortalamasıdır. Her metrik önce kendi değerine göre bir alt skora dönüştürülür, ardından ağırlığıyla çarpılarak toplanır. Dolayısıyla tüm metrikler skora eşit katkı yapmaz. Total Blocking Time ve Largest Contentful Paint toplam puanın yarısından fazlasını belirler.

Ağırlıklar Lighthouse sürümleriyle değişir. Lighthouse 8 döneminde Time to Interactive hesaplamada yer alıyor ve Cumulative Layout Shift %15 paya sahipti. Güncel sürümlerde Time to Interactive skordan çıkarıldı ve CLS’nin ağırlığı %25’e yükseldi. Aşağıdaki tablo güncel dağılımı ve her metriğin yorum eşiklerini bir arada gösterir.

Metrik Skordaki Ağırlık İyi Geliştirilmeli Zayıf
First Contentful Paint (FCP) %10 0 – 1,8 sn 1,8 – 3 sn 3 sn üzeri
Speed Index (SI) %10 0 – 3,4 sn 3,4 – 5,8 sn 5,8 sn üzeri
Largest Contentful Paint (LCP) %25 0 – 2,5 sn 2,5 – 4 sn 4 sn üzeri
Total Blocking Time (TBT) %30 0 – 200 ms 200 – 600 ms 600 ms üzeri
Cumulative Layout Shift (CLS) %25 0 – 0,1 0,1 – 0,25 0,25 üzeri

Google’ın yayımladığı Lighthouse Score Calculator, metrik değerlerini girerek skorun nasıl değiştiğini simüle etmenizi sağlar. Hangi metriği iyileştirmenin puana en fazla katkı vereceğini görmek için pratik bir yöntemdir.

Skor Aralıkları ve Renk Kodları

Performans puanı üç renk bandında gösterilir. 0 ile 49 arası kırmızı ve zayıf, 50 ile 89 arası turuncu ve iyileştirme gerektiren, 90 ile 100 arası yeşil ve iyi kabul edilir. Hedef olarak yeşil bandı yakalamak yeterlidir. Skorun üst uçlarında puan eğrisi yataylaşır. 99’dan 100’e çıkmak için gereken mühendislik eforu, 50’den 80’e çıkmak için gerekenden kat kat fazladır ve kullanıcıya yansıyan fark çoğu zaman ihmal edilebilir düzeydedir.

Core Web Vitals ve Diğer Performans Metrikleri

Sık yapılan bir karışıklığı netleştirmek gerekir. PageSpeed Insights’ta listelenen tüm metrikler Core Web Vitals sayılmaz. Core Web Vitals, Google’ın sayfa deneyiminin çekirdeği olarak tanımladığı üç metrikten oluşur. Bunlar yükleme hızını ölçen LCP, etkileşim yanıtını ölçen INP ve görsel kararlılığı ölçen CLS‘dir. FCP, TBT ve Speed Index ise Lighthouse’un tanı amaçlı kullandığı destekleyici metriklerdir.

Largest Contentful Paint (LCP)

LCP, görünür alandaki en büyük metin bloğunun veya görselin ekrana çizilme süresidir. Genellikle ana görsel, manşet başlığı ya da büyük bir banner bu öğeyi oluşturur. 2,5 saniye altı iyi kabul edilir. LCP’yi geciktiren başlıca nedenler yavaş sunucu yanıtı, render’ı engelleyen CSS ve JavaScript dosyaları, optimize edilmemiş görseller ve geç keşfedilen kaynaklardır.

Interaction to Next Paint (INP)

INP, 2024 yılında First Input Delay metriğinin yerini alarak Core Web Vitals setine girdi. Sayfa ömrü boyunca gerçekleşen tıklama, dokunma ve klavye etkileşimlerinin yanıt sürelerini değerlendirir. 200 ms altı iyi, 500 ms üzeri zayıf sayılır. INP yalnızca saha verisinde ölçülür. Laboratuvar tarafında ona en yakın göstergelerden biri TBT’dir. Metriğin ölçüm mantığı ve optimizasyon yöntemleri için INP (Interaction to Next Paint) metriğinin nasıl ölçüldüğini ve optimize edildiğini ayrıca incelemenizi öneririm.

Cumulative Layout Shift (CLS)

CLS, sayfa yüklenirken öğelerin beklenmedik biçimde kayma miktarını ölçer. Kullanıcı bir butona basmak üzereyken üstte geç yüklenen bir reklam alanının içeriği aşağı itmesi tipik bir örnektir. 0,1 altı iyi, 0,25 üzeri zayıftır. Boyutları tanımlanmamış görseller, geç yüklenen web fontları, dinamik olarak eklenen banner ve çerez bildirimleri kayma üreten başlıca kaynaklardır.

FCP, TBT ve Speed Index

First Contentful Paint, sayfadaki ilk metin veya görselin ekrana gelme süresidir. Kullanıcının “sayfa yanıt veriyor” algısını belirler. Total Blocking Time, FCP ile etkileşime hazır olma noktası arasında ana iş parçacığını 50 ms’den uzun süre kilitleyen görevlerin, 50 ms’yi aşan kısımlarının toplamıdır. Örneğin 150, 90 ve 200 ms’lik üç uzun görev varsa fazlalıklar 100, 40 ve 150 ms olarak toplanır ve TBT 290 ms çıkar. Speed Index ise sayfa içeriğinin görsel olarak ne kadar hızlı dolduğunu gösterir. Bu üçü, LCP ve CLS’deki sorunların kök nedenini bulmak için tanı aracı olarak kullanılır.

PageSpeed Insights Adım Adım Nasıl Kullanılır?

Aracı kullanmak için pagespeed.web.dev adresine gidip test edilecek URL’yi giriş alanına yazmanız yeterlidir. Analiz birkaç on saniye sürer. Rapordan en yüksek verimi almak için aşağıdaki sırayı izlemek işe yarar.

  • Önce mobil sekmeyi açın ve üstteki saha verisinin Core Web Vitals değerlendirmesini “başarılı” ya da “başarısız” olarak not edin.
  • Saha verisinde hangi metriğin eşik dışında kaldığını belirleyin. Optimizasyon önceliği bu metriğe verilmelidir.
  • Laboratuvar verisinde aynı metriğin değerini karşılaştırın ve tutarsızlık varsa nedenini araştırın.
  • “Fırsatlar” ve “Teşhis” bölümlerinden o metriğe bağlı önerileri filtreleyin.
  • Değişiklikleri uyguladıktan sonra testi tekrarlayın. Saha verisinin güncellenmesi için 28 günlük dönemin ilerlemesini bekleyin.

Fırsatlar, Teşhis ve Başarılı Denetimler Bölümleri

Raporun alt kısmı üç bölümden oluşur. “Fırsatlar” bölümü, uygulandığında tahmini kazanç sağlayacak önerileri saniye cinsinden listeler. Örneğin kullanılmayan JavaScript’in azaltılması veya görsellerin modern formatlara dönüştürülmesi bu bölümde yer alır. “Teşhis” bölümü ise doğrudan kazanç tahmini vermeyen ama sayfa mimarisi hakkında bilgi sunan bulguları içerir. Aşırı büyük DOM boyutu, uzun ana iş parçacığı görevleri ve önbellek politikaları burada görünür.

Bu iki bölümdeki maddeler performans puanına doğrudan eklenmez. Puan yalnızca metrik ölçümlerinden hesaplanır. Ancak önerilerin uygulanması metrik değerlerini iyileştirdiği için dolaylı olarak skoru yükseltir. “Başarılı Denetimler” bölümü ise geçtiğiniz kontrolleri gösterir. Bu liste, hangi alanlarda mevcut kurulumun doğru çalıştığını teyit etmek açısından faydalıdır.

Skoru ve Kullanıcı Deneyimini İyileştirme Yöntemleri

Görsel ve Medya Optimizasyonu

LCP öğesi çoğu sayfada bir görseldir. Bu görseli WebP veya AVIF formatında sunmak, görüntüleme boyutuna uygun ölçeklendirmek ve ilk görünür alandaki ana görsele öncelik vermek yükleme süresini belirgin biçimde kısaltır. Ekranın altında kalan görsellerde ise tembel yükleme kullanılmalıdır. Ana görselde tembel yükleme kullanmak ise LCP’yi geciktirdiği için hatalı bir uygulamadır. Tüm görsellerde genişlik ve yükseklik değerlerini tanımlamak CLS sorunlarının büyük kısmını da ortadan kaldırır.

JavaScript ve CSS Yönetimi

TBT ve INP sorunlarının temel kaynağı ana iş parçacığını meşgul eden JavaScript’tir. Kullanılmayan kodların temizlenmesi, betiklerin bölünerek ihtiyaç anında yüklenmesi ve üçüncü taraf etiketlerin (analitik, sohbet, reklam pikselleri) denetlenmesi ilk adımlardır. Kritik CSS’in satır içi sunulması ve geri kalanının ertelenmesi, render’ı engelleyen kaynak uyarılarını azaltır. Font dosyalarında font-display ayarı ve ön yükleme kullanımı, yazı tipi kaynaklı kaymaları önler.

Sunucu ve Ağ Katmanı

Sunucu yanıt süresi (TTFB) yavaşsa hiçbir ön yüz iyileştirmesi LCP’yi tek başına kurtaramaz. Sayfa önbellekleme, CDN kullanımı, Brotli veya Gzip sıkıştırma, HTTP/2 ya da HTTP/3 desteği ve veritabanı sorgularının optimizasyonu bu katmanın başlıca konularıdır. Gereksiz yönlendirme zincirleri ve hatalı yanıt kodları da ölçülebilir gecikme yaratır. Bu açıdan HTTP durum kodlarının SEO performansına etkisini bilmek, yönlendirme kaynaklı hız kayıplarını tespit etmeyi kolaylaştırır. Sunucu ve tarama tarafının arama botlarıyla ilişkisini merak edenler için yapay zekâ botlarının web sitenizi nasıl keşfettiğini ve işlediğini anlatan içerik de teknik altyapı açısından tamamlayıcıdır.

Sayfa Hızı Yorumlarında Sık Yapılan Hatalar

İlk hata, laboratuvar skorunu tek gerçek ölçüm saymaktır. Saha verisi yeşilken laboratuvar skorunun 70’lerde kalması mümkündür ve bu durumda sayfa gerçek kullanıcılar için yeterince hızlıdır. Tersi de geçerlidir. Laboratuvar skoru yüksek görünürken saha verisi başarısız olabilir. Bu fark genellikle gerçek kullanıcıların daha zayıf cihaz ve bağlantılarla gelmesinden kaynaklanır.

İkinci hata, her optimizasyonu skora indirgemektir. Hız çalışmalarının amacı skor biriktirmek değil, ziyaretçinin sayfayı akıcı biçimde kullanmasını sağlamaktır. Bu bağlamda hız iyileştirmelerinin dönüşüm üzerindeki etkisini ölçmek gerekir. Dönüşüm oranı optimizasyonu yaklaşımı ile hız verisini birleştirmek ve değişiklikleri A/B testi ile doğrulamak, teknik çalışmanın iş sonucuna katkısını kanıtlamanın en
güvenilir yoludur. Hız verisini iş sonuçlarıyla eşleştirmeyen bir optimizasyon programı, teknik olarak başarılı görünse de ticari değerini gösteremez.

Üçüncü hata, değişikliklerin etkisini beklemeden yeni müdahaleler yapmaktır. Saha verisi 28 günlük bir pencereyle güncellendiği için bugün yapılan bir iyileştirme CrUX tarafına birkaç hafta içinde yansır. Bu süre içinde testin tekrar tekrar çalıştırılması yalnızca laboratuvar dalgalanmasını izlemenizi sağlar. Son olarak, yalnızca ana sayfaya odaklanmak da eksik bir yaklaşımdır. Kategori, ürün ve blog şablonlarının her biri farklı bileşenler yüklediği için ayrı ayrı test edilmelidir.

Hız Verisini Sürekli İzleme ve Raporlama

Tek seferlik bir test, performansın seyri hakkında yeterli bilgi vermez. Sağlıklı bir izleme düzeni için PageSpeed Insights’ı, Search Console içindeki Core Web Vitals raporuyla birlikte kullanmak gerekir. Search Console, sorunlu URL’leri şablon gruplarına ayırır ve hangi sayfa türünün eşik dışında kaldığını gösterir. Dizinleme tarafındaki teknik sorunları da aynı panelden yönetmek için Search Console sayfa dizinleme raporundaki hata mesajları ve çözümleri başlıklı rehberden yararlanabilirsiniz.

Raporlamada önerilen yöntem, her şablon türü için temsili birkaç URL belirlemek ve LCP, INP, CLS değerlerini aylık olarak kaydetmektir. Büyük bir tema güncellemesi, yeni bir eklenti ya da üçüncü taraf betik eklenmesi gibi değişikliklerden önce ve sonra ölçüm almak, gerileme yaratan unsuru hızla izole etmenizi sağlar. Böylece hız çalışması bir seferlik temizlik olmaktan çıkar, sürdürülebilir bir kalite kontrol sürecine dönüşür.

Öncelik Sırası Nasıl Belirlenir?

Optimizasyon listesi uzun olduğunda en yüksek etkiyi veren işlerden başlamak gerekir. Genel bir sıralama şu mantıkla kurulabilir: önce sunucu yanıt süresi ve önbellekleme, ardından LCP öğesinin yüklenmesi, sonra ana iş parçacığını meşgul eden JavaScript, en son da CLS’ye yol açan düzen sorunları ele alınır. Saha verisinde hangi metrik başarısızsa sıralama o metriğe göre değişebilir. Bir sayfada LCP yeşil, INP kırmızıysa görsel optimizasyonuna zaman harcamak yerine betik ve etkileşim performansına odaklanmak daha doğrudur.

Kapanış Değerlendirmesi

PageSpeed Insights, doğru yorumlandığında sayfa hızı çalışmalarının yol haritasını çıkaran güvenilir bir teşhis aracıdır. Skorun arkasındaki ağırlıkları, saha ve laboratuvar verisi arasındaki ayrımı ve Core Web Vitals eşiklerini bilmek, gereksiz müdahalelerden kaçınmanızı sağlar. Hız optimizasyonu, tek bir rakamı yükseltme çabası değil; sunucu, görsel, betik ve düzen katmanlarında düzenli yürütülen bir mühendislik disiplinidir. Gerçek kullanıcı verisini temel alan, değişiklikleri ölçerek doğrulayan ve sonuçları iş hedefleriyle ilişkilendiren bir yaklaşım, hem arama görünürlüğü hem de ziyaretçi memnuniyeti açısından kalıcı kazanım sağlar.