Dowiedz się, jak zoptymalizować czas od interakcji do kolejnego wyrenderowania w witrynie.
Data publikacji: 19 maja 2023 r., ostatnia aktualizacja: 3 czerwca 2025 r.
Interakcja do kolejnego wyrenderowania (INP) to stabilny podstawowy wskaźnik internetowy, który ocenia ogólną responsywność strony na interakcje użytkowników na podstawie obserwacji czasu oczekiwania na wszystkie kwalifikujące się interakcje, które występują w całym okresie wizyty użytkownika na stronie. Ostateczna wartość INP to najdłuższa zaobserwowana interakcja (czasami z pominięciem wartości odstających).
Aby wygodnie korzystać z witryny, użytkownicy powinni mieć 200 milisekund lub mniej od interakcji do kolejnego wyrenderowania. Aby osiągnąć ten cel w przypadku większości użytkowników, warto mierzyć 75. percentyl wczytywania stron na urządzeniach mobilnych i stacjonarnych.
W zależności od witryny interakcje mogą być rzadkie lub w ogóle ich nie ma. Przykładem mogą być strony, które zawierają głównie tekst i obrazy, a mają niewiele lub w ogóle nie mają elementów interaktywnych. W przypadku witryn takich jak edytory tekstu czy gry może być nawet kilkaset lub nawet kilka tysięcy interakcji. W obu przypadkach, gdy wskaźnik INP jest wysoki, wrażenia użytkownika są zagrożone.
Poprawa INP wymaga czasu i wysiłku, ale nagrodą są lepsze wrażenia użytkowników. W tym przewodniku omówimy sposób na poprawę INP.
Ustalanie przyczyny niskiej wartości INP
Zanim naprawisz problemy z powolnym wczytywaniem, musisz uzyskać dane, które pozwolą Ci określić, czy INP witryny jest zły czy wymaga poprawy. Gdy już je uzyskasz, możesz przejść do laboratorium, aby rozpocząć diagnostykę powolnego działania interakcji i znaleźć rozwiązanie.
Znajdowanie interakcji o niskiej szybkości w terenie
Optymalizacja INP powinna się zacząć od danych pochodzących z pola. W najlepszym przypadku dane z pola od dostawcy usługi RUM (Real User Monitoring) zawierają nie tylko wartość INP strony, ale też dane kontekstowe, które wskazują, która konkretna interakcja odpowiada za wartość INP, czy interakcja nastąpiła podczas wczytywania strony czy po nim, typ interakcji (kliknięcie, naciśnięcie klawisza lub dotknięcie) oraz inne cenne informacje.
Jeśli nie korzystasz z usługi RUM do uzyskiwania danych z pól, w przewodniku po danych z pól w INP znajdziesz zalecenie wyświetlania danych z raportu na temat użytkowania Chrome (CrUX) za pomocą PageSpeed Insights, aby uzupełnić luki. CrUX to oficjalny zbiór danych programu Core Web Vitals, który zawiera ogólne podsumowanie danych dotyczących milionów witryn, w tym INP. Jednak CrUX często nie udostępnia danych kontekstowych, które dostawca RUM udostępnia, aby pomóc w analizowaniu problemów. Dlatego nadal zalecamy, aby strony korzystały w miarę możliwości z usług dostawcy RUM lub wdrożyły własne rozwiązanie RUM, które uzupełnia to, co jest dostępne w CrUX.
Diagnozowanie powolnych interakcji w laboratorium
Najlepiej zacząć testowanie w laboratorium, gdy masz już dane z pola, które wskazują na wolne interakcje. W przypadku braku danych z pola możesz w laboratorium zastosować pewne strategie identyfikowania powolnych interakcji. Takie strategie obejmują śledzenie typowych ścieżek użytkownika i testowanie interakcji na poszczególnych etapach, a także interakcje ze stroną podczas jej wczytywania (gdy główny wątek jest często najbardziej obciążony), aby wykryć powolne interakcje w tym kluczowym momencie ścieżki użytkownika.
Optymalizacja interakcji
Gdy zidentyfikujesz powolną interakcję i ręcznie ją odtworzysz w laboratorium, możesz ją zoptymalizować. Interakcje można podzielić na 3 części:
- Opóźnienie przy pierwszym działaniu, które rozpoczyna się, gdy użytkownik rozpoczyna interakcję ze stroną, a kończy, gdy zaczynają się wywołania zwrotne zdarzeń związane z tą interakcją.
- Czas przetwarzania, który obejmuje czas potrzebny na wywołanie funkcji zwracającej dane o zdarzeniu.
- Opóźnienie wyświetlania, czyli czas potrzebny przeglądarce na wyświetlenie kolejnego klatki zawierającej wizualny wynik interakcji.
Łączna wartość tych 3 podelementów to łączny czas oczekiwania na interakcję. Każda część interakcji przyczynia się do opóźnienia interakcji, dlatego ważne jest, aby wiedzieć, jak zoptymalizować każdą część interakcji, aby trwała jak najkrócej.
Wykrywanie i zmniejszanie opóźnienia wejściowego
Gdy użytkownik wchodzi w interakcję ze stroną, pierwszą częścią tej interakcji jest opóźnienie przy pierwszym działaniu. W zależności od innych działań na stronie opóźnienia w przyjmowaniu danych mogą być znaczne. Może to być spowodowane aktywnością w głównym wątku (np. wczytywaniem, analizowaniem i kompilowaniem skryptów), obsługą pobierania, funkcjami timera lub nawet innymi interakcjami, które występują szybko po sobie i nakładają się na siebie.
Niezależnie od źródła opóźnienia wejścia interakcji, warto je zminimalizować, aby interakcje mogły jak najszybciej wywoływać funkcje wywołujące zdarzenia.
Związek między obliczaniem skryptu a długimi zadaniami podczas uruchamiania
Kluczowym aspektem interakcji w cyklu życia strony jest czas uruchamiania. Podczas wczytywania strony najpierw jest ona renderowana, ale należy pamiętać, że renderowanie nie oznacza, że wczytywanie zostało zakończone. W zależności od tego, ile zasobów wymaga strona, aby działać w pełni, użytkownicy mogą próbować wchodzić z nią w interakcję, gdy jest ona jeszcze wczytywania.
Opóźnienie w wejściu danych podczas wczytywania strony może wydłużać czas interakcji, np. ze względu na interpretację skryptu. Po pobraniu pliku JavaScript z sieci przeglądarka musi jeszcze wykonać kilka czynności, zanim kod JavaScript będzie mógł się uruchomić. Do tych czynności należy zanalizowanie skryptu w celu sprawdzenia poprawności jego składni, skompilowanie go w bajtek i ostatecznie jego wykonanie.
W zależności od rozmiaru skryptu może to spowodować długie wykonywanie zadań w wątku głównym, co opóźnia reagowanie przeglądarki na inne interakcje użytkownika. Aby strona była responsywna na działania użytkownika podczas wczytywania, musisz wiedzieć, jak zmniejszyć prawdopodobieństwo długiego wykonywania zadań podczas wczytywania, aby strona była szybka.
Optymalizacja wywołań zwrotnych zdarzenia
Opóźnienie przy pierwszym działaniu to tylko pierwsza część pomiaru INP. Musisz też zadbać o to, aby funkcje wywoływane przez zdarzenia w odpowiedzi na interakcje z użytkownikiem były wykonywane tak szybko, jak to możliwe.
często wracać do wątku głównego,
Najlepszą ogólną radą dotyczącą optymalizacji wywołań zwrotnych zdarzeń jest to, aby wykonywać w nich jak najmniej pracy. Jednak logika interakcji może być skomplikowana i możesz tylko nieznacznie ograniczyć ilość wykonywanej przez nie pracy.
Jeśli tak jest w przypadku Twojej witryny, możesz spróbować podzielić zadania w zwrotach wywołania zdarzenia na osobne zadania. Zapobiega to temu, aby zbiorcza praca nie stała się długim zadaniem, które blokuje wątek główny. Dzięki temu inne interakcje, które normalnie czekałyby na wątek główny, mogą się uruchomić wcześniej.
setTimeout to jeden ze sposobów dzielenia zadań, ponieważ przekazywana do niego funkcja wywołania zwrotnego jest wykonywana w ramach nowego zadania. Możesz użyć funkcji setTimeout samodzielnie lub umieścić ją w ramach osobnej funkcji , aby uzyskać bardziej ergonomiczne wyniki.
Bezwzględne oddawanie zasobów jest lepsze niż brak oddawania zasobów. Istnieje jednak bardziej wyrafinowany sposób oddawania zasobów wątkowi głównemu. Polega on na oddawaniu zasobów bezpośrednio po wywołaniu zwrotnym zdarzenia, które aktualizuje interfejs użytkownika, aby logika renderowania mogła działać wcześniej.
Yield, aby umożliwić szybsze renderowanie
Bardziej zaawansowana technika rezygnacji polega na ustrukturyzowaniu kodu w funkcjach zwracanych przez zdarzenia w taki sposób, aby ograniczyć wykonywane operacje do logiki wymaganej do zastosowania wizualnych zmian w kolejnych klatkach. Pozostałe zadania można odłożyć na później. Dzięki temu funkcje wywołujące są lekkie i szybkie, a czas renderowania interakcji jest krótszy, ponieważ nie pozwalają one na blokowanie aktualizacji wizualnych przez kod wywołania zdarzenia.
Wyobraź sobie na przykład edytor tekstu, który formatuje tekst podczas pisania, ale także aktualizuje inne aspekty interfejsu w odpowiedzi na to, co zostało napisane (np. zliczanie słów, wyróżnianie błędów ortograficznych i inne ważne informacje wizualne). Aplikacja może też potrzebować zapisać to, co zostało napisane, aby po zamknięciu i powrocie nie stracić żadnych danych.
W tym przykładzie w odpowiedzi na wpisy użytkownika muszą wystąpić 4 działania. Jednak przed wyświetleniem następnej klatki musi zostać wykonane tylko pierwsze zadanie.
- Zaktualizuj pole tekstowe, wpisując w nim tekst użytkownika i zastosuj odpowiednie formatowanie.
- Zaktualizuj część interfejsu, która wyświetla bieżącą liczbę słów.
- Uruchom logikę, aby sprawdzić, czy nie ma literówek.
- Zapisywanie najnowszych zmian (lokalnie lub w zdalnej bazie danych).
Kod, który to umożliwia, może wyglądać tak:
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
Poniższa wizualizacja pokazuje, jak opóźnienie nieistotnych aktualizacji do następnego klatki może skrócić czas przetwarzania, a w konsekwencji zmniejszyć ogólny czas oczekiwania na interakcję.
Użycie w poprzednim przykładzie kodu funkcji setTimeout() w ramach wywołania requestAnimationFrame() jest co prawda nieco ezoteryczne, ale jest to skuteczna metoda, która działa we wszystkich przeglądarkach i zapobiega blokowaniu następnego kadru przez kod niekrytyczny.
Unikaj chaotycznych zmian układu
Zbyt częste układy – czasami nazywane wymuszaniem synchronicznego układu – to problem z wydajnością podczas renderowania, gdy układ jest tworzony synchronicznie. Występuje, gdy aktualizujesz style w JavaScript, a potem odczytujesz je w tym samym zadaniu. W JavaScript jest wiele właściwości, które mogą powodować twarde przeformatowanie układu.
Zmiana układu jest wąskim gardłem wydajności, ponieważ po zaktualizowaniu stylów i natychmiastowym żądaniu wartości tych stylów w JavaScript przeglądarka jest zmuszona do wykonania synchronicznego działania dotyczącego układu, które w przeciwnym razie mogło zostać wykonane asynchronicznie w późniejszym czasie, po zakończeniu działania wywołań zwrotnych zdarzeń.
Minimalizowanie opóźnienia prezentacji
Opóźnienie wyświetlania interakcji obejmuje czas od zakończenia wywołań zwrotnych zdarzenia interakcji do momentu, w którym przeglądarka jest w stanie narysować następny kadr, który pokazuje wynikowe zmiany wizualne.
Minimalizowanie rozmiaru DOM
Jeśli DOM strony jest mały, renderowanie zazwyczaj kończy się szybko. Jednak gdy DOM-y stają się bardzo duże, renderowanie staje się coraz bardziej pracochłonne. Związek między pracą związaną z renderowaniem a rozmiarem DOM nie jest liniowy, ale renderowanie dużych elementów DOM wymaga więcej pracy niż małych. Duży DOM jest problematyczny w 2 przypadkach:
- Podczas początkowego renderowania strony, gdy duży DOM wymaga dużo pracy, aby wyrenderować początkowy stan strony.
- W odpowiedzi na interakcję użytkownika, gdy duży DOM może powodować, że renderowanie aktualizacji będzie bardzo kosztowne, a w konsekwencji wydłuży czas potrzebny przeglądarce na wyświetlenie kolejnego klatki.
Pamiętaj, że w niektórych przypadkach dużych DOM-ów nie można znacząco zmniejszyć. Istnieją pewne metody, które pozwalają zmniejszyć rozmiar modelu DOM, np. spłaszczenie modelu DOM lub dodawanie do modelu DOM podczas interakcji z użytkownikiem, aby zachować mały rozmiar początkowy modelu DOM. Jednak te techniki mają swoje ograniczenia.
Używanie elementu content-visibility do opóźnionego renderowania elementów poza ekranem
Jednym ze sposobów na ograniczenie ilości pracy związanej z renderowaniem podczas wczytywania strony i pracy związanej z renderowaniem w odpowiedzi na interakcje użytkownika jest korzystanie z właściwości CSS content-visibility, która polega na opóźnionym renderowaniu elementów w miarę ich pojawiania się w widocznym obszarze. Chociaż content-visibility wymaga trochę praktyki, aby skutecznie go używać, warto sprawdzić, czy dzięki niemu skróci się czas renderowania, co może poprawić INP strony.
Koszt wydajności podczas renderowania kodu HTML za pomocą JavaScriptu
Tam, gdzie jest HTML, jest też parsowanie HTML. Gdy przeglądarka zakończy parsowanie HTML do elementu DOM, musi zastosować do niego style, wykonać obliczenia układu, a następnie wyrenderować ten układ. Jest to nieunikniony koszt, ale sposób renderowania kodu HTML ma znaczenie.
Gdy serwer wysyła kod HTML, trafia on do przeglądarki jako strumień. Strumieniowanie oznacza, że odpowiedź HTML z serwera jest dostarczana w kawałkach. Przeglądarka optymalizuje sposób obsługi strumienia, stopniowo analizując jego fragmenty w miarę ich pojawiania się i renderując je po kawałku. Jest to optymalizacja pod kątem wydajności, która polega na tym, że przeglądarka okresowo i automatycznie wczytuje strony, a Ty nie płacisz za to.
Podczas pierwszej wizyty w dowolnej witrynie zawsze jest wczytywane trochę kodu HTML. Jednak zwykle najpierw wczytuje się minimalną ilość kodu HTML, a do wypełniania obszaru treści używa się kodu JavaScript. Kolejne aktualizacje tego obszaru treści również mają miejsce w wyniku interakcji użytkowników. Jest to zwykle nazywane modelem aplikacji jednostronicowej (SPA). Jednym z mankamentów tego wzorca jest to, że renderowanie kodu HTML za pomocą JavaScriptu po stronie klienta wiąże się nie tylko z koszty przetwarzania JavaScriptu na potrzeby tworzenia kodu HTML, ale też z tym, że przeglądarka nie zwróci wyniku, dopóki nie zakończy analizowania i renderowania kodu HTML.
Pamiętaj jednak, że nawet witryny, które nie są SPA, prawdopodobnie będą zawierać pewne elementy renderowania HTML za pomocą JavaScriptu w ramach interakcji. Jest to zazwyczaj w porządku, o ile nie renderujesz dużych ilości kodu HTML po stronie klienta, co może opóźnić prezentację następnego klatki. Ważne jest jednak, aby zrozumieć wpływ tego podejścia do renderowania kodu HTML w przeglądarce na wydajność oraz to, jak może ono wpływać na responsywność witryny na działania użytkownika, jeśli renderujesz dużo kodu HTML za pomocą JavaScriptu.
Podsumowanie
Ulepszanie INP witryny to proces iteracyjny. Gdy naprawisz wolne działanie interakcji w polu, istnieje duże prawdopodobieństwo, że – zwłaszcza jeśli Twoja witryna jest bardzo interaktywna – zaczniesz znajdować inne wolno działające interakcje, które również musisz zoptymalizować.
Kluczem do poprawy INP jest wytrwałość. Z czasem możesz doprowadzić do tego, że użytkownicy będą zadowoleni z wygody korzystania ze strony. Jest też spora szansa, że podczas opracowywania nowych funkcji dla użytkowników będziesz musiał przejść przez ten sam proces optymalizacji interakcji z nimi. Zajmie to trochę czasu i wysiłku, ale warto.
Obraz główny z Unsplash autorstwa Davida Pisnoy, zmodyfikowany zgodnie z licencją Unsplash.