Online mağazalar için Core Web Vitals: LCP, INP ve CLS nedir?

LCP, INP ve CLS neyi ölçer, 75. yüzdelikte iyi ve kötü eşikler, laboratuvar ve saha verisi farkı, Shopify ve WooCommerce mağazalarında yaygın düzeltmeler.

FixReports editör ekibi11 dk okuma

Core Web Vitals, gerçek ziyaretçilerin bir sayfayı nasıl deneyimlediğini anlatan üç Google metriğidir: yükleme için Largest Contentful Paint (LCP), yanıt verme hızı için Interaction to Next Paint (INP) ve görsel kararlılık için Cumulative Layout Shift (CLS). Ziyaretlerin en az %75'i "iyi" aralıktaysa sayfa testi geçer: LCP 2,5 saniye içinde, INP 200 milisaniye içinde ve CLS 0,1 veya altında olmalıdır; değerler mobil ve masaüstü için ayrı ayrı ölçülür. Online mağazalarda başarısız sonuçların kaynağı genellikle büyük veya geç yüklenen (lazy load) hero ve ürün görselleri, uygulama ve izleme script'leri, web fontları ve sayfa göründükten sonra içeriği aşağı iten banner'lar ya da yorum widget'larıdır.

Temel noktalar

Core Web Vitals eşik değerleri nelerdir?

Bir sayfa, yüklemelerinin 75. yüzdelik dilimi üç metriğin üçünde de iyi aralığa düştüğünde Core Web Vitals'ı karşılar.

MetrikNeyi ölçerİyiİyileştirilmesi gerekiyorKötü
LCPGörüntü alanındaki (viewport) en büyük görselin, videonun veya metin bloğunun ekrana gelmesine kadar geçen süre2,5 s veya altı2,5 s'nin üzerinde, 4,0 s'ye kadar4,0 s'nin üzerinde
INPBir tıklama, dokunma veya tuşa basmadan sonraki karenin çizilmesine kadar geçen süre200 ms veya altı200 ms'nin üzerinde, 500 ms'ye kadar500 ms'nin üzerinde
CLSGörünür içeriğin beklenmedik biçimde ne kadar kaydığı0,1 veya altı0,1'in üzerinde, 0,25'e kadar0,25'in üzerinde

Eşik değerleri, Ekim 2026 itibarıyla web.dev'in LCP (yeni sekmede açılır), INP (yeni sekmede açılır) ve CLS (yeni sekmede açılır) rehberlerinden alınmıştır.

Değerlendirmenin 75. yüzdelik dilime göre yapılması, sonucun yalnızca en hızlı ziyaretçileri değil ziyaretçilerin çoğunu yansıttığı anlamına gelir; Google ayrıca mobil ve masaüstünü ayrı değerlendirir (yeni sekmede açılır). PageSpeed Insights, üç metriğin üçü de iyi olduğunda sayfayı başarılı sayar; yeterli INP verisi yoksa yalnızca LCP ve CLS'ye göre değerlendirir (PageSpeed Insights belgeleri (yeni sekmede açılır)). Google, kararlı (stable) Core Web Vitals metriklerinin yılda bir defadan sık değişmeyeceğini söylüyor.

Bir mağazada LCP öğesi çoğu zaman hero banner'ı veya ana ürün görselidir; görsellerin nasıl yüklendiğinin bu kadar önemli olmasının nedeni budur.

INP, Mart 2024'te neden FID'nin yerini aldı?

INP, FID'nin yerini aldı, çünkü FID yalnızca ilk etkileşimi ve onun gecikmesinin yalnızca bir kısmını ölçüyordu; INP ise ziyaretin tamamındaki etkileşimlere bakar.

Google, Mayıs 2023'te INP'nin bir Core Web Vitals metriği olacağını duyurdu ve geçiş 12 Mart 2024'te (yeni sekmede açılır) yürürlüğe girdi. FID yalnızca ilk etkileşimi, o da yalnızca giriş gecikmesini raporluyordu; olay işleyicilerinin (event handler) çalışması veya sonucun ekrana çizilmesi için geçen süreyi kapsamıyordu. INP ise ziyaret boyunca tıklamaları, dokunmaları ve tuşa basmaları gözlemler ve aykırı değerleri göz ardı ederek en uzun olanı raporlar; kaydırma ve fareyle üzerine gelme (hover) sayılmaz. CrUX ve PageSpeed Insights API kullanıcılarının geçiş yapmak için 9 Eylül 2024'e kadar süresi vardı (web.dev (yeni sekmede açılır)).

Her etkileşimin üç bölümü vardır: giriş gecikmesi (meşgul script'lerin bitmesini beklemek), işleme süresi (işleyicilerin çalıştırılması) ve sunum gecikmesi (sonraki karenin çizilmesi) (web.dev (yeni sekmede açılır)).

Bir mağazada bu etkileşimler varyant seçici, adet butonları, sepete ekle butonu, yan sepet paneli, filtreler ve menülerdir. Bir sayfa hızlı bir ilk dokunuşla FID'yi geçebilir, ama biri daha sonra filtreleri açtığında yine de yavaş hissettirebilirdi.

Laboratuvar verisi ile saha verisi arasındaki fark nedir?

Laboratuvar verisi sabit koşullar altında yapılan tek bir testten gelir, saha verisi ise zaman içinde gerçek ziyaretçilerden toplanır; Google, neyin önce düzeltileceğine karar vermek için saha verisinin kullanılmasını önerir (web.dev (yeni sekmede açılır)).

Laboratuvar verisiSaha verisi
KaynakSimüle edilmiş tek bir sayfa yüklemesi (Lighthouse, Chrome DevTools, PageSpeed Insights'ın laboratuvar bölümü)Gerçek Chrome ziyaretçileri (Chrome UX Report) veya kendi gerçek kullanıcı izleme (real user monitoring) verileriniz
KoşullarSabit cihaz ve ağ. Lighthouse'un varsayılan mobil testi (yeni sekmede açılır) "Slow 4G" (150 ms gidiş-dönüş süresi, 1,6 Mbps indirme) ve 4x CPU yavaşlatması kullanırZiyaretçilerinizin kullandığı cihazlar, ağlar ve bulundukları konumlar
INPSıradan bir sayfa yüklemesinde ölçülmez. Total Blocking Time (TBT) kabaca yerine geçen bir göstergedirGerçek etkileşimlerden ölçülür
En uygun kullanımHata ayıklama ve bir değişikliği yayına almadan önce kontrol etmeZiyaretçilerin gerçekte ne deneyimlediğini görme

TBT, ana iş parçacığındaki (main thread) her görevin 50 ms'yi aşan kısmını toplar; web.dev ortalama mobil donanımda 200 ms'nin altını önerir, ancak bunun INP'nin yerini tutmadığını söyler (web.dev (yeni sekmede açılır)).

Chrome UX Report'un (CrUX) üç ayrıntısı mağazalar için önemlidir:

  • Günlük olarak güncellenen 28 günlük kayan bir ortalamadır (yeni sekmede açılır).
  • Chrome'un raporlama koşullarını karşılayan kullanıcılar için masaüstü ve Android'deki Chrome'u kapsar. iOS'taki Chrome hariç tutulur; bu nedenle alışverişçilerinin çoğu iPhone kullanan bir mağaza, kitlesinin yalnızca bir kısmından saha verisi görür (metodoloji (yeni sekmede açılır)).
  • Sayfalar ve kaynaklar (origin) yalnızca herkese açık olarak keşfedilebilir ve yeterince popüler olduklarında yer alır; bu nedenle trafiği düşük bir mağazanın yalnızca kaynak düzeyinde verisi olabilir ya da hiç verisi olmayabilir.

Shopify'ın web performansı panosu (yeni sekmede açılır) da gerçek kullanıcılardan alınan LCP, INP ve CLS değerlerini 75. yüzdelik dilimde raporlar, ancak 28 yerine 30 günlük bir dönem üzerinden; bu yüzden CrUX'tan bazı farklılıklar görmeyi bekleyin.

Mağaza sayfalarında LCP'yi ne yavaşlatır?

Mağazalarda LCP genellikle ana görsel çok ağır olduğu, geç keşfedildiği ya da geç yükleme (lazy loading) veya bir animasyonla kasıtlı olarak geciktirildiği için yavaştır.

  • LCP görselini geç yüklemek (lazy load). web.dev bunun asla yapılmamasını söyler (web.dev (yeni sekmede açılır)). web.dev'in WordPress sayfaları üzerindeki analizi, tarayıcının yerel (native) lazy loading özelliğini kullanan sitelerde 75. yüzdelik dilimdeki LCP'nin daha yavaş olduğunu ve ekranın görünen ilk bölümündeki (above the fold) görsellerin geç yüklenmemesinin bu gerilemeyi ortadan kaldırdığını buldu (web.dev (yeni sekmede açılır)).
  • Geç bulunan bir görsel. CSS background-image olarak tanımlanmış ya da bir slider script'iyle eklenmiş bir hero görseli, tarayıcının ilk taradığı HTML'de yer almaz. Shopify, hero içeriği için CSS arka planlarının ve LCP görselinde belirme (fade-in) efektlerinin kullanılmamasını önerir (Shopify (yeni sekmede açılır)).
  • Düşük öncelik. Görseller düzen (layout) tamamlanana kadar düşük öncelikle yüklenir; bu yüzden Shopify LCP görselinde fetchpriority="high" kullanılmasını önerir (Shopify (yeni sekmede açılır)). web.dev, bunu bir veya iki görselden fazlasına uygulamanın yararını azalttığını belirtir (web.dev (yeni sekmede açılır)).
  • Oluşturmayı engelleyen (render-blocking) CSS ve script'ler. <head> içindeki büyük stil dosyaları ve senkron script'ler, görsel geldikten sonra bile sayfanın ekrana gelmesini geciktirir (web.dev (yeni sekmede açılır)).
  • Dosya boyutu ve fontlar. Modern görsel formatları, srcset ve sizes ile bir CDN kullanın. Web fontları için auto veya block dışında bir font-display değeri seçin.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Mağaza sayfalarında INP'yi ne yavaşlatır?

Mağazalarda yavaş INP genellikle ana iş parçacığında çok fazla JavaScript olduğu anlamına gelir; bunun büyük kısmı uygulamalardan, izleme etiketlerinden ve tema özelliklerinden gelir, bu yüzden dokunuşlar beklemek zorunda kalır.

Yorum, canlı sohbet ve analiz script'leri hâlâ çalışırken bir alışverişçi "Sepete ekle"ye dokunursa bu dokunuş bekler. Tüm ürün formunu yeniden oluşturan bir varyant seçici işleme süresini uzatır. Devasa mega menüler ve çok sayıda renk seçeneği (swatch) içeren koleksiyon ızgaraları sunum gecikmesini artırır.

web.dev uzun görevleri bölmeyi ve kontrolü ana iş parçacığına geri vermeyi (yielding), önce ekranı güncelleyip gerisini ertelemeyi ve DOM'u küçük tutmayı önerir (web.dev (yeni sekmede açılır)). Shopify buna mağazalara özgü adımlar ekler: Her uygulamayı, pikseli ve tema script'ini denetleyin, kritik olmayanları erteleyin, özellikleri etkileşim anında yükleyin ve çalışan bir test yokken A/B testi araçlarının titreme önleyici (anti-flicker) kod parçacıklarını kapatın (Shopify (yeni sekmede açılır)).

Ürün ve koleksiyon sayfalarında düzen kaymalarına ne yol açar?

Mağazalarda düzen kaymaları çoğunlukla sayfa ilk kez ekrana geldikten sonra beliren veya boyutu değişen içerikten kaynaklanır: boyutları belirtilmemiş görseller, duyuru ve çerez çubukları, yorum widget'ları, uygulama blokları ve font değişimleri.

web.dev yaygın nedenleri boyutları bilinmeyen medya, mevcut içeriğin üstüne eklenen içerik, kendini yeniden boyutlandıran üçüncü taraf widget'lar ve yedek fonttan farklı boyutta olan web fontları olarak sıralar (web.dev (yeni sekmede açılır)). Mağazalarda bu; sayfanın en üstüne eklenen bir ücretsiz kargo çubuğu, başlıktan sonra yüklenen yıldız puanları, fiyatın altındaki taksit seçenekleri mesajı ve öneri karuselleri demektir. Shopify, açılır pencere (pop-up) içeriğinin de kaymalara yol açabileceğini belirtir (Shopify (yeni sekmede açılır)).

Kullanıcı girdisinden sonraki 500 ms içinde gerçekleşen kaymalar sayılmaz, ancak kaydırma sırasındaki kaymalar sayılır ve laboratuvar araçları bunları çoğu zaman kaçırır (web.dev (yeni sekmede açılır)). Görsellere width ve height ya da bir CSS aspect-ratio değeri verin, widget'lar için yer ayırın, banner'ları içeriği itmeyen katmanlar (overlay) olarak gösterin, font değişiminden kaynaklanan kaymaları size-adjust ile azaltın ve animasyonlarda top veya left yerine transform kullanın.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Shopify'da Core Web Vitals nasıl iyileştirilir?

Shopify'da kazanımların çoğu ilk görseli yüksek öncelikle hemen yüklemekten, uygulama script'lerini azaltmaktan ve sonucu yönetici panelindeki web performansı raporlarında kontrol etmekten gelir.

Verileri yönetici panelinizde kontrol edin

Online Store > Themes sayfasında bir özet görünür; LCP, INP ve CLS raporlarının tamamı ise Analytics > Reports altındadır. Veriler 36 saate kadar gecikmeli gelebilir ve özel modun (private mode) kapalı olması gerekir (Shopify Yardım Merkezi (yeni sekmede açılır)).

Liquid'de görsel yüklemeyi kontrol edin

image_tag filtresi, preload ayarlamadığınız sürece sayfanın aşağısındaki bölümlerde görselleri geç yükler (image_tag referansı (yeni sekmede açılır)): 1 ile 3 arasındaki bölümlerde eager, 4. bölümden itibaren lazy. Tema düzenleyicide section.index değeri nil olduğu için koşulu <= 3 yerine > 3 ile yazın:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

Shopify, ürün ızgaralarında yalnızca ilk birkaç kartın hemen yüklenmesini önerir (örneğin forloop.index <= 4) (Shopify (yeni sekmede açılır)). preload: true ayarını idareli kullanın; Shopify yalnızca geç keşfedilen bir veya iki kaynağın önceden yüklenmesini önerir.

Uygulamaların geride bıraktıklarını temizleyin

Kullanılmayan uygulama yerleştirmelerini (app embeds) Online Store > Edit theme > App embeds altından kapatın (Shopify Yardım Merkezi (yeni sekmede açılır)). Bir uygulamayı kaldırmak uygulama bloklarını da kaldırır, ancak tema dosyalarını doğrudan düzenleyen uygulamalar, Shopify'ın kalite ve performans sorunlarına yol açabileceğini söylediği "hayalet kod" (ghost code) bırakabilir (Shopify (yeni sekmede açılır)). Shopify ayrıca script tag'lerin 1 Mart 2027'de çalışmayı bırakacağını belirtiyor. Fontlar için Shopify, harici font hizmetleri yerine kendi CDN'ini veya sistem fontlarını önerir (Shopify (yeni sekmede açılır)).

WooCommerce'te Core Web Vitals nasıl iyileştirilir?

WooCommerce'te eklentilerin WordPress'in görsel önceliklendirmesini geçersiz kılmadığından emin olun, sepet ve ödeme sayfaları dışındaki her şeyi önbelleğe alın ve gereksiz yere her sayfada yüklenen script'leri kaldırın.

  • Çekirdeğin görsel yönetimini koruyun. WordPress 6.3'ten (8 Ağustos 2023'te yayımlandı) bu yana çekirdek, muhtemel LCP görseline (varsayılan olarak en az 50.000 piksel kare) fetchpriority="high" ekler ve ilk üç içerik görselinde lazy loading uygulamaz (Make WordPress Core (yeni sekmede açılır)). Bir optimizasyon eklentisi kendi lazy loading özelliğini ekliyorsa hero görselini ve ana ürün görselini hariç tuttuğunu kontrol edin.
  • Sayfaları önbelleğe alın, sepetleri değil. WooCommerce'in rehberi, sunucu veya eklenti tabanlı sayfa önbelleklemesi ve bir CDN kullanılmasını, sepet ve ödeme sayfalarının ise önbelleğe alınmamasını önerir (WooCommerce geliştirici belgeleri (yeni sekmede açılır)).
  • Cart fragments'ı kontrol edin. WooCommerce 7.8'den bu yana cart fragments script'i yalnızca bir Cart (Sepet) widget'ının bulunduğu sayfalarda yüklenir, ancak bazı temalar bu widget'ı koda gömülü olarak içerir. Mini-Cart bloğu cart fragments kullanmaz (WooCommerce geliştirici blogu (yeni sekmede açılır)).
  • Ağır eklentileri bulun. WooCommerce, yavaş eklentileri bulmak için Query Monitor'ü ve kritik olmayan JavaScript'in ertelenmesini önerir.

Sayfa düzeniniz ekranın görünen ilk bölümünde üçten fazla görsel gösteriyorsa WordPress'in eşiğini yükseltebilirsiniz:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Düzeltmelerin etkisi ne zaman görünür?

Laboratuvar testleri bir düzeltmenin etkisini hemen gösterir, ancak CrUX önceki 28 günün ortalamasını aldığı için saha verilerinin bunu tam olarak yansıtması yaklaşık dört haftayı bulabilir.

Tek tek ölçümler değişkenlik gösterdiğinden laboratuvar testini bir değişiklikten önce ve sonra birkaç kez çalıştırın, ardından saha verilerini PageSpeed Insights'ta, Search Console'un Core Web Vitals raporunda veya Shopify'ın raporlarında izleyin. Ücretsiz tarama, yaklaşık bir dakikada ilk sonucu verir. Performans Düzeltme Raporu, hızı kısıtlanmış bir mobil laboratuvar testi (yavaş 4G, 4x CPU) çalıştırır ve buna Chrome UX Report saha verilerini ekler; Google'da mağazanız için yeterli veri varsa INP de bunlara dahildir.

Sık sorulan sorular

Core Web Vitals Google sıralamalarını etkiler mi?

Google, Core Web Vitals metriklerinin sıralama sistemlerinde kullanıldığını, ancak iyi değerlerin üst sıraları garanti etmediğini ve sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeye devam ettiğini söylüyor (Google Search Central (yeni sekmede açılır)).

PageSpeed Insights mağazam için neden saha verisi göstermiyor?

CrUX yalnızca herkese açık olarak keşfedilebilen ve yeterli sayıda uygun Chrome ziyaretçisi olan sayfaları ve kaynakları (origin) içerir. Trafiği düşük bir mağazanın yalnızca kaynak düzeyinde verisi olabilir ya da hiç verisi olmayabilir; bu durumda laboratuvar testlerine ve platformunuzun kendi raporlarına başvurun.

Testi geçmek için 90 veya üzeri bir Lighthouse puanı gerekir mi?

Hayır. Lighthouse performans puanı bir laboratuvar sonucudur, Core Web Vitals değerlendirmesi ise 75. yüzdelik dilimdeki saha verilerini kullanır; bu nedenle bir sayfa mütevazı bir Lighthouse puanıyla geçebilir, yüksek bir puanla da başarısız olabilir.

Tüm ürün görsellerini lazy load ile mi yüklemeliyim?

Hayır. İlk ekranın altındaki görselleri geç yükleyin, ancak hero görselini ve ana ürün görselini hemen yükleyin ve bunlardan birine fetchpriority="high" ekleyin.

Mobil sonuçlarım neden masaüstünden daha kötü?

Google mobil ve masaüstünü ayrı ölçer ve telefonların işlemcileri ile ağları daha yavaştır. Lighthouse'un mobil testi bunu Slow 4G profili ve 4x CPU yavaşlatmasıyla simüle eder.

Kaynaklar

Tüm rehberler