Jak nowoczesne platformy radzą sobie z nowym wskaźnikiem INP

Dowiedz się, jak nowy wskaźnik INP wpływa na działanie witryn utworzonych za pomocą platform i bibliotek JavaScript.

Lena Sohoni
Leena Sohoni
Addy Osmanii
Addy Osmani
Keen Yee Liau
Keen Yee Liau

W raporcie na temat użytkowania Chrome w Chrome pojawiły się niedawno nowe eksperymentalne dane dotyczące reagowania. Te dane, które teraz znamy jako Interakcja przy kolejnym wyrenderowaniu (INP), służą do pomiaru ogólnej responsywności na interakcje użytkowników na stronie. Dziś chcemy podzielić się spostrzeżeniami na temat tego, gdzie w odniesieniu do tego wskaźnika znajdują się witryny utworzone z wykorzystaniem nowoczesnych platform JavaScript. Chcemy porozmawiać o tym, dlaczego INP ma znaczenie dla platform oraz jak Aurora i platformy pomagają optymalizować czas reagowania.

Wprowadzenie

Chrome używa opóźnienia przy pierwszym działaniu (FID) jako jednego z podstawowych wskaźników internetowych (CWV) do pomiaru czasu reakcji stron na wczytywanie. FID to czas oczekiwania od pierwszej interakcji użytkownika do momentu, w którym przeglądarka jest w stanie przetworzyć moduły obsługi zdarzeń połączone z tą interakcją. Nie obejmuje to czasu na przetworzenie modułów obsługi zdarzeń, przetwarzanie kolejnych interakcji na tej samej stronie ani na wyrenderowanie następnej ramki po uruchomieniu wywołań zwrotnych zdarzenia. Jednak responsywność ma kluczowe znaczenie dla wygody użytkowników w całym cyklu życia strony, ponieważ po jej załadowaniu użytkownicy spędzają około 90% czasu na stronie.

INP mierzy czas potrzebny do zareagowania na interakcje użytkownika przez stronę internetową od momentu rozpoczęcia interakcji do momentu wyrenderowania następnej klatki na ekranie. Mamy nadzieję, że dzięki INP uda nam się włączyć pomiar postrzeganego opóźnienia wszystkich interakcji w cyklu życia strony. Sądzimy, że INP pozwala dokładniej oszacować czas wczytywania stron internetowych i czas reakcji.

FID mierzy tylko opóźnienie wejściowe pierwszej interakcji, więc prawdopodobnie programiści stron internetowych nie zoptymalizowali późniejszych interakcji w ramach procesu ulepszania CWV. Witryny, zwłaszcza te o wysokim stopniu interaktywności, musiałyby popracować nad osiągnięciem dobrych wyników w tym zakresie.

Rola platform

Ponieważ wiele witryn korzysta z JavaScriptu, aby zapewnić interaktywność, na wynik INP wpływa przede wszystkim ilość kodu JavaScript przetworzonego w wątku głównym. Platformy JavaScript są niezbędnym elementem nowoczesnych interfejsów internetowych i zapewniają deweloperom cenne streszczenia routingu, obsługi zdarzeń i dzielenia kodu JavaScript na segmenty. Odgrywają one kluczową rolę w optymalizacji reagowania i wygody użytkowników witryn, które z nich korzystają.

Platformy mogły podjąć kroki w celu zwiększenia responsywności przez ulepszenie FID na wcześniejszych stronach. W tym celu musiałby jednak teraz przeanalizować dostępne dane dotyczące czasu reagowania i wyeliminować wszelkie wykryte luki. Ogólnie rzecz biorąc, INP ma niższe współczynniki odrzuceń, a różnica w procesie pomiaru wymaga dodatkowej optymalizacji kodu. W poniższej tabeli znajdziesz podsumowanie tych przyczyn.

FID INP
Pomiary Mierzy czas upływający między pierwszym działaniem użytkownika a czasem uruchomienia odpowiedniego modułu obsługi zdarzeń. Mierzy ogólny czas oczekiwania na interakcję przy użyciu opóźnienia
Zależy od Dostępność wątku głównego do uruchomienia modułu obsługi zdarzeń wymaganego przy pierwszej interakcji. Wątek główny może zostać zablokowany, ponieważ podczas wstępnego wczytywania strony przetwarza on inne zasoby. Dostępność głównego wątku i rozmiar skryptu wykonywanego przez moduły obsługi zdarzeń w przypadku różnych interakcji, w tym pierwszej interakcji.
Główna przyczyna słabych wyników Słaby parametr FID jest spowodowany głównie dużym wykonywaniem kodu JavaScript w wątku głównym. Obsługa zdarzeń JavaScript i inne zadania renderowania po uruchomieniu modułów obsługi zdarzeń może skutkować niską wartością INP.
Optymalizacja FID można zoptymalizować, ulepszając ładowanie zasobów podczas wczytywania strony i optymalizując kod JavaScript. Podobne do FID w przypadku każdej interakcji oraz z wykorzystaniem wzorców renderowania, które nadają priorytet najważniejszym aktualizacjom UX zamiast innych zadań renderowania.
FID a INP: pomiary i optymalizacja

Zespół Aurora w Chrome korzysta z platform internetowych typu open source, aby pomagać programistom w ulepszaniu różnych aspektów związanych z wrażeniami użytkownika, w tym między innymi wydajności i danych CWV. Wprowadzenie INP oznacza, że chcemy przygotować się na zmianę w danych dotyczących CWV w witrynach opartych na platformie. Zebraliśmy dane na podstawie eksperymentalnych danych dotyczących reagowania w raportach na temat użytkowania Chrome. Udostępnimy statystyki i działania, które ułatwią przejście na wartość INP w przypadku witryn opartych na platformie.

Eksperymentalne dane wskaźnika reagowania

Wartość INP o wartości poniżej lub równej 200 milisekund oznacza dobrą reagowanie. Dane raportu CrUX i Raport technologiczny CWV z czerwca 2023 r. zawierają następujące informacje na temat responsywności popularnych platform JavaScript.

Technologia % zaliczonych
% komórek Komputer
Angular (wersja 2.0.0 lub nowsza) 28,6 83,6
Next.js 28,5 87,3
Nuxt.js 32,0 91,2
Przed początkiem 48,6 92,8
Vue (wersja 2.0.0+) 50,3 94,1
Lit 50,0 88,3
Raport dotyczący technologii CWV – dane INP za czerwiec 2023 r.

Tabela przedstawia odsetek źródeł, które mają dobrą odpowiedź w każdej platformie. Liczby są zachęcające, ale pokazują nam, że można coś poprawić.

Jak JavaScript wpływa na INP?

Wartości INP w tym polu są dobrze skorelowane z całkowitym czasem blokowania (TBT) zaobserwowanym w module. Może to oznaczać, że dowolny skrypt, który blokuje główny wątek na długi czas, jest nieprawidłowy w przypadku INP. Intensywne wykonanie JavaScriptu po dowolnej interakcji może zablokować wątek główny na dłuższy czas i opóźnić odpowiedź na tę interakcję. Oto kilka najczęstszych przyczyn blokowania skryptów:

  • Niezoptymalizowany kod JavaScript: zbędny kod lub niewłaściwa strategia podziału kodu i wczytywania mogą spowodować zatory w języku JavaScript oraz zablokowanie wątku głównego na dłuższy czas. Podział kodu, ładowanie progresywne i dzielenie długich zadań mogą znacznie skrócić czas odpowiedzi.

  • Skrypty innych firm: skrypty innych firm, które czasami nie są wymagane do przetwarzania interakcji (np. skrypty reklam), mogą zablokować wątek główny i powodować niepotrzebne opóźnienia. Nadanie priorytetu najważniejszym skryptom może pomóc w ograniczeniu negatywnego wpływu skryptów zewnętrznych.

  • Wiele modułów obsługi zdarzeń: wiele modułów obsługi zdarzeń powiązanych z każdą interakcją, z których każdy uruchomi inny skrypt, może wzajemnie się zakłócać i generować duże opóźnienia. Niektóre z tych zadań mogą nie być niezbędne i można je zaplanować w narzędziu internetowym lub w czasie bezczynności przeglądarki.

  • Nakład pracy związany z obsługą zdarzeń: platformy mogą mieć dodatkowe funkcje lub składnię do obsługi zdarzeń. Na przykład Vue używa parametru v-on do dołączania detektorów zdarzeń do elementów, a Angular pakuje moduły obsługi zdarzeń użytkownika. Implementacja tych funkcji wymaga dodatkowego kodu platformy nad vanilla JavaScript.

  • Hydracja: korzystając z platformy JavaScript, często zdarza się, że serwer generuje początkowy kod HTML dla strony, który następnie trzeba uzupełnić o moduły obsługi zdarzeń i stan aplikacji, by zapewnić ich interaktywność w przeglądarce. Proces ten nazywamy nawodnieniem. Ten proces może być intensywny podczas wczytywania, w zależności od tego, jak długo trwa wczytywanie JavaScriptu i dokończenie nawodnienia. Może też prowadzić do stron, które wyglądają jak interaktywne, a nie są. Nawodnienie często odbywa się automatycznie podczas wczytywania strony lub leniwie (np. podczas interakcji z użytkownikiem) i może wpływać na INP lub czas przetwarzania ze względu na harmonogram zadań. W bibliotekach takich jak React możesz wykorzystać useTransition, dzięki czemu część renderowanego komponentu pojawi się w następnej klatce, a bardziej kosztowne efekty uboczne zostawią w przyszłych klatkach. Z tego względu aktualizacje w trakcie przejścia na pilniejsze powiadomienia, np. kliknięcia, mogą być wzorcem z korzyścią dla wartości INP.

  • Pobieranie z wyprzedzeniem: prawidłowe pobieranie zasobów potrzebnych przy kolejnych nawigowaniu z wyprzedzeniem może zwiększyć wydajność. Jeśli jednak pobieranie z wyprzedzeniem i renderowanie odbywa się synchronicznie w trasach SPA, może to negatywnie wpłynąć na wartość INP, ponieważ wszystkie te kosztowne próby renderowania zostaną ukończone w jednej klatce. W przeciwnym razie nie musisz wstępnie pobierać trasy, a zamiast tego rozpoczynać niezbędną pracę (np. fetch()) i umożliwiać odblokowywanie renderowania. Zalecamy ponowne sprawdzenie, czy podejście Twojej platformy do pobierania z wyprzedzeniem zapewnia optymalny komfort UX i jak (o ile w ogóle) może to wpłynąć na INP.

Od teraz, aby uzyskać dobry wynik INP, deweloperzy będą musieli skupić się na sprawdzaniu kodu, który jest wykonywany po każdej interakcji na stronie, i optymalizowaniu podziałów, nawodnienia, strategii wczytywania i rozmiaru każdej aktualizacji render() zarówno w przypadku skryptów własnych, jak i skryptów innych firm.

W jaki sposób Aurora i platformy pomagają rozwiązać problemy z INP?

Aurora wykorzystuje platformy, wdrażając sprawdzone metody, aby dostarczać gotowe rozwiązania typowych problemów. Współpracowaliśmy z firmami Next.js, Nuxt.js, Gatsby i Angular nad rozwiązaniami, które oferują silne ustawienia domyślne w ramach platformy w celu optymalizacji skuteczności. Oto najważniejsze nasze prace w tym kontekście:

  • React i Next.js: komponent skryptu Next.js pomaga rozwiązywać problemy powodowane przez nieefektywne ładowanie skryptów innych firm. W Next.js wprowadziliśmy szczegółowy fragment, który umożliwia tworzenie mniejszych fragmentów kodu. Zmniejsza to ilość nieużywanego kodu wspólnego, który jest pobierany na wszystkie strony. Współpracujemy również z Next.js, aby udostępnić dane INP w ramach usługi Analytics.

  • Angular: Aurora współpracuje z zespołem Angular nad usprawnieniem renderowania i nawodnienia po stronie serwera. Planujemy też ulepszyć obsługę zdarzeń i wykrywanie zmian, aby ulepszyć wartość INP.

  • Vue i Nuxt.js: badamy możliwości współpracy, głównie w zakresie wczytywania i renderowania skryptów.

W jaki sposób platformy zastanawiają się nad poprawą wartości INP?

React i Next.js

Wycinek czasu za pomocą React.js, wdrożony za pomocą narzędzi startTransition i Suspense, pozwala wybrać selektywne lub progresywne nawodnienie. To oznacza, że nawodnienie nie jest blokiem synchronicznym. Powstaje ona na małe fragmenty, z którymi w każdej chwili mogą wystąpić przerwy.

To powinno poprawić wartość INP i umożliwi szybsze reagowanie na naciśnięcia klawiszy, efekty najechania kursorem podczas przejścia czy kliknięcia. Pomaga też zapewnić reakcję aplikacji React nawet w przypadku dużych przejść, takich jak autouzupełnianie.

W Next.js zaimplementowaliśmy nową platformę routingu, która domyślnie używa startTransition do przenoszenia tras. Dzięki temu właściciele witryn Next.js mogą wdrożyć podział czasowy w React i zwiększyć szybkość przenoszenia tras.

Angular

Zespół Angular analizuje kilka pomysłów, które mogą pomóc również w przypadku wartości INP:

  • Bez strefy: zmniejsza początkowy rozmiar pakietu i wymagany kod, który musi się wczytać przed wyrenderowaniem aplikacji.
  • Nawodnienie: czyli nawodnienie przypominające wyspę, aby ograniczyć ilość potrzebnej aplikacji do wybudzenia, aby użytkownik mógł wejść w interakcję.
  • Zredukuj koszty związane z CD: na przykład tańsze wykrywanie zmian, znajdowanie sposobów na rzadsze sprawdzanie aplikacji i wykorzystywanie sygnałów reagujących na zmiany.
  • Bardziej szczegółowy podział kodu: zmniejsz początkowy pakiet.
  • Lepsza obsługa wskaźników wczytywania: na przykład podczas ponownego renderowania SSR, nawigacji po trasie i operacji leniwego ładowania.
  • Narzędzia do profilowania: lepsze narzędzia dla programistów do analizowania kosztów interakcji, zwłaszcza związanych z kosztem wykrywania zmian w przypadku konkretnych interakcji.

Dzięki tym ulepszeniom możemy rozwiązać różne problemy, które pogarszają czas reakcji i wrażenia użytkowników, oraz poprawić wskaźniki CWV i nowy wskaźnik INP w przypadku witryn opartych na platformie.

Podsumowanie

Spodziewamy się, że wynik INP będzie bardziej przydatny dla witryn, a w przyszłości pozwoli poprawić ich czas reakcji i wydajność. Opieramy się na naszym dotychczasowym przewodniku po INP, aby w 2023 r. udostępnić deweloperom więcej przydatnych wskazówek dla deweloperów platform. Mamy nadzieję osiągnąć ten cel:

  • Tworzenie kanałów w celu ułatwienia dostępu do danych terenowych w INP dla platform i programistów stron internetowych.
  • Pracuj z platformami, aby tworzyć funkcje, które będą domyślnie ulepszać INP.

Chętnie poznamy opinie użytkowników platformy, którzy rozpoczynają korzystanie z optymalizacji INP.