Sonraki Boyama (INP) ile Etkileşimi Ölçme

1. Giriş

Bu etkileşimli codelab'de, web-vitals kitaplığını kullanarak Interaction to Next Paint (INP) metriğinin nasıl ölçüleceği açıklanmaktadır.

Ön koşullar

Öğrenecekleriniz

  • web-vitals kitaplığını sayfanıza ekleme ve ilişkilendirme verilerini kullanma
  • INP'yi iyileştirmeye nereden ve nasıl başlayacağınızı teşhis etmek için ilişkilendirme verilerini kullanın.

İhtiyacınız olanlar

  • GitHub'dan kodu klonlayabilen ve npm komutlarını çalıştırabilen bir bilgisayar.
  • Metin düzenleyici
  • Tüm etkileşim ölçümlerinin çalışması için Chrome'un son sürümü.

2. Kurun

Kodu alma ve çalıştırma

Kod, web-vitals-codelabs deposunda bulunur.

  1. Depoyu terminalinizde klonlayın: git clone https://github.com/GoogleChromeLabs/web-vitals-codelabs.git.
  2. Klonlanan dizine gidin: cd web-vitals-codelabs/measuring-inp.
  3. Bağımlılıkları yükleyin: npm ci.
  4. Web sunucusunu başlatın: npm run start.
  5. Tarayıcınızda http://localhost:8080/ adresini ziyaret edin.

Sayfayı deneyin

Bu codelab'de, INP ile ilgili olası sorunları keşfetmek için Gastropodicon (popüler bir salyangoz anatomisi referans sitesi) kullanılır.

Gastropodicon demo sayfasının ekran görüntüsü

Hangi etkileşimlerin yavaş olduğunu anlamak için sayfayla etkileşimde bulunmayı deneyin.

3. Chrome Geliştirici Araçları'nda gezinme

Geliştirici Araçları'nı açmak için Diğer Araçlar > Geliştirici Araçları menüsünü kullanın, sayfayı sağ tıklayıp İncele'yi seçin veya klavye kısayolu kullanın.

Bu codelab'de hem Performans panelini hem de Konsol'u kullanacağız. Bunlar arasında dilediğiniz zaman Geliştirici Araçları'nın üst kısmındaki sekmelerden geçiş yapabilirsiniz.

  • INP sorunları en sık mobil cihazlarda yaşandığından mobil ekran emülasyonuna geçin.
  • Masaüstü veya dizüstü bilgisayarda test yapıyorsanız performans, gerçek bir mobil cihazdaki performanstan muhtemelen çok daha iyi olacaktır. Performansa daha gerçekçi bir bakış için Performans panelinin sağ üst kısmındaki dişli simgesini tıklayın ve CPU 4x yavaşlatma'yı seçin.

Uygulamanın yanında, 4 kat CPU yavaşlatma seçeneğinin belirlendiği Geliştirici Araçları Performans panelinin ekran görüntüsü

4. web-vitals'ı yükleme

web-vitals, kullanıcılarınızın deneyimlediği Web Vitals metriklerini ölçmek için kullanılan bir JavaScript kitaplığıdır. Bu değerleri yakalamak için kitaplığı kullanabilir, ardından bunları daha sonra analiz etmek üzere bir Analytics uç noktasına gönderebilirsiniz. Bizim amacımız, yavaş etkileşimlerin ne zaman ve nerede gerçekleştiğini belirlemektir.

Kitaplığı sayfaya eklemenin birkaç farklı yolu vardır. Kitaplığı kendi sitenize nasıl yükleyeceğiniz, bağımlılıkları nasıl yönettiğinize, derleme işlemine ve diğer faktörlere bağlıdır. Tüm seçenekleriniz için kitaplığın dokümanlarını inceleyin.

Bu codelab, belirli bir derleme işlemine girmeden doğrudan komut dosyasını yüklemek ve npm'den yüklemek için kullanılacaktır.

Kullanabileceğiniz iki web-vitals sürümü vardır:

  • Sayfa yükleme işleminde Core Web Vitals'ın metrik değerlerini izlemek istiyorsanız "standart" derleme kullanılmalıdır.
  • "İlişkilendirme" derlemesi, bir metriğin neden belirli bir değere ulaştığını teşhis etmek için her metriğe ek hata ayıklama bilgileri ekler.

Bu codelab'de INP'yi ölçmek için ilişkilendirme derlemesini istiyoruz.

npm install -D web-vitals komutunu çalıştırarak web-vitals kartını projenin devDependencies bölümüne ekleyin.

Sayfaya web-vitals ekleyin:

Komut dosyasının ilişkilendirme sürümünü index.html öğesinin en altına ekleyin ve sonuçları konsola kaydedin:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log);
</script>

Deneyin

Konsol açıkken sayfayla tekrar etkileşime geçmeyi deneyin. Sayfada tıkladığınız hiçbir şey kaydedilmez.

INP, bir sayfanın tüm yaşam döngüsü boyunca ölçülür. Bu nedenle web-vitals, kullanıcı sayfadan ayrılana veya sayfayı kapatana kadar varsayılan olarak INP'yi bildirmez. Bu, analiz gibi işlemler için sinyal gönderme konusunda ideal bir davranıştır ancak etkileşimli hata ayıklama için daha az idealdir.

web-vitals, daha ayrıntılı raporlama için reportAllChanges seçeneğini sunar. Etkinleştirildiğinde her etkileşim raporlanmaz ancak önceki etkileşimlerden daha yavaş olan her etkileşim raporlanır.

Seçeneği komut dosyasına ekleyip sayfayla tekrar etkileşime geçmeyi deneyin:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log, {reportAllChanges: true});
</script>

Sayfayı yenilediğinizde etkileşimler artık konsola raporlanacak ve yeni bir en yavaş etkileşim olduğunda güncellenecektir. Örneğin, arama kutusuna yazmayı ve ardından girişi silmeyi deneyin.

INP mesajlarının başarıyla yazdırıldığı Geliştirici Araçları konsolunun ekran görüntüsü

5. İlişkilendirme ne içerir?

Çoğu kullanıcının sayfayla kuracağı ilk etkileşim olan çerez izni iletişim kutusuyla başlayalım.

Birçok sayfada, kullanıcılar çerezleri kabul ettiğinde çerezlerin eşzamanlı olarak tetiklenmesini gerektiren komut dosyaları bulunur. Bu durum, tıklamanın yavaş bir etkileşim olmasına neden olur. Burada da aynı durum geçerlidir.

(Demo) çerezleri kabul etmek için Evet'i tıklayın ve artık Geliştirici Araçları konsoluna kaydedilen INP verilerine göz atın.

INP veri nesnesi, Geliştirici Araçları konsoluna kaydedildi

Bu üst düzey bilgiler hem standart hem de ilişkilendirme web hayati bileşenleri derlemelerinde kullanılabilir:

{
  name: 'INP',
  value: 344,
  rating: 'needs-improvement',
  entries: [...],
  id: 'v4-1715732159298-8028729544485',
  navigationType: 'reload',
  attribution: {...},
}

Kullanıcının tıkladığı andan bir sonraki boyamaya kadar geçen süre 344 milisaniye oldu. Bu, "iyileştirilmesi gereken" bir INP değeridir. entries dizisinde bu etkileşimle ilişkili tüm PerformanceEntry değerleri bulunur. Bu örnekte yalnızca bir tıklama etkinliği vardır.

Ancak bu süre zarfında neler olduğunu öğrenmek için en çok attribution özelliğiyle ilgileniyoruz. İlişkilendirme verilerini oluşturmak için web-vitals, hangi uzun animasyon çerçevesinin (LoAF) tıklama etkinliğiyle çakıştığını bulur. LoAF, bu çerçeve sırasında harcanan süreyle ilgili ayrıntılı veriler sağlayabilir. Bu veriler, çalıştırılan komut dosyalarından requestAnimationFrame geri çağırma, stil ve düzende harcanan süreye kadar her şeyi kapsar.

Daha fazla bilgi görmek için attribution özelliğini genişletin. Veriler çok daha zengin.

attribution: {
  interactionTargetElement: Element,
  interactionTarget: '#confirm',
  interactionType: 'pointer',

  inputDelay: 27,
  processingDuration: 295.6,
  presentationDelay: 21.4,

  processedEventEntries: [...],
  longAnimationFrameEntries: [...],
}

İlk olarak, etkileşimde bulunulan öğelerle ilgili bilgiler yer alır:

  • interactionTargetElement: Etkileşimde bulunulan öğeye canlı referans (öğe DOM'dan kaldırılmadıysa).
  • interactionTarget: Sayfadaki öğeyi bulmak için kullanılan bir seçici.

Ardından, zamanlama genel olarak şu şekilde özetlenir:

  • inputDelay: Kullanıcının etkileşimi başlattığı (ör. fareyi tıkladığı) an ile bu etkileşim için etkinlik işleyicinin çalışmaya başladığı an arasındaki süre. Bu durumda, CPU sınırlama açıkken bile giriş gecikmesi yalnızca yaklaşık 27 milisaniyeydi.
  • processingDuration: Etkinlik işleyicilerin tamamlanması için gereken süre. Genellikle sayfalar tek bir etkinlik için birden fazla dinleyiciye (örneğin, pointerdown, pointerup ve click) sahip olur. Bunların tümü aynı animasyon çerçevesinde çalışıyorsa bu süreye birleştirilir. Bu durumda, işleme süresi 295,6 milisaniye sürer.Bu süre, INP süresinin büyük bir kısmını oluşturur.
  • presentationDelay: Etkinlik işleyicilerin tamamlanmasından tarayıcının bir sonraki kareyi boyamayı bitirmesine kadar geçen süre. Bu durumda 21, 4 milisaniye.

Bu INP aşamaları, neyin optimize edilmesi gerektiğini teşhis etmek için önemli bir sinyal olabilir. INP'yi optimize etme kılavuzunda bu konu hakkında daha fazla bilgi edinebilirsiniz.

Biraz daha ayrıntılı incelediğimizde, üst düzey INP entries dizisindeki tek etkinliğin aksine processedEventEntries dizisinin beş etkinlik içerdiğini görüyoruz. Farkı nedir?

processedEventEntries: [
  {
    name: 'mouseover',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {
    name: 'mousedown',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {name: 'mousedown', ...},
  {name: 'mouseup', ...},
  {name: 'click', ...},
],

En üst düzey giriş, INP etkinliğidir. Bu örnekte tıklama etkinliği kullanılmıştır. İlişkilendirme processedEventEntries, aynı çerçeve sırasında işlenen tüm etkinliklerdir. Bu işlevin yalnızca tıklama etkinliğini değil, mouseover ve mousedown gibi diğer etkinlikleri de içerdiğini unutmayın. Diğer etkinliklerin de yavaş olup olmadığını bilmek önemlidir. Çünkü tüm bu etkinlikler yavaş yanıt vermeye katkıda bulunmuştur.

Son olarak, longAnimationFrameEntries dizisi vardır. Bu tek bir giriş olabilir ancak etkileşimin birden fazla kareye yayılabileceği durumlar da vardır. Burada, tek bir uzun animasyon karesi içeren en basit durumu görüyoruz.

longAnimationFrameEntries

LoAF girişini genişletme:

longAnimationFrameEntries: [{
  name: 'long-animation-frame',
  startTime: 1823,
  duration: 319,

  renderStart: 2139.5,
  styleAndLayoutStart: 2139.7,
  firstUIEventTimestamp: 1801.6,
  blockingDuration: 268,

  scripts: [{...}]
}],

Burada, stil oluşturmaya harcanan süreyi ayrıntılı olarak göstermek gibi bir dizi faydalı değer bulunur. Long Animation Frames API makalesinde bu özellikler daha ayrıntılı olarak ele alınmaktadır. Şu anda öncelikli olarak, uzun süren karelerden sorumlu komut dosyalarıyla ilgili ayrıntılar sağlayan girişleri içeren scripts özelliğiyle ilgileniyoruz:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 1828.6,
  executionStart: 1828.6,
  duration: 294,

  sourceURL: 'http://localhost:8080/third-party/cmp.js',
  sourceFunctionName: '',
  sourceCharPosition: 1144
}]

Bu durumda, zamanın büyük bir kısmının BUTTON#confirm.onclick üzerinde çağrılan tek bir event-listener içinde geçirildiğini söyleyebiliriz. Hatta komut dosyası kaynak URL'sini ve işlevin tanımlandığı karakter konumunu bile görebiliriz.

Önemli çıkarım

Bu ilişkilendirme verilerinden bu dava hakkında ne belirlenebilir?

  • Etkileşim, button#confirm öğesinin (bir komut dosyası ilişkilendirme girişindeki attribution.interactionTarget ve invoker mülkünden) tıklanmasıyla tetiklendi.
  • Zamanın büyük bir kısmı etkinlik dinleyicilerini yürütmekle geçti (toplam metrik value ile karşılaştırıldığında attribution.processingDuration).
  • Yavaş etkinlik işleyici kodu, third-party/cmp.js içinde tanımlanan bir tıklama işleyiciden (scripts.sourceURL konumundan) başlar.

Bu veriler, optimizasyon yapmamız gereken yerleri anlamak için yeterlidir.

6. Birden fazla etkinlik işleyici

Geliştirici Araçları konsolunun temizlenmesi ve çerez izni etkileşiminin artık en uzun etkileşim olmaması için sayfayı yenileyin.

Arama kutusuna yazmaya başlayın. İlişkilendirme verileri neleri gösterir? Sizce neler oluyor?

İlişkilendirme verileri

İlk olarak, demoyu test etme örneğinin üst düzey bir taraması:

{
  name: 'INP',
  value: 1072,
  rating: 'poor',
  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'keyboard',

    inputDelay: 3.3,
    processingDuration: 1060.6,
    presentationDelay: 8.1,

    processedEventEntries: [...],
    longAnimationFrameEntries: [...],
  }
}

Bu, input#search-terms öğesiyle klavye etkileşiminden kaynaklanan düşük bir INP değeridir (CPU sınırlaması etkin). Sürenin büyük bir kısmı (toplam 1.072 milisaniyelik INP'nin 1.061 milisaniyesi) işleme süresinde harcandı.

Ancak scripts girişleri daha ilgi çekici.

Düzen karmaşası

scripts dizisinin ilk girişi bize değerli bir bağlam sunar:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 4875.6,
  executionStart: 4875.6,
  duration: 497,
  forcedStyleAndLayoutDuration: 388,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'handleSearch',
  sourceCharPosition: 940
},
...]

İşleme süresinin büyük bir kısmı, bu komut dosyası yürütülürken gerçekleşir. Bu, input işleyicisidir (çağıran INPUT#search-terms.oninput). İşlev adı (handleSearch) ve index.js kaynak dosyasındaki karakter konumu verilir.

Ancak yeni bir özellik var: forcedStyleAndLayoutDuration. Bu, tarayıcının sayfayı yeniden düzenlemeye zorlandığı bu komut dosyası çağrısında harcanan süredir. Diğer bir deyişle, bu etkinlik işleyicinin yürütülmesine harcanan sürenin% 78'i (497 milisaniyenin 388 milisaniyesi) aslında düzen karmaşasıyla geçirilmiştir.

Bu sorun, düzeltilmesi gereken en önemli sorunlardan biridir.

Tekrar dinleyenler

Aşağıdaki iki komut dosyası girişinde tek tek ele alındığında özellikle dikkat çekici bir durum yoktur:

scripts: [...,
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5375.3,
  executionStart: 5375.3,
  duration: 124,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526,
},
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5673.9,
  executionStart: 5673.9,
  duration: 95,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526
}]

Her iki giriş de keyup dinleyicidir ve biri diğerinin hemen ardından yürütülür. Dinleyiciler anonim işlevlerdir (bu nedenle sourceFunctionName mülkünde hiçbir şey bildirilmez) ancak yine de bir kaynak dosyamız ve karakter konumumuz vardır. Bu sayede kodun nerede olduğunu bulabiliriz.

İlginç olan, ikisinin de aynı kaynak dosyadan ve karakter konumundan gelmesidir.

Tarayıcı, tek bir animasyon karesinde birden fazla tuşa basma işlemini işledi ve bu da bu etkinlik işleyicinin herhangi bir şey çizilmeden önce iki kez çalışmasına neden oldu.

Bu etki, etkinlik dinleyicilerinin tamamlanması ne kadar uzun sürerse o kadar fazla ek giriş etkinliğinin gelmesiyle birleşebilir ve yavaş etkileşimi daha da uzatabilir.

Bu bir arama/otomatik tamamlama etkileşimi olduğundan, girişin ardışık tekrarı iyi bir strateji olacaktır. Böylece kare başına en fazla bir tuşa basma işlemi işlenir.

7. Giriş gecikmesi

Giriş gecikmelerinin tipik nedeni (kullanıcının etkileşimde bulunması ile bir etkinlik dinleyicisinin etkileşimi işlemeye başlaması arasındaki süre), ana iş parçacığının meşgul olmasıdır. Bunun birden fazla nedeni olabilir:

  • Sayfa yükleniyor ve ana iş parçacığı, DOM'u ayarlama, sayfayı düzenleme ve stil verme, komut dosyalarını değerlendirme ve çalıştırma gibi ilk işlemleri yapmakla meşgul.
  • Sayfa genellikle yoğundur (ör. hesaplamalar, komut dosyasına dayalı animasyonlar veya reklamlar çalıştırılıyordur).
  • Önceki etkileşimlerin işlenmesi çok uzun sürdüğünden gelecekteki etkileşimler gecikiyor. Bu durum, son örnekte görülmüştü.

Demo sayfasında, sayfanın üst kısmındaki salyangoz logosunu tıkladığınızda animasyon yapmaya ve ana iş parçacığında yoğun JavaScript işlemleri gerçekleştirmeye başlayan gizli bir özellik bulunur.

  • Animasyonu başlatmak için salyangoz logosunu tıklayın.
  • JavaScript görevleri, salyangoz zıplamanın en alt noktasında olduğunda tetiklenir. Sayfayla, hemen çıkma işleminin en alt kısmına mümkün olduğunca yakın bir noktada etkileşim kurmayı deneyin ve ne kadar yüksek bir INP tetikleyebileceğinizi görün.

Örneğin, salyangoz zıplarken arama kutusunu tıklama ve odaklama gibi başka hiçbir etkinlik dinleyicisini tetiklemeseniz bile ana iş parçacığı çalışması, sayfanın fark edilebilir bir süre boyunca yanıt vermemesine neden olur.

Birçok sayfada ana iş parçacığının yoğun çalışması bu kadar düzenli olmayacaktır ancak bu, INP ilişkilendirme verilerinde nasıl tanımlanabileceğini görmek için iyi bir örnektir.

Aşağıda, yavaş yönlendirme sırasında yalnızca arama kutusuna odaklanarak yapılan bir ilişkilendirme örneği verilmiştir:

{
  name: 'INP',
  value: 728,
  rating: 'poor',

  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'pointer',

    inputDelay: 702.3,
    processingDuration: 4.9,
    presentationDelay: 20.8,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 2064.8,
      duration: 790,

      renderStart: 2065,
      styleAndLayoutStart: 2854.2,
      firstUIEventTimestamp: 0,
      blockingDuration: 740,

      scripts: [{...}]
    }]
  }
}

Tahmin edildiği gibi, etkinlik dinleyicileri hızlı bir şekilde yürütüldü.İşleme süresi 4, 9 milisaniye olarak gösterildi ve kötü etkileşimin büyük bir kısmı giriş gecikmesinde harcandı.Toplam 728 milisaniyenin 702, 3 milisaniyesi giriş gecikmesiyle geçti.

Bu durumu ayıklamak zor olabilir. Kullanıcının neyle ve nasıl etkileşimde bulunduğunu bilmemize rağmen, etkileşimin bu kısmının hızlıca tamamlandığını ve sorun olmadığını da biliyoruz. Bunun yerine, sayfadaki başka bir şey etkileşimin işlenmeye başlamasını geciktiriyordu. Ancak aramaya nereden başlayacağımızı nasıl bilecektik?

LoAF komut dosyası girişleri, günü kurtarmak için burada:

scripts: [{
  name: 'script',
  invoker: 'SPAN.onanimationiteration',
  invokerType: 'event-listener',

  startTime: 2065,
  executionStart: 2065,
  duration: 788,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'cryptodaphneCoinHandler',
  sourceCharPosition: 1831
}]

Bu işlevin etkileşimle hiçbir ilgisi olmasa da animasyon karesini yavaşlattığı için etkileşim etkinliğiyle birleştirilen LoAF verilerine dahil edilir.

Bu sayede, etkileşim işlemesini geciktiren işlevin nasıl tetiklendiğini (bir animationiteration dinleyici tarafından), tam olarak hangi işlevin sorumlu olduğunu ve kaynak dosyalarımızda nerede bulunduğunu görebiliriz.

8. Sunum gecikmesi: Güncelleme boyanmadığında

Sunum gecikmesi, etkinlik dinleyicilerinin çalışması tamamlandıktan sonra tarayıcının ekrana yeni bir çerçeve çizerek kullanıcıya görünür geri bildirim göstermesine kadar geçen süreyi ölçer.

INP değerini tekrar sıfırlamak için sayfayı yenileyin, ardından hamburger menüyü açın. Açılırken kesinlikle bir aksaklık var.

Neler yapılabilir?

{
  name: 'INP',
  value: 376,
  rating: 'needs-improvement',
  delta: 352,

  attribution: {
    interactionTarget: '#sidenav-button>svg',
    interactionType: 'pointer',

    inputDelay: 12.8,
    processingDuration: 14.7,
    presentationDelay: 348.5,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 651,
      duration: 365,

      renderStart: 673.2,
      styleAndLayoutStart: 1004.3,
      firstUIEventTimestamp: 138.6,
      blockingDuration: 315,

      scripts: [{...}]
    }]
  }
}

Bu sefer yavaş etkileşimin büyük bir kısmını sunum gecikmesi oluşturuyor. Yani ana iş parçacığını engelleyen her şey, etkinlik dinleyicileri tamamlandıktan sonra gerçekleşir.

scripts: [{
  entryType: 'script',
  invoker: 'FrameRequestCallback',
  invokerType: 'user-callback',

  startTime: 673.8,
  executionStart: 673.8,
  duration: 330,

  sourceURL: 'http://localhost:8080/js/side-nav.js',
  sourceFunctionName: '',
  sourceCharPosition: 1193,
}]

scripts dizisindeki tek girişe baktığımızda, FrameRequestCallback tarihinden itibaren user-callback tarihinde harcanan süreyi görüyoruz. Bu kez sunu gecikmesine requestAnimationFrame geri çağırması neden oluyor.

9. Sonuç

Alan verilerini toplama

Tek bir sayfa yüklemesinden gelen tek bir INP ilişkilendirme girişine bakıldığında bu durumun daha kolay olduğu unutulmamalıdır. Bu veriler, alan verilerine dayalı INP'yi hata ayıklamak için nasıl toplanabilir? Faydalı ayrıntıların miktarı, bu durumu daha da zorlaştırıyor.

Örneğin, hangi sayfa öğesinin yavaş etkileşimlerin yaygın bir kaynağı olduğunu bilmek son derece faydalıdır. Ancak sayfanızda derlenmiş ve derlemeden derlemeye değişen CSS sınıf adları varsa aynı öğedeki web-vitals seçiciler derlemeler arasında farklı olabilir.

Bunun yerine, neyin en faydalı olduğunu ve verilerin nasıl toplanabileceğini belirlemek için kendi uygulamanızı düşünmeniz gerekir. Örneğin, ilişkilendirme verilerini geri göndermeden önce web-vitals seçiciyi, hedefin bulunduğu bileşene veya hedefin karşıladığı ARIA rollerine göre kendi tanımlayıcınızla değiştirebilirsiniz.

Benzer şekilde, scripts girişlerinin sourceURL yollarında, birleştirilmelerini zorlaştıran dosya tabanlı karma değerler olabilir. Ancak verileri geri işaretlemeden önce, bilinen derleme sürecinize göre karma değerleri kaldırabilirsiniz.

Maalesef bu kadar karmaşık verilerle kolay bir yol yoktur ancak verilerin bir alt kümesini kullanmak bile hata ayıklama sürecinde hiç ilişkilendirme verisi olmamasından daha değerlidir.

Her yerde eser sahibinin belirtilmesi

LoAF tabanlı INP ilişkilendirmesi, güçlü bir hata ayıklama aracıdır. INP sırasında tam olarak ne olduğu hakkında ayrıntılı veriler sunar. Çoğu durumda, optimizasyon çalışmalarınıza başlamanız gereken komut dosyasındaki tam konumu size gösterebilir.

Artık herhangi bir sitede INP ilişkilendirme verilerini kullanmaya hazırsınız.

Bir sayfayı düzenleme erişiminiz olmasa bile, bulabileceklerinizi görmek için Geliştirici Araçları konsolunda aşağıdaki snippet'i çalıştırarak bu codelab'deki süreci yeniden oluşturabilirsiniz:

const script = document.createElement('script');
script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';
script.onload = function () {
  webVitals.onINP(console.log, {reportAllChanges: true});
};
document.head.appendChild(script);

Daha fazla bilgi