Çoğu satıcı, arama sonuçlarında geride kalmasını içerik eksikliğine bağlar. Daha çok ürün açıklaması yazar, blog üretir, başlıklara anahtar kelime sıkıştırır. Bunlar yanlış değil ama çoğu zaman eksik teşhis. Çünkü aynı kelimede senden önde çıkan rakibinin metni senden daha iyi olmayabilir; onun sayfası mobil cihazda 1,9 saniyede boyanıyor, senin sayfan 4,6 saniyede boyanıyordur. Arama motoru bu farkı tahmin etmiyor, gerçek ziyaretçilerin tarayıcılarından topladığı veriyle biliyor.
Core Web Vitals, tam olarak bu farkı sayıya çeviren üç ölçüm kümesi: en büyük içerik boyaması, sonraki boyamayla etkileşim ve toplam düzen kayması. Kulağa teknik geliyor ama işletme tarafındaki karşılığı çok somut: bir e-pin satış yazılımı bu üç sayıda kötüyse, hem sıralamada hem sepete ekleme oranında kaybediyorsun. Bu yazıda üç ölçümü tek tek açıp, bir dijital ürün satış scriptinde hangi müdahalenin gerçekten iğneyi oynattığını sıraya dizeceğim.
Laboratuvar Skorunun Seni Neden Yanılttığını Biliyor musun?
Panelinde bir hız testi çalıştırıp 92 puan görmek rahatlatıcıdır. Ama o puan, senin bilgisayarından, senin bağlantından, tek bir ölçümle alınmış bir simülasyon. Arama motorunun kullandığı veri farklı: son 28 günde siteni gezen gerçek kullanıcıların cihazlarından toplanan alan verisi. İçinde beş yıllık orta segment telefonlar, zayıf mobil şebekeler, arka planda on sekme açık tarayıcılar var.
Bu yüzden doğru iş akışı şudur: karar vermek için alan verisine bak, hangi değişikliğin işe yaradığını anlamak için laboratuvar testini kullan. İkisini karıştırırsan aylarca yanlış yerde kürek çekersin. Laboratuvar testi hipotez üretir, alan verisi karar verir. Search Console'un Sayfa Deneyimi raporu bu alan verisini sana ücretsiz açıyor; oradan başlamayan her hız çalışması tahmine dayanır.
Bir de örnekleme sorunu var. Az trafikli sayfalar için alan verisi oluşmaz; o durumda benzer şablonları tek bir grup olarak değerlendirmen gerekir. Kategori şablonun yavaşsa, o şablonu kullanan üç yüz sayfa birlikte yavaştır.
LCP: Sayfanın En Büyük Parçası Neden Bu Kadar Geç Geliyor?
En büyük içerik boyaması, ziyaretçinin ekranında görünen en büyük öğenin ne zaman boyandığını ölçer. E-pin sitelerinde bu öğe neredeyse her zaman ya hero banner'ı ya da ürün detay sayfasındaki ana görseldir. Yani LCP, pratikte "o tek görsel ne zaman geldi" sorusunun cevabıdır.
Gecikmenin dört klasik sebebi var. Birincisi sunucu yanıt süresi: veritabanı sorguları optimize değilse, tarayıcı ilk baytı beklerken zaman akar. İkincisi engelleyici kaynaklar: head içinde senkron yüklenen betikler ve yazı tipleri boyamayı erteler. Üçüncüsü görselin kendisi; önceki yazıda anlattığım boyut disiplini burada doğrudan LCP'ye dönüşür. Dördüncüsü de keşif gecikmesi: görsel CSS arka planı olarak tanımlanmışsa ya da JavaScript ile sonradan ekleniyorsa, tarayıcı onu çok geç fark eder.
Müdahale sırası şöyle olmalı: hero görselini HTML içinde gerçek bir img etiketiyle ver, ona fetchpriority="high" ekle ve kesinlikle gecikmeli yükleme uygulama. Yazı tiplerini font-display: swap ile sun ve yalnızca kullandığın ağırlıkları yükle. Sunucu tarafında kategori ve ürün sorgularını önbelleğe al. Bu dört adım, çoğu e-pin scriptinde LCP'yi bir buçuk iki saniye aşağı çeker.
| Ölçüm | Ne ölçüyor | İyi | Geliştirilmeli | E-pin sitelerindeki baş sebep |
|---|---|---|---|---|
| LCP | En büyük öğenin boyanma anı | < 2,5 sn | 2,5 - 4,0 sn | Sıkıştırılmamış hero görseli |
| INP | Etkileşim sonrası yanıt gecikmesi | < 200 ms | 200 - 500 ms | Ağır üçüncü taraf betikleri |
| CLS | Beklenmeyen düzen kayması | < 0,1 | 0,1 - 0,25 | Boyutsuz görsel ve sonradan gelen banner |
| TTFB | İlk baytın gelme süresi | < 0,8 sn | 0,8 - 1,8 sn | Önbelleklenmemiş sorgular |
| FCP | İlk içeriğin boyanması | < 1,8 sn | 1,8 - 3,0 sn | Engelleyici CSS ve yazı tipi |
INP: Müşteri Butona Bastı, Peki Sayfa Ne Zaman Cevap Verdi?
INP, ziyaretçinin bir tıklamasından sonra ekranda değişiklik görmesine kadar geçen süreyi ölçer. E-pin satışında en kritik anlar burada: kupon kodu girme, adet artırma, ödeme yöntemi seçme, sepete ekleme. Bu etkileşimler yavaşsa müşteri butona iki kez basar, sonra üç kez, sonra sayfayı yeniler ve sipariş kaybolur.
Suçlu neredeyse her zaman ana iş parçacığının tıkanmasıdır. Canlı destek widget'ı, üç ayrı analitik betiği, iki piksel, bir yorum sistemi ve bir sosyal kanıt bildirimi aynı anda yüklendiğinde tarayıcının tek iş parçacığı dolar. Sen butona tıklarsın, tarayıcı önce sıradaki işleri bitirir. Çözüm, üçüncü taraf listesini acımasızca budamak ve kalanları ertelemekle başlar.
Kod tarafında da iki alışkanlık işe yarar: uzun süren işleri küçük parçalara bölmek ve hemen görünmesi gerekmeyen her şeyi etkileşimden sonra yüklemek. Örneğin yorum bölümünü ziyaretçi aşağı kaydırana kadar hiç yüklememek, INP'yi tek hamlede düzelten bir karardır.
Denetlenen e-pin sitelerinde INP gecikmesinin kaynakları
- Üçüncü taraf betikleri 44%
- Kendi tema JavaScript'i 26%
- Yeniden düzen ve boyama maliyeti 18%
- Sunucu bekleyen istekler 12%
CLS: Ziyaretçi Yanlış Butona Basıyorsa Suç Onun Değil
Düzen kayması, sayfa yüklenirken içeriğin yer değiştirmesidir. Ziyaretçi "Satın Al" butonuna uzanır, tam o anda üstte bir kampanya şeridi belirir, düzen aşağı kayar ve tıklama başka yere iner. Bu, ölçülebilir bir kullanıcı deneyimi kazası ve doğrudan sıralamaya etki ediyor.
Üç ana sebebi ve üç net çözümü var. Boyutu belirtilmemiş görseller: her img etiketine genişlik ve yükseklik ver, tarayıcı yeri baştan ayırsın. Sonradan enjekte edilen banner ve bildirimler: onlara CSS ile sabit yükseklikte bir yer ayır, boş dursa bile. Geç yüklenen yazı tipleri: yedek yazı tipini ölçü olarak yakın seçip metrik uyumu ayarla, aksi halde metin bloğu yazı tipi geldiğinde sıçrar.
Özellikle sosyal kanıt bildirimleri ve çerez şeritleri konusunda dikkatli ol. Bunlar dönüşüme yardım etmek için konulur ama düzenin içine hesapsız girdiklerinde tam tersini yapar. Sabit konumlu, akışın dışında duran bir yerleşim tercih et.
Hangi Müdahale Ne Kadar Getiriyor? Öncelik Sıralaması
Yapılacaklar listesi uzun olduğunda hiçbiri yapılmaz. Bu yüzden etkiye göre sıralamak gerekir. Aşağıdaki tabloyu bir denetim listesi gibi kullan: üstten aşağı in, her satırı tamamladıktan sonra alan verisinin güncellenmesi için iki hafta bekle, sonra bir sonrakine geç.
| Müdahale | Etkilediği ölçüm | Beklenen kazanç | Zorluk | Sıra |
|---|---|---|---|---|
| Hero görselini küçült ve öncelik ver | LCP | 0,8 - 1,6 sn | Kolay | 1 |
| Kullanılmayan üçüncü taraf betiklerini kaldır | INP | 80 - 220 ms | Kolay | 2 |
| Tüm görsellere boyut niteliği ekle | CLS | 0,05 - 0,15 | Kolay | 3 |
| Kategori sorgularını önbelleğe al | TTFB, LCP | 0,3 - 0,7 sn | Orta | 4 |
| Yazı tiplerini yerelleştir ve budama uygula | FCP, CLS | 0,2 - 0,5 sn | Orta | 5 |
| Canlı destek widget'ını etkileşimde yükle | INP | 60 - 180 ms | Orta | 6 |
| Kritik CSS'i ayır, kalanını ertele | FCP, LCP | 0,2 - 0,6 sn | Zor | 7 |
| Uzun görevleri parçalara böl | INP | 40 - 120 ms | Zor | 8 |
E-pin sitelerinde yüzlerce sayfa aynı şablonu paylaşır. Kategori şablonunda yaptığın tek bir iyileştirme, tüm kategorilerin alan verisini birlikte yukarı taşır. Tek sayfa üzerinde uğraşmak, aynı emeğin yüzde birini geri döndürür.
Bu İşi Sürdürülebilir Kılan Şey Ne?
Hız çalışmasının en büyük tuzağı, bir defa yapılıp bırakılmasıdır. Üç ay sonra pazarlama yeni bir piksel ekler, tedarikçi yeni bir widget ister, tema güncellenir ve kazandığın saniyeler geri gider. Bu yüzden ölçümü bir alışkanlığa çevirmen gerekiyor: ayda bir Search Console raporunu aç, üç ölçümü not et, yeni eklenen her betiği hız bütçesine karşı sorgula.
İkinci sürdürülebilirlik unsuru, altyapının kendisi. Kullandığın epin yazılım temelde şişmiş bir mimari üzerine kuruluysa, üzerine yaptığın her iyileştirme yama olarak kalır. Sayfa başına sorgu sayısı, varsayılan olarak yüklenen betik ağırlığı ve şablonların boyut disiplini; bunlar yazılım seçimiyle belirlenen kalemler. Pinova'nın özellik dökümünde bu tarafa özellikle bakmanı öneririm.
Hız bütçesi baştan kurulmuş bir altyapıyla başla
Pinova'da şablonlar boyut nitelikleri, öncelik işaretleri ve erteleme kurallarıyla birlikte gelir. Sen kampanya kurmaya odaklanırken üç ölçüm arka planda korunur.
Core Web Vitals gerçekten sıralama etkeni mi?
Evet, ama tek başına belirleyici değil. İçerik uygunluğu ve otorite hâlâ ağırlıklı. Bu ölçümler, yakın rekabette eşitliği bozan etken olarak çalışır; aynı kalitede iki sayfadan hızlı olanı öne geçer ve dönüşüm tarafında da kazanır.
Skorum 100 olmalı mı?
Hayır. Hedef mükemmel puan değil, üç ölçümün de "iyi" eşiğinin altında kalması. 100 puan peşinde koşmak genellikle dönüşümü artıran öğeleri sökmeye kadar gider ve zarar eder.
Değişiklikten sonra sonucu ne zaman görürüm?
Laboratuvar testinde hemen, alan verisinde 28 günlük pencere kaydıkça kademeli olarak. Genelde net değişimi üçüncü haftada görmeye başlarsın, tam etkiyi bir ayda alırsın.
Cloudflare gibi bir katman bu işi tek başına çözer mi?
Kısmen. TTFB ve dağıtım tarafında ciddi katkı verir ama ana iş parçacığını tıkayan betikleri, boyutsuz görselleri ve kayan düzeni düzeltmez. Önce sayfayı hafiflet, sonra önüne dağıtım katmanı koy.
Üç ölçüm, aslında tek bir soruyu farklı açılardan soruyor: müşterin senin sitende beklemek zorunda mı kalıyor? Cevabı kendi gözünle test etmek istersen canlı demo üzerinde bir kategori sayfası açıp tarayıcının performans sekmesini kaydet; şablonun ne kadar yük taşıdığını doğrudan görürsün. Paketleri karşılaştırmak istersen fiyat bölümü ve sipariş adımı hazır bekliyor.