PageSpeed puanı neden tek başına yeterli değil?
PageSpeed Insights tek bir sayı üretmiyor.
Aslında iki farklı dünyayı bir arada gösteriyor:
- laboratuvar verisi,
- gerçek kullanıcı verisi.
Laboratuvar verisi Lighthouse tarafından kontrollü/simüle edilmiş koşullarda üretilir.
Gerçek kullanıcı verisi ise uygun veri bulunduğunda Chrome User Experience Report üzerinden son 28 günlük gerçek ziyaretçi deneyimini yansıtır.
Bu iki sonuç birbirinden farklı olabilir.
Örneğin bir site:
laboratuvar testinde 95 puan alırken gerçek kullanıcıların LCP değeri kötü olabilir.
Tam tersi de mümkündür.
Bu nedenle bir projede yalnız:
“PageSpeed kaç?”
diye sormuyorum.
Şunlara birlikte bakıyorum:
- LCP,
- INP,
- CLS,
- TTFB,
- FCP,
- render blocking kaynaklar,
- JavaScript yükü,
- görsel transferi,
- cache davranışı,
- sunucu yanıtı,
- gerçek kullanıcı verisi.
Core Web Vitals nedir?
Google’ın güncel Core Web Vitals seti üç temel metriğe odaklanır.
LCP — Largest Contentful Paint
Kullanıcının ilk ekranda gördüğü ana içeriğin ne kadar hızlı görüntülendiğini ölçer.
İyi eşik:
2,5 saniye veya daha kısa.
LCP problemi çoğunlukla şu alanlardan kaynaklanabilir:
- hero görseli,
- yavaş sunucu,
- render blocking CSS,
- geç yüklenen font,
- preload eksikliği,
- client-side rendering,
- yanlış lazy loading,
- ağır üçüncü taraf kodlar.
Burada yapılacak doğru müdahale LCP öğesinin ne olduğuna göre değişir.
Hero görseli LCP ise sunucu yükseltmek tek başına çözüm olmayabilir.
Sunucu ilk HTML’i geç gönderiyorsa görsel sıkıştırmak da yeterli değildir.
INP — Interaction to Next Paint
Kullanıcının sayfadaki etkileşimlerine ne kadar hızlı yanıt verildiğini ölçer.
İyi eşik:
200 ms’nin altı.
INP problemi genellikle:
- ağır JavaScript,
- uzun main-thread görevleri,
- gereksiz framework kodu,
- üçüncü taraf scriptler,
- ağır event handler’lar,
- DOM karmaşıklığı
ile ilişkilidir.
Bu nedenle INP iyileştirmesi “cache açmak” ile aynı problem değildir.
CLS — Cumulative Layout Shift
Sayfadaki beklenmedik görsel kaymaları ölçer.
İyi eşik:
0,1 veya altı.
Sık görülen nedenler:
- width/height tanımlanmamış görseller,
- geç gelen fontlar,
- dinamik banner’lar,
- iframe,
- harita,
- video,
- reklam alanları,
- sonradan eklenen CTA veya widget’lar.
Site hızlı görünse bile öğeler yüklenirken sürekli yer değiştiriyorsa kullanıcı deneyimi kötü olabilir.
Core Web Vitals SEO’dur ama SEO yalnız Core Web Vitals değildir
Core Web Vitals Google’ın sıralama sistemlerinin kullandığı sayfa deneyimi sinyalleri arasındadır.
Ancak:
90–100 PageSpeed puanı sizi otomatik olarak Google’da üst sıraya çıkarmaz.
İçerik kötü ise hız bunu telafi etmez.
Arama niyeti yanlışsa hız bunu düzeltmez.
Site indekslenemiyorsa performans puanı anlamsız hale gelir.
Bu nedenle performans projesini SEO’dan tamamen bağımsız ele almıyorum.
Optimizasyon sırasında:
- URL,
- canonical,
- structured data,
- internal links,
- indexability,
- mevcut içerik,
- görsel alt metinleri,
- analytics,
- conversion tracking
korunmalıdır.
TTFB: Sayfa daha başlamadan kaybedilen süre
TTFB — Time to First Byte — tarayıcının bir isteği başlatması ile sunucudan ilk baytı almaya başlaması arasında geçen süredir.
Bu süre yalnız PHP’nin çalışma süresi değildir.
Toplam sürece:
- DNS,
- bağlantı kurulması,
- TLS,
- ağ gecikmesi,
- sunucu işleme süresi
gibi katmanlar katkıda bulunabilir.
Google/web.dev tarafından kullanılan genel referansta çoğu site için:
0,8 saniye veya altında TTFB
iyi bir hedef olarak kabul edilir.
Ancak TTFB bir Core Web Vital değildir.
TTFB’nin önemi, kendisinden sonra gelen FCP ve LCP gibi metriklerin önüne gecikme eklemesidir.
Sunucu ilk HTML’i 2 saniyede gönderiyorsa tarayıcı LCP görselini daha erken göstermeye başlayamaz.
WordPress neden yavaşlar?
WordPress’in kendisi otomatik olarak yavaş değildir.
Sorun çoğunlukla yıllar içinde üst üste eklenen katmanlardan oluşur.
Örneğin:
- ağır tema,
- page builder,
- çok sayıda eklenti,
- yavaş PHP,
- cache bypass,
- veritabanı sorguları,
- autoload şişmesi,
- harici API istekleri,
- WooCommerce session’ları,
- gereksiz cron işlemleri,
- düşük kaynaklı hosting,
- hatalı Redis/object cache,
- çok sayıda üçüncü taraf script.
Bu nedenle WordPress hızlandırmaya:
“Şu cache eklentisini kurun.”
şeklinde yaklaşmıyorum.
Önce hangi katmanın gerçekten süre tükettiğini belirlemek gerekir.
LiteSpeed, WP Rocket veya cache tek başına çözüm mü?
Hayır.
Cache doğru kullanıldığında çok büyük performans kazancı sağlayabilir.
Ancak cache’in çözmediği problemler vardır.
Örneğin:
- ağır client-side JavaScript,
- büyük LCP görseli,
- kötü CLS,
- gereksiz fontlar,
- cache dışı dinamik endpoint,
- üçüncü taraf API,
- ödeme/üyelik/session tabanlı sayfalar.
Cache eklentisi sorunları saklayabilir ancak mimari darboğazı ortadan kaldırmayabilir.
Cloudflare siteyi her zaman hızlandırır mı?
Hayır.
Cloudflare veya başka bir CDN doğru kurulduğunda:
- statik içerikleri kullanıcıya yakın noktadan sunabilir,
- ağ gecikmesini azaltabilir,
- cache sağlayabilir,
- güvenlik avantajı sağlayabilir.
Ancak yanlış cache kuralları:
- dinamik sayfaları bozabilir,
- oturum sorunlarına neden olabilir,
- eski içerik gösterebilir,
- admin/login davranışını etkileyebilir.
CDN kullanmak ile CDN’i doğru yapılandırmak aynı şey değildir.
Görseller hâlâ en büyük problemlerden biri
Modern sitelerde görseller hâlâ en sık gördüğüm performans sorunlarından biridir.
Örneğin:
300–400 piksel gösterilen bir görselin tarayıcıya 3000 piksel olarak gönderilmesi gereksizdir.
Kullandığım temel yaklaşım:
- doğru fiziksel ölçü,
- responsive
srcset, - AVIF/WebP,
- uygun compression,
- width/height,
- ekran dışındaki görsellerde lazy loading,
- LCP görselinde lazy loading kullanmama,
- gerekiyorsa preload/fetchpriority.
Ama burada da amaç her görseli mümkün olan en küçük dosyaya çevirmek değildir.
Kalite ile transfer boyutu dengelenmelidir.
LCP görselini yanlış optimize etmek
Bir hero görseli sayfanın LCP öğesiyse:
loading="lazy"
kullanmak LCP’yi kötüleştirebilir.
Tarayıcının ilk ekranda gerekli kaynağı erkenden keşfetmesi gerekir.
Bu nedenle LCP görsellerinde projeye göre:
- preload,
fetchpriority,- doğru
srcset, - doğru boyut,
- AVIF/WebP
birlikte değerlendirilebilir.
JavaScript ve üçüncü taraf servisler
Bir sitenin kendi JavaScript’i hızlı olabilir.
Ancak siteye:
- GTM,
- GA4,
- Meta Pixel,
- chat widget,
- WhatsApp widget,
- reCAPTCHA,
- YouTube embed,
- Google Maps,
- heatmap,
- call tracking
eklendiğinde ana thread yükü ciddi biçimde artabilir.
Sorunun kaynağını belirlemeden tüm scriptleri silmek doğru çözüm değildir.
Önemli olan:
- gerekli mi?
- ne zaman yüklenmeli?
- consent sonrası mı çalışmalı?
- lazy-load edilebilir mi?
- facade kullanılabilir mi?
sorularıdır.
Doktor ve klinik web sitelerinde hız neden özellikle önemli?
Sağlık sitelerinde birçok performans maliyeti aynı anda bulunabilir.
Örneğin:
- yüksek çözünürlüklü doktor fotoğrafları,
- klinik galerileri,
- video,
- harita,
- WhatsApp,
- randevu sistemleri,
- çerez yönetimi,
- analytics,
- çok dilli içerik,
- üçüncü taraf sağlık platformları.
Bunların tamamını kaldırmak doğru çözüm değildir.
Ama yükleme sırasını ve gerekliliğini doğru planlamak mümkündür.
Bir doktor sitesinde amaç:
“görselleri kaldırıp 100 puan almak”
değil;
güven veren görsel kaliteyi korurken hızlı ve stabil bir deneyim üretmektir.
E-ticaret sitelerinde performans neden farklıdır?
E-ticaret:
- sepet,
- kullanıcı oturumu,
- fiyat/stok,
- filtre,
- varyasyon,
- öneriler,
- analytics,
- reklam tag’leri
nedeniyle statik bir kurumsal siteden daha karmaşıktır.
Bu nedenle bütün sayfaları agresif biçimde cache’lemek mümkün olmayabilir.
Ana sayfa, kategori, ürün, sepet ve checkout ayrı performans profilleri olarak değerlendirilmelidir.
PageSpeed puanı neden her testte değişebilir?
Aynı URL üzerinde kısa aralıklarla:
95 72 88 43 97
gibi farklı Lighthouse sonuçları görmek mümkündür.
Bu her zaman sitenin beş dakika içinde bozulduğu anlamına gelmez.
Laboratuvar ölçümleri şu faktörlerden etkilenebilir:
- test lokasyonu,
- ağ koşulları,
- test sunucusundaki kaynak kullanımı,
- CDN edge,
- cache HIT/MISS,
- backend yoğunluğu,
- dinamik üçüncü taraf içerikler,
- A/B testleri,
- reklam veya widget davranışı.
Bu yüzden tek çalıştırmayı “gerçek hız” olarak kabul etmiyorum.
Bu konu için ayrıca:
PageSpeed Puanı Neden Her Testte Değişiyor?
rehberini hazırladım.
Bir siteyi nasıl hızlandırıyorum?
1. Baseline
Önce hiçbir şeyi değiştirmeden ölçerim.
- PageSpeed Insights
- Lighthouse
- Core Web Vitals / CrUX
- browser network waterfall
- TTFB
- transfer boyutu
- request sayısı
- LCP resource
- main-thread yükü
kaydedilir.
2. Darboğaz sınıflandırması
Sorunun ağırlıklı katmanı belirlenir:
- SERVER
- NETWORK
- CACHE
- DATABASE
- HTML
- CSS
- JAVASCRIPT
- IMAGE
- FONT
- THIRD PARTY
- CLS
- RENDER
3. En yüksek etki / en düşük risk sırası
Her problemi aynı anda değiştirmem.
Önce en büyük kullanıcı etkisini oluşturan ve en düşük regresyon riskine sahip müdahaleler yapılır.
4. Sonra yeniden ölçüm
Önce/sonra verisi alınır.
Yalnız skor değil:
- LCP,
- TTFB,
- CLS,
- INP/TBT,
- transfer,
- request waterfall
karşılaştırılır.
5. Fonksiyon kontrolü
Hız uğruna:
- sepet,
- form,
- tracking,
- çerez,
- login,
- menü,
- slider,
- görsel
bozulmamalıdır.
Performans iyileştirmesi fonksiyon kaybı yaratıyorsa tamamlanmış sayılmaz.
Hangi altyapılarda çalışıyorum?
Projenin ihtiyacına göre:
- WordPress,
- WooCommerce,
- CS-Cart,
- Laravel,
- Astro/statik site,
- Next.js,
- özel PHP altyapıları,
- özel frontend/backend sistemleri
üzerinde performans analizi yapılabilir.
Her altyapıya aynı optimizasyon reçetesini uygulamıyorum.
Yapmadığım şeyler
- sadece PageSpeed 100 ekran görüntüsü satmıyorum,
- işlevleri kapatıp yüksek skor üretmiyorum,
- SEO içeriğini hız için silmiyorum,
- tüm JavaScript’i kör biçimde ertelemiyorum,
- her siteye aynı cache ayarını uygulamıyorum,
- test ortamındaki tek Lighthouse sonucunu başarı metriği kabul etmiyorum,
- “100 puan = Google’da 1. sıra” iddiası kullanmıyorum.
Kimler için?
Bu hizmet:
- doktor ve klinikler,
- sağlık kuruluşları,
- kurumsal siteler,
- e-ticaret projeleri,
- ajanslar,
- içerik platformları,
- yüksek trafikli siteler,
- reklam trafiği alan landing page’ler
için uygulanabilir.
Türkiye ile sınırlı değildir.
Siteniz gerçekten yavaş mı, yoksa test sonucu mu dalgalanıyor?
Önce nerede zaman kaybedildiğini belirleyelim.
Sunucu, frontend, görsel, JavaScript, cache veya üçüncü taraf servislerden hangisinin asıl darboğaz olduğunu ölçmeden optimizasyona başlamayalım.