Shopify’da Core Web Vitals ve INP: neyle iyileşir?

Core Web Vitals tavsiyelerinin çoğu yirmi maddelik bir düzeltme listesidir. Bir Shopify mağazasında genellikle bunlardan yalnızca birkaçı önemlidir; hangilerinin önemli olduğu da çoğu mağaza sahibinin zaten elinde olan veriye bağlıdır. Veriyle başlayın; sonra başarısız olan metriğin parçalarını, size en çok süre kaybettirenden başlayarak ele alın.

Üç metrik ve eşikleri

Her biri gerçek ziyaretlerin 75. yüzdeliğinde değerlendirilir; yani ziyaretçilerin çoğu için hızlı olan bir deneyim, en yavaş çeyrek yavaşsa yine başarısız sayılır. INP, First Input Delay’in yerini aldı; çünkü yalnızca ilk etkileşime değil, ziyaretteki her etkileşime bakar. Google, Core Web Vitals’ın sıralama sistemlerinde kullanıldığını söyler; ama iyi skorlar üst sıraları garanti etmez. Bunları önce bir kullanıcı deneyimi hedefi olarak görün.

Sayıları nerede okumalı?

• Shopify’ın web performansı raporları, yönetim panelinde gerçek ziyaretçilerden gelen LCP, INP ve CLS değerlerini 75. yüzdelikte, sayfa URL’si, sayfa türü ve cihaza göre ayrılmış olarak gösterir. Son 90 günü kapsar, 36 saate kadar gecikebilir ve uygulama kurulumlarını, tema güncellemelerini ve kod değişikliklerini grafikte numaralı çizgilerle işaretler. Bu işaretler, bir kötüleşmenin nedenini bulmanın en hızlı yoludur.
• Search Console’un Core Web Vitals raporu, gerçek Chrome kullanıcılarından gelen Chrome User Experience Report (CrUX) saha verisini kullanır.
• Lighthouse ve PageSpeed laboratuvar ölçümleri teşhis içindir, hüküm için değil. INP gerçek etkileşimler ister; laboratuvarda Total Blocking Time makul bir yaklaşık gösterge olabilir, ama yerini tutmaz.

Trafiği düşük mağazalarda günlük görünüm çok dalgalanır. Trafik az olduğunda Shopify haftalık ya da aylık görünümü önerir.

LCP’yi ne değiştirir?

LCP dört parçaya ayrılır: ilk bayta kadar geçen süre, LCP kaynağı yüklenmeye başlamadan önceki gecikme, indirme süresi ve render’dan önceki gecikme. Bir Shopify temasında LCP öğesi genellikle ana görsel (hero) ya da ana ürün görselidir. Sırasıyla:

1. LCP görselini tarayıcının hemen bulabileceği şekilde ekleyin ve önceliklendirin. Duyarlı boyutlar alması için onu HTML’de image_url ve image_tag ile oluşturun; asla loading="lazy" kullanmayın ve fetchpriority="high" ile işaretleyin. Shopify ikisini de etkisi yüksek LCP uygulamaları olarak değerlendirir.
2. Render’ı engelleyenleri kaldırın. Tema kodu da olsa uygulama kodu da olsa, render’ı engelleyen script’ler görsel indikten sonra bile onun ekrana çizileceği anı geciktirir.
3. Preload’u geç keşfedilen bir iki kaynağa saklayın. Shopify’ın önerisi preload’u ölçülü kullanmaktır; her şeyi önceden yüklemek tarayıcının önceliklendirmesini bozar.
4. Yazı tipleri. Metin başka bir bağlantıyı beklemesin diye yazı tiplerini Shopify’ın CDN’inde barındırın ya da sistem yazı tiplerini kullanın.

INP’yi ne değiştirir?

Bir etkileşimin üç aşaması vardır: girdi gecikmesi (ana iş parçacığını beklemek), işleme (olay işleyicileriniz) ve sunum gecikmesi (bir sonraki karenin çizilmesi). Shopify’ın kendi rehberi ana neden konusunda açıktır: tema kodu da olsa kurulu uygulamaların script’leri de olsa JavaScript ana iş parçacığında çalışır. Çoğu mağazada iş şu sırayla ilerler:

1. Yükleme sırasında ana iş parçacığındaki işi azaltın. Ayrıştırılıp çalıştırılan script’lerden gelen uzun görevler ilk dokunuşları bekletir. Kritik olmayan script’lerde defer ya da async kullanın ve gerekmeyeni kaldırın; uygulamalar için kurulu uygulamaların vitrin yüküne ne eklediğine bakın.
2. Kodu etkileşim anında yükleyin. Beden tablosu, yorum widget’ı ya da yakınlaştırma görüntüleyicisi JavaScript’ini, ziyaretçi onu ilk kullandığında dinamik import ile yükleyebilir.
3. İşleyicileri bölün. Fiyatı, stoğu, görselleri ve önerileri tek bir callback’te yeniden hesaplayan bir varyant seçici klasik bir yavaş etkileşimdir. Önce ziyaretçinin gördüğünü güncelleyin, sonra ana iş parçacığını serbest bırakıp gerisini yapın.
4. Render edilmesi gerekeni küçültün. Büyük DOM’ların render’ı daha çok iş ister; bu yüzden onlarca bölümden kurulmuş uzun ürün sayfaları, bir etkileşim sayfayı her değiştirdiğinde bunun bedelini ödeyebilir. Ekran dışındaki içerik content-visibility ile ertelenebilir.

Saha verisiyle başlayın: DevTools’u açmadan önce hangi etkileşimin, hangi sayfa türünde yavaş olduğunu size o söyler.

Başarısız bir mağaza için çalışma sırası

1. Web performansı raporunu açın, mobil görünüme geçin ve başarısız olan metriği ve sayfa türünü bulun. En çok ziyaret alan başarısız sayfa türleriyle başlayın.
2. Grafikteki işaretlere bakın. Sorun bir uygulama kurulumu ya da tema değişikliğiyle başladıysa oradan başlayın.
3. LCP için o şablondaki LCP öğesini belirleyin ve dört parçasını kontrol edin: geç mi keşfediliyor, lazy-load mu ediliyor, çok mu büyük, yoksa engelleyen kod yüzünden mi bekliyor?
4. INP için ziyaretçilerin o şablonda gerçekten kullandığı etkileşimleri (varyant seçici, sepete ekle, filtreler, menü) listeleyin ve her birini DevTools’ta CPU kısıtlamasıyla profilleyin.
5. Her seferinde bir nedeni düzeltin, yayına alın ve saha verisinin güncellenmesini bekleyin. Haftalar boyunca toplanan 75. yüzdelik bir metrikte birlikte yayına alınan birkaç değişiklik birbirinden ayırt edilemez.

Modern bir temada CLS nadiren bu kadar süreç ister. Başarısız olduğunda olağan neden, yüklemeden sonra var olan içeriğin üstüne eklenen içeriktir: bannerlar, açılır pencereler ya da geç yüklenen uygulama widget’ları. Çözüm de bunların yerini önceden ayırmaktır.

Sayıları nadiren değiştiren değişiklikler

• Lighthouse skorunun peşine düşmek. Ana sayfada 100 laboratuvar skoru, gerçek telefonlarda ürün sayfasındaki INP hakkında pek bir şey söylemez.
• Her şeyi preload etmek. Daha fazla preload, LCP görseline yardım etmek yerine onunla yarışır.
• Her görseli lazy-load etmek. Ekranın alt kısmında işe yarar, ilk görünen kısımda zarar verir; LCP öğesi de oradadır.
• Bir uygulamayı kaldırıp kodunun da gittiğini varsaymak. Uygulamayı kaldırmak ve kodunu temizlemek ayrı adımlardır; uygulamaların vitrin yüküne ne eklediğine bakın.

Headless bunu çözer mi?

Kendiliğinden çözmez. Headless bir vitrin de bir hero görseli yükler ve ana iş parçacığında JavaScript çalıştırır; yani bir temayla aynı LCP ve INP bütçe sorunlarıyla başlar ve onları aynı yollarla çözmek zorundadır. Shopify’ın kendi tema rehberi, sunucu tarafı render için Hydrogen’ı yalnızca bir framework gerçekten gerektiğinde önerir. Hydrogen vitrin projemiz Snow / Motion, laboratuvar ölçümlerini araç ve tarihle birlikte vaka çalışmasında yayınlar; bir demonun anlamlı saha verisi olmaz. Daha fazlası için Hydrogen mı Liquid mi yazısına bakın.

Lintel bu işi nasıl yapar?

Önce saha verisini okuruz, en yavaş şablonları ve etkileşimleri buluruz, her birini bir tema dosyasına, bir uygulamaya ya da bir görsele kadar izleriz ve en çok ziyaretçiyi etkileyenden başlayarak sorunu kaynağında düzeltiriz. Sonra yeniden ölçeriz. Bir skor ya da sıralama vaat etmeyiz; çünkü ikisi de bizim vaat edebileceğimiz şeyler değildir.