Search Console'da "iyileştirilmesi gerekiyor" uyarısı alan KOBİ sitelerinin çoğunda sorun sunucu gücü değil; sıraya sokulmamış dosyalar, ölçüsü verilmemiş görseller ve gereğinden fazla üçüncü parti script. Aşağıdakiler, paylaşımlı hosting üzerindeki sıradan bir PHP/MySQL sitesinde bile uygulanabilecek, etkisi ölçülebilir düzeltmeler.

Önce hangi veriye baktığınızı bilin

İki ayrı ölçüm dünyası var ve bunları karıştırmak en pahalı hata. Saha verisi, gerçek ziyaretçilerin tarayıcılarından toplanır ve Search Console'daki Core Web Vitals raporunu besler. Laboratuvar verisi ise PageSpeed Insights veya Lighthouse'un tek seferlik simülasyonudur. Google'ın değerlendirmesine giren saha verisidir; laboratuvar verisi ise "neden böyle" sorusunu çözmek için kullanılır. Not: INP, 2024 Mart'ında FID'nin yerini aldı; eski rehberlerde hâlâ FID görürseniz o tavsiyeler güncelliğini yitirmiştir.

Saha verisi tipik olarak 28 günlük kayan pencereyle güncellenir. Yani bugün yaptığınız düzeltmenin rapora tam yansıması haftalar sürer. Düzeltmenin ertesi günü "değişmedi" deyip geri almayın; laboratuvar ölçümünüz düzeldiyse yoldasınız demektir.

MetrikİyiGeliştirilmeliKötü
LCP (en büyük içeriğin boyanması)2,5 sn ve altı2,5 - 4 sn4 sn üstü
INP (etkileşimden sonraki tepki)200 ms ve altı200 - 500 ms500 ms üstü
CLS (düzen kayması)0,1 ve altı0,1 - 0,250,25 üstü

Bu eşikler ziyaretçilerinizin en yavaş dilimine göre değil, %75'lik dilimine göre hesaplanır. Yani sayfanızın dört ziyaretçiden üçünde eşiği geçmesi gerekir; ortalamaya bakmak sizi yanıltır.

LCP: ana görsel ekrana ne zaman geliyor?

LCP genellikle ürün fotoğrafı, hero görseli ya da büyük bir başlık bloğudur. Süreyi iki parça hâlinde düşünün: sunucunun ilk baytı gönderme süresi ve tarayıcının o görseli indirip çizme süresi.

Sunucu tarafı

  • TTFB'yi 600 ms altına çekin. Paylaşımlı hostingde en sık suçlu, her sayfa isteğinde çalışan onlarca sorgu ve kapalı OPcache'tir. PHP 8.x ve OPcache'in açık olduğundan emin olun.
  • Ana sayfa ve kategori sorgularını önbellekleyin. Değişmeyen menü, kategori ağacı ve "çok satanlar" bloklarını dosya tabanlı bir önbelleğe alın. 5 dakikalık bir ömür bile, sorgu sayısını sayfa başına onlarca adetten birkaç adede indirir; kaç sorgu attığınızı ölçmeden başlamayın.
  • Sıkıştırmayı ve tarayıcı önbelleğini açın. cPanel'de gzip/brotli ve statik dosyalar için uzun süreli Cache-Control çoğu panelde birkaç tıkla etkinleşir.

Görsel ve yazı tipi tarafı

  • Hero görselini WebP'ye çevirin ve gerçek ekran genişliğine göre boyutlandırın. 3000 piksel genişliğindeki bir JPEG'i 1200 piksellik alana sığdırmak, telefonda saniyeler kaybettirir.
  • Ekranın ilk görünen bölgesindeki görsele asla loading="lazy" vermeyin. Tersine, ona fetchpriority="high" verin.
  • Yazı tiplerinde font-display: swap kullanın ve iki aileden fazlasını yüklemeyin. Her ek ağırlık (300, 400, 600, 700) ayrı bir dosyadır.
  • Slider kullanıyorsanız yalnızca ilk kareyi hemen yükleyin, kalan kareleri geciktirin. Beş görseli birden indiren bir slider, LCP görselinin sırasını beklettiği için süreyi doğrudan uzatır.

INP: tıklamadan sonra ne kadar bekletiyorsunuz?

INP, ziyaretçinin tıklama, dokunma veya tuş vuruşundan sonra ekranda görünür bir değişiklik olana kadar geçen süreyi ölçer. Yani "sepete ekle" butonuna basıldığında ekranın donması doğrudan bu metriğe yazılır. Sorun neredeyse her zaman tarayıcının ana iş parçacığını meşgul eden JavaScript'tir.

  • Üçüncü parti script sayımını yapın. Canlı destek, ısı haritası, iki ayrı analitik, pop-up aracı ve reklam pikseli aynı sayfada duruyorsa INP kurtarılamaz. Gerçekten kullanılmayanları kaldırın.
  • Kritik olmayan tüm scriptlere defer verin ve canlı destek bileşenini ilk kaydırmadan ya da 3 saniyeden sonra yükleyin.
  • Filtre ve arama alanlarında her tuş vuruşunda sorgu atmayın. 250-300 ms'lik bir gecikme (debounce) hem sunucuyu hem INP'yi rahatlatır.
  • Butona basınca önce görsel geri bildirim verin. Buton "Ekleniyor..." durumuna geçsin, ağ isteği arkadan gitsin. Kullanıcının algıladığı bekleyiş kısalır, metrik düzelir.

CLS: sayfa neden zıplıyor?

Düzen kayması, ziyaretçi okumaya başladıktan sonra içeriğin yer değiştirmesidir. En sinir bozucu hâli, kullanıcı tam butona basacakken üstte bir bandın açılıp butonu aşağı itmesidir.

  • Her görsele ve iframe'e genişlik ve yükseklik değeri verin. Tarayıcı yeri baştan ayırsın.
  • Çerez bandı, KVKK aydınlatma kutusu ve "ücretsiz kargo" şeridi için sabit yükseklikli bir alan ayırın; sonradan içeriği iterek açılmasın.
  • Sonradan gelen yorum, kampanya sayacı veya öneri bloklarına minimum yükseklik tanımlayın.
  • Özel yazı tipiniz yüklendiğinde satır sayısı değişiyorsa, yedek yazı tipini boyut olarak yakın seçin.

Sık yapılan hatalar

  • Tek bir puanın peşine düşmek. PageSpeed'de 100 görmek amaç değil; üç metriğin de eşik altına inmesi amaç.
  • Ana sayfayı ölçüp bitirmek. Trafiğin çoğu ürün ve kategori sayfalarına gelir; asıl orayı ölçün.
  • Masaüstünde test etmek. Analytics'te kendi cihaz kırılımınıza bakın; çoğu KOBİ sitesinde ağırlık mobilde olur ve mobil skorlar masaüstünden belirgin şekilde düşüktür. Ölçümü mobil sekmede yapın.
  • "Hepsini birden yapalım" demek. Aynı gün beş değişiklik yaparsanız hangisinin işe yaradığını asla bilemezsiniz.
  • Eklenti üstüne eklenti kurmak. Performans eklentisi eklemek, çoğu zaman yeni bir JavaScript yükü eklemektir.

Uygulama sırası

  1. Search Console'daki Core Web Vitals raporundan en çok URL barındıran hata grubunu seçin; temsili bir URL alın.
  2. O URL'yi PageSpeed Insights'ta mobil olarak ölçün ve en büyük üç kalemi not edin (genellikle görsel boyutu, script süresi, TTFB).
  3. Önce görselleri düzeltin: WebP, doğru boyut, ilk görselde öncelik. Görsel kaynaklı bir LCP'de en hızlı kazanç genelde buradan gelir; öncesi ve sonrası laboratuvar ölçümünü not edip kendi kazancınızı sayıyla görün.
  4. Sonra script temizliği yapın; kullanılmayan araçları silin, kalanları geciktirin.
  5. Değişikliği yayına alın, en az 4 hafta bekleyin (28 günlük pencerenin tamamen yenilenmesi için) ve saha verisinin yönünü kontrol edin. Ancak ondan sonra bir sonraki kaleme geçin.