Google PageSpeed skorunu yükseltmenin yolu rastgele optimizasyon yapmaktan değil, önceliklendirmeden geçer. Önce skorun nasıl hesaplandığını anla, sonra PageSpeed Insights'ın en çok zaman kazandıracağını söylediği önerilerden başla. Çoğu sitede en büyük kazanç görsel ve font optimizasyonundan gelir; 100/100 takıntısı ise genellikle zaman kaybıdır.
Site hızı hem kullanıcı deneyimini hem de aramadaki görünürlüğü doğrudan etkiliyor. Ama "PageSpeed skorum düşük, nasıl yükseltirim" sorusuna verilen cevapların çoğu ya çok yüzeysel kalıyor ya da yanlış şeye odaklanıyor. Bu yazıda skorun gerçekte ne ölçtüğünü, hangi iyileştirmenin gerçekten fark yarattığını ve nereden başlaman gerektiğini sırayla anlatıyorum.
Skorun Anlamı: Önce Neyi Ölçtüğünü Anla
PageSpeed Insights (PSI) sana tek bir sayı verir ama o sayının arkasında iki ayrı veri dünyası vardır. Google for Developers'ın PageSpeed Insights dokümantasyonuna göre araç iki tür veri kullanır: CrUX (Chrome User Experience Report) üzerinden gelen saha verisi yani gerçek kullanıcıların deneyimi ve Lighthouse'un kontrollü bir ortamda ürettiği lab verisi. Aynı dokümana göre skor renk kodludur: 90 ve üzeri iyi (yeşil), 50 ile 89 arası iyileştirilmeli (sarı), 50'nin altı ise kötü (kırmızı) sayılır.
Lab Verisi mi, Saha Verisi mi?
Bu ayrım önemli çünkü çoğu kişi sadece sayfanın tepesindeki Lighthouse skoruna bakıp paniğe kapılır. Lab verisi tek bir test çalıştırmasıdır; belirli bir cihaz, belirli bir ağ hızı ve sabit koşullarla üretilir. Hata ayıklamak için harikadır çünkü tekrarlanabilir. Saha verisi (field/CrUX) ise son dönemde siteni gerçekten ziyaret eden insanların yaşadığı deneyimdir. Hangisi gerçeği gösterir derseniz: kullanıcı deneyimi açısından saha verisi gerçeği gösterir, lab verisi ise sorunu teşhis etmeni sağlar.
Pratikte sıralama önceliğin şu olmalı: saha verisi seni uyarıyorsa gerçek bir sorun var demektir. Lab skoru düşük ama saha verisi iyiyse, telaşa kapılmadan diagnostikleri inceleyebilirsin. Tersi de mümkündür: lab skorun yüksek görünürken saha verin zayıfsa, kullanıcılarının cihazları ve bağlantı hızları senin test ortamından farklı demektir. Bu durumda mobil tarafa ve yavaş bağlantılara öncelik vermen gerekir.
Yeni yayına aldığın bir sayfada henüz saha verisi olmayabilir, çünkü CrUX yeterli gerçek kullanıcı trafiği biriktiğinde dolar. Böyle durumlarda geçici olarak lab verisine güvenip sayfayı sağlama alır, sonra trafik geldikçe saha verisini izlersin.
Core Web Vitals ve Güncel Metrikler
Skorun temelinde Core Web Vitals yatar. Google'ın web.dev Web Vitals kaynağına göre üç ana metrik ve eşikleri şöyle: LCP (Largest Contentful Paint) 2,5 saniye veya altı iyi kabul edilir, CLS (Cumulative Layout Shift) 0,1 veya altı iyidir. Aynı kaynak bu metriklerin sayfa yüklemelerinin 75. yüzdelik diliminde, hem mobil hem masaüstünde ölçüldüğünü belirtir. Yani en hızlı yüklemen değil, kullanıcılarının çoğunluğunun deneyimi sayılır.
Üçüncü metrik konusunda dikkatli ol: pek çok Türkçe rehber hala eski FID metriğini anlatıyor. Oysa web.dev INP kaynağına göre INP (Interaction to Next Paint) 2024'te FID'in yerini alarak kararlı bir Core Web Vital oldu. INP eşikleri ise şöyle: 200 ms ve altı iyi, 200 ile 500 ms arası iyileştirilmeli, 500 ms üstü kötü. FID sadece ilk etkileşimi ölçerken INP sayfadaki tüm etkileşimleri değerlendirir, yani çok daha gerçekçi bir tablo verir. Rehberin güncelliğini test etmek istersen: hala FID yazıyorsa o içerik eskimiş demektir.
Önerileri Önceliklendirme: Her Şeyi Aynı Anda Yapma
PageSpeed skorunu yükseltirken yapılan en büyük hata, raporda görünen her uyarıyı baştan sona düzeltmeye çalışmaktır. Bu hem zaman kaybıdır hem de en kritik kazançları geciktirir. Bunun yerine skorun nasıl hesaplandığını bilip ağırlığı yüksek metriklere yönelmelisin.
Chrome for Developers'ın Lighthouse Performance Scoring dokümantasyonuna göre Lighthouse performans skoru metriklerin ağırlıklı ortalamasıdır. Lighthouse 10 sürümünde ağırlıklar şöyledir: TBT (Total Blocking Time) %30, LCP %25, CLS %25, FCP (First Contentful Paint) %10 ve Speed Index %10. Bu tabloyu okumanın pratik karşılığı net: skorunu en çok TBT, LCP ve CLS etkiliyor. Yani JavaScript'in ana iş parçacığını bloklaması, en büyük içerik öğesinin geç yüklenmesi ve düzen kaymaları en yüksek getirili düzeltme alanlarıdır.
Tasarruf Süresine Göre Sırala
PSI raporunda "Opportunities" (Fırsatlar) ve "Diagnostics" (Tanılar) bölümleri vardır. Fırsatlar listesi her öneriyi tahmini tasarruf süresiyle gösterir. İşte sıralama mantığın burada başlamalı:
- En çok saniye kazandıracağı söylenen maddeyi en üste koy.
- Ağırlığı yüksek metriği (LCP, TBT, CLS) etkileyen önerileri öne al.
- Tek seferlik, düşük efor gerektiren düzeltmeleri (görsel sıkıştırma gibi) hızlıca tamamla.
Bu yaklaşım sayesinde birkaç saatlik işle skorda büyük sıçrama görürsün; geri kalan küçük uyarıları ise zamanı geldiğinde ele alırsın. Unutma, raporun verdiği tahmini tasarruf süreleri kesin değil, yön gösterici işaretlerdir. Yine de hangi düzeltmenin daha değerli olduğunu kabaca anlamana fazlasıyla yeter.
Bir de bağımlılıklara dikkat et. Bazı düzeltmeler birbirini açar: görselleri küçülttüğünde LCP iyileşir, ağır bir script'i ertelediğinde hem TBT hem INP rahatlar. Bu yüzden tek bir metrik için uğraşmak yerine, en pahalı kaynakları (büyük görseller ve bloklayan script'ler) hedeflemek genellikle birden fazla metriği aynı anda iyileştirir.
Görsel ve Font: En Çok Kazanç Buradan Gelir
Çoğu sitede performansı en çok düşüren şey ağır medyadır. Bu yüzden görsel optimizasyonu neredeyse her zaman en yüksek getirili adımdır ve genellikle LCP'yi doğrudan iyileştirir.
Görsel Optimizasyonu
Görsellerde dikkat etmen gereken birkaç temel nokta var:
- Modern format kullan: JPEG ve PNG yerine WebP veya AVIF formatları aynı görsel kalitesini çok daha küçük dosya boyutuyla sunar.
- Doğru boyutlandır: Ekranda 400 piksel genişlikte gösterilen bir görseli 2000 piksel olarak yüklemek boşuna bant genişliği harcar. Görseli kullanılacağı boyuta yakın servis et.
- Sıkıştır: Kaliteyi gözle görülür biçimde bozmadan dosya boyutunu küçülten sıkıştırma uygula.
- Lazy loading kullan: Ekranın altında kalan, kullanıcı kaydırmadan görünmeyen görselleri geç yükle. Ancak LCP öğesi olan üst görseli lazy load etme, aksine onu öncelikli yükle.
Font Optimizasyonu
Fontlar çoğu rehberin atladığı sessiz bir performans hırsızıdır. Web fontu yavaş yüklendiğinde ya metin bir süre görünmez (FOIT) ya da düzen kayması yaşanır ki bu da CLS skoruna zarar verir. Şunlara dikkat et:
- font-display kullan: font-display: swap ile font yüklenene kadar yedek bir sistem fontu gösterilir, böylece metin gizli kalmaz.
- Kritik fontları preload et: İlk ekranda kullanılan fontları preload ederek tarayıcının onları erken keşfetmesini sağla.
- Gereksiz font ağırlıklarını çıkar: Sadece kullandığın kalınlık ve stilleri yükle; her ağırlık ek bir indirme demektir.
- Sistem fontlarını değerlendir: Tasarımın izin veriyorsa, hiç web fontu yüklemeyip kullanıcının cihazındaki sistem fontlarını kullanmak en hızlı seçenektir.
Fontlar küçük dosyalar gibi görünse de render akışının kritik yolunda dururlar. Bir fontun geç gelmesi sadece o metni değil, çevresindeki düzeni de etkileyebilir. Bu yüzden font kararlarını görsel kararları kadar ciddiye almakta fayda var.
Kod Küçültme: JavaScript ve CSS'i Hafiflet
Skor tablosunda TBT'nin %30 ağırlığa sahip olduğunu hatırla. TBT'yi şişiren ana neden genellikle ağır JavaScript'tir. Kod tarafında atabileceğin adımlar şöyle:
- Küçültme (minify): CSS, JavaScript ve HTML dosyalarındaki gereksiz boşluk, yorum ve karakterleri kaldır. Çoğu modern derleme aracı bunu otomatik yapar.
- Kullanılmayan kodu kaldır: Sayfada hiç çalışmayan CSS ve JavaScript'i ayıkla. PSI'nin "unused CSS/JavaScript" uyarıları tam olarak bunu gösterir.
- async ve defer kullan: Render'ı bloklayan script etiketlerine async veya defer ekleyerek tarayıcının sayfayı çizmeye devam etmesini sağla. Böylece ana iş parçacığı daha az bloklanır.
Bu adımlar hem indirilen byte miktarını hem de tarayıcının işlemesi gereken kodu azaltır, bu da doğrudan TBT ve INP'ye yansır. Özellikle üçüncü taraf script'leri (canlı destek widget'ları, analitik kodları, reklam ağları) çoğu zaman performansın en sessiz düşmanıdır. Her birini gerçekten ihtiyacın olup olmadığı açısından gözden geçir; kullanmadığın bir aracı yüklemeye devam etmek için hiçbir neden yok.
Mümkün olan yerde kritik olmayan script'leri kullanıcı etkileşime geçtiğinde yüklemek de güçlü bir tekniktir. Örneğin bir sohbet penceresini sayfa açılır açılmaz değil, kullanıcı butona dokunduğunda yüklersen ilk yükleme çok daha hafif olur.
Wix ve Ikas Gibi Platformlarda Sınırlar
Eğer siten Wix, Ikas gibi hazır bir platform üzerindeyse her optimizasyona erişemeyebilirsin. Bu platformlar altyapıyı, sunucu yapılandırmasını ve büyük ölçüde kod çıktısını kendileri yönetir. Yani "kullanılmayan tüm JavaScript'i sil" gibi bir kontrolün her zaman olmaz.
Yine de elinde gerçek kazanç sağlayan kaldıraçlar var: yüklediğin görselleri doğru formatta ve boyutta hazırlamak, gereksiz uygulama ve üçüncü taraf script'lerini kapatmak, fontları sadeleştirmek, düzen kaymasına yol açan öğeleri düzeltmek. Bu platformlarda hedefin ham skoru en üste çıkarmak değil, kontrol edebildiğin alanları temizleyerek eşik değerlerin içine girmektir.
Pratik bir örnek: bir Ikas mağazasında ürün görsellerini optimize etmek ve kullanmadığın eklentileri kapatmak çoğu zaman temadaki teknik ayrıntılarla uğraşmaktan çok daha fazla fark yaratır. Wix tarafında da benzer şekilde, her bölüme eklenen ağır animasyonlar ve gömülü video'lar yükü artırır. Sade tutmak çoğunlukla en iyi performans stratejisidir. Platformun sınırlarını kabul edip elindeki kaldıraçları sonuna kadar kullanmak, var olmayan kontrolleri aramaktan çok daha verimlidir.
Skor Takıntısı: 100/100 Bir Tuzak
Son ve belki en önemli nokta: skor bir araçtır, amaç değil. Lighthouse Performance Scoring dokümantasyonuna göre skor dalgalanması tamamen normaldir ve bu değişkenliğin büyük kısmı aslında Lighthouse'tan değil, ağ yönlendirme, test cihazı, tarayıcı eklentileri gibi alttaki koşullardan kaynaklanır. Yani aynı sayfayı arka arkaya test ettiğinde farklı sayılar görmen beklenen bir durumdur.
Bu yüzden 100/100 peşinde koşmak çoğu zaman azalan getiri kanununa takılır. Son birkaç puan için harcadığın saatler, gerçek kullanıcı deneyimine neredeyse hiç dokunmayabilir. Doğru hedef şudur:
- Core Web Vitals eşiklerini geç: LCP 2,5 sn altı, CLS 0,1 altı, INP 200 ms altı.
- Lab skorundan çok saha (CrUX) verisini takip et, çünkü gerçek kullanıcıyı o gösterir.
- Tek bir testin sayısına değil, zaman içindeki eğilime bak.
Skorunu yeşile taşıdıysan ve saha verin sağlıklıysa, kalan birkaç puanı kovalamak yerine içeriğe ve dönüşüme odaklanman çok daha değerlidir.
VixSEO ile Hız Tarafını Yönet
Hız optimizasyonu tek seferlik bir iş değil; her yeni sayfa, görsel ve eklenti skoru yeniden etkiler. VixSEO, Wix, Ikas ve özel kurulan sitelerde teknik SEO ve site hızı tarafını tek panelden takip etmeni kolaylaştırır. Eğer skorların neden düştüğünü çözmekte zorlanıyorsan hizmetler sayfamıza göz atabilir ya da araçlar bölümünden işe başlayabilirsin.