Core Web Vitals dönüşüme gerçekten etki eder mi?

Core Web Vitals tartışması iki uçta sıkışmış durumda. Bir tarafta "Google sıralama sinyali dedi, hepsini yeşile çekmeliyiz" diyen ekipler var; diğer tarafta "biz zaten iyi dönüşüyoruz, hız bahane" diyenler. İkisi de sahada yanlış karar üretiyor. Doğru soru şu: hangi metrik, hangi eşikte, hangi trafik segmentinde para kaybettiriyor?

Bu yazı, üç metriğin dönüşümle ilişkisini eşik bazında ele alıyor ve sınırlı geliştirici saatiyle nereye dokunulacağını sıralıyor.

Hız ile dönüşüm arasındaki ilişki doğrusal değil, eşikli

En yaygın hata, hızı sürekli bir kazanç eğrisi gibi düşünmek. "Her 100 ms şu kadar dönüşüm" tarzı genellemeler tekil vaka çalışmalarından çıkmış rakamlar; kendi sitenize taşıdığınızda çoğu zaman tutmuyor. Sahada gördüğümüz davranış daha çok basamaklı: belirli bir eşiğe kadar kullanıcı bekliyor, o eşiği geçtiğinizde davranış aniden değişiyor.

Pratik ayrım şöyle kurulabilir:

• 2,5 saniye altı LCP: kullanıcı sayfayı "hızlı" olarak algılıyor. Buradan 2,0 saniyeye inmek ölçülebilir dönüşüm farkı üretmiyor. Yatırım yapıyorsanız başka yere yapın.
• 2,5–4 saniye arası: gri bölge. Mobil trafikte ve reklamdan gelen soğuk kullanıcıda bounce artışı görülüyor, ama organik ve marka trafiğinde etki sınırlı kalıyor.
• 4 saniye üstü: burası kanamanın başladığı yer. Özellikle ücretli trafikte, sayfa açılmadan geri dönen kullanıcı oranı belirgin biçimde yükseliyor. Tıklama başına ödediğiniz için bu doğrudan yakılmış bütçe.
• 6 saniye üstü: mobil kullanıcının önemli bir kısmı sayfayı hiç görmüyor. Analytics'te bu kullanıcılar çoğu zaman oturum olarak bile düzgün kaydedilmiyor, dolayısıyla kaybı olduğundan küçük görüyorsunuz.

Bu yüzden ilk iş, ortalamalarla değil yüzdeliklerle bakmak. Ortalama LCP'niz 2,8 saniye olabilir ama mobilde 75. yüzdelik 6,4 saniyeyse, trafiğinizin dörtte biri hiç şansı olmayan bir deneyim yaşıyor. Core Web Vitals'ın 75. yüzdelik üzerinden ölçülmesinin nedeni de bu.

En pahalı metrik LCP değil, CLS ve INP olabilir

LCP konuşulmaya en uygun metrik, çünkü ölçmesi kolay ve raporlarda güzel görünüyor. Ama dönüşüm hunisinin dibinde asıl hasarı diğer ikisi veriyor.

CLS: yanlış tıklama üreten metrik

Layout kayması, kullanıcının niyeti ile eylemi arasına giren tek metrik. Kullanıcı "Sepete Ekle"ye basmak üzereyken üstte geç yüklenen bir banner düzeni aşağı itiyor ve parmak başka bir yere değiyor. Sonuç: yanlış sayfaya gitme, geri dönme, bazen tamamen çıkma.

CLS'in dönüşüme etkisini anlamanın en hızlı yolu metriğe değil davranışa bakmak. Bir ısı haritası veya oturum kaydı aracında, ürün sayfasında "rage click" ve hızlı geri dönüş oranı yükseldiyse, çoğu zaman altında kayma problemi vardır. Özellikle checkout adımlarında 0,1'in üzerindeki CLS, form doldurma sırasında alan atlamaya ve yanlış onaya yol açıyor.

INP: butona bastı, hiçbir şey olmadı

INP, FID'in yerini aldığından beri daha dürüst bir metrik: artık sadece ilk etkileşimi değil, oturum boyunca en kötü etkileşim gecikmesini ölçüyor. Bu, e-ticaret ve form ağırlıklı siteler için kritik, çünkü ilk tıklama genelde hızlıdır; sorun varyant seçme, filtre uygulama, sepete ekleme gibi JavaScript yoğun etkileşimlerde çıkıyor.

Kullanıcı butona basıp 400 ms boyunca hiçbir görsel geri bildirim almazsa ne yapar? Tekrar basar. Bazı kurulumlarda bu çift sipariş, bazılarında ise formun sıfırlanması demek. INP'nin 200 ms eşiğini aşan sitelerde, sepet terk oranı ile mobil cihaz sınıfı arasında güçlü bir korelasyon görmek olağan: orta segment Android cihazlarda dönüşüm, aynı sitede iPhone'un yarısına düşebiliyor.

Hangi düzeltmeler düşük bütçeyle en çok kazandırıyor?

Sınırlı geliştirici saatiniz varsa sıra önemlidir. Aşağıdaki liste, maliyet–etki oranına göre sıralanmış; ilk üçü çoğu projede birkaç günlük iş.

1. Hero görselini disipline edin. Ana görseli WebP veya AVIF'e çevirin, gerçek gösterim boyutunda sunun, `fetchpriority="high"` verin ve lazy-load'dan çıkarın. LCP'si 5 saniyenin üzerindeki sitelerde tek başına 1–2 saniye kazandırdığı çok oluyor, çünkü LCP elemanı genellikle bu görseldir.
2. Üçüncü parti script envanteri çıkarın. Chat widget'ı, üç farklı ısı haritası, iki eski remarketing pikseli, kullanılmayan A/B test aracı. Her birinin ne zaman eklendiğini ve şu an kimin kullandığını yazın. Kullanılmayanları silin, kalanları etkileşim sonrası veya `defer` ile yükleyin. Bu, INP'ye en hızlı etki eden müdahale.
3. Yer rezervasyonu yapın. Görsel ve iframe'lere `width`/`height` ya da `aspect-ratio` verin; banner, kupon çubuğu ve çerez bildirimi için sabit yükseklik ayırın. CLS'i sıfıra yakın tutmanın maliyeti neredeyse sadece dikkat.
4. Font yükleme stratejisini düzeltin. `font-display: swap`, kritik fontlara `preload`, kullanılmayan ağırlıkların kaldırılması. Hem LCP hem de algılanan hızda fark yaratır.
5. Ana iş parçacığını boşaltın. Sepete ekleme, filtreleme gibi etkileşimlerde uzun görevleri parçalayın; tıklama anında anında görsel geri bildirim (buton durumu, spinner) verin. Geri bildirim, gerçek gecikmeyi çözmese bile ikinci tıklamayı önler.
6. Sunucu yanıt süresine bakın. TTFB 800 ms'nin üzerindeyse görsel optimizasyonu bir yere kadar gider. Önbellekleme katmanı, CDN ve veritabanı sorguları burada devreye girer — maliyeti en yüksek kalem, o yüzden en sona.

Dikkat: bu listenin hiçbir maddesi "tema değiştirelim" ya da "siteyi baştan yazalım" değil. Baştan yazma kararı Core Web Vitals gerekçesiyle alınırsa neredeyse her zaman yanlış karardır; performans, mimari kararların sonucu olarak düzelir, sebebi olarak değil.

Etkiyi nasıl kanıtlarsınız?

Performans işinin en zayıf tarafı ölçümlemesi. PageSpeed Insights puanınız 42'den 78'e çıktı, ciro değişmedi — bu senaryo çok yaygın, çünkü ölçülen şeyle kazanılan şey aynı değil.

Daha savunulabilir bir yaklaşım şu:

• Lab değil field verisi kullanın. Lighthouse tek bir simülasyon; Chrome UX Report ve kendi RUM verisi gerçek kullanıcıyı gösterir. Karar field verisiyle alınır.
• Öncesi–sonrası yerine segment karşılaştırması kurun. Aynı dönemde hızlı ve yavaş yüzdelikteki kullanıcıların dönüşüm oranını karşılaştırın. Mevsimsellik ve kampanya etkisini böyle izole edebilirsiniz.
• Tek bir metriği tek bir sayfa tipinde düzeltin. Önce sadece ürün detay sayfasının LCP'sini iyileştirin, iki hafta bekleyin, sonra checkout'a geçin. Hepsini aynı hafta değiştirirseniz hangisinin çalıştığını asla bilemezsiniz.
• Gelir metriğine bağlayın. Dönüşüm oranı yerine oturum başına gelir bakın. Hız iyileştirmeleri bazen dönüşüm oranını değiştirmeden sepet büyüklüğünü artırır, çünkü kullanıcı daha fazla ürün gezmeye vakit ayırır.

Sıralama etkisi mi, dönüşüm etkisi mi?

Core Web Vitals bir sıralama sinyali, ama zayıf bir sinyal. İçerik uyumu ve otorite eşitken devreye giren bir eşik faktörü gibi davranıyor: kötüyseniz cezalandırıyor, mükemmelseniz ödüllendirmiyor. Yeşile geçmek için harcanan üçüncü haftanın SEO getirisi genellikle sıfıra yakın.

Dönüşüm tarafı farklı. Orada eşiği geçtiğinizde etki hemen ve doğrudan: sayfa açılıyor, buton çalışıyor, form kaymıyor. Yani performans çalışmasını SEO bütçesinden değil, dönüşüm optimizasyonu bütçesinden yürütmek daha doğru bir muhasebe. Ücretli trafiğe ayda ciddi bütçe harcayıp mobil LCP'si 6 saniye olan bir açılış sayfasına yönlendirmek, en pahalı performans hatasıdır — çünkü orada her kaybedilen kullanıcının bir fiyat etiketi var.

Kısa özet: her metriği yeşile boyamak bir hedef değil. Trafiğinizin en kötü çeyreğinin hangi eşiğin altında kaldığını bulun, o çeyreğe hangi kanalın para ödediğini görün, işe oradan başlayın.