PageSpeed Puanı Nasıl Yükseltilir? Core Web Vitals Rehberi

PageSpeed Insights'ta kırmızı bir puan görmek can sıkıcıdır; ama asıl mesele puanın kendisi değil, ziyaretçinin yaşadığı deneyimdir. Yavaş açılan, yüklenirken zıplayan ya da dokunulduğunda geç tepki veren bir sayfa, ziyaretçiyi rakibe gönderir. Bu rehberde Core Web Vitals metriklerini sade bir dille açıklıyor ve PageSpeed puanını yükseltmek için uygulanabilir adımları sıralıyoruz.

Kısa cevap: PageSpeed puanını yükseltmenin en etkili yolları; görselleri WebP formatında ve doğru boyutta sunmak, ana görseli önceliklendirmek, gereksiz JavaScript ve üçüncü taraf betikleri ayıklamak, görsellere boyut vererek kaymaları önlemek ve sunucu yanıt süresini önbellek ve CDN ile kısaltmaktır. Hedef: LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1.

Core Web Vitals nedir?

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini ölçmek için öne çıkardığı üç metriktir. Google bu metrikleri sayfa deneyimi değerlendirmesinin bir parçası olarak kullanır. Eşik değerler, sayfa ziyaretlerinin 75. yüzdelik dilimine göre değerlendirilir.

INP, Mart 2024'te FID (First Input Delay) metriğinin yerini aldı. Eski rehberlerde FID görürseniz bunun artık güncel olmadığını bilin.

Laboratuvar verisi ile saha verisi arasındaki fark

PageSpeed Insights iki tür veri gösterir. Üstteki "Gerçek kullanıcılarınızın deneyimi" bölümü, Chrome kullanıcılarından toplanan saha verisidir (CrUX) ve yeterli trafiğiniz varsa görünür. Alttaki "Performans sorunlarını teşhis edin" bölümü ise Lighthouse'un simüle edilmiş bir mobil cihaz ve ağ koşulunda yaptığı laboratuvar ölçümüdür. Laboratuvar puanı her ölçümde biraz oynayabilir; kararlarınızı tek bir ölçüme göre değil, birkaç ölçümün ortalamasına ve saha verisine göre verin.

LCP'yi iyileştirmek: ana içeriği hızlı getirin

LCP'yi en çok etkileyen şeyler sunucu yanıt süresi, ağır görseller ve render'ı engelleyen kaynaklardır.

Yapılacaklar

• Görselleri modern formatta sunun: WebP veya AVIF, aynı görsel kalitesinde PNG/JPEG'e göre çoğu zaman çok daha küçük dosya demektir. Telefonda 400 piksel genişliğinde görünen bir görsel için 3000 piksellik dosya göndermeyin; srcset ve sizes ile cihaza uygun boyutu verin.
• LCP görselini önceliklendirin: Ana görselde fetchpriority="high" kullanın, ona asla loading="lazy" vermeyin.
• Render'ı engelleyen CSS ve JS'yi azaltın: Kritik CSS'i satır içi verin, diğer betikleri defer ile yükleyin.
• Sunucu yanıt süresini düşürün: Önbellekleme, güncel PHP sürümü, veritabanı sorgularının iyileştirilmesi ve bir CDN kullanımı TTFB'yi kısaltır.
• Fontları akıllıca yükleyin: font-display: swap kullanın, sadece gereken ağırlıkları ve karakter alt kümelerini yükleyin; mümkünse fontları kendi sunucunuzda barındırın.

INP'yi iyileştirmek: sayfa tıklamaya hemen cevap versin

INP sorunlarının kaynağı çoğunlukla ana iş parçacığını uzun süre meşgul eden JavaScript'tir.

• Kullanılmayan kütüphaneleri kaldırın. Sadece birkaç ikon için koca bir ikon kütüphanesi yüklemek tipik bir israftır.
• Üçüncü taraf betikleri (sohbet balonları, reklam pikselleri, ısı haritaları) gözden geçirin; gerçekten kullanılmayanları çıkarın, gerekenleri geç yükleyin.
• Uzun görevleri parçalara bölün; ağır hesaplamaları kullanıcı etkileşiminden sonraya erteleyin.
• Geliştirme ortamında kullanılan CDN tabanlı CSS çerçevelerini (örneğin tarayıcıda derlenen Tailwind) üretimde derlenmiş, küçültülmüş CSS ile değiştirin.

CLS'yi iyileştirmek: içerik yerinden oynamasın

• Tüm görsel ve videolara width ve height verin ya da CSS'te aspect-ratio tanımlayın.
• Reklam, gömülü içerik ve çerez bandı gibi sonradan gelen alanlar için yer ayırın.
• Web fontlarının yüklenmesiyle oluşan kaymayı azaltmak için yedek font boyutlarını ayarlayın.
• Sayfanın üst kısmına, kullanıcı etkileşimi olmadan içerik eklemeyin.

Adım adım iyileştirme planı

1. Ölçün: Ana sayfa, en çok trafik alan hizmet sayfası ve bir blog yazısını PageSpeed Insights ile mobilde ölçün. Sonuçları not alın.
2. En büyük kazancı bulun: "Fırsatlar" bölümünde tahmini tasarrufu en yüksek maddelerden başlayın. Genellikle görseller ve gereksiz JavaScript ilk sıradadır.
3. Görselleri dönüştürün: Tüm büyük görselleri WebP'ye çevirin, farklı genişlikler üretin.
4. CSS/JS'yi sadeleştirin: Derleme adımı ekleyin, kullanılmayan kodu ayıklayın.
5. Önbellek ve CDN: Statik dosyalara uzun süreli önbellek başlıkları verin; gerekirse Cloudflare gibi bir CDN ekleyin.
6. Tekrar ölçün: Değişikliklerin etkisini aynı sayfalarda tekrar ölçün, saha verisini birkaç hafta takip edin.

Sık yapılan hatalar

• Sadece masaüstü puanına bakmak. Ziyaretçilerin büyük kısmı mobilden geliyorsa mobil puan daha önemlidir.
• Puanı yükseltmek için içerik veya işlevi kırpmak. Amaç kullanıcı deneyimidir; puan bunun göstergesidir.
• Her şeyi tembel yüklemek (lazy load). Ekranın üstündeki ana görseli geç yüklemek LCP'yi kötüleştirir.
• Çok sayıda eklenti ile "optimizasyon" yapmak. Bazı eklentiler çözdüğünden fazla sorun yaratır.

Hangi araçla ne ölçülür?

Search Console raporu, değişikliklerin etkisini görmek için en güvenilir kaynaktır; ancak saha verisi 28 günlük bir dönem üzerinden hesaplandığı için iyileştirmelerin rapora yansıması zaman alır. Sabırlı olun ve laboratuvar ölçümleriyle ara kontroller yapın.

Görsel optimizasyonu: pratik bir iş akışı

Çoğu sitede en büyük kazanç görsellerden gelir. Basit bir iş akışı şöyle olabilir:

1. Kaynak görselleri en yüksek kalitede saklayın, siteye asla doğrudan yüklemeyin.
2. Her görsel için kullanılacağı en büyük genişliği belirleyin (örneğin tam genişlik kapak için 1600 piksel, kart görseli için 600 piksel).
3. Bu genişliklerde WebP sürümleri üretin; kalite ayarını gözle kontrol ederek düşürün.
4. HTML'de srcset ile farklı genişlikleri, sizes ile görselin ekranda kaplayacağı alanı belirtin.
5. Ekranın üst kısmındaki ana görsel dışındaki tüm görsellere loading="lazy" ekleyin.

Bu adımlar bir derleme betiği veya sunucu tarafında otomatik dönüştürme ile kalıcı hâle getirilmelidir; aksi hâlde yeni yüklenen her görsel sorunu geri getirir.

Üçüncü taraf betikleri denetlemek

Analiz araçları, reklam etiketleri, sohbet balonları ve sosyal medya gömmeleri zamanla birikir. Yılda en az bir kez şu soruları sorun: Bu betik hâlâ kullanılıyor mu? Verisine kim bakıyor? Sayfa yüklenirken hemen mi gerekli, yoksa kullanıcı etkileşiminden sonra mı yüklenebilir? Gereksiz her betiği kaldırmak hem hızı hem de gizlilik uyumunu iyileştirir.

Platforma göre hız iyileştirme notları

WordPress ve benzeri CMS'ler

• Eklenti sayısını azaltın; her eklentinin her sayfada betik ve stil yükleyip yüklemediğini kontrol edin.
• Sayfa önbellekleme eklentisi veya sunucu seviyesinde önbellek kullanın.
• Sayfa oluşturucu (page builder) temaları ağır HTML ve CSS üretebilir; kritik sayfalarda daha sade şablonlar değerlendirin.
• Veritabanını ve revizyon kayıtlarını düzenli temizleyin.

Özel PHP veya framework tabanlı siteler

• Güncel PHP sürümü ve OPcache etkin olsun.
• Tekrarlanan veritabanı sorgularını önbelleğe alın; yavaş sorguları indeksle iyileştirin.
• CSS çerçevesini derleme adımıyla küçültün, kullanılmayan sınıfları ayıklayın.
• Statik dosyalara sürüm parametresi ekleyerek uzun süreli önbellek başlığı verin.

Tek sayfa uygulamaları (React, Vue vb.)

• İlk yüklemede gönderilen JavaScript miktarını kod bölme (code splitting) ile küçültün.
• İçerik ağırlıklı sayfalarda sunucu tarafı render veya statik üretim değerlendirin.
• Hidrasyon sırasında oluşan uzun görevlerin INP'ye etkisini ölçün.

Sunucu ve barındırma tarafı

Ön yüzde yapılan iyileştirmeler, yavaş bir sunucunun açığını tamamen kapatamaz. Sunucu yanıt süresi (TTFB) yüksekse şunlara bakın:

1. Barındırma türü: Aşırı kalabalık paylaşımlı sunucular yoğun saatlerde yavaşlayabilir.
2. Sunucu konumu: Ziyaretçileriniz ağırlıklı olarak Türkiye'deyse, uzak bir veri merkezi gecikmeyi artırır; bir CDN bu farkı azaltır.
3. Sıkıştırma: Metin tabanlı dosyalarda Gzip veya Brotli sıkıştırması açık olmalıdır.
4. HTTP/2 veya HTTP/3: Modern protokoller çok sayıda küçük dosyanın daha verimli iletilmesini sağlar.

Hızı kalıcı tutmak: performans bütçesi

Bir kez iyileştirilen site, yeni eklenen görseller, betikler ve özelliklerle zamanla yeniden yavaşlar. Bunu önlemenin yolu bir performans bütçesi belirlemektir: örneğin "ana sayfanın toplam ağırlığı belirli bir sınırı geçmeyecek" veya "mobil laboratuvar ölçümünde LCP 2,5 saniyenin altında kalacak" gibi kurallar. Yeni bir özellik eklendiğinde bu bütçe aşılıyorsa, ya özellik hafifletilir ya da başka bir şeyden tasarruf edilir. Ekipte bu kuralı herkesin bilmesi, hızı bir proje değil bir alışkanlık hâline getirir.

INP sorunlarını adım adım bulmak

INP, sayfa yüklendikten sonraki etkileşimlerle ilgili olduğu için laboratuvar testinde her zaman görünmez. Sorunu bulmak için şu yolu izleyebilirsiniz:

1. Sorunlu sayfaları belirleyin: Search Console'daki Core Web Vitals raporunda INP sorunu olan URL gruplarına bakın.
2. Etkileşimleri tahmin edin: O sayfalarda en sık kullanılan öğeler neler? Menü açma, filtre seçme, sepete ekleme, form alanına yazma gibi.
3. Performance panelinde kaydedin: Chrome DevTools'ta CPU yavaşlatmasını açıp bu etkileşimleri yaparken kayıt alın.
4. Uzun görevleri inceleyin: Etkileşimden sonra ana iş parçacığını uzun süre meşgul eden betikleri bulun.
5. Kaynağa göre çözün: Kendi kodunuzsa işi bölün veya erteleyin; üçüncü taraf betikse geç yükleyin veya kaldırın.

Gerçek kullanıcılardan veri toplamak isterseniz, Google'ın web-vitals JavaScript kütüphanesi ile metrikleri kendi analiz aracınıza gönderebilirsiniz. Bu sayede hangi sayfada, hangi etkileşimin yavaş olduğunu daha net görürsünüz.

Font optimizasyonu: küçük ama etkili

• Ağırlık sayısını azaltın: Her ağırlık (400, 500, 700) ayrı bir dosyadır. Tasarımda gerçekten kullanılanları yükleyin.
• Değişken font değerlendirin: Çok sayıda ağırlık kullanılıyorsa tek bir değişken font dosyası daha verimli olabilir.
• Karakter alt kümesi: Türkçe karakterleri (ç, ğ, ı, İ, ö, ş, ü) içeren Latin Extended alt kümesini dahil etmeyi unutmayın; aksi hâlde bu harfler yedek fontla görünür.
• Ön yükleme: Ekranın üst kısmında kullanılan font dosyasını preload ile erken isteyin.
• Kendi sunucunuzda barındırın: Harici font servislerine yapılan ek bağlantılar ilk yüklemede gecikme yaratabilir.

Hız iyileştirmesinin iş sonuçlarına etkisini izlemek

Teknik metriklerin iyileşmesi önemlidir, ancak asıl soru bunun işinize ne kattığıdır. Hız çalışmasından önce ve sonra şu göstergeleri karşılaştırın: mobil ziyaretçilerin hemen çıkma ve etkileşim oranı, form gönderimleri veya satışlar gibi dönüşümler, sayfa başına ortalama görüntüleme ve organik aramalardan gelen trafik. Mevsimsellik ve kampanyalar gibi dış etkenleri de hesaba katarak birkaç haftalık dönemleri kıyaslayın. Bu şekilde hız çalışmasının yatırım değerini somut olarak görebilir ve sonraki iyileştirmeleri önceliklendirebilirsiniz.

Terimler sözlüğü

• TTFB: Tarayıcının isteği gönderdikten sonra sunucudan ilk baytı alana kadar geçen süre.
• CrUX: Chrome kullanıcılarından toplanan gerçek kullanıcı deneyimi veri seti.
• Lighthouse: Sayfa performansını simüle koşullarda ölçen açık kaynaklı denetim aracı.
• Render engelleyen kaynak: Sayfanın ekrana çizilmesini, yüklenene kadar bekleten CSS veya JavaScript dosyası.
• Lazy loading: Ekranda görünmeyen görsellerin, kullanıcı yaklaştıkça yüklenmesi.
• Uzun görev (long task): Ana iş parçacığını 50 milisaniyeden uzun süre meşgul eden işlem.

Özetle: akılda kalması gerekenler

• Core Web Vitals; LCP, INP ve CLS metriklerinden oluşur.
• Kararları tek bir laboratuvar ölçümüne değil, saha verisine dayandırın.
• Görseller, gereksiz JavaScript ve üçüncü taraf betikler en büyük kazanç alanlarıdır.
• Performans bütçesi belirleyerek hızı kalıcı hâle getirin.

Sık Sorulan Sorular

PageSpeed puanı 100 olmadan iyi sıralama alınamaz mı?

Alınır. Sayfa deneyimi sıralama sinyallerinden yalnızca biridir; içeriğin kalitesi ve aramayla ilgisi çok daha belirleyicidir. Ancak yavaş bir sayfa, iyi içeriğin bile değerlendirilmesini zorlaştırır ve dönüşümleri düşürür.

Puanım her ölçümde neden değişiyor?

Laboratuvar testi ağ ve sunucu koşullarından etkilenir. Birkaç ölçüm alıp ortalamaya bakın; kalıcı değerlendirme için saha verisini izleyin.

Mobil puanım neden masaüstünden düşük?

Mobil test, daha yavaş bir cihaz ve ağ koşulu simüle eder. Masaüstünde fark edilmeyen ağır görseller ve JavaScript mobilde belirgin şekilde yavaşlatır.

Hazır temalarla iyi puan almak mümkün mü?

Mümkün, ama temanın ve eklentilerin getirdiği kod yükünü dikkatle yönetmek gerekir. Gereksiz özellikleri kapatmak ve görselleri optimize etmek büyük fark yaratır.

Core Web Vitals sıralamayı ne kadar etkiler?

Google sayfa deneyimini sıralama sistemlerinin değerlendirdiği sinyallerden biri olarak açıklar; ancak alakalı ve faydalı içerik çok daha belirleyicidir. Hız, iyi içeriğin önündeki engelleri kaldırır.

CDN kullanmak puanı yükseltir mi?

Statik dosyaların ziyaretçiye yakın noktadan sunulması sunucu yanıt süresini ve dosya indirme süresini kısaltabilir. Ancak ağır görseller ve gereksiz JavaScript gibi sorunları tek başına çözmez.

Saha verisi görünmüyor, ne yapmalıyım?

Saha verisi için sayfanın yeterli Chrome trafiğine sahip olması gerekir. Veri yoksa laboratuvar ölçümlerine ve Search Console raporuna göre ilerleyin.

Sonuç

Core Web Vitals, sitenizin ziyaretçiye ne hissettirdiğinin ölçüsüdür. Görselleri doğru boyutta ve formatta sunmak, gereksiz JavaScript'i ayıklamak ve yerleşimi sabitlemek çoğu sitede büyük iyileşme sağlar. Sitenizin hızını birlikte ele almak isterseniz web geliştirme hizmetimize göz atabilir veya bizimle iletişime geçebilirsiniz.

Kaynaklar

• web.dev – Web Vitals
• web.dev – Largest Contentful Paint (LCP)
• web.dev – Interaction to Next Paint (INP)
• web.dev – Cumulative Layout Shift (CLS)
• PageSpeed Insights