Dlaczego optymalizacja wskaźnika INP jest trudna?
Optymalizacja wydajności interakcji względem wskaźnika INP jest trudna, gdyż jedynie nas naprowadza, co jest powodem problemów. Nadal wymagana jest późniejsza manualna analiza nagranej interakcji np. przez DevTools Performance.
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.
Jeżeli chciał(a)byś dołączyć do kursu Wydajne Interakcje na Frontendzie - przejdź na stronę szkolenia online.