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

1. Giriş

Bu, web-vitals kitaplığını kullanarak Interaction to Next Paint (INP)'yi nasıl ölçeceğinizi öğrenmek için hazırlanmış etkileşimli bir codelab'dir.

Ön koşullar

• HTML ve JavaScript geliştirme hakkında bilgi sahibi olmanız gerekir.
• Önerilen: web.dev INP metrik belgelerini okuyun.

Öğrenecekleriniz

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

İhtiyacınız olanlar

• GitHub'dan kod 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ünü edinin.

2. Hazırlanın

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ı deneme

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

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

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

Diğer Araçlar > Geliştirici Araçları menüsünden, sayfayı sağ tıklayıp İncele'yi seçerek veya klavye kısayolunu kullanarak Geliştirici Araçları'nı açın.

Bu codelab'de hem Performans panelini hem de Konsol'u kullanacağız. DevTools'un üst kısmındaki sekmelerden dilediğiniz zaman bunlar arasında geçiş yapabilirsiniz.

• INP sorunları genellikle mobil cihazlarda ortaya çıkar. Bu nedenle, mobil ekran emülasyonuna geçin.
• Masaüstü veya dizüstü bilgisayarda test ediyorsanız performans, gerçek bir mobil cihaza kıyasla büyük olasılıkla önemli ölçüde daha iyi olacaktır. Performansı daha gerçekçi bir şekilde incelemek için Performans panelinin sağ üst kısmındaki dişli simgesini tıklayın ve CPU'yu 4 kat yavaşlat'ı seçin.

Dilerseniz her iki paneli de aynı anda açık tutabilirsiniz. Performans paneline geçin ve ardından konsolu açmak için Escape tuşuna basın.

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 ve daha sonra analiz etmek üzere bir analiz uç noktasına işaretçi gönderebilirsiniz. Böylece, yavaş etkileşimlerin ne zaman ve nerede gerçekleştiğini anlayabilirsiniz.

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

Bu codelab, belirli bir derleme sürecine girmemek için npm'den yüklenir ve komut dosyasını doğrudan yükler.

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

• Bir sayfa yüklemesinde 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 sahip olduğunu 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 çalıştırarak web-vitals'ü projenin devDependencies'ine ekleme

Sayfaya web-vitals ekleme:

Komut dosyasının ilişkilendirme sürümünü index.html'ün 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

Console açıkken sayfayla tekrar etkileşim kurmayı deneyin. Sayfada tıklama yaptığınız sırada hiçbir şey günlüğe kaydedilmez.

INP, bir sayfanın tüm yaşam döngüsü boyunca ölçülür. Bu nedenle, varsayılan olarak web-vitals, kullanıcı sayfadan ayrılana veya sayfayı kapatana kadar INP'yi bildirmez. Bu, analizler gibi bir şey için işaretçi gönderme işleminde ideal davranıştır ancak etkileşimli olarak hata ayıklama için ideal değildir.

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

Seçeneği komut dosyasına eklemeyi ve sayfayla tekrar etkileşim kurmayı deneyin:

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

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

Sayfayı yenileyin. Artık etkileşimler konsola raporlanır ve en yavaş etkileşim değiştiğinde güncellenir. Örneğin, arama kutusuna bir şeyler yazıp girişi silmeyi deneyin.

5. İlişkilendirmede neler bulunur?

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

Birçok sayfada, çerezler kullanıcı tarafından kabul edildiğinde eşzamanlı olarak tetiklenmesi gereken çerezlere ihtiyaç duyan komut dosyaları bulunur. Bu da tıklamanın yavaş bir etkileşime dönüşmesine neden olur. Burada olan budur.

Çerez iznini daha önce reddettiyseniz demoyu tekrar görmek için demonun yerel depolama alanını temizlemeniz gerekebilir. Tarayıcı konum çubuğundaki URL'nin yanındaki bilgi simgesini tıklayın, Çerezler ve site verileri'ni, ardından Cihaz üzerindeki site verilerini yönet'i seçin ve "localhost"in yanındaki çöp kutusu simgesini tıklayarak verileri temizleyin. Sayfayı yenilediğinizde çerez izni iletişim kutusu yeniden görünür.

Çerezleri (demo) kabul etmek için Evet'i tıklayın ve DevTools konsoluna kaydedilen INP verilerine göz atın.

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

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

Kullanıcının tıklamasından sonraki bir sonraki boyamaya kadar geçen süre 344 milisaniyeydi. Bu, "iyileştirme gerektiren" bir INP'dir. entries dizisi, bu etkileşimle ilişkili tüm PerformanceEntry değerlerini (bu durumda yalnızca bir tıklama etkinliği) içerir.

Ancak bu süre zarfında neler olduğunu öğrenmek için en çok attribution mülkünü incelemek istiyoruz. İlişkilendirme verilerini oluşturmak için web-vitals, tıklama etkinliğiyle çakışık olan uzun animasyon çerçevesini (LoAF) bulur. LoAF, çalıştırılan komut dosyalarından requestAnimationFrame geri çağırma, stil ve düzende harcanan süreye kadar, ilgili kare sırasında ne kadar sürenin harcandığını ayrıntılı olarak gösterebilir.

Daha fazla bilgi görmek için attribution mülkünü genişletin. Veriler çok daha zengindir.

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

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

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

Öncelikle, etkileşimde bulunulan öğeyle ilgili bilgiler bulunur:

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

Ardından zamanlama üst düzeyde ayrılır:

• inputDelay: Kullanıcının etkileşimi başlattığı (ör. fareyi tıkladığı) andan bu etkileşimin etkinlik işleyicisinin çalışmaya başladığı ana kadar geçen süre. Bu durumda, CPU sınırlaması açıkken bile giriş gecikmesi yalnızca yaklaşık 27 milisaniyeydi.
• processingDuration: Etkinlik işleyicilerin tamamlanması için geçen süre. Sayfalarda genellikle tek bir etkinlik için birden fazla dinleyici bulunur (örneğin, pointerdown, pointerup ve click). Bunların tümü aynı animasyon çerçevesinde çalıştırılırsa bu süre içinde 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ı tamamlamasına kadar geçen süre. Bu durumda 21, 4 milisaniye.

Bu INP aşamaları, optimize edilmesi gerekenlerin teşhisi için önemli bir sinyal olabilir. INP'yi optimize etme kılavuzunda bu konu hakkında daha fazla bilgi yer almaktadır.

Daha ayrıntılı olarak incelediğimizde, üst düzey INP entries dizisindeki tek etkinliğin aksine processedEventEntries beş etkinlik içerir. 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', ...},
],

Üst düzey giriş, INP etkinliğidir (bu durumda bir tıklama). İlişkilendirme processedEventEntries, aynı çerçevede işlenen tüm etkinliklerdir. Yalnızca tıklama etkinliğini değil, mouseover ve mousedown gibi diğer etkinlikleri de içerdiğini unutmayın. Bu diğer etkinlikler de yavaşsa yanıt süresinin yavaşlamasına katkıda bulundukları için bu etkinlikler hakkında bilgi sahibi olmak hayati önem taşıyabilir.

Son olarak longAnimationFrameEntries dizisi var. Bu tek bir giriş olabilir ancak etkileşimin birden fazla kareyi kapsayabileceğ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şturmak için harcanan süreyi ayırmak gibi birçok yararlı değer vardır. Long Animation Frames API makalesinde bu özellikler hakkında daha ayrıntılı bilgi verilmektedir. Şu anda öncelikle, uzun süre çalışan çerçeveden sorumlu komut dosyalarıyla ilgili ayrıntılar sağlayan girişler içeren scripts mülküyle 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 öncelikle BUTTON#confirm.onclick'te çağrılan tek bir event-listener içinde harcandığını söyleyebiliriz. Hatta komut dosyası kaynak URL'sini ve işlevin tanımlandığı karakter konumunu bile görebiliriz.

Paket servis

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

• Etkileşim, button#confirm öğesinin tıklanmasıyla (attribution.interactionTarget ve bir komut dosyası ilişkilendirme girişindeki invoker mülkünden) tetiklendi.
• Zaman, temel olarak etkinlik dinleyicilerini yürütmek için harcanmıştır (toplam value metriğine kıyasla attribution.processingDuration).
• Yavaş etkinlik işleyici kodu, third-party/cmp.js'te (scripts.sourceURL'ten) tanımlanan bir tıklama işleyiciden başlar.

Bu, nerede optimizasyon yapmamız gerektiğini bilmemiz için yeterli veridir.

6. Birden fazla etkinlik işleyici

DevTools konsolunun net olması 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 neyi gösterir? Ne olduğunu düşünüyorsunuz?

İlişkilendirme verileri

Öncelikle, demo testinin bir örneğinin üst düzey 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: [...],
  }
}

input#search-terms öğesiyle klavye etkileşiminden elde edilen düşük bir INP değeridir (CPU tarama etkin). Sürelerin büyük bir kısmı (toplam 1.072 milisaniyelik INP'den 1.061 milisaniye) işleme süresine harcanmıştır.

Ancak scripts girişleri daha ilginçtir.

Düzen aşırı bellek kullanımı

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

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 kısmı, bir input dinleyicisi olan bu komut dosyası yürütülmesi sırasında gerçekleşir (çağrıcı INPUT#search-terms.oninput'dır). İşlev adı (handleSearch) ve index.js kaynak dosyasındaki karakter konumu verilir.

Ancak yeni bir mülk var: forcedStyleAndLayoutDuration. Bu, tarayıcının sayfayı yeniden düzenlemeye zorlandığı bu komut dosyası çağrısı sırasında harcanan süredir. Diğer bir deyişle, bu etkinlik dinleyicisinin yürütülmesi için harcanan sürenin% 78'i (497 milisaniyeden 388 milisaniye) aslında düzenin yeniden düzenlenmesi için harcanmıştır.

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

Tekrar dinleyen kullanıcılar

Aşağıdaki iki komut dosyası girişinde tek tek dikkate değer bir şey 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 dinleyicisidir ve biri diğerinden hemen sonra yürütülür. Dinleyiciler anonim işlevlerdir (bu nedenle sourceFunctionName mülkünde hiçbir şey raporlanmaz), ancak yine de bir kaynak dosyamız ve karakter konumumuz olduğu için kodun nerede olduğunu bulabiliriz.

Tuhaf olan, her ikisinin de aynı kaynak dosyadan ve karakter konumundan gelmesidir.

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

Bu etki, etkinlik dinleyicilerinin tamamlanması ne kadar uzun sürerse o kadar fazla ek giriş etkinliği gelebileceği ve yavaş etkileşimin çok daha uzun süreceği şekilde de artabilir.

Bu bir arama/otomatik tamamlama etkileşimi olduğundan, girişin tıklama seslerini kaldırmak iyi bir strateji olacaktır. Böylece, kare başına en fazla bir tuş basma işlemi işlenir.

7. Giriş gecikmesi

Giriş gecikmelerinin (kullanıcı etkileşime geçtiği andan bir etkinlik dinleyicisinin etkileşimi işlemeye başlayabileceği ana kadar geçen süre) tipik nedeni, ana iş parçacığının meşgul olmasıdır. Bunun birden fazla nedeni olabilir:

• Sayfa yüklenirken ana iş parçacığı, DOM'u ayarlama, sayfayı biçimlendirme ve stillendirme, komut dosyalarını değerlendirme ve çalıştırma gibi ilk işlemleri yapmakla meşguldür.
• Sayfa genellikle meşguldür (ör. hesaplamalar, komut dosyası tabanlı animasyonlar veya reklamlar çalışır).
• Önceki etkileşimlerin işlenmesi o kadar uzun sürer ki sonraki etkileşimleri geciktirir. Bu durum son örnekte gösterilmiştir.

Demo sayfasında, sayfanın üst kısmındaki salyangoz logosunu tıkladığınızda animasyonlu bir hareketin başlamasına ve yoğun ana iş parçacığı JavaScript çalışmasının yapılmasına neden olan gizli bir özellik vardır.

• Animasyonu başlatmak için salyangoz logosunu tıklayın.
• JavaScript görevleri, salyangoz sekmenin en altındayken tetiklenir. Sayfayla, hemen çıkma oranının en altı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, başka bir etkinlik dinleyicisi tetiklemeseniz bile (ör. salyangoz sıçradığı anda arama kutusunu tıklayıp odaklamanız) ana iş parçacığı çalışması, sayfanın belirgin bir süre boyunca yanıt vermemesi sorununa neden olur.

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

Aşağıda, salyangoz sıçraması sırasında yalnızca arama kutusuna odaklanan 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 çalıştırıldı ve 4, 9 milisaniyelik bir işlem süresi gösterildi. Kötü etkileşimin büyük çoğunluğu giriş gecikmesinde harcandı ve toplam 728 milisaniyeden 702, 3 milisaniye sürdü.

Bu durumda hatayı gidermek zor olabilir. Kullanıcının neyle ve nasıl etkileşime geçtiğini bilmemize rağmen etkileşimin bu kısmının hızlı bir şekilde tamamlandığını ve sorun olmadığını da biliyoruz. Bunun yerine, sayfadaki başka bir şey etkileşimin işlenmeye başlamasını geciktiriyordu. Ancak nereden bakacağımızı nasıl bilebilirdik?

LoAF komut dosyası girişleri günü kurtarmaya hazırdır:

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 çerçevesini yavaşlattığı için etkileşim etkinliğiyle birleştirilen LoAF verilerine dahil edilir.

Bu sayede, etkileşim işlemenin gecikmesine neden olan 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: Bir güncelleme boyanmıyorsa

Gösterim gecikmesi, etkinlik dinleyicilerinin çalışmayı tamamlamasından tarayıcı ekrana yeni bir kare çizip kullanıcıya görünür geri bildirim gösterene kadar geçen süreyi ölçer.

INP değerini tekrar sıfırlamak için sayfayı yenileyin, ardından hamburger menüsünü açın. Açıldığında kesinlikle bir sorun var.

Bu nasıl görünür?

{
  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 kez yavaş etkileşimin büyük kısmını sunu gecikmesi oluşturuyor. Yani ana iş parçacığının engellenmesine neden olan ş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, sürenin FrameRequestCallback kaynağından gelen bir user-callback içinde harcandığını görüyoruz. Bu sefer sunu gecikmesinin nedeni requestAnimationFrame geri çağırma işlemidir.

requestAnimationFrame genellikle animasyonlar için her karede JavaScript'i tetiklemek amacıyla kullanıldığından, sonraki kare için geri çağırma işlevi tetikliyormuş gibi düşünülmesi kolaydır. Ancak aslında mevcut kare tarayıcı tarafından boyanmadan önce geri çağırma işlevi isteğinde bulunur. Bu, bir etkileşim tarafından tetiklenen yavaş bir requestAnimationFrame geri çağırma işlevinin, söz konusu etkileşimi yavaşlatacağı ve INP'nin kötü olmasına neden olma olasılığını artıracağı anlamına gelir.

9. Sonuç

Alan verilerini toplama

Tek bir sayfa yüklemesinden elde edilen tek bir INP ilişkilendirme girişine bakıldığında tüm bunların daha kolay olduğunu belirtmek gerekir. Alan verilerine göre INP'de hata ayıklama yapmak için bu veriler nasıl toplanabilir? Faydalı ayrıntıların çokluğu bu durumu daha da zorlaştırıyor.

Örneğin, hangi sayfa öğesinin yavaş etkileşimlere yol açtığını bilmek son derece yararlıdır. Ancak sayfanızda derlemeden derlemeye değişen derlenmiş CSS sınıf adları varsa aynı öğenin web-vitals seçicileri derlemeler arasında farklı olabilir.

Bunun yerine, en yararlı olanı ve verilerin nasıl birleştirilebileceğini belirlemek için 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 yerine getirdiği ARIA rollerine göre kendi tanımlayıcınızla değiştirebilirsiniz.

Benzer şekilde, scripts girişlerinin sourceURL yollarında dosya tabanlı karma oluşturma işlemleri olabilir. Bu, verilerin birleştirilmesini zorlaştırır ancak verileri geri göndermeden önce bilinen derleme işleminize göre karma oluşturma işlemlerini kaldırabilirsiniz.

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

Her yerde ilişkilendirme

LoAF tabanlı INP ilişkilendirmesi, güçlü bir hata ayıklama yardımcısıdır. Özellikle bir INP sırasında neler olduğuyla ilgili ayrıntılı veriler sunar. Çoğu durumda, optimizasyon çalışmalarınızı başlatmanız gereken komut dosyası konumunu tam olarak gösterebilir.

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

Bir sayfayı düzenleme erişiminiz olmasa bile, ne bulacağınızı görmek için DevTools konsolunda aşağıdaki snippet'i çalıştırarak bu kod laboratuvarındaki 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

• web.dev: Interaction to Next Paint
• web.dev: Alanda yavaş etkileşimleri bulma
• web.dev: Interaction to Next Paint'i optimize etme
• INP codelab'i anlama