Google PageSpeed Insights Nedir, Nasıl Kullanılır?

• 16.07.2026
• Genel
• 1619
• 7 dk okuma

Google PageSpeed Insights, bir web sayfasının performansını mobil ve masaüstü için inceleyen ücretsiz bir araçtır. Rapor; gerçek kullanıcı deneyimi verilerini, kontrollü laboratuvar testini ve uygulanabilir teknik önerileri aynı ekranda sunar. Buna rağmen yalnızca performans puanına bakmak, raporun en değerli bölümünü kaçırmak anlamına gelir. Doğru kullanım; saha verisi ile laboratuvar verisini ayırmak, sorunun hangi yükleme aşamasında oluştuğunu bulmak ve iş etkisine göre önceliklendirme yapmaktır.

PageSpeed Insights hangi verileri kullanır?

Gerçek kullanıcı verisi: CrUX

Chrome User Experience Report (CrUX), uygun koşulları sağlayan sitelerde gerçek Chrome kullanıcılarının deneyimlerinden anonimleştirilmiş veriler sunar. Bu alan son 28 günlük dönemi temsil eder ve tek bir hızlı testten çok daha geniş cihaz, ağ ve coğrafya çeşitliliğini kapsar. Yeterli veri yoksa sayfa veya site düzeyinde saha bölümü görünmeyebilir; bu, sayfanın iyi ya da kötü olduğu anlamına gelmez.

Laboratuvar verisi: Lighthouse

Lighthouse, sayfayı belirli cihaz ve ağ varsayımlarıyla yeniden yükleyerek tanı koymaya yardımcı olur. Her çalıştırmada ortam, sunucu yanıtı ve üçüncü taraf hizmetler değişebildiği için puan dalgalanabilir. Laboratuvar verisi hatayı yeniden üretmek ve çözüm geliştirmek için güçlüdür; gerçek kullanıcı deneyiminin doğrudan yerine geçmez.

Core Web Vitals metrikleri

Güncel Core Web Vitals değerlendirmesi üç ana metriğe dayanır:

• LCP (Largest Contentful Paint): İlk ekrandaki ana içeriğin ne kadar hızlı görünür olduğunu ölçer. İyi eşik 2,5 saniye veya altıdır.
• INP (Interaction to Next Paint): Kullanıcının tıklama, dokunma ve klavye etkileşimlerine sayfanın genel yanıt verme hızını değerlendirir. İyi eşik 200 milisaniye veya altıdır.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken oluşan beklenmedik görsel kaymaları ölçer. İyi eşik 0,1 veya altıdır.

Saha değerlendirmesinde 75. yüzdelik kullanılır. Yani ziyaretlerin en az yüzde 75’inde hedefe ulaşmak gerekir. Ortalama değerin iyi olması, yavaş cihaz ve bağlantılarda sorun yaşanmadığını kanıtlamaz.

Performans puanı neden tek başına yeterli değildir?

0–100 arasındaki Lighthouse performans puanı birden fazla laboratuvar metriğinin ağırlıklı sonucudur. Puan, ekiplerin hızlı karşılaştırma yapmasına yardımcı olur; ancak ticari hedef değildir. 100 puana ulaşmak için yapılan agresif değişiklikler görsel kaliteyi, ölçüm araçlarını veya işlevleri bozabilir. Asıl hedef; kullanıcıların ana içeriğe hızlı ulaşması, etkileşimlerin gecikmemesi ve sayfanın yerinden oynamamasıdır.

Ayrıca ana sayfa puanı bütün siteyi temsil etmez. Ürün, hizmet, blog, kategori ve form sayfalarının şablonları ayrı ayrı test edilmelidir. En fazla trafik ve dönüşüm alan şablonlar önce ele alınmalıdır.

PageSpeed raporu nasıl okunur?

1. Doğru URL’yi ve cihaz türünü seçin

Yönlendirme alan URL, parametreli adres veya giriş gerektiren sayfa yanlış sonuç üretebilir. Önce kanonik URL’yi test edin, ardından mobil ve masaüstü sekmelerini ayrı değerlendirin. Mobil rapor çoğu site için daha belirleyicidir çünkü işlemci ve ağ kısıtları sorunları daha görünür hale getirir.

2. Saha verisini kontrol edin

“Gerçek kullanıcılarınızın deneyimini keşfedin” bölümü varsa Core Web Vitals sonucuna ve metrik dağılımlarına bakın. URL düzeyinde veri yetersizse kaynak düzeyi sunulabilir. Son 28 günde yapılan değişikliklerin etkisi hemen tam olarak görünmez; saha verisinin yenilenmesi zaman alır.

3. LCP öğesini belirleyin

Tanılar bölümündeki LCP öğesi çoğunlukla hero görseli veya büyük metin bloğudur. Görsel CSS ya da JavaScript çalıştıktan sonra keşfediliyorsa tarayıcı indirmeye geç başlar. İlk ekran görseli HTML içinde bulunmalı, gerekli olduğunda önceliklendirilmeli ve kesinlikle tembel yüklenmemelidir.

4. Ana iş parçacığı ve INP risklerini inceleyin

Uzun JavaScript görevleri, büyük paketler ve üçüncü taraf etiketler etkileşimleri geciktirebilir. Kullanılmayan JavaScript raporu her kodun silinmesi gerektiğini söylemez; hangi bileşenin ne zaman gerekli olduğunu araştırmak gerekir. Ağır kodu bölmek, etkileşim sonrasına ertelemek veya daha hafif bir çözüm seçmek etkili olabilir.

5. CLS kaynaklarını bulun

Genişlik ve yükseklik bilgisi olmayan görseller, sonradan açılan reklam alanları, font değişimleri ve içeriğin üstüne eklenen bildirimler kayma oluşturabilir. Görsellere boyut veya en-boy oranı tanımlamak, dinamik alan için önceden yer ayırmak ve font yükleme stratejisini düzenlemek temel çözümlerdir.

Fırsatlar ve tanılar nasıl önceliklendirilir?

PageSpeed’in tahmini tasarruf süreleri yön gösterir fakat kesin sonuç değildir. Öncelik verirken şu sırayı kullanabilirsiniz:

1. Gerçek kullanıcı verisinde başarısız olan Core Web Vital
2. İlk ekrandaki kritik kaynak ve sunucu yanıtı
3. Bütün sayfa şablonlarını etkileyen ortak CSS/JavaScript
4. Yüksek trafik veya dönüşüm alan URL’ler
5. Üçüncü taraf kaynakların iş değeri ile maliyeti

Yaygın sorunlar ve kaliteli çözümler

Büyük görseller

Görseli yalnızca düşük kaliteye sıkıştırmak doğru yaklaşım değildir. Gerçek görüntüleme boyutu, modern format, responsive srcset, doğru kalite seviyesi ve yükleme sırası birlikte değerlendirilmelidir. Transparan PNG’yi rastgele JPEG’e çevirmek marka kalitesini bozabilir; uygun durumda WebP veya AVIF tercih edilmelidir.

Render engelleyen CSS

Kritik üst bölüm için gerekli stiller ile sayfanın devamındaki stiller ayrılabilir. Ancak CSS’yi kontrolsüz biçimde parçalamak önbelleği ve bakım maliyetini kötüleştirebilir. Şablon bazlı ölçüm yapılmalıdır.

Yavaş sunucu yanıtı

TTFB; barındırma altyapısı, veritabanı sorguları, PHP işlemleri, önbellek ve yönlendirmelerden etkilenir. Sadece CDN eklemek, dinamik sayfanın kök sorununu çözmeyebilir. Uygulama profillemesi ve sorgu analizi gerekebilir.

Üçüncü taraf kodlar

Sohbet, reklam, harita, video ve analiz araçları önemli olabilir. Her birini silmek yerine yükleme zamanını, sayfa kapsamını ve kullanıcı onayı sonrasına ertelenip ertelenemeyeceğini değerlendirin.

Sağlıklı test süreci

1. Değişiklikten önce mobil ve masaüstü raporlarını kaydedin.
2. Aynı URL’yi farklı zamanlarda birkaç kez test edin.
3. Tek bir ana soruna odaklanan değişiklik uygulayın.
4. Lighthouse ile teknik sonucu yeniden ölçün.
5. Gerçek kullanıcı ölçümünü analitik veya RUM aracıyla izleyin.
6. CrUX döneminin yenilenmesini bekleyerek saha sonucunu değerlendirin.

PageSpeed Insights API hakkında güncel not

Otomatik raporlama için PageSpeed Insights API kullanılabilir. Google’ın güncel dokümantasyonu, API içindeki gerçek kullanıcı verisinin ileride kaldırılmasının planlandığını ve saha verisi için CrUX API veya CrUX History API’nin tercih edilmesini önerir. Entegrasyon geliştirirken yalnızca tek bir API yanıt yapısına bağımlı kalmamak önemlidir.

Network şelalesi raporla birlikte nasıl kullanılır?

PageSpeed hangi kaynakların sorun oluşturabileceğini söyler; tarayıcı Network paneli ise isteklerin gerçek sırasını gösterir. HTML’nin ne zaman geldiğini, kritik CSS’nin kaç bağlantı sonra indirildiğini, hero görselinin hangi anda keşfedildiğini ve üçüncü taraf betiklerin ana iş parçacığını ne zaman meşgul ettiğini birlikte inceleyin. “Initiator” bilgisi, bir dosyanın HTML, CSS veya JavaScript tarafından başlatıldığını anlamaya yardımcı olur.

Örneğin LCP görseli ancak slider kütüphanesi çalıştıktan sonra isteniyorsa dosya boyutunu azaltmak tek başına yeterli olmaz. Görsel URL’sini başlangıç HTML’inde görünür kılmak veya ilk slaytı doğrudan yüklemek daha yüksek etki oluşturabilir.

INP sorunlarını ayrıntılı inceleme

Yükleme puanı iyi olduğu halde kullanıcı tıklamalarında gecikme yaşanabilir. INP için etkileşimi üç aşamada düşünün: giriş gecikmesi, olay işleyicinin çalışma süresi ve sonraki görüntünün çizilmesi. Büyük JavaScript görevi giriş gecikmesini; karmaşık hesaplama işleyici süresini; dev DOM güncellemesi ise çizim gecikmesini artırabilir.

Uzun görevleri daha küçük parçalara bölmek, gereksiz yeniden çizimleri önlemek, olay işleyicilerini sadeleştirmek ve ana iş parçacığını kullanıcı etkileşimine bırakmak gerekir. Sadece script dosyasını küçültmek, çalışma anındaki pahalı işlemi ortadan kaldırmayabilir.

Performans bütçesi oluşturun

İyileştirmelerin zamanla geri alınmasını önlemek için sayfa şablonlarına ölçülebilir bütçe tanımlanabilir. İlk ekrandaki toplam görsel ağırlığı, kritik JavaScript miktarı, üçüncü taraf istek sayısı ve Core Web Vitals hedefleri sürüm kontrol sürecinde izlenebilir. Yeni bir pazarlama aracı eklendiğinde yalnızca işlevi değil performans maliyeti de değerlendirilmelidir.

Örnek önceliklendirme senaryosu

Bir e-ticaret ürün sayfasında mobil LCP zayıf, CLS iyi ve INP sınırdaysa önce LCP öğesi ile TTFB incelenir. Hero görseli gecikmeli keşfediliyorsa HTML ve öncelik düzenlenir; ardından görsel boyutları optimize edilir. Sonraki aşamada varyant seçiminin INP etkisi ölçülür. Bütün metrikleri aynı anda değiştirmek yerine her adımın sonucu ayrı kaydedilir.

Sık yapılan yorumlama hataları

• Tek çalıştırmadaki puanı kesin sonuç kabul etmek
• Masaüstü sonucu iyi olduğu için mobil sorunları yok saymak
• Saha ve laboratuvar verisini aynı şey sanmak
• LCP görselini lazy-load ederek daha da geciktirmek
• Görsel kaliteyi gereksiz düşürerek puan kovalamak
• İşlevi önemli üçüncü taraf araçları ölçmeden kaldırmak
• Yalnızca ana sayfayı test etmek

Sonuç

PageSpeed Insights bir not verme aracı değil, performans teşhis sistemidir. En doğru yaklaşım; CrUX ile gerçek kullanıcı sorununu görmek, Lighthouse ile sebebi yeniden üretmek, yüksek etkili değişikliği uygulamak ve sonucu saha verisinde takip etmektir. Hedef 100 puan değil; hızlı, kararlı ve etkileşime hazır bir kullanıcı deneyimidir.

Resmî kaynaklar: PageSpeed Insights hakkında ve PageSpeed Insights API dokümantasyonu.

İlgili İçerikler

Captcha Nedir?

23.07.2026

P Etiketi Nedir?

21.07.2026

Hafıza Kartı Nerdir? Hafıza Kartı Çeşitleri

03.01.2023

Yorum Yapabilirsiniz.

E-posta mailiniz gizli kalacaktır.*