Dowiedz się, jak nowe dane INP wpływają na sposób działania witryn utworzonych przy użyciu platform i bibliotek JavaScript.
Niedawno wprowadziliśmy w Chrome nowe eksperymentalne dane o czasie reakcji w Raporcie na temat użytkowania Chrome. Te dane, które teraz nazywamy interakcją z następnym wyrenderowaniem (INP), określają ogólną responsywność w odniesieniu do interakcji użytkowników na stronie. Dziś chcemy podzielić się spostrzeżeniami na temat tego, jak radzą sobie witryny utworzone przy użyciu nowoczesnych struktur JavaScript. Chcemy porozmawiać o tym, dlaczego INP sprawdza się w przypadku platform i jak Aurora i platformy pomagają w optymalizacji responsywności.
Tło
Chrome używa opóźnienia przy pierwszym działaniu (FID) w ramach podstawowych wskaźników internetowych (CWV), aby mierzyć responsywność ładowania stron internetowych. FID mierzy czas oczekiwania od pierwszej interakcji użytkownika do momentu, gdy przeglądarka jest w stanie przetworzyć moduły obsługi zdarzeń powiązane z daną interakcją. Nie uwzględnia czasu na przetworzenie modułów obsługi zdarzeń, przetworzenie kolejnych interakcji na tej samej stronie ani wyrenderowanie następnej klatki po uruchomieniu wywołań zwrotnych zdarzenia. Czas reagowania ma jednak kluczowe znaczenie dla wygody użytkowników w całym cyklu życia strony, ponieważ po jej wczytaniu użytkownicy spędzają na niej około 90% czasu.
INP to czas potrzebny stronie internetowej na reakcję na interakcje użytkownika od momentu rozpoczęcia przez użytkownika interakcji do momentu wyrenderowania następnej klatki na ekranie. Mamy nadzieję, że dzięki metodzie INP uda nam się uzyskać zagregowany wskaźnik postrzeganego czasu oczekiwania we wszystkich interakcjach w cyklu życia strony. Sądzimy, że INP pozwoli nam dokładniej oszacować dane o stronach internetowych czas wczytywania i responsywność środowiska wykonawczego.
FID mierzy tylko opóźnienie wejściowe pierwszej interakcji, prawdopodobnie więc twórcy stron internetowych nie zoptymalizowali z własnej strony kolejnych interakcji w ramach procesu ulepszania CWV. Z tego względu witryny, zwłaszcza te o dużej interaktywności, będą musiały bardzo się postarać, aby dobrze wykorzystać tę wartość.
Rola schematów
Wiele witryn opiera się na języku JavaScript, który zapewnia interaktywność, dlatego na wynik INP miałaby wpływ przede wszystkim ilość kodu JavaScript przetworzonych w wątku głównym. Platformy JavaScript są istotnym elementem nowoczesnych frontendów internetowych i zapewniają programistom cenne abstrakcje na potrzeby routingu, obsługi zdarzeń i dzielenia kodu JavaScript na segmenty. Dlatego odgrywają kluczową rolę w optymalizowaniu czasu reagowania i wrażenia użytkowników korzystających z witryn, w których są używane.
Rozwiązania te mogły podjąć działania w celu zwiększenia responsywności przez wcześniejsze ulepszenia FID dla witryn. Musi jednak teraz przeanalizować dostępne dane dotyczące responsywności i wyeliminować wszelkie wykryte luki. INP ma zwykle niższe współczynniki zdawalności, a różnica w procesie pomiaru wymaga dodatkowej optymalizacji kodu. W tabeli poniżej znajdziesz podsumowanie przyczyn.
Zespół Aurora w Chrome pracuje z platformami internetowymi typu open source, aby pomóc programistom poprawić różne aspekty wygody użytkowników, w tym wydajność i CWV. Wprowadzając standard INP, chcemy przygotować się na zmianę danych dotyczących CWV w przypadku witryn opartych na platformie. Zebraliśmy dane na podstawie eksperymentalnych danych o responsywności w raportach raportu na temat użytkowania Chrome. Udostępnimy statystyki i działania, aby ułatwić przejście na dane INP w przypadku witryn opartych na platformie.
Eksperymentalne dane dotyczące responsywności
Wartość INP mniejsza niż lub równa 200 milisekund oznacza dobrą responsywność. Dane z raportu raportu CrUX i raportu na temat technologii CWV z czerwca 2023 roku zawierają poniższe informacje o responsywności popularnych platform JavaScript.
Tabela pokazuje odsetek źródeł w każdej platformie o dobrym wyniku responsywności. Wyniki są zachęcające, ale wiemy, że wiele można jeszcze poprawić.
Jak JavaScript wpływa na INP?
Wartości INP w polu są dobrze skorelowane z łącznym czasem blokowania (TBT) zaobserwowanym w module. Może to sugerować, że każdy skrypt, który przez dłuższy czas blokuje wątek główny, byłby zły dla INP. Intensywne wykonywanie kodu JavaScript po jakiejkolwiek 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 złe strategie podziału i wczytywania kodu mogą powodować przerost kodu JavaScript i blokowanie na długi czas głównego wątku. Dzielenie kodu, ładowanie progresywne i dzielenie długich zadań może znacznie skrócić czas odpowiedzi.
Skrypty innych firm: skrypty zewnętrzne, które czasami nie są wymagane do przetwarzania interakcji (np. skryptów reklam), mogą blokować wątek główny i powodować niepotrzebne opóźnienia. Nadanie priorytetu najważniejszym skryptom może ograniczyć negatywny wpływ 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 uruchamia inny skrypt, może zakłócać siebie i skutkować długotrwałymi opóźnieniami. Niektóre z tych zadań mogą być nieistotne i można je zaplanować w narzędziu internetowym lub gdy przeglądarka jest nieaktywna.
Narzut 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 powyżej zwykłego kodu JavaScript.
Hydration:w przypadku używania platformy JavaScript serwer często generuje początkowy kod HTML strony, który następnie musi zostać rozszerzony o moduły obsługi zdarzeń i stan aplikacji, aby można było wejść interaktywnie w przeglądarce. Nazywamy to nawodnieniem. W zależności od tego, jak długo załaduje się JavaScript i dokończy nawodnienie, może to być proces ciężki. Może to też prowadzić do stron, które wyglądają, jakby były interaktywne, choć w rzeczywistości tak nie są. Nawodnienie często zachodzi automatycznie podczas wczytywania strony lub leniwie (np. podczas interakcji użytkownika) i może wpływać na wartość INP lub czas przetwarzania ze względu na planowanie zadań. W bibliotekach takich jak React można użyć komponentu
useTransition, aby część renderowania komponentu znajdowała się w następnej klatce, a bardziej kosztowne efekty uboczne pozostawały w przyszłych klatkach. W związku z tym wzorcem INP mogą być aktualizacje w okresie przejściowym, które nastąpią w wyniku pilnych aktualizacji, takich jak kliknięcia.Pobieranie z wyprzedzeniem: jeśli przeprowadzisz odpowiednie pobieranie z wyprzedzeniem, agresywnie pobieranie zasobów potrzebnych do kolejnych nawigacji może pomóc w zwiększeniu wydajności. Jeśli jednak pobierasz z wyprzedzeniem i renderujesz trasy SPA synchronicznie, może to negatywnie wpłynąć na INP, ponieważ wszystkie te kosztowne procesy renderowania trwają w ramach jednej klatki. Dla kontrastu nie pobieraj trasy z wyprzedzeniem, tylko rozpoczynaj pracę (np.
fetch()) i odblokowuje farbę. Zalecamy ponowne sprawdzenie, czy sposób pobierania z wyprzedzeniem stosowany przez Twoją platformę zapewnia optymalny UX i jak (jeśli w ogóle) może to wpłynąć na INP.
Aby uzyskać dobry wynik INP, deweloperzy będą musieli skupiać się na przeglądaniu kodu, który wykonuje się po każdej interakcji na stronie, i optymalizacji podziału na fragmenty, ponownego nawadniania, wczytywania strategii i rozmiaru każdej aktualizacji render() w przypadku skryptów własnych i zewnętrznych.
W jaki sposób Aurora i platformy radzą sobie z problemami z INP?
Aurora wykorzystuje sprawdzone metody, aby wbudowane 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 wydajności. Oto najważniejsze osiągnięcia w tym kontekście:
React i Next.js: komponent Next.js Script pomaga rozwiązywać problemy powodowane przez nieefektywne wczytywanie skryptów innych firm. W Next.js wprowadziliśmy szczegółowe dzielenie na fragmenty, aby umożliwić udostępnianie mniejszego fragmentu kodu. Pomaga to ograniczyć ilość nieużywanego wspólnego kodu, który jest pobierany na wszystkich stronach. Współpracujemy też z Next.js, aby udostępniać dane INP w ramach usługi Analytics.
Angular: Aurora współpracuje z zespołem Angular, aby opracować ulepszenia renderowania po stronie serwera i nawadniania. Planujemy też ulepszyć obsługę zdarzeń i wykrywanie zmian w celu ulepszenia INP.
Vue i Nuxt.js: Szukamy sposobów na współpracę, głównie w zakresie wczytywania i renderowania skryptów.
Jakie są przemyślenia platformy na temat poprawy wskaźnika INP?
React i Next.js
Dzielenie czasu w react.js jest zaimplementowane za pomocą narzędzi startTransition i Suspense. Dzięki temu możesz wyrazić zgodę na nawodnienie selektywne lub progresywne. To oznacza, że nawodnienie nie jest synchroniczne. Film jest podzielony na mniejsze kawałki, które mogą się w każdej chwili przerwać.
Powinno to pomóc ulepszyć INP i umożliwić szybsze reagowanie na naciśnięcia klawiszy, efekty najeżdżania kursorem podczas przejścia i kliknięcia. Pomaga to też w elastyczności aplikacji React nawet w przypadku dużych przejść, takich jak autouzupełnianie.
Usługa Next.js wdrożyła nową platformę routingu, która domyślnie używa protokołu startTransition do przenoszenia tras. Dzięki temu właściciele witryn Next.js mogą stosować fragmentację czasu React i poprawić responsywność przejścia tras.
Angular
Zespół Angular analizuje kilka pomysłów, które również powinny pomóc w rozwiązaniu INP:
- Bezstrefowy: zmniejsza początkowy rozmiar pakietu i wymaga kodu, który musi zostać załadowany, zanim aplikacja będzie mogła cokolwiek wyrenderować.
- Nawodnienie: nawodnienie przypominające wyspę, by ograniczyć ilość danych, które aplikacja musi wybudzić przed interakcją.
- Zmniejsz koszty związane z funkcją CD: możesz na przykład obniżyć koszty wykrywania zmian, znaleźć sposoby na ograniczenie ilości danych do sprawdzenia w aplikacji i wykorzystywać sygnały reaktywne dotyczące zmian.
- 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 pozwalające poznać koszty interakcji, zwłaszcza dotyczące kosztów wykrywania zmian w przypadku konkretnych interakcji.
Dzięki tym ulepszeniom możemy rozwiązywać różne problemy, które powodują słabą responsywność i wrażenia użytkownika, oraz zwiększać dane CWV i nowe dane INP w przypadku witryn opartych na platformie.
Podsumowanie
Spodziewamy się, że wynik INP zapewni witrynom lepszy kompas i w przyszłości poprawi czas reakcji i skuteczność. W 2023 r. wzbogacimy nasz przewodnik po INP, aby dostarczyć więcej praktycznych wskazówek dla deweloperów platform. Mamy nadzieję, że osiągniemy ten cel:
- Tworzenie kanałów dla łatwego dostępu do danych terenowych w INP dla platform i programistów stron internetowych.
- Korzystaj ze platform, aby tworzyć funkcje, które domyślnie poprawią INP.
Zachęcamy użytkowników platformy do opinii, które pomogą im w optymalizacji pod kątem wartości INP.