PageSpeed Puanı Neden Her Testte Değişir?

Aynı siteyi PageSpeed Insights’ta birkaç kez test edip:

bir testte 95,

sonraki testte 71,

başka bir testte 43

görmek mümkündür.

Bu durum çoğu zaman:

“Site biraz önce hızlıydı, şimdi bozuldu.”

anlamına gelmez.

PageSpeed’in laboratuvar bölümü Lighthouse çalıştırır ve tek bir kontrollü/simüle edilmiş yüklemeyi ölçer.

Gerçek web ise tamamen sabit değildir.

Sunucu, cache, network, üçüncü taraf servisler ve test ortamı değişebilir.

Bu nedenle performans analizinde tek skor yerine dağılım ve neden önemlidir.

Önce iki farklı veri türünü ayırın

Field Data

Gerçek Chrome kullanıcılarının önceki 28 günlük deneyimidir.

Yeterli veri varsa:

LCP,
INP,
CLS,
FCP,
TTFB

gibi metrikler gösterilebilir.

Bu veri anlık test değildir.

Tarihsel kullanıcı deneyimidir.

Lab Data

Lighthouse tarafından o anda yapılan simüle edilmiş testtir.

Debug etmek için çok değerlidir.

Ancak tek bir Lighthouse çalıştırması bütün kullanıcıların deneyimini temsil etmez.

Puan neden değişir?

1. Sunucu yükü

Sunucu ilk testte boş olabilir.

İkinci testte:

backup,
cron,
bot,
PHP işlemi,
database sorgusu

çalışıyor olabilir.

TTFB değişirse sonraki birçok metrik de etkilenebilir.

2. Cache HIT / MISS

İlk istek cache MISS olabilir.

Sonraki istek cache HIT olabilir.

Bu durumda aynı kod ve aynı sayfa farklı hızlarda cevap verir.

Özellikle:

WordPress,
WooCommerce,
CDN,
reverse proxy

kullanan sistemlerde bu fark önemlidir.

3. CDN edge farkı

Test isteği farklı edge veya ağ yolundan origin’e ulaşabilir.

Bu nedenle özellikle CDN kullanan sitelerde network katmanı tamamen sabit değildir.

4. Üçüncü taraf scriptler

Site:

analytics,
reklam,
chat,
map,
video,
consent,
A/B test

kullanıyorsa bu servislerin yanıt süresi her testte aynı olmayabilir.

5. Dinamik içerik

Ana sayfadaki:

ürün,
slider,
kampanya,
reklam,
kişiselleştirme,
öneri

değişebiliyorsa LCP öğesi bile farklılaşabilir.

6. Test altyapısı

Google da PageSpeed dokümantasyonunda performans ölçümünde doğal değişkenlik bulunduğunu açıkça belirtir.

Ağ kullanılabilirliği ve test kaynaklarının durumu gibi faktörler Lighthouse sonucunu etkileyebilir.

95 → 40 puan normal mi?

Küçük farklar normaldir.

Ancak:

95 → 40

gibi çok büyük değişimler yalnız “ölçüm gürültüsü” diye geçiştirilmemelidir.

Bu durumda özellikle şunları karşılaştırırım:

TTFB,
LCP,
Total Blocking Time,
request waterfall,
resource count,
transfer size,
üçüncü taraf request,
cache header.

Eğer düşük puanlı testlerde aynı darboğaz sürekli tekrarlanıyorsa gerçek problem olabilir.

Tek test yerine nasıl ölçüm yapılmalı?

Adım 1

Aynı URL’yi birkaç kez test edin.

Adım 2

En iyi skoru seçmeyin.

Median/ortanca davranışı inceleyin.

Örneğin:

42 88 91 93 95

sonuçlarında:

“95 alıyor.”

demek eksik yorumdur.

42 neden oldu?

sorusu da cevaplanmalıdır.

Adım 3

Skordan önce metriklere bakın.

Puan değişmiş olabilir ama:

LCP sabit,
CLS sabit,
TTFB sabit

ise gerçek kullanıcı farkı düşündüğünüz kadar büyük olmayabilir.

Adım 4

Waterfall karşılaştırın.

Hangi request gecikti?

Origin mi?

Image mi?

Font mu?

Third party mi?

Adım 5

Field data varsa onu ayrıca değerlendirin.

Laboratuvar testinde 100 görmek, gerçek kullanıcı verisinde kötü LCP’yi yok etmez.

Mobil neden daha kötü çıkar?

PageSpeed mobil testi daha kısıtlı cihaz/network koşullarını simüle eder.

Bu nedenle desktop 98 iken mobile 65 görmek tek başına anormal değildir.

Mobilde özellikle:

CPU maliyeti,
JavaScript,
büyük görseller,
font,
üçüncü taraf script

daha fazla etkili olabilir.

“90 üstü yeterli mi?”

PageSpeed laboratuvar skorunda 90 ve üzeri yeşil kabul edilir.

Ancak bu hedef:

“Her koşulda 100 almak zorundayım.”

şeklinde yorumlanmamalıdır.

Önemli olan:

gerçek kullanıcı deneyimi,
Core Web Vitals,
işlevlerin korunması,
stabil performans.

100 puan için gerekli bir özelliği kapatmak bazen kötü mühendislik kararı olabilir.

Gerçek kullanıcı verisi neden değişmiyor?

CrUX verisi son 28 günlük hareketli dönemden oluştuğu için bugün yaptığınız optimizasyon yarın bütün field data’yı değiştirmeyebilir.

Yeni performansın gerçek kullanıcı veri setine ağırlık kazanması zaman alır.

Bu yüzden:

“Dün hızlandırdık, neden CrUX hâlâ kötü?”

sorusu normaldir.

PageSpeed testinde site fonksiyonlarını kapatmalı mıyız?

Hayır.

Hız testi için:

analytics’i silmek,
formu kaldırmak,
menüyü bozmak,
gerekli JavaScript’i iptal etmek,
gerçek görselleri değiştirmek

gerçek kullanıcı deneyimini iyileştirmek değildir.

Amaç gerçek production sitesini hızlandırmaktır.

Demo üretmek değil.

Ben nasıl değerlendiriyorum?

Bir projede:

score → symptom

olarak görülür.

Asıl soru:

bottleneck → cause

ilişkisidir.