Kısa cevap: Core Web Vitals, bir sayfanın hızlı olup olmadığını üç somut ölçüye indirger: içeriğin ne zaman göründüğü, sayfanın etkileşime ne zaman hazır olduğu ve görüntünün yüklenirken kayıp kaymadığı. Asıl mesele sıralama değil, dönüşümdür.
- Düzen kayması, en çok ölçü verilmemiş görsellerden ve sonradan gelen yazı tiplerinden doğar.
- Lab ve saha ölçümü farklı şeyler söyler; kararı saha verisiyle verin.
- Tek tek sayfa değil şablon düzeltin; kazanç yüzlerce sayfada birden gelir.
Core Web Vitals, bir sayfanın “hızlı” olup olmadığını üç somut ölçüye indirger. Bu ölçüler soyut bir puan değil, kullanıcının fiilen yaşadığı üç deneyimi sayar: içerik ne zaman göründü, göründükten sonra zıpladı mı, dokununca ne kadar sürede tepki verdi. Bu yazıda üç metriği, e-ticarete etkisini ve iyileştirme sırasını anlatıyoruz.
Core Web Vitals nedir?
LCP — En büyük içerik boyaması
Sayfanın en büyük görsel öğesinin (genellikle ana görsel ya da başlık bloğu) ekranda görünmesine kadar geçen süre. Kullanıcı açısından “sayfa açıldı” hissinin oluştuğu andır.
LCP’yi uzatan tipik sebepler: yavaş sunucu yanıtı, büyük ve optimize edilmemiş ana görsel, render engelleyen stil dosyaları ve ana görselin tembel yüklemeye bırakılması. Son madde sık yapılan bir hatadır: ilk ekrandaki görsele tembel yükleme uygulamak, tam da ölçülen öğeyi geciktirir.
CLS — Kümülatif düzen kayması
Sayfa yüklenirken içeriğin ne kadar zıpladığını ölçer. Okumaya başladığınız satırın kayması ya da basmak üzere olduğunuz butonun yer değiştirmesi bu metrikte görünür.
Kritik bir ayrım: CLS öğelerin hareketini sayar, belgenin yüksekliğini değil. Bu yüzden “kabın yüksekliğini sabitleyelim” türü çözümler işe yaramaz; kabın boyu sabit kalsa da içindeki öğeler kayar. Gerçek çözümler ölçü bildirmek, yer ayırmak ve içeriği geç gelen bir iskeletle değiştirmemektir.
INP — Sonraki boyamayla etkileşim
Kullanıcı bir şeye dokunduğunda sayfanın görsel olarak tepki vermesine kadar geçen süre. Butona basıp hiçbir şey olmadığında hissedilen o boşluk tam olarak budur.
INP’yi bozan şey genellikle ağır JavaScript’tir: tarayıcının ana iş parçacığı meşgulken dokunuşu işleyemez. Filtreleme, arama önerisi ve sepete ekleme gibi etkileşimler e-ticarette en çok INP sorunu çıkaran yerlerdir.
Kaymanın en sık görülen üç sebebi
- Ölçüsü bildirilmemiş görseller: görsel indiğinde altındaki her şeyi aşağı iter. Çözüm, genişlik ve yükseklik bildirmek ya da kutusunu CSS ile sabitlemek.
- Geç yüklenen yazı tipi: yedek yazı tipiyle çizilen metin, asıl yazı tipi geldiğinde farklı genişlikte olur ve satır sayısı değişir. Ölçüsü eşitlenmiş bir yedek yazı tipi tanımlamak bu kaymayı büyük ölçüde kapatır.
- Sonradan eklenen bloklar: çerez bandı, kampanya duyurusu, reklam alanı. Bunlar için baştan yer ayrılmadığında, geldikleri anda bütün sayfayı iterler.
Bir dördüncüsü de veriyle çalışan sayfalarda görülür: sayfa önce kısa bir “yükleniyor” iskeletiyle çizilir, veri gelince gerçek içerikle değişir. İskelet ile gerçek içeriğin yüksekliği farklıysa aradaki fark tek seferde büyük bir kayma üretir.
Asıl mesele: dönüşüm
Core Web Vitals bir sıralama faktörüdür, ama etkisi içerik uyumunun yanında sınırlıdır. Asıl önemi başka yerdedir: bu üç metrik, kullanıcının sayfayı terk etme sebeplerini ölçer.
Yavaş açılan sayfa beklenmez. Zıplayan sayfada yanlışlıkla farklı bir ürüne tıklanır. Tepki vermeyen butona iki kez basılır ve iki ürün sepete girer. Bunların hepsi doğrudan gelir kaybıdır ve hiçbiri arama sıralamasıyla ilgili değildir.
Ölçüm: lab mı, saha mı?
İki tür ölçüm vardır ve ikisi de gereklidir:
- Laboratuvar ölçümü: kontrollü koşullarda, tek bir cihaz ve bağlantı profiliyle. Tekrarlanabilir olduğu için değişikliğin etkisini ölçmeye uygundur.
- Saha verisi: gerçek ziyaretçilerin cihazlarından toplanan veri. Gerçeği söyler ama gecikmelidir ve tek bir değişikliğin etkisini ayırt etmeye uygun değildir.
Doğru kullanım şudur: neyin sorun olduğunu saha verisinden öğrenin, düzeltmeyi laboratuvar ölçümüyle doğrulayın, sonucu tekrar sahada teyit edin. Laboratuvar ölçümü için hız testi aracını kullanabilirsiniz.
Ölçüm kendisi de yanılabilir
Deneyimde sık karşılaşılan bir tuzak: ölçüm betiği sayfayı sorgularken tarayıcıyı yeniden düzenlemeye zorlar ve ölçtüğü şeyi değiştirir. Aynı sayfa, ölçüm yöntemine göre farklı sonuç verebilir.
Bu yüzden bir bulguyu düzeltmeye başlamadan önce iki kez ölçün ve mümkünse iki farklı yöntemle doğrulayın. “Sayfa değil ölçüm bozuk” ihtimali, sanılandan çok daha sık gerçekleşir — ve yanlış teşhisle harcanan gün, ölçümü tekrarlamak için harcanan beş dakikadan pahalıdır.
İyileştirme sırası
- Sunucu yanıt süresi: her şeyin önündedir. Yavaşsa diğer iyileştirmeler ölçülemez.
- Ana görsel: ilk ekrandaki en büyük görseli küçültün, formatını değiştirin ve tembel yüklemeden çıkarın.
- Düzen kayması: görsellere ölçü verin, geç gelen bloklara yer ayırın, yazı tipi yedeğini ölçüsü eşitlenmiş hâle getirin.
- Render engelleyen kaynaklar: kritik olmayan stil ve script’leri erteleyin.
- JavaScript ağırlığı: kullanılmayan kodu çıkarın; INP sorunlarının kaynağı buradadır.
- Üçüncü taraf betikler: her biri için “bu olmasa ne kaybederiz?” sorusunu sorun.
Teşhis sırasının ayrıntısını sitem neden yavaş açılıyor yazısında, görsel tarafını görsel SEO yazısında anlattık.
Mobil öncelikli bakın
Masaüstünde iyi görünen bir sayfa mobilde tamamen farklı davranır: işlemci yavaştır, bağlantı değişkendir, ekran dardır. Değerlendirmeyi mobil ölçümle yapın; masaüstü sonucu yalnız bir kontrol noktasıdır.
Mobilde en sık görülen fark JavaScript tarafındadır. Aynı miktarda kod, mobil işlemcide kat kat uzun sürede işlenir — bu yüzden INP sorunları neredeyse her zaman önce mobilde görünür.
Tek tek sayfa değil, şablon düzeltin
E-ticaret sitelerinde yüzlerce ürün sayfası aynı şablondan üretilir. Bir sayfada bulduğunuz kayma sorunu, muhtemelen bütün ürün sayfalarında vardır. Bu yüzden düzeltmeyi sayfa düzeyinde değil şablon düzeyinde yapın: bir kez düzeltilen görsel ölçüsü kuralı, katalogun tamamını birden iyileştirir.
Aynı mantıkla, ölçümü de şablon bazlı yapın: ana sayfa, kategori sayfası, ürün sayfası, sepet ve blog yazısı. Beş şablonu ölçmek, beş yüz sayfayı ölçmekle aynı bilgiyi verir.
Ne zaman durmalı?
Hız çalışmasının getirisi doğrusal değildir. Çok yavaş bir sayfayı hızlandırmak dönüşümde belirgin fark yaratır; zaten hızlı bir sayfayı biraz daha hızlandırmanın etkisi ölçülemez.
Pratik durma noktası: üç metrik de “iyi” bandına girdiyse ve mobilde de öyleyse, aynı emeği ürün sayfası kalitesine, içeriğe ya da müşteri deneyimine kaydırın. Mükemmel bir puan uğruna haftalar harcamak, çoğu işletme için en pahalı optimizasyondur.
Sık sorulan sorular
Core Web Vitals sıralamayı ne kadar etkiler?
Bir sıralama sinyalidir ama içerik uygunluğunun yerine geçmez; kötü bir içeriği hızlandırmak sıralamayı kurtarmaz. Asıl karşılığı kullanıcı tarafındadır: yavaş açılan ve yüklenirken zıplayan bir sayfa, sıralamadan bağımsız olarak dönüşüm kaybettirir.
Düzen kayması nasıl önlenir?
Üç şeyle: her görsele ve videoya genişlik-yükseklik bilgisi vermek, yazı tipi yüklenirken ölçüsü eşitlenmiş bir yedek yüz kullanmak ve içeriğin üstüne sonradan eleman eklememek. Kayma çoğu zaman tek bir şablon düzeltmesiyle toplu olarak çözülür.
Nereden başlamalıyım?
Önce ölçün, sonra en yaygın şablondan başlayın. Ürün sayfası şablonundaki bir düzeltme, katalogunuzdaki tüm ürünlere aynı anda yansır. Tek tek sayfa optimize etmek, aynı emeğin çok küçük bir kısmını geri verir.
Özet
Core Web Vitals üç somut deneyimi ölçer: içerik ne zaman göründü (LCP), göründükten sonra zıpladı mı (CLS), dokununca ne kadar sürede tepki verdi (INP). Sıralamadaki etkisinden çok dönüşümdeki etkisi için önemlidir. Sorunu saha verisinden bulun, düzeltmeyi laboratuvarda doğrulayın, ölçümün kendisine de şüpheyle yaklaşın ve düzeltmeyi sayfa değil şablon düzeyinde yapın. Üç metrik de iyi banda girdiğinde durun.
