Search Console'da Core Web Vitals raporunu açan çoğu satıcının ilk tepkisi aynıdır: "demek ki sunucu yetersiz, paketi yükseltelim". Paket yükselir, fatura artar, rapor bir ay sonra hâlâ aynı kırmızı çubuğu gösterir. Çünkü bu üç metrik sunucunun gücünü değil, kullanıcının ekranında olup biten şeyi ölçer. Sunucu bir saniyede cevap verse bile tarayıcı o cevabı çizerken tıkanıyorsa rapor düzelmez.
Burada anlatacağım şey, bir e-pin satış scripti üzerinde LCP, INP ve CLS'in gerçekte neyi ölçtüğü ve her birini hangi sırayla düzelteceğin. Sıra önemli, çünkü bu üç metrik birbirini etkiler; yanlış yerden başlarsan iki gün çalışıp hiçbir şeyi kıpırdatamazsın. Kullandığın e-pin yazılımı hangisi olursa olsun mantık değişmez.
Rapor neden panelde ölçtüğünden farklı çıkıyor?
İki ayrı dünya var. Tarayıcıdaki hız testi laboratuvar verisi üretir: tek cihaz, tek bağlantı, tek an. Search Console ise son 28 günün gerçek kullanıcı verisini gösterir; İstanbul'da fiber bağlantıdan girenle taşrada eski bir Android telefonla girenin ortalamasını değil, yüzde 75'lik dilimini alır. Yani sitenin "iyi" sayılması için ziyaretlerin dörtte üçünün eşiği geçmesi gerekir.
Bunu kavradığın an strateji değişir. Ortalamayı iyileştirmeye değil, en kötü dilimi yukarı çekmeye odaklanırsın. Pratikte bu, mobil ve yavaş cihaz senaryosunu birincil test ortamı yapmak demektir. Kendi masaüstü tarayıcında sayfa bir saniyede açılıyor olabilir; rapor onu hiç görmüyor.
LCP: sayfanın en büyük parçası neden geç geliyor?
LCP, ekranın üst kısmındaki en büyük görsel ya da metin bloğunun ne zaman çizildiğini ölçer. E-pin vitrinlerinde bu neredeyse her zaman ana sayfa banner'ı veya ilk ürün kartının kapağıdır. Geç gelmesinin üç klasik nedeni vardır: dosyanın büyük olması, geç keşfedilmesi ve önünde render'ı bloklayan bir kaynağın durması.
Sırayla çöz. Önce o tek görseli küçült ve modern formata çevir. Sonra sayfanın head bölümüne o görsel için preload ekle ve etiketine fetchpriority="high" ver, böylece tarayıcı onu JavaScript'i beklemeden çekmeye başlar. En son, banner'ı bir kaydırıcı içinde gösteriyorsan ilk slaytı statik HTML olarak bas; kaydırıcı kütüphanesi yüklenmeden önce görsel ekranda olsun. LCP'yi çoğu zaman tek bir dosya belirler, tüm sayfa değil.
| Metrik | E-pin sitesindeki tipik sebep | İlk müdahale | Beklenen kazanç |
|---|---|---|---|
| LCP | Ağır ana sayfa banner'ı | Format + preload + fetchpriority | 1,2-2,0 sn |
| LCP | Bloklayan üçüncü taraf CSS | Yerel barındır, kritik CSS gömme | 0,4-0,8 sn |
| INP | Tek dosyada toplanmış büyük JS | Sayfa bazlı parçalama | 80-160 ms |
| INP | Canlı destek ve analiz betikleri | Etkileşime kadar geciktir | 50-120 ms |
| CLS | Boyutsuz ürün görselleri | width-height niteliği | 0,05-0,15 |
| CLS | Sonradan düşen duyuru şeridi | Yer ayır veya alta al | 0,03-0,10 |
INP: kullanıcı tıklıyor, senin script düşünüyor
INP eski FID'in yerini aldı ve çok daha acımasız: sadece ilk tıklamayı değil, oturum boyunca her etkileşimin gecikmesini ölçüp en kötülerini raporlar. "Sepete ekle" butonuna basan kullanıcı 400 milisaniye boyunca hiçbir tepki görmüyorsa metrik çöker. Sebep neredeyse her zaman ana iş parçacığının başka bir işle meşgul olmasıdır.
Üç hamle işe yarar. Birincisi, her sayfaya tüm JavaScript'i yüklemeyi bırakmak: ödeme sayfasının betiği kategori sayfasında yüklenmesin. İkincisi, analiz, ısı haritası, sohbet ve benzeri üçüncü taraf kodlarını ilk kaydırma ya da ilk dokunuşa kadar ertelemek. Üçüncüsü, butonun kendisine anında görsel geri bildirim vermek; arka planda işlem sürerken butonu "ekleniyor" durumuna geçirmek algılanan gecikmeyi ölçülebilir biçimde düşürür.
Mobil e-pin vitrininde ana iş parçacığı meşguliyeti
- Üçüncü taraf betikler 41%
- Script kendi JS paketi 27%
- Stil hesaplama ve düzen 19%
- Çizim ve diğer 13%
CLS: en sinsi metrik, en kolay düzelen
Sayfa açılıyor, kullanıcı "Satın Al" butonuna uzanıyor, tam o anda üstteki kampanya şeridi yükleniyor ve her şey iki santim aşağı kayıyor. Kullanıcı yanlış yere basıyor. CLS tam olarak bunu ölçer ve dönüşüme verdiği zarar metrik puanından çok daha büyüktür.
Çözümü sıkıcı derecede basit: sonradan gelen her şeye baştan yer ayır. Görsellere width ve height yaz, reklam ve duyuru alanlarına sabit yükseklikte kapsayıcı ver, web fontlarını font-display: swap ile yükle ama yedek fontu benzer ölçüde seç. Kurun sonradan enjekte ettiği çerez bildirimi varsa onu sayfanın akışına değil üstüne bindir. CLS, bir öğleden sonrada sıfıra yaklaştırılabilecek tek metriktir.
Aynı gün beş iyileştirmeyi birlikte yayınlarsan hangisinin işe yaradığını asla bilemezsin. Her müdahaleyi ayrı yayınla ve 48 saat gerçek kullanıcı verisi biriksin; bu disiplin, ikinci ayda neyi geri alacağını bilmeni sağlar.
Peki bunun arama sıralamasına gerçek etkisi ne?
Dürüst cevap: Core Web Vitals tek başına seni rakibinin önüne geçirmez. İçerik ve alan otoritesi eşitken devreye giren bir eleme kriteridir. Ama e-pin işinde asıl kazanç sıralamada değil, dönüşümde ortaya çıkar. Ödeme adımında ekranı kayan, butonu geç tepki veren bir sitede terk oranı görünür biçimde yükselir. Yani bu üç metriği düzeltirken aslında ödeme hunini tamir ediyorsun.
Bu yüzden ölçmeyi de sadece Search Console'a bırakma. Kendi analiz kurulumunda LCP ve INP değerlerini sayfa tipine göre kaydet: ana sayfa, kategori, ürün detayı, ödeme. Ödeme sayfasının INP'si kötüyse bu, kategori sayfasının LCP'sinden çok daha acildir. Hangi dijital ürün satış yazılımı üzerinde çalıştığından bağımsız olarak önceliği paranın döndüğü sayfa belirler.
Bir haftada ne kadar yol alınır?
Gerçekçi bir takvim şöyle: birinci gün ölçüm ve öncelik listesi, ikinci gün LCP görseli, üçüncü gün CLS yer ayırma işleri, dördüncü ve beşinci gün JavaScript parçalama ve üçüncü taraf erteleme, altıncı gün ödeme akışının ayrı testi, yedinci gün doğrulama. Rapor yeşile dönmesi 28 günlük pencere yüzünden zaman alır ama laboratuvar ölçümlerinden ilk günden itibaren doğru yolda olup olmadığını görürsün.
Bu işi her yeni özellik eklediğinde baştan yapmak istemiyorsan, performansı sonradan eklenen bir yama değil altyapının varsayılanı yapan bir kurulum seçmek mantıklı. Pinova'da hangi hız kararlarının varsayılan geldiğini özellikler bölümünde, paket farklarını fiyat tablosunda karşılaştırabilirsin.
| Kontrol adımı | Ölçüm aracı | Geçer değer | Durum |
|---|---|---|---|
| Mobil ana sayfa LCP | Gerçek kullanıcı verisi | < 2,5 sn | Tamam / Bekliyor |
| LCP görseli preload edildi | Sayfa kaynağı | Mevcut | Tamam / Bekliyor |
| Ödeme sayfası INP | Alan verisi, sayfa bazlı | < 200 ms | Tamam / Bekliyor |
| Üçüncü taraf betik sayısı | Network listesi | En fazla 3 | Tamam / Bekliyor |
| Görsellerde boyut niteliği | Şablon taraması | %100 | Tamam / Bekliyor |
| Toplam CLS | Alan verisi | < 0,1 | Tamam / Bekliyor |
| Sayfa bazlı JS paketi | Derleme çıktısı | Ayrılmış | Tamam / Bekliyor |
Hız optimizasyonunu her güncellemede baştan yapmak zorunda kalma
Pinova'da sayfa bazlı kaynak yükleme, boyut ayrılmış görsel alanları ve ertelenen üçüncü taraf entegrasyonları hazır gelir; sen ürün ve fiyatla uğraşırsın.
Search Console raporu ne kadar sürede güncellenir?
Rapor 28 günlük kayan pencere kullanır. Bir düzeltmenin etkisini kısmen bir hafta içinde, tamamen dört haftada görürsün. Bu arada laboratuvar testleri yönü doğru kontrol etmek için yeterlidir.
Trafiğim az olduğu için rapor veri göstermiyor, ne yapmalıyım?
Yeterli örnek toplanmayan sitelerde alan verisi görünmez. Bu durumda kendi analiz kurulumuna metrik kaydı ekle ve mobil kısıtlamalı laboratuvar testlerini referans al; eşikler aynı kalır.
Hosting paketini yükseltmek metrikleri düzeltir mi?
Sunucu yanıt süresi çok kötüyse sınırlı bir katkı sağlar. Ama LCP'nin büyük kısmı dosya boyutu ve yükleme sırasıyla, INP ve CLS ise tamamen tarayıcı tarafıyla ilgilidir; bunları paket yükseltmesi çözmez.
Canlı destek widget'ını tamamen kaldırmam mı gerekir?
Hayır. Kaldırmak yerine yüklenmesini ilk dokunuş veya üç saniye gecikmeye bağla. Böylece hem destek kanalını korursun hem de ilk yükleme sırasında ana iş parçacığını meşgul etmez.
Core Web Vitals'ı bir SEO ödevi olarak değil, ödeme hunisinin sağlık kontrolü olarak görmeye başladığında iş çok daha somutlaşıyor. Bu üç metriğin varsayılan olarak iyi geldiği bir kurulumu incelemek istersen canlı demo üzerinde kategori ve ödeme sayfalarını mobil kısıtlamayla açıp kendi sitenle yan yana ölçmeni öneririm.