Core Web Vitals ve PageSpeed 100: Hızlı Web Sitesinin Teknik Rehberi

Bir web sitesinin hızı hem kullanıcı deneyiminin hem de SEO'nun sessiz kahramanıdır. Yavaş bir site en iyi içeriği bile okunmadan terk ettirir, reklam bütçesini boşa harcatır ve mobilde formların doldurulmasını zorlaştırır.

Bu rehberde Core Web Vitals'ı temelden anlatıyorum: metrikler ne ölçer, Google nasıl değerlendirir, PageSpeed skoru ile farkı ne? Ardından her metrik için teşhis ve çözüm yollarını, WordPress ve hazır e-ticaret altyapılarına özel önerileri ve bu sitenin altyapısında ölçtüğüm gerçek sonuçları paylaşıyorum.

Core Web Vitals nedir?

Core Web Vitals, Google'ın bir sayfanın yüklenme hızı, etkileşime yanıt verme ve görsel kararlılık deneyimini ölçen üç temel metriğidir. Bu metrikler Google'ın sayfa deneyimi sinyallerinin bir parçasıdır.

Google nasıl değerlendirir?

Bu üç nokta, sonuçları yorumlarken en çok karıştırılan konular:

• 75. yüzdelik: Bir sayfanın "iyi" sayılması için ziyaretlerin en az %75'inde eşiğin altında kalması gerekir. Yani ortalama değil, yavaş kullanıcılarınızın deneyimi belirleyicidir.
• Mobil ve masaüstü ayrı: Masaüstünde her şey yeşil olabilir, mobilde kırmızı. Türkiye'de trafiğin büyük kısmı mobilden geldiği için önce mobile bakın.
• 28 günlük pencere: Saha verisi, Chrome Kullanıcı Deneyimi Raporu'ndan (CrUX) gelir ve son 28 günün kayan ortalamasıdır. Bugün yaptığınız iyileştirme raporlara kademeli olarak yansır.

Yeterli trafiği olmayan sayfalar için CrUX verisi oluşmaz. Bu durumda Search Console benzer URL gruplarının verisini veya sitenin genel verisini kullanır, PageSpeed Insights ise "veri yok" der.

PageSpeed skoru ile Core Web Vitals aynı şey mi?

Hayır, ve bu fark önemli. PageSpeed Insights iki tür veri gösterir:

Lighthouse performans skoru beş metriğin ağırlıklı ortalamasıdır: Total Blocking Time (%30), LCP (%25), CLS (%25), First Contentful Paint (%10) ve Speed Index (%10). Laboratuvarda INP ölçülemediği için yerine onunla ilişkili olan TBT kullanılır.

Yani 100 skor almak güzel bir hedef, ama asıl önemli olan gerçek kullanıcılarınızın deneyimi. Laboratuvarda 100 alıp sahada kalan siteler de var: ağır bir canlı sohbet widget'ı, test sırasında yüklenmeyen ama gerçek kullanıcıda açılan bir çerez bannerı, yavaş mobil ağlar.

Core Web Vitals sıralamayı ne kadar etkiler?

Dürüst cevap: sınırlı ama gerçek. Google, sayfa deneyiminin sıralama sistemlerinde kullanıldığını ama alaka düzeyinin her zaman önce geldiğini açıkça belirtiyor. Hızlı ama soruyu cevaplamayan bir sayfa, yavaş ama mükemmel cevap veren bir sayfayı geçemez. Benzer kalitede sayfalar arasında ise hız fark yaratabilir.

Hızın asıl etkisi çoğu zaman sıralamadan çok dönüşümde görülür. Formun daha hızlı açılması, butonun dokunur dokunmaz tepki vermesi ve sayfanın kaymaması doğrudan daha fazla teklif talebi demektir.

LCP'yi iyileştirmek

LCP öğesi genellikle sayfanın üst kısmındaki büyük başlık, kapak görseli veya ürün fotoğrafıdır. PageSpeed Insights raporunda "Largest Contentful Paint öğesi" bölümü hangi öğe olduğunu gösterir.

LCP'yi dört parçaya ayırarak teşhis edin

Google'ın önerdiği yöntem, LCP süresini dört alt parçaya bölmektir. Hangi parça uzunsa çözüm oradadır:

Web.dev'in genel önerisi TTFB'nin 800 ms'nin altında olmasıdır. Paylaşımlı hostingde önbelleksiz çalışan bir WordPress sitesinde TTFB tek başına 1–2 saniyeyi bulabilir; bu durumda diğer optimizasyonlar LCP'yi yeşile taşımaya yetmez.

LCP için kontrol listesi

1. Sayfaları önbellekten sunun. Bu sitede her sayfa ilk ziyaretten sonra tam sayfa önbelleğine alınıyor ve milisaniyeler içinde sunuluyor.
2. LCP görselini asla lazy-load etmeyin. Ekranın üst kısmındaki görsele loading="lazy" vermek en sık gördüğüm hatalardan biri. Bunun yerine fetchpriority="high" kullanın.
3. Render'ı engelleyen CSS'i azaltın. Kritik CSS'i sayfaya gömün veya tek, küçük bir dosyada tutun.
4. Fontları kendi sunucunuzdan verin ve önceden yükleyin. Kritik font için <link rel="preload"> ve font-display: swap kullanın.
5. Kaydırıcıdan (slider) kaçının. Ana sayfa kaydırıcıları genellikle büyük görseller ve JavaScript yükler; LCP öğesi de çoğu zaman JS çalışana kadar görünmez.

INP'yi iyileştirmek

INP sorunlarının neredeyse tamamı ana iş parçacığını meşgul eden JavaScript'ten kaynaklanır. Kullanıcı dokunduğunda tarayıcı başka bir işle uğraşıyorsa yanıt gecikir.

1. JavaScript'i azaltın. Kullanmadığınız eklentileri, kaydırıcıları ve üçüncü taraf scriptleri kaldırın. Her eklenen "küçük" script toplam yükü artırır.
2. Uzun görevleri bölün. 50 ms'den uzun süren JavaScript görevleri "uzun görev" sayılır. Ağır işleri küçük parçalara ayırın ve aralarında tarayıcıya nefes aldırın (ör. scheduler.yield() veya setTimeout ile).
3. Üçüncü taraf scriptleri erteleyin. Analitik, sohbet widget'ları, reklam pikselleri ve harita gömmeleri sayfa yüklendikten veya kullanıcı etkileşime geçtikten sonra yüklenebilir.
4. Önce görsel geri bildirim verin. Tıklanan butonun hemen tepki vermesini sağlayın (renk değişimi, yükleniyor durumu); ağır işi ondan sonra yapın.
5. Büyük DOM'dan kaçının. Binlerce öğe içeren sayfalarda her etkileşim daha pahalıdır. Uzun listeleri sayfalayın veya content-visibility: auto kullanın.

CLS'yi iyileştirmek

1. Görsellere ve videolara boyut verin. Her <img> etiketinde width ve height niteliklerini belirtin veya CSS'te aspect-ratio kullanın.
2. Dinamik içerik için alan ayırın. Reklam, banner, çerez bildirimi ve gömülü içeriklere sabit bir yükseklik verin. Çerez bannerını içeriği itmeden, üstte sabit katman olarak gösterin.
3. Font kaymasını önleyin. Yedek fontun ölçülerini web fontuna yaklaştırın (size-adjust, ascent-override) veya fontu önceden yükleyin.
4. Animasyonlarda yalnızca transform ve opacity kullanın. top, height, margin gibi özellikleri canlandırmak hem kayma hem de performans sorunu yaratır.
5. bfcache'i bozmayın. Geri/ileri tuşuyla anında açılan sayfalar CLS ve LCP açısından da avantajlıdır; unload olay dinleyicileri bu önbelleği devre dışı bırakır.

Platforma göre öncelikler

WordPress

• Sayfa oluşturucu yükü: Ağır sayfa oluşturucular her sayfaya büyük CSS ve JS paketleri ekler. Mümkünse yerleşik blok editörü ve hafif bir tema kullanın.
• Eklenti envanteri: Her eklentinin ön yüze script ekleyip eklemediğini kontrol edin. Kullanılmayanları silin, yalnızca devre dışı bırakmak yetmez.
• Önbellek: Sunucu seviyesinde (LiteSpeed Cache, Nginx FastCGI cache gibi) veya bir önbellek eklentisiyle tam sayfa önbellek kurun.
• Görseller: WebP dönüşümü ve otomatik srcset sağlayan bir çözüm kullanın; medya kütüphanesine 4000 px fotoğraf yüklemeyin.

Hazır e-ticaret altyapıları

• Tema seçiminde demo sitenin mobil PageSpeed sonucunu kontrol edin.
• Uygulama/eklenti mağazasından eklenen her uygulamanın (yorum, sohbet, pop-up, sadakat) sayfaya script eklediğini unutmayın.
• Ürün görsellerini platformun önerdiği boyutlarda yükleyin; kategori sayfalarında lazy-load'ın yalnızca ekran dışı görsellere uygulandığından emin olun.

Özel yazılım

• Sunucu tarafında render (HTML'in hazır gelmesi) hem hız hem de yapay zekâ tarayıcıları için avantajlıdır. Detaylar: ChatGPT aramasında görünmek.
• Tam sayfa önbellek, OPcache, HTTP/2 veya HTTP/3 ve Brotli/Gzip sıkıştırma temel gereksinimlerdir.

Bu sitede neler yaptım ve sonuç ne oldu?

Bu siteyi baştan hız hedefiyle kurdum. Uyguladıklarım:

• Tüm CSS minify edilip sayfaya gömülü; render'ı engelleyen harici CSS isteği yok.
• Fontlar kendi sunucumda barındırılıyor, Türkçe karakterler için ayrı küçük bir alt küme kullanılıyor ve önceden yükleniyor.
• Yüklenen görseller otomatik olarak WebP'ye çevriliyor ve 480/960/1600 px boyutlarında srcset ile sunuluyor.
• Sayfalar tam sayfa önbellekten sunuluyor.
• Ana sayfadaki kaydırmaya bağlı animasyonlar yalnızca transform ve opacity kullanıyor; "hareketi azalt" tercihine saygı gösteriyor.
• Yerleşik analitik çerezsiz ve sayfa yüklendikten sonra küçük bir istekle çalışıyor; Google Analytics açıldığında da sayfa yüklendikten birkaç saniye sonra yükleniyor.

Sonuç (Lighthouse, mobil, laboratuvar): Blog yazılarında performans 95–100, animasyonlu ana sayfada 93–99 (test makinesine göre değişiyor); erişilebilirlik, en iyi uygulamalar ve SEO 100; LCP 1,4–1,8 sn, CLS 0.

Hangi araçlarla ölçmeli?

Ölçüm yaparken laboratuvar testini en az üç kez çalıştırın ve ortancaya bakın; tek bir test sunucu veya ağ dalgalanmasından etkilenebilir.

Sık yapılan hatalar

1. Yalnızca masaüstüne bakmak: Asıl sorun neredeyse her zaman mobildedir.
2. Skor için kullanıcıyı feda etmek: Gerekli bir sohbet widget'ını veya formu sırf skor için kaldırmak yerine yüklenme zamanını erteleyin.
3. LCP görselini lazy-load etmek: En hızlı yüklenmesi gereken görseli en son yükletmek.
4. Optimizasyon eklentisi üstüne eklenti kurmak: Birbiriyle çakışan önbellek ve küçültme eklentileri siteyi bozabilir.
5. Bir kez düzeltip unutmak: Yeni eklenen bir pop-up, kampanya bannerı veya pazarlama scripti tüm emeği sıfırlayabilir. Ayda bir kontrol edin.

Sonuç

PageSpeed'de 100 almak bir hedef değil, iyi kurulmuş bir altyapının doğal sonucudur. Önce saha verisine bakın; sorun varsa LCP'yi alt parçalarına ayırarak teşhis edin, INP için JavaScript yükünü, CLS için boyutsuz öğeleri hedefleyin. Yeni bir web sitesi planlıyorsanız hızı baştan gereksinim listesine koyun. Diğer kriterler için Web sitesi yaptırırken dikkat edilmesi gerekenler rehberime göz atabilirsiniz. Hız odaklı web siteleri için floopping ile çalışabilirsiniz.