E-ticaret için Core Web Vitals: Sayfaları değil şablonları düzeltin

Bir online mağazanın elli bin URL’si ama yalnızca bir avuç şablonu olabilir: ana sayfa, kategori, ürün, arama, sepet ve ödeme. Ürün sayfaları Core Web Vitals’tan kaldığında suç neredeyse hiçbir zaman tek bir ürünün değildir. Şablonu düzeltirseniz onun üzerine kurulu her sayfa iyileşir; sayfaları tek tek düzeltmeye kalkarsanız iş hiç bitmez.

Şablonlar neden önemli?

Tüm ürün sayfaları aynı kodu, aynı görsel işleme hattını ve aynı üçüncü taraf scriptleri kullanır; kategori, ana sayfa ve sepet sayfaları için de durum aynıdır. Yavaş bir galeri bileşeni ya da geç yüklenen bir yorum widget’ı tüm ürünleri aynı anda etkiler. Search Console da aynı mantıkla çalışır: Core Web Vitals raporu URL’leri benzer kullanıcı deneyimi sunan sayfalar olarak gruplar ve bir grup, o cihaz türündeki en kötü metriğinin durumunu alır. Başarısız bir ürün URL’leri grubu bir şablon sorunudur; çözümü de şablonda yapılır.

Core Web Vitals Google’ın sıralama sistemlerinde kullanılır; ancak Google, sayfa deneyimi vasat olsa bile her zaman en alakalı içeriği göstermeye çalıştığını söylüyor. Asıl güçlü gerekçe, her yavaş görseli ve her zıplayan düzeni hisseden müşterilerinizdir.

Şablon bazında ölçün

İşe URL kalıplarını şablonlarla eşleştirerek başlayın: ürünler için /p/, kategoriler için /c/ gibi. Sonra her şablonu ayrı ölçün:

• Önce saha verisi. Search Console grupları ve PageSpeed Insights’taki CrUX verisi, gerçek Chrome kullanıcılarının sayfalarınızı son 28 günde, 75. yüzdelik dilimde nasıl deneyimlediğini gösterir.
• Şablon bazında gerçek kullanıcı izleme. LCP, INP ve CLS değerlerini kendi ziyaretçilerinizden toplayın (örneğin Google’ın açık kaynaklı web-vitals kütüphanesiyle) ve her ölçümü sayfa şablonuyla etiketleyin. Böylece hangi şablonun, hangi cihazlarda başarısız olduğunu görürsünüz.
• Hata ayıklamak için laboratuvar testleri. Nedeni bulmak için her şablondan birkaç temsili URL’de Lighthouse çalıştırın, ardından düzeltmeyi saha verisiyle doğrulayın.

Şablona göre p75 LCP, mobil

Ana sayfa2,2 s

Kategori3,1 s

Ürün4,4 s

Arama sonuçları3,4 s

Sepet2,4 s

Böyle bir döküm, site geneli bir ortalamanın yerine önce düzeltilecek tek bir şablon koyar.

LCP: Ana ürün görseli

Ürün sayfalarında en büyük öğe genellikle ana ürün görselidir; kategori sayfalarında ise çoğu zaman ilk sıradaki ürün görselleri ya da bir banner. LCP dört parçaya ayrılır: ilk bayta kadar geçen süre (TTFB), görselin yüklenmeye başlamasından önceki gecikme, görselin yüklenme süresi ve görüntülenmeden önceki gecikme. Ürün şablonları genellikle bu dördünün hepsinde zaman kaybeder.

Core Web Vitals eşikleri

LCP Largest Contentful Paint · yüklenme

İyi≤ 2,5 sİyileştirilmeli2,5–4 sZayıf> 4 s

INP Interaction to Next Paint · yanıt hızı

İyi≤ 200 msİyileştirilmeli200–500 msZayıf> 500 ms

CLS Cumulative Layout Shift · görsel kararlılık

İyi≤ 0,1İyileştirilmeli0,1–0,25Zayıf> 0,25

• Görseli HTML’e koyun. Ana görseli bir galeri scripti ekliyorsa, tarayıcı onu script çalışana kadar bulamaz. İlk görseli sunucuda render edin; görsel yalnızca CSS ya da JavaScript içinden çağrılıyorsa önceden yükleyin (preload).
• Önceliklendirin. Ana görsele fetchpriority="high" ekleyin ve bunu toplamda en fazla bir iki görselle sınırlı tutun; her şeyi önceliklendirmek hiçbir şeyi önceliklendirmemektir.
• Asla lazy-load etmeyin. LCP görselinde loading="lazy" kullanmak onu her zaman geciktirir. Bunun yerine galerinin geri kalanını ve ızgaranın aşağısındaki ürünleri lazy-load edin.
• Doğru boyutlandırın. sizes ile birlikte duyarlı bir srcset kullanın, AVIF ya da WebP sunun ve görselleri müşterilere yakın noktalarda yeniden boyutlandırıp önbelleğe alan bir görsel CDN’i kullanın.
• Sunucu yanıtını düzeltin. Yavaş bir ilk bayt, 2,5 saniyelik bir LCP’yi zorlaştırabilir, hatta imkânsız kılabilir. Kategori ve ürün sayfalarını anonim ziyaretçiler için uçta (edge) önbelleğe alın, yönlendirmeleri yolun dışında tutun ve kişiselleştirilmiş bölümleri sonradan yükleyin.

<img src="/img/kanepe-800.avif"
  srcset="/img/kanepe-480.avif 480w, /img/kanepe-800.avif 800w, /img/kanepe-1200.avif 1200w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  width="800" height="800" fetchpriority="high" alt="Yeşil kadife üçlü kanepe">

INP: Filtreler, sepete ekleme ve üçüncü taraflar

Interaction to Next Paint, sayfanın tıklamalara, dokunmalara ve tuş basışlarına ne kadar hızlı yanıt verdiğini ölçer. E-ticaret şablonları bu etkileşimlerle doludur ve yavaş olanlar tahmin edilebilir:

• Filtreler: herhangi bir geri bildirim göstermeden önce tüm ürün ızgarasını yeniden render eden filtreler. Seçimi hemen gösterin, sonuçları ardından güncelleyin.
• Sepete ekle: ekranda bir şey değişmeden önce ağı bekleyen, sepeti yeniden hesaplayan ve analitik etiketlerini tetikleyen işleyiciler. Önce butonu güncelleyin, gerisini sonra yapın.
• Varyant seçiciler: beden ya da renk seçmenin yalnızca fiyatı, görseli ve stok mesajını değil, tüm sayfayı yeniden render ettiği bileşenler.
• Üçüncü taraflar: yorum widget’ları, canlı destek, kişiselleştirme, A/B test araçları ve etiket yöneticileri ana iş parçacığına (main thread) iş yükler. Bunları şablon bazında denetleyin, kimsenin kullanmadıklarını kaldırın, gerisini sonradan ya da yalnızca gerektiğinde yükleyin.

Asıl suçlu genellikle 50 ms’yi aşan uzun görevlerdir (long tasks): tarayıcının arada yanıt verebilmesi için bunları bölün. Yavaş etkileşimleri bulmak ve düzeltmek üzerine yazımız konuya daha derinlemesine giriyor. Filtrelerin kendine özgü SEO sonuçları da var; bunları filtreli navigasyon yazımızda ele aldık. Ağır istemci taraflı render ise hem yanıt hızına hem de arama motorlarının sayfada gördüklerine zarar verebilir; Googlebot’un gerçekte ne gördüğünü anlattığımız yazıya göz atın.

CLS: Düzeni sabit tutun

• Görsel boyutları: tarayıcının yer ayırabilmesi için her ürün ve banner görseline width ve height (ya da bir en-boy oranı) verin.
• Sonradan eklenen kampanya bantları: sayfa yüklendikten sonra beliren ücretsiz kargo şeritleri ve geri sayımlar her şeyi aşağı iter. Yerlerini önceden ayırın ya da sunucuda render edin.
• Çerez bildirimleri: sayfanın üzerinde açılan bir katman hiçbir şeyi kaydırmaz; içeriğin üstüne eklenen bir bant ise kaydırır.
• Web fontları: geç gelen bir font değişimi ürün adlarını ve fiyatları yeniden akıtır. Önemli fontları önceden yükleyin ve ölçüleri eşleşen yedek fontlar kullanın.
• Yorum widget’ları: geç yüklenen yıldız puanları ve yorum blokları “Sepete ekle” butonunu yerinden oynatır. Bunlar için sabit bir yükseklik ayırın.

Trafiğe ve gelire göre önceliklendirin

Her şablon aynı emeği hak etmez. Şablonları kendi analitiğinizden aldığınız organik trafik ve gelir paylarıyla listeleyin, her birinde hangi metriğin başarısız olduğunu işaretleyin ve ikisinin kesiştiği yerden başlayın; bu genellikle ürün ve kategori sayfalarıdır. Ardından düzeltmeleri etki ve efora göre sıralayın.

Şablon düzeltmeleri: Etki ve efor

Etki →

Bu sprintte yapınProje olarak planlayınDiğer işlerle birleştirinŞimdilik bekletinHero’da lazy-load yokGörsele fetchpriorityYorumlara yer ayırCanlı desteği geciktirUçta önbelleklemeYeni varyant seçiciA/B aracını değiştirİkon fontlarını azalt

Efor →

Ardından kazanımları koruyun. Her şablon için bir performans bütçesi belirleyin (örneğin azami JavaScript boyutu, üçüncü taraf etiketler için bir üst sınır ve ana görsel için bir ağırlık limiti) ve bir sürümün bu bütçeyi sessizce aşamaması için build sürecinizde kontrol edin. Gerçek kullanıcı izlemeyi açık tutun ve her sürümden sonra gerilemeler için uyarı kurun. Saha verisi kayan 28 günlük bir dönemi kapsar; bu yüzden bir düzeltmeyi Search Console’da değerlendirmeden önce yaklaşık dört hafta bekleyin.

E-ticaret SEO ve web tasarım ve geliştirme ekiplerimiz bu işi birlikte yürütür; e-ticarette organik gelir yaklaşımımız ise bunun daha geniş bir planda nereye oturduğunu gösterir.

---

Mağazanızı hangi şablonun geride tuttuğunu öğrenmek ister misiniz? Ücretsiz SEO analizi isteyin: analiz, gerçek kullanıcı LCP, INP ve CLS değerlerini ve olası sorunların nedenlerini kapsıyor.