Hız Puanından İş Sonucuna: Core Web Vitals İçin Ticari Yol Haritası

1. Üç Metrik, Üç Farklı Kullanıcı Sorunu

LCP, ilk ekranda ana içeriğin ne zaman görünür hâle geldiğini yaklaşık olarak anlatır. Bir ürün fotoğrafı, büyük başlık veya kahraman görseli LCP öğesi olabilir. Sorun yalnızca dosya boyutu değildir; sunucu yanıtı, kaynağın HTML içinde ne kadar erken keşfedildiği, önceliği ve render gecikmesi birlikte etkilidir. Kullanıcı açısından soru basittir: Geldiğim sayfanın ana vaadini ne zaman görebiliyorum?

INP, kullanıcının tıklama, dokunma veya klavye etkileşimlerine sayfanın ne kadar tutarlı yanıt verdiğini değerlendirir. Ağır JavaScript, uzun ana iş parçacığı görevleri, büyük DOM ve pahalı yeniden render işlemleri butonun çalışmadığı hissini yaratabilir. İlk yükleme hızlı olsa bile ürün filtresinin donması veya form alanının geç tepki vermesi karar akışını keser.

CLS, görünür öğelerin beklenmedik biçimde yer değiştirmesini ölçer. Boyutu tanımlanmayan görseller, sonradan eklenen banner, değişen font veya rezerve edilmemiş reklam alanı kullanıcının yanlış bağlantıya basmasına yol açabilir. Bu üç metrik birbirinin yerine geçmez. Bir sayfa iyi LCP'ye sahipken kötü INP yaşayabilir; tek toplam puan kök nedeni saklayabilir.

2. Alan Verisi ile Laboratuvar Testini Karıştırmayın

Core Web Vitals öncelikle alan metrikleridir: gerçek ziyaretlerin cihaz, ağ ve etkileşim koşullarını yansıtır. Chrome User Experience Report, PageSpeed Insights ve Search Console geniş ölçekli alan görünümü sağlayabilir. Laboratuvar araçları ise geliştirme sırasında tekrarlanabilir test ve teşhis için değerlidir. Kullanıcı etkileşimi olmayan simülasyon INP'yi doğrudan ölçemez; Lighthouse'taki Total Blocking Time yalnızca teşhise yardımcı bir vekildir.web.dev — Web Vitals

Alan verisi size sorunun gerçek kullanıcıda var olup olmadığını, laboratuvar ise nedenini araştırmak için nereden başlayacağınızı söyler. PageSpeed Insights'ta URL düzeyi veri yoksa origin verisi görülebilir; bunu tek sayfanın performansıymış gibi yorumlamayın. Trafiği az yeni sayfalarda yeterli alan örneği oluşmayabilir. Bu durumda benzer şablonların verisi, sentetik testler ve kendi gerçek kullanıcı ölçümünüz birlikte kullanılabilir.

Cihaz, ağ, önbellek, oturum ve izin koşullarını kaydedin. En iyi tek skoru değil tekrarlı ölçüm dağılımını raporlayıp üretim alan verisiyle doğrulayın.

3. Teknik Kuyruğu Ticari Etkiyle Sıralayın

Her kırmızı URL aynı değerde değildir. Önce kullanıcı yolculuğundaki rolü belirleyin: trafik giriş sayfası mı, ürün keşif şablonu mu, fiyatlandırma mı, form mu, sepet mi? Ardından etkilenen trafik payını, metriğin şiddetini, kullanıcı segmentini ve düzeltme maliyetini değerlendirin. Yüksek trafik alan ancak karar akışından uzak bir içerik ile az trafik alan fakat tüm ödemelerin geçtiği sayfa farklı öncelik taşıyabilir.

Erişim, iş kritikliği, deneyim şiddeti, uygulama güveni ve maliyet için ortak bir puanlama kullanın. Bu kesin bilim değildir; ekiplerin aynı varsayımları konuşmasını sağlar. Puanı veri ve gözlemle destekleyin.

Performans işini özellik geliştirmeden ayrı bir temizlik dönemi gibi görmeyin. Tasarım sistemi, görsel servisi, analitik etiketleri ve bileşen mimarisi tekrar tekrar aynı sorunları üretebilir. Kök neden ortak bir bileşendeyse tek düzeltme onlarca URL'yi iyileştirebilir. Bu yüzden şablon ve bileşen düzeyinde gruplama, URL listesinden daha etkili bir teknik plan oluşturur.

4. Metrik Başına Kök Neden Ağacı Kurun

LCP için önce öğeyi doğru tanımlayın. Sorun TTFB ise sunucu, önbellek ve veri erişimi incelenir; kaynak yükleme gecikmesiyse LCP görselinin CSS veya JavaScript arkasında geç keşfedilmesi araştırılır; yükleme süresiyse boyut, format ve CDN; render gecikmesiyse ana iş parçacığı ve stil maliyeti ele alınır. Görseli sıkıştırıp sunucu gecikmesini bırakmak, yalnızca toplamın bir parçasını düzeltir.

INP için yavaş etkileşimi alan verisinde adlandırın: arama kutusu, menü, varyant seçimi, sepet veya form. Etkileşimi giriş gecikmesi, işlem süresi ve bir sonraki çizime kadar bekleme olarak parçalayın. Uzun görevleri bölmek, gereksiz JavaScript'i kaldırmak, pahalı bileşen ağacını küçültmek ve anında görsel geri bildirim vermek seçeneklerdir. Ancak iş mantığını bozmadan gerçek kullanıcı akışında doğrulama gerekir.

CLS için ekran kaydı ve layout shift bölgelerini kullanın. Görsel ve iframe ölçülerini ayırın, dinamik alan için yer rezerve edin, mevcut içeriğin üstüne sonradan banner eklemeyin, font değişimini test edin. Çerez bildirimi veya kişiselleştirme gibi üçüncü taraf bileşenler farklı koşullarda çalıştığından yalnızca temiz test oturumuyla yetinmeyin.

• Metrik sorununu URL yerine şablon ve bileşen bazında grupladık.
• LCP öğesini ve gecikmenin hangi aşamada oluştuğunu belirledik.
• Yavaş INP etkileşimini kullanıcı eylemiyle adlandırdık.
• CLS kaynağını ekran kaydı veya shift bölgeleriyle doğruladık.
• Düzeltmeyi üretim alan verisi ve iş metriğiyle yeniden ölçüyoruz.

5. Örnek Senaryo: Ürün Listeleme Sayfasında Hızı İş Sonucuna Bağlamak

Bu senaryo varsayımsaldır; gerçek müşteri verisi veya performans vaadi değildir. Bir e-ticaret sitesinin mobil kategori sayfalarında LCP hedef dışı, filtre açıldığında INP zayıf olsun. Ekip ilk olarak tüm görselleri yeniden sıkıştırmayı öneriyor. Alan kaydı ise LCP öğesinin kampanya görseli olduğunu, geç keşfedildiğini; filtre gecikmesinin de büyük ürün listesinin her dokunuşta yeniden render edilmesinden kaynaklandığını gösteriyor.

Ekip iki ayrı hipotez kuruyor. LCP için kampanya görselini HTML içinde erken keşfedilebilir yapıyor, doğru responsive boyutu sunuyor ve önceliğini test ediyor. INP için filtre durumunu sadeleştiriyor, uzun görevi parçalıyor ve sonuç sayısını hemen gösteren geri bildirim ekliyor. Değişiklikler aynı deney grubunda rastgele karıştırılmıyor; teknik sürüm notlarıyla aşamalı yayınlanıyor.

Başarı panelinde yalnızca CWV yok. Kategoriye giriş, ürün görüntüleme, filtre kullanımı, sepete ekleme ve hata oranı segmentlere göre izleniyor. Metrik iyileşirken ürün görüntüleme düşerse tasarım davranışı yeniden inceleniyor. Böylece performans çalışması teknik ekibin kapalı puan hedefi olmaktan çıkıp ürün, pazarlama ve gelir ekiplerinin ortak deneyi hâline geliyor.

6. İyileştirmeyi Korumak İçin Performans Bütçesi Koyun

Performans bütçesi; sayfa ağırlığı, JavaScript, kritik istek ve görsel boyutu için sınırlar koyar. Alan hedefini garanti etmez, fakat kötüleşmeyi sürekli entegrasyonda erken yakalar.

Üçüncü taraf betikler ayrı envanter gerektirir. Her etikette iş sahibi, amacı, veri kapsamı, yükleme koşulu ve son kullanım tarihi bulunmalıdır. Bir kampanya bittikten sonra etiket kalıyorsa her kullanıcı sonsuza kadar maliyet öder. Onay yönetimi, canlı destek, kişiselleştirme ve A/B test araçlarını tek tek değil toplam ana iş parçacığı etkisiyle değerlendirin.

Tasarım sistemine performans kuralları ekleyin: medya oranı tanımlı olsun, içerik gerektiğinde yüklensin ve bileşen gereksiz istemci kodu taşımasın. Yeni özelliklere performans kabul kriteri yazın.

7. Yaygın Hatalar ve 30 Günlük Başlangıç Planı

Masaüstü laboratuvar skorunu kullanıcı gerçeği sanmayın; yalnızca ana sayfayı ölçmeyin ve her sorunu görsel sıkıştırmaya indirgemeyin. Core Web Vitals erişilebilirlik, hata oranı ve görev tamamlamanın yerine geçmez.

İlk hafta alan verisini şablon, cihaz ve trafik değeriyle gruplayın. İkinci hafta en yüksek öncelikli iki yolculukta performans profili çıkarın ve kök nedenleri kanıtlayın. Üçüncü hafta düşük riskli düzeltmeleri yayınlayın, daha büyük mimari işleri planlayın. Dördüncü hafta teknik ve iş göstergelerini birlikte değerlendirin; performans bütçelerini CI ve tasarım sürecine ekleyin.

web.dev, önerilen eşiklerin gerçek kullanıcı ziyaretlerinin 75. yüzdelik diliminde değerlendirilmesini ve alan ölçümünde dağılım raporlanmasını öneriyor. Yüksek yüzdelikleri ayrıca izlemek, çok yavaş ağ veya cihaz kullanan segmentleri anlamanıza yardım edebilir. Karar paneliniz ortalamayı değil dağılımı ve şablon kırılımını göstermelidir.web.dev — Core Web Vitals eşiklerinin tanımıweb.dev — Web Vitals

• Mobil ve masaüstü alan verisini ayrı inceliyoruz.
• Kritik kullanıcı yolculuklarını performans önceliğine bağladık.
• Her düzeltmenin teknik hipotezi ve iş göstergesi yazılı.
• Üçüncü taraf betiklerin sahibi ve son kullanım tarihi belli.
• Performans bütçeleri yayın sürecinde otomatik kontrol ediliyor.
• CWV yanında erişilebilirlik, hata ve görev tamamlama ölçülüyor.