PageSpeed Insights Raporu Nasıl Okunur?

PageSpeed Insights Raporu Nasıl Okunur?

Google PageSpeed Insights'a bir URL yapıştırıp "Analiz Et" butonuna basmak kolay kısım. Zorluk, karşınıza çıkan rengarenk skorun, onlarca metriğin ve uzun "Diagnostics" listesinin ne anlama geldiğini çözmekte başlıyor. Birçok site sahibi tek bir sayıya (0-100 arası performans skoru) takılıp kalıyor, altındaki asıl veriyi hiç okumadan sayfayı kapatıyor. Oysa bu rapor doğru okunduğunda; hangi görselin sayfayı yavaşlattığını, hangi JavaScript dosyasının ana iş parçacığını kilitlediğini ve sunucunuzun ilk baytı ne kadar sürede gönderdiğini net biçimde gösterir.

Bu yazıda PageSpeed Insights raporunun her bölümünü sırasıyla açacağız: skor hesaplama mantığı, Core Web Vitals metrikleri, laboratuvar verisi ile saha verisi arasındaki fark, Diagnostics ve Opportunities listelerinin önceliklendirilmesi ve son olarak sunucu/hosting tarafının rapora nasıl yansıdığı. Amaç, raporu bir kez okuyup kapatmak değil; her sprint'te tekrar bakıp gerçek iyileştirme yapabileceğiniz bir kontrol listesine dönüştürmek.

PageSpeed Insights Nedir, Neyi Ölçer?

PageSpeed Insights (PSI), Google'ın Lighthouse motoru üzerine kurulu, açık ve ücretsiz bir performans analiz aracı. Bir URL girdiğinizde iki farklı kaynaktan veri toplar:

1. Lab Data (Laboratuvar Verisi): Google'ın sunucularında, kontrollü bir ağ/cihaz simülasyonuyla (genelde orta seviye bir mobil cihaz + yavaşlatılmış bağlantı) sayfanızı tek seferlik çalıştırır.
2. Field Data (Saha Verisi / CrUX): Chrome kullanıcı deneyimi raporundan (Chrome User Experience Report) gelen, gerçek ziyaretçilerin son 28 günde o sayfada yaşadığı ölçümlerdir.

Bu ikisi birbirinden bağımsız çalışır ve çoğu zaman farklı sonuçlar verir — bu normaldir, aşağıda nedenini açıklayacağız. PSI raporunu okurken ilk yapmanız gereken şey, hangi bölümün lab hangi bölümün field veri olduğunu ayırt etmek.

Büyükweb'de site sahiplerinden en sık duyduğumuz şikayet "PageSpeed'de skorum düşük ama sayfam bana hızlı geliyor" oluyor. Genelde sebep, kendi bilgisayarınızın güçlü donanımı ve hızlı bağlantısıyla test etmenizken, PSI'ın orta seviye bir mobil cihazı simüle etmesi.

Performans Skoru (0-100) Nasıl Hesaplanır?

Üstteki büyük renkli daire — yeşil, turuncu veya kırmızı — aslında altı farklı metriğin ağırlıklı ortalamasıdır. Skorun kendisi bir "sıralama" faktörü değildir; Google'ın sıralamada doğrudan kullandığı şey Core Web Vitals eşikleridir, skor sadece bu metriklerin özet bir görselleştirmesidir. 2026 itibarıyla ağırlıklandırma şu şekildedir:

Metrik	Kısaltma	Ağırlık (yaklaşık)
Largest Contentful Paint	LCP	%25
Total Blocking Time	TBT	%30
Cumulative Layout Shift	CLS	%25
First Contentful Paint	FCP	%10
Speed Index	SI	%10

Dikkat: INP (Interaction to Next Paint), laboratuvar skoruna dahil edilmez çünkü gerçek kullanıcı etkileşimi gerektirir — laboratuvar ortamında bot sayfayla "etkileşime girmez". INP sadece saha verisinde (varsa) görünür. Bu yüzden 100 üzerinden yüksek bir laboratuvar skoru almanız, gerçek kullanıcıların etkileşimlerde takılma yaşamadığı anlamına gelmez.

Renk kodları şöyle yorumlanır:

• 90-100 (yeşil): İyi
• 50-89 (turuncu): Geliştirilmeli
• 0-49 (kırmızı): Zayıf

Bu eşik değerleri hem tüm skor hem de tek tek her metrik için ayrı ayrı geçerlidir; yani "skor 92" yazıyor diye tüm metrikleriniz yeşil olmak zorunda değil, ortalama iyi çıkmış olabilir.

Core Web Vitals Metrikleri: LCP, INP, CLS

Google'ın sıralama sinyali olarak kullandığı üç temel metrik — Core Web Vitals — raporun ortasında ayrı bir kutuda gösterilir. Bu üçlüyü ve kabul edilebilir eşik değerlerini iyi bilmek gerekiyor:

Metrik	Ne Ölçer	İyi	Geliştirilmeli	Zayıf
LCP	En büyük görünür içeriğin yüklenme süresi	≤ 2,5 sn	2,5-4,0 sn	> 4,0 sn
INP	Kullanıcı etkileşiminden ekrana yansımaya kadar geçen gecikme	≤ 200 ms	200-500 ms	> 500 ms
CLS	Sayfa yüklenirken elemanların kayma miktarı	≤ 0,1	0,1-0,25	> 0,25

Bu üç metriği ayrıntılı optimizasyon teknikleriyle birlikte daha derinlemesine incelemek isterseniz Core Web Vitals 2026: LCP, INP, CLS Optimizasyonu Rehberi yazımıza bakabilirsiniz. INP özelinde, 2024'te FID'nin (First Input Delay) yerini alan bu metrik hâlâ birçok site sahibi tarafından yanlış anlaşılıyor; INP (Interaction to Next Paint): Core Web Vitals 2026 Optimizasyonu yazımızda konuyu tek başına ele aldık.

Raporda her metriğin yanında küçük bir bilgi ikonu bulunur; üzerine geldiğinizde "bu metrik ne ölçer" açıklaması çıkar. Bu açıklamaları okumak, hangi metriğin hangi kullanıcı deneyimi problemine işaret ettiğini anlamak için değerlidir — örneğin yüksek CLS genelde reklam alanlarının veya web fontlarının geç yüklenmesinden, yüksek LCP ise ağır bir hero görselinden veya yavaş sunucu yanıtından kaynaklanır.

Lab Data ve Field Data (CrUX) Arasındaki Fark

PSI raporunda iki ayrı blok görürsünüz: üstte "Discover what your real users are experiencing" başlığıyla Field Data, altında "Diagnose performance issues" başlığıyla Lab Data. Bu ikisini karıştırmak en yaygın okuma hatasıdır.

Field Data (Saha Verisi) özellikleri:

• Son 28 günün gerçek Chrome kullanıcılarından toplanır
• Yeterli trafiğiniz yoksa bu bölüm hiç görünmez ("Field data not available" uyarısı çıkar)
• Sayfa bazında değil, çoğu zaman origin (tüm site) bazında da gösterilebilir
• Google'ın sıralama sinyali olarak kullandığı asıl veri budur

Lab Data (Laboratuvar Verisi) özellikleri:

• Google'ın sunucusunda, tek seferlik ve simüle edilmiş bir ortamda ölçülür
• Her zaman mevcuttur, trafik gerektirmez
• Değişkenlik gösterebilir — aynı sayfayı art arda iki kez test etseniz bile farklı sayılar alabilirsiniz (ağ gecikmesi, sunucu yükü anlık farklılıkları nedeniyle)
• Sorunları teşhis etmek (diagnose) için kullanılır, "gerçeği" temsil etmek için değil

Pratik kural: Sıralamanızı etkileyen şey Field Data'dır. Ama Field Data size "neyin bozuk olduğunu" söylemez, sadece "kötü bir deneyim var" der. Lab Data ve altındaki Diagnostics listesi ise size "neyi düzeltmeniz gerektiğini" gösterir. İkisini birlikte kullanmadan etkili bir optimizasyon yapamazsınız.

Field verisi yoksa (küçük/orta trafikli siteler için sık rastlanan bir durum), tek referansınız Lab Data olur. Bu durumda Google Search Console: Teknik SEO Hata Analizi ve Düzeltme yazımızda anlattığımız gibi, Search Console'daki "Core Web Vitals" raporunu da PSI ile birlikte takip etmenizi öneririz — Search Console, site genelinde URL grupları bazında Field Data toplayıp gösterir.

Diagnostics ve Opportunities Bölümü Nasıl Önceliklendirilir?

Raporun en uzun kısmı, "Diagnostics" (Teşhisler) ve eski adıyla "Opportunities" (Fırsatlar) başlıklı liste. Her satırda bir öneri ve yanında tahmini kazanç (örneğin "Reduce unused JavaScript — Est savings: 1,2 sn") görürsünüz. Bu listeyi verimli okumanın üç kuralı var:

1. Tahmini kazançlar toplanmaz. Beş öneri "1,2 sn + 0,8 sn + 0,5 sn tasarruf" gösteriyorsa toplamda 2,5 saniye kazanacağınızı sanmayın — bu tahminler ayrı ayrı, birbirinden bağımsız hesaplanır ve gerçekte çakışan optimizasyonlar olabilir.
2. En büyük tahmini kazançtan başlayın, ama etki-efor dengesini de gözetin. "Görselleri modern formata dönüştürün" genelde en yüksek getiri/efor oranına sahip öneridir.
3. "Passed audits" (geçilen denetimler) bölümünü de okuyun. Neyin zaten doğru yapıldığını görmek, gereksiz yere elle dokunup bir şeyi bozmamanız için önemlidir.

En sık karşılaşılan Diagnostics maddeleri ve pratik çözümleri:

Reduce initial server response time (TTFB)
  → Sunucu/hosting katmanı, PHP-OPcache, veritabanı sorgu optimizasyonu

Eliminate render-blocking resources
  → CSS/JS dosyalarını defer/async yükleme, kritik CSS'i inline etme

Properly size images
  → Görselleri gerçek gösterim boyutuna göre yeniden boyutlandırma

Serve images in next-gen formats
  → JPEG/PNG yerine WebP veya AVIF kullanımı

Reduce unused JavaScript
  → Kullanılmayan kütüphaneleri kaldırma, kod bölme (code splitting)

Avoid large layout shifts
  → Görsel/reklam alanlarına width-height veya aspect-ratio tanımlama

Bu maddelerden özellikle "Reduce initial server response time" (TTFB — Time to First Byte) sıkça göz ardı edilir çünkü çözümü kod tarafında değil, altyapı tarafındadır. WordPress veya Next.js gibi sistemlerde performans ayarlarının detaylarını Sayfa Hızı Optimizasyonu: WordPress & Next.js Performans İpuçları yazımızda adım adım işledik.

Sunucu Yanıt Süresinin (TTFB) Rapordaki Yeri

PSI raporunda TTFB doğrudan bir "Core Web Vital" olarak listelenmez ama LCP'nin bir alt bileşenidir — sayfanın hiçbir öğesi, tarayıcı ilk bayt'ı almadan çizilemez. Rapor genişletildiğinde "LCP breakdown" bölümünde dört alt zaman dilimi görürsünüz:

• TTFB: İsteğin sunucuya ulaşıp ilk yanıtın dönmesi
• Load Delay: Kaynağın (görsel, font) keşfedilip indirmeye başlanması arasındaki gecikme
• Load Time: Kaynağın indirilme süresi
• Render Delay: İndirilen kaynağın ekrana çizilmesi

Bu dört dilimden TTFB'nin uzunluğu doğrudan barındığınız sunucunun donanımı, disk türü (SSD/NVMe), PHP sürümü, önbellekleme katmanı ve sunucunun coğrafi konumuyla ilişkilidir. Paylaşımlı hosting ortamında aynı sunucuyu paylaşan başka sitelerin yoğun kaynak kullanımı da TTFB'yi artırabilir. Bu nedenle SEO odaklı bir performans çalışmasında hosting seçimi, kod optimizasyonu kadar belirleyici bir faktördür — konuyu Web Hosting Seçiminin SEO Etkisi yazımızda detaylandırdık.

Büyükweb'in cPanel Web Hosting paketlerinde NVMe disk altyapısı ve LiteSpeed önbellekleme katmanı kullanılır; bu, PSI raporundaki "Reduce initial server response time" uyarısının kod değişikliği yapmadan önce çözülebilecek kısmını doğrudan etkiler. Ancak unutulmamalı: hosting katmanı sadece TTFB'yi iyileştirir, render-blocking kaynaklar veya büyük JavaScript paketleri gibi front-end sorunlarını çözmez — o kısım geliştirici tarafında kalır.

Mobil ve Masaüstü Sonuçları Neden Farklı Çıkar?

PSI raporunun üstünde "Mobile" ve "Desktop" sekmeleri bulunur ve genelde mobil skor, masaüstü skorundan belirgin şekilde düşük çıkar. Bunun sebebi kötü bir optimizasyon değil, test koşullarının farklı olmasıdır:

• Mobil test, CPU gücü düşürülmüş (throttled) bir orta seviye Android cihazı simüle eder
• Ağ bağlantısı, yavaş 4G benzeri bir profille kısıtlanır
• Masaüstü testi ise güçlü bir CPU ve hızlı bağlantı varsayar

Google, sıralama için mobil öncelikli indeksleme (mobile-first indexing) kullandığından, asıl odaklanmanız gereken sekme mobildir. Masaüstü skorunuz 95 olsa bile mobil skorunuz 40'larda kalıyorsa, gerçek SEO riski mobil taraftadır. Mobil deneyim optimizasyonunu bütünsel olarak ele almak isterseniz Mobil SEO: Mobile-First Indexing 2026 Uyum Rehberi yazımız faydalı olacaktır.

Yaygın Yanlış Yorumlamalar

Raporu okurken sık düşülen tuzaklardan bazıları:

• "Skor 100 olmalı" saplantısı. 90 üzerindeki her skor "iyi" kategorisindedir; 100'e ulaşmak için kritik olmayan uyarıları (örneğin üçüncü taraf bir analitik script'i) feda etmek çoğu zaman gereksizdir.
• Tek bir test sonucuna güvenmek. Lab Data doğası gereği değişken olduğundan, aynı sayfayı 3-5 kez test edip ortalamaya bakmak daha güvenilirdir.
• Field Data'yı görmezden gelmek. "Skorum 95, harika" deyip Field Data bölümündeki kırmızı INP uyarısını atlamak, gerçek kullanıcı deneyimini gözden kaçırmak demektir.
• Third-party script'leri unutmak. Canlı destek widget'ları, reklam script'leri, çok sayıda analiz aracı genelde en büyük gizli yavaşlatıcılardır ama raporun "Reduce third-party impact" satırında topluca gösterilir, tek tek fark edilmesi zordur.
• Tek seferlik ölçüm yapıp bırakmak. Performans, bir kere düzeltilip unutulacak bir iş değil; her içerik/eklenti güncellemesinden sonra tekrar kontrol edilmesi gereken sürekli bir süreçtir.

Adım Adım Rapor Okuma Rutini

Aşağıdaki sırayı takip ederek raporu her seferinde tutarlı biçimde okuyabilirsiniz:

1. Sekmeyi kontrol edin: Önce Mobile, sonra Desktop.
2. Field Data var mı bakın: Varsa gerçek kullanıcı LCP/INP/CLS değerlerini not edin.
3. Skor rengine değil, alt metriklere bakın: Hangi metrik kırmızı/turuncu?
4. LCP breakdown'ı açın: TTFB mi, render delay mi büyük?
5. Diagnostics listesini tahmini kazanca göre sıralayın.
6. Passed audits'i hızlıca tarayın: Zaten doğru olanı bozmayın.
7. Değişikliği yapın, aynı URL'yi tekrar test edin, sonucu kaydedin.

API üzerinden otomatik takip yapmak isteyenler için PageSpeed Insights'ın bir de ücretsiz REST API'si var; bu sayede skorları manuel kontrol yerine bir betikle periyodik ölçebilirsiniz:

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://siteniz.com&strategy=mobile&category=performance" \
  | jq '.lighthouseResult.categories.performance.score'

Bu komut, ilgili URL'nin mobil performans skorunu 0-1 arası bir ondalık sayı olarak döner (0,92 gibi — yani 92/100). Sprint bazlı çalışan ekipler için bu tarz otomasyonlar, her yayından önce regresyon kontrolü yapmayı kolaylaştırır.

Google Analytics ve Search Console ile Birlikte Değerlendirme

PSI raporu tek başına bir SEO stratejisi değildir, sadece teknik bir teşhis aracıdır. Gerçek etkiyi görmek için performans verisini kullanıcı davranışı verisiyle eşleştirmek gerekir. Örneğin LCP'yi 4,2 saniyeden 2,1 saniyeye indirdiğinizde hemen çıkma oranında ve oturum süresinde gerçekten bir değişim oldu mu? Bunu doğrulamak için Google Analytics 4 Kurulumu ve Temel Rapor Kullanımı yazımızda anlatılan temel raporları PSI ölçümleriyle aynı tarih aralığında karşılaştırmanızı öneririz. Benzer şekilde Search Console'daki Core Web Vitals raporu, PSI'ın tek URL bazlı verisini site genelinde URL grupları halinde gösterdiğinden, iki aracı birlikte kullanmak eksik bir teşhis sırasında sizi yanlış yönlendirme riskini azaltır.

Sıkça Sorulan Sorular

PageSpeed Insights skoru doğrudan Google sıralamasını mı belirler?

Hayır. Google sıralamada skoru değil, altındaki Core Web Vitals (LCP, INP, CLS) eşik değerlerini bir sinyal olarak kullanır. Skor, bu metriklerin görsel bir özetidir; SEO açısından asıl önemli olan Field Data'daki "iyi" eşiklerinin geçilip geçilmediğidir.

Lab Data ile Field Data neden farklı sonuç veriyor?

Lab Data, Google'ın kontrollü bir ortamda yaptığı tek seferlik simülasyondur; Field Data ise son 28 günde gerçek ziyaretçilerin farklı cihaz ve bağlantılarla yaşadığı ortalama deneyimdir. İkisi farklı örneklemlerden geldiği için sayılar örtüşmeyebilir, bu normaldir.

Field Data bölümü neden hiç görünmüyor?

Sayfanızın veya sitenizin Chrome kullanıcı deneyimi raporuna (CrUX) girecek kadar trafiği yoksa "Field data not available" uyarısı çıkar. Bu durumda tek referansınız Lab Data ve Search Console'daki site geneli Core Web Vitals raporu olur.

Mobil skor neden masaüstünden düşük çıkıyor?

PSI, mobil testte CPU gücü kısıtlanmış bir orta seviye cihaz ve yavaşlatılmış ağ profili simüle eder; masaüstü testinde ise güçlü donanım varsayılır. Google mobil öncelikli indeksleme kullandığından odak noktanız mobil sekme olmalı.

TTFB'yi düşürmek için hosting değiştirmek gerekir mi her zaman?

Her zaman değil, ama TTFB sürekli yüksek çıkıyorsa (genelde 600 ms üzeri) önce önbellekleme, veritabanı sorgu optimizasyonu ve PHP sürümü güncellemesi denenmeli. Bunlar yeterli iyileşme sağlamıyorsa disk hızı ve kaynak paylaşımı düşük bir hosting altyapısına geçmek somut fark yaratabilir.

Aynı sayfayı iki kez test ettiğimde neden farklı skor alıyorum?

Lab Data, o anki ağ koşulları ve Google'ın test sunucusundaki anlık yüküne bağlı olarak küçük dalgalanmalar gösterebilir. Güvenilir bir sonuç için aynı URL'yi 3-5 kez test edip ortalama almanız önerilir.

Diagnostics listesindeki tüm önerileri uygulamak zorunda mıyım?

Hayır. Tahmini kazancı düşük olan (örneğin 0,1 saniyelik) maddeler için geliştirme riskine girmeden önce, en yüksek tahmini kazancı olan öneriye (genelde görsel optimizasyonu veya render-blocking kaynaklar) odaklanmak daha verimlidir.

Büyükweb Hizmetleri

PageSpeed Insights raporunda TTFB kaynaklı uyarılar sürekli tekrarlıyorsa, sorunun kod değil altyapı katmanında olup olmadığını kontrol etmek isteyebilirsiniz:

• cPanel Web Hosting

Sorularınız için 0850 302 60 70 numaralı satış öncesi destek numaramızdan bize ulaşabilir veya iletişim sayfası üzerinden yazabilirsiniz.