Acil müdahale gerektiren bir sorununuz mu var?Acil müdahale mi?Acil yardım alın →
Blog

MageBooster ekibinden sürüm yükseltme, güvenlik, hız ve taşıma üzerine pratik Magento 2 rehberleri.

Magento 2 için Core Web Vitals: Pratik INP ve LCP Kontrol Listesi

Güncel LCP, INP ve CLS eşikleri, bunların nasıl ölçüleceği ve daha hızlı mağazalar için Magento 2'ye özel düzeltmelerden oluşan, öncelik sırasına göre bir kontrol listesi.
Magento 2 danışmanlığı

Kısaca

Bir Magento 2 sayfasının Core Web Vitals'ı geçmesi için gerçek ziyaretlerin 75. yüzdelik diliminde LCP'nin 2,5 saniye, INP'nin 200 ms, CLS'nin ise 0,1 veya altında olması gerekir. Çoğu mağazada en büyük kazanımı şunlar sağlar: düzgün çalışan bir tam sayfa önbelleği (full page cache), hızlı yüklenen bir LCP görseli, ana iş parçacığında (main thread) daha az JavaScript ve üçüncü taraf etiketlerin sıkı kontrolü. Önce saha verisiyle ölçün, ardından aşağıdaki sırayla düzeltin.

Core Web Vitals, Google’ın yükleme hızını, etkileşimi ve görsel kararlılığı ölçen üç kullanıcı deneyimi metriğidir. Magento 2 veya Adobe Commerce mağazaları için aynı zamanda iyi bir sağlık göstergesidir: düşük skor genellikle dönüşümü de düşüren sorunlara işaret eder. Örneğin önbelleğe alınmamış yavaş sayfalar, ağır RequireJS paketleri ve ana iş parçacığını kilitleyen etiket yöneticileri.

Bu rehberde güncel eşikleri, bunları doğru ölçmenin yolunu ve skorları gerçekten yukarı taşıyan, Magento 2'ye özgü düzeltmeleri bulacaksınız.

Güncel eşikler

Google her metriği mobil ve masaüstü için ayrı ayrı, sayfa yüklemelerinin 75. yüzdelik diliminde değerlendirir. 12 Mart 2024'ten bu yana yanıt hızı metriği olarak First Input Delay (FID) yerine Interaction to Next Paint (INP) kullanılıyor.

MetrikÖlçtüğü alanİyiİyileştirilmeliZayıf
LCP (Largest Contentful Paint)Yükleme≤ 2.5 s2,5 sn – 4,0 sn> 4,0 sn
INP (Interaction to Next Paint)Yanıt hızı≤ 200 ms200 ms – 500 ms> 500 ms
CLS (Cumulative Layout Shift)Görsel kararlılık≤ 0.10,1 – 0,25> 0,25

PageSpeed Insights, üç metriğin de 75. yüzdelik dilimdeki değeri İyi olduğunda sayfayı veya kaynağı (origin) başarılı sayar. Yeterli INP verisi yoksa değerlendirme yalnızca LCP ve CLS'ye bakılarak da başarılı sayılabilir.

Nasıl ölçülür: önce saha verisi, sonra laboratuvar verisi

CrUX ve PageSpeed Insights

Chrome User Experience Report (CrUX), uygun Chrome kullanıcılarından gerçek kullanıcı verisi toplar. CrUX API her gün güncellenen 28 günlük hareketli ortalamayı sunar; PageSpeed Insights da önceki 28 günün aynı saha verisini gösterir. Trafiği düşük URL'lerde yalnızca kaynak (origin) düzeyinde veri görünebilir ya da hiç veri olmayabilir.

Bugün yayına aldığınız bir düzeltmenin CrUX'a tam olarak yansıması haftalar sürer. Ayrıca Search Console benzer URL'leri gruplar; bu yüzden tek bir yavaş şablon binlerce URL'nin sonucunu aşağı çekebilir. Sonuçları şablon bazında kontrol edin: ana sayfa, kategori, ürün, sepet, ödeme sayfası ve arama.

Lighthouse ve laboratuvar araçları

PageSpeed Insights veya Chrome DevTools içindeki Lighthouse, tekrarlanabilir laboratuvar testleri ve tanılama bilgileri sunar. Render'ı engelleyen kaynaklar veya uzun görevler gibi sorunların nedenini bulmak için kullanın. Laboratuvar skorunu Core Web Vitals sonucunuz sanmayın. Laboratuvar testleri INP'yi ölçemez; çünkü INP için gerçek kullanıcı etkileşimi gerekir.

Gerçek kullanıcı izleme (RUM)

CrUX bir şablonun yavaş olduğunu söyler; RUM ise nedenini, hangi cihazlarda ve hangi etkileşimlerde yaşandığını gösterir. Google’ın açık kaynaklı web-vitals JavaScript kütüphanesi, gerçek oturumlardaki LCP, INP ve CLS değerlerini; LCP öğesi ve en yavaş etkileşimin hedefi gibi kaynak (attribution) bilgileriyle birlikte raporlar. Bu olayları analitik aracınıza veya bir RUM servisine gönderin ve sayfa türüne göre ayrıştırın.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: metric.value,
    pageType: document.body.className, // Magento adds page-type classes to body
    attribution: metric.attribution
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

Magento 2'ye özgü düzeltmeler

1. Sunucu yanıt süresi ve tam sayfa önbelleği

Time to First Byte (TTFB), LCP'nin ilk bölümüdür. Google’ın LCP rehberi LCP'yi dört alt bölüme ayırır (TTFB, kaynak yükleme gecikmesi, kaynak yükleme süresi ve öğe render gecikmesi) ve TTFB'nin toplamın yaklaşık 'ı olmasını önerir. Önbelleğe alınmamış bir Magento sayfası, tarayıcıya henüz hiç HTML ulaşmadan LCP bütçesinin büyük kısmını tüketebilir.

Adobe’un yapılandırma rehberi (best practices), canlı ortamda sayfa önbelleği olarak Varnish'i öneriyor. Varnish'i etkinleştirin ve Magento'ya temizleme (purge) isteklerini nereye göndereceğini belirtin:

bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2
bin/magento setup:config:set --http-cache-hosts=127.0.0.1:6081

Ardından VCL dosyasını şu bölümden dışa aktarın: Stores > Settings > Configuration > Advanced > System > Full Page Cache. Ardından önbellek isabet oranınızı (hit rate) kontrol edin. Magento'da isteklerin önbellekten karşılanamamasının (cache miss) yaygın nedenleri şunlardır: layout XML içinde cacheable="false" olarak işaretlenen bloklar (bunlar tüm sayfayı önbelleğe alınamaz hale getirir), önbelleği parçalayan izleme parametreleri ve private content section'lar yerine sunucu tarafında oluşturulan müşteriye özel içerik.

# Find layout XML that disables FPC for a whole page
grep -rn 'cacheable="false"' app/code app/design vendor/*/*/view/frontend/layout

Adobe ayrıca performans için indeksleyicileri Update on Schedule moduna almanızı önerir; böylece katalogda yapılan kayıtlar yoğun trafik sırasında ağır yeniden indekslemeyi tetiklemez:

bin/magento indexer:set-mode schedule
bin/magento indexer:status

Not: Adobe’a göre Customer Grid indeksi Update on Save modunda kalmalıdır.

2. Önbellek ısıtma (cache warming)

Her yayına alma (deploy) ya da tam önbellek temizliği, sonraki ziyaretçilerin isteklerini doğrudan PHP'ye düşürür. Yayına almanın hemen ardından en değerli URL'leri ısıtın: ana sayfa, en önemli kategoriler, en çok satan ürünler ve kilit CMS sayfaları. Adobe Commerce on cloud infrastructure'da bu işi WARM_UP_PAGES ve WARM_UP_CONCURRENCY post-deploy değişkenleri üstlenir. Kendi sunucularınızda barındırdığınız altyapılarda sitemap'i tarayan basit bir crawler yeterlidir (bu örnek GNU grep kullanır):

curl -s https://www.example.com/sitemap.xml \
  | grep -oP '(?<=<loc>)[^<]+' \
  | head -500 \
  | xargs -P 4 -I{} curl -s -o /dev/null -w "%{http_code} %{time_starttransfer} {}\n" {}

Ayrıca tam önbellek temizliğini rutin hale getirmeyin. Yalnızca ilgili önbellek türlerini temizleyin ve mümkün olduğunca etiket tabanlı geçersiz kılmayı (tag-based invalidation) kullanın.

3. LCP görseli

Ürün ve kategori sayfalarında LCP öğesi genellikle ana ürün görseli veya sayfanın üstündeki büyük banner'dır (hero). Google’ın önerisi net: LCP görselini asla lazy-load ile yüklemeyin ve bu görselde fetchpriority="high" kullanmayı değerlendirin; ancak yüksek önceliği en fazla bir veya iki görselle sınırlı tutun.

  • İlk galeri görselinden ve ekranın üst kısmındaki banner'lardan loading="lazy" özniteliğini kaldırın.
  • Luma'da ürün galerisi, yer tutucu görsel yüklendikten sonra JavaScript ile başlatılır. DevTools'ta hangi öğenin LCP olarak raporlandığını kontrol edin; bu görselin bir script tarafından sonradan bulunması yerine HTML'de erkenden istendiğinden (veya preload edildiğinden) emin olun.
  • Doğru boyutlarda görseller sunun. Magento’nun görsel önbelleği ürün görsellerini her görünüm için yeniden boyutlandırır; view.xml dosyanızdaki boyutların gerçek gösterim boyutuyla eşleştiğinden emin olun.
  • Modern formatlar kullanın. Adobe Commerce on cloud infrastructure'da Fastly Image Optimization görselleri otomatik olarak WebP'ye dönüştürebilir. Diğer hosting ortamlarında bir CDN görsel servisi veya güvenilirliği kanıtlanmış bir eklenti kullanın.
  • Ekranın görünmeyen alt kısmındaki görselleri ise (örneğin ürün listesinde ilk satırdan sonrakileri) lazy-load ile yükleyin.

4. JavaScript: bundling ve minification mı, Hyvä mı?

Magento 2'deki INP sorunları genellikle ana iş parçacığının meşgul olmasından kaynaklanır. Luma çok sayıda RequireJS ve Knockout modülü yükler; eklentiler de üzerine yenilerini ekler.

Adobe’un kendi dokümantasyonu yerleşik seçenekler konusunda temkinli. Yerleşik bundling'in, sayfa yalnızca birkaç pakete ihtiyaç duysa bile tüm paketleri yüklediğini belirtiyor; bundling ve minification için r.js gibi üçüncü taraf araçları öneriyor; HTTP/2'nin bundling'e iyi bir alternatif olabileceğini not ediyor ve kullanımdan kaldırılmış JS ve CSS birleştirme (merge) ayarlarını kullanmamayı tavsiye ediyor. Minification'ı ise gönül rahatlığıyla etkinleştirebilirsiniz:

bin/magento config:set --lock-config dev/js/minify_files 1
bin/magento config:set --lock-config dev/css/minify_files 1

Luma tabanlı temalarda dokümante edilmiş ileri düzey yöntem, r.js ile sayfa türüne göre (common, catalog, checkout) paketler oluşturmaktır.

Diğer yol, ön yüzü tamamen değiştirmektir. Hyvä Theme, Alpine.js ve Tailwind CSS kullanarak mağaza ön yüzünü çok daha az JavaScript ile yeniden kurar. 10 Kasım 2025'ten bu yana Hyvä Theme ücretsiz ve açık kaynaklıdır (OSL3 + AFL3); Hyvä Checkout ve diğer ticari ürünleri ise ücretli olmaya devam ediyor. Hyvä bir ayar değil, başlı başına bir projedir: ön yüzle ilgili her eklentinin Hyvä uyumlu bir sürümü olmalı ya da eklenti yeniden yazılmalıdır. Bu yüzden işe eklenti listenizi analiz ederek başlayın.

5. Üçüncü taraf script'ler

Etiket yöneticileri, canlı sohbet widget'ları, yorum widget'ları, A/B test araçları ve kişiselleştirme script'leri, zayıf INP ve CLS değerlerinin sık görülen nedenleridir. Her birini tek tek gözden geçirin:

  • Kimsenin kullanmadığı etiketleri kaldırın. Etiket yöneticisi container'ını en az üç ayda bir denetleyin.
  • Zorunlu olmayan widget'ları sayfa yüklenirken değil, kullanıcı etkileşiminden sonra veya tarayıcı boştayken yükleyin.
  • Düzen kaymalarını önlemek için geç render edilen her şeye (yorum yıldızları, banner'lar, çerez onay çubukları) önceden alan ayırın.
  • Kendi kodunuzdaki uzun görevleri parçalara bölün. Google 50 ms'yi aşan her işi uzun görev sayar ve ana iş parçacığını serbest bırakmak için scheduler.yield()kullanmayı, bunun desteklenmediği tarayıcılarda ise setTimeout kullanmayı önerir.

6. Düzen kararlılığı

Google, düzen kaymasının başlıca nedenleri olarak boyutları belirtilmemiş görselleri, reklam ve gömülü içerikleri, web fontlarını ve sayfaya sonradan eklenen dinamik içeriği sayar. Magento'da ürün görseli yer tutucularına, renk/beden seçeneklerinin (swatch) görüntülenmesine, mini sepet ve customer-section güncellemelerine ve eklentilerin eklediği promosyon çubuklarına bakın. Görsellere açıkça width ve height (veya aspect-ratio) tanımlayın ve içerik yüklenirken container'ların yüksekliğini sabit tutun.

Öncelik sırasına göre kontrol listesi

  1. CrUX ve Search Console verilerini şablon bazında çekin. Hangi metriğin nerede başarısız olduğunu belirleyin.
  2. LCP öğesini ve en yavaş etkileşimleri görmek için web-vitals kütüphanesiyle RUM ekleyin.
  3. Varnish'in (veya Fastly'nin) ana sayfa, kategori ve ürün sayfalarında önbellekten yanıt verdiğini doğrulayın. Gereksiz cacheable="false" bloklarını kaldırın.
  4. İndeksleyicileri Update on Schedule moduna alın ve rutin tam önbellek temizliklerini bırakın.
  5. Her yayına alma işleminden sonra en önemli URL'leri ısıtın.
  6. LCP görseli için: lazy loading yok, fetchpriority="high", doğru boyut, mümkünse WebP.
  7. JS ve CSS minification'ı etkinleştirin; JS birleştirmeyi kapatın; sayfa türüne göre bundling'i veya bundling olmadan HTTP/2'yi test edin.
  8. Üçüncü taraf script'leri denetleyin ve yüklenmelerini erteleyin (defer).
  9. CLS'yi 0,1'in altına indirmek için geç yüklenen öğelere önceden alan ayırın.
  10. Bu adımlardan sonra Luma'da INP hâlâ zayıfsa Hyvä'ya geçişin kapsamını çıkarın.
  11. 28 günlük saha verisi biriktikten sonra yeniden ölçün.

Sıkça sorulan sorular

FID hâlâ Core Web Vitals metriklerinden biri mi?

Hayır. INP, 12 Mart 2024'te Core Web Vitals metriği olarak FID'in yerini aldı. Eski bir rapor veya araç hâlâ FID gösteriyorsa onun yerine INP'ye bakın.

PageSpeed Insights iyi skor gösteriyor ama Search Console sayfalarımın başarısız olduğunu söylüyor. Neden?

Performans skoru tek bir Lighthouse laboratuvar testinden gelir. Search Console ise gerçek Chrome kullanıcılarından 28 gün boyunca toplanan CrUX saha verisini kullanır. Core Web Vitals için belirleyici olan saha verisidir ve laboratuvar testinin yansıtamayabileceği yavaş cihazları ve ağları da kapsar.

Magento 2'de Core Web Vitals'ı geçmek için Hyvä şart mı?

Şart değil. Birçok Luma mağazası önbellek, görsel ve script iyileştirmeleriyle ciddi bir gelişme kaydeder. Luma ön yüzünün ve eklentilerinin yüklediği JavaScript yüzünden INP zayıf kalmaya devam ediyorsa Hyvä'yı değerlendirmenin zamanı gelmiş demektir.

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

CrUX son 28 günün verisini kullanır; bu yüzden yayına almanın ardından yaklaşık dört hafta boyunca kademeli bir iyileşme bekleyin. RUM verisi ise etkiyi hemen gösterir.

Magento 2 mağazanız Core Web Vitals'ı geçemiyor mu?

Önbelleği, ön yüzü ve üçüncü taraf script'leri analiz ediyor, mağazanız için öncelik sırasına konmuş bir düzeltme planı sunuyoruz.

Performans analizi için randevu alın

Kaynaklar

Ücretsiz Site Analizi

Mağaza bilgilerinizi gönderin. Hız, güvenlik ve eklentileri inceleyip 3 iş günü içinde hemen uygulayabileceğiniz üç iyileştirme önerisiyle size dönelim.

Konuşalım

Teklif alın

Mağazanızdan bahsedin, bir iş günü içinde size dönelim. Sohbet etmeyi mi tercih edersiniz? WhatsApp'tan yazın