Musimy zerknąć na główny wątek przeglądarki i skorelować to z długimi zadaniami (Long Tasks). Dane z INP wysyłane do usług RUM na bazie Long Tasks API choć przydatne, nie są w 100% efektywne i nie zawierają aż tylu zaawansowanych informacji, aby precyzyjnie określić źródło problemu w kodzie.

Alternatywnym podejściem do analizy długich zadań jest analiza długo wykonujących się klatek, dzięki Long Animation Frames API (na razie jest to eksperymentalny interfejs Google'a). Jeśli INP traktuje o szybkości reakcji w postaci wizualnej zmiany dla użytkownika, badanie szybkości renderowania kolejnych klatek na stronie jest zatem bardziej akuratne, a proponowane API precyzyjniej określa przyczynę problemu w kodzie. Wiele płatnych systemów RUM loguje już dane z tego inferfejsu.

Na chwilę obecną LoAF jest eksperymentalnym API. Rekomenduje się manualną analizę wydajności nagranej interakcji przez DevTools Performance, a korzystanie z LoAF API powinno być wykorzystywane jedynie jako dodatkowa pomoc.

LoAF - skrypt JS, by logować wyniki do konsoli w DevTools:

const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
    for (const entry of list.getEntries()) {
      if (entry.duration > REPORTING_THRESHOLD_MS &&
        entry.firstUIEventTimestamp > 0
      ) {
        console.log(entry);
      }
    }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Poniżej znajdziesz lekcję wideo z kursu o optymalizacji wydajności interakcji względem wskaźnika INP.

Lekcja z kursu Wydajne Interakcje na Frontendzie o optymalizacji wskaźnika INP

Jeżeli chciał(a)byś dołączyć do kursu Wydajne Interakcje na Frontendzie - przejdź na stronę szkolenia online.

Mój kurs optymalizacji INP