Dowiedz się, jak nowy wskaźnik INP wpływa na działanie witryn utworzonych za pomocą frameworków i bibliotek JavaScript.
Chrome wprowadził niedawno w Raporcie na temat użytkowania Chrome nową eksperymentalną miarę szybkości reakcji. Te dane, które znamy teraz jako czas od interakcji do kolejnego wyrenderowania (INP), mierzą ogólną responsywność strony na interakcje użytkowników. Dzisiaj chcemy się podzielić z Tobą informacjami o tym, jak wypadają strony internetowe utworzone za pomocą nowoczesnych frameworków JavaScriptu w porównaniu z tą miarą. Chcemy omówić, dlaczego INP jest istotny w przypadku frameworków i jak Aurora oraz frameworky optymalizują responsywność.
Tło
Chrome używa opóźnienia przy pierwszym działaniu (FID) jako jednego z podstawowych wskaźników internetowych (CWV) do pomiaru opóźnienia wczytywania witryn. FID mierzy czas oczekiwania od pierwszej interakcji użytkownika do momentu, w którym przeglądarka jest w stanie przetworzyć związane z nią przetwarzacze zdarzeń. Nie obejmuje on czasu potrzebnego na przetworzenie obciążników zdarzeń, przetworzenie kolejnych interakcji na tej samej stronie ani namalowanie kolejnego obrazu po wykonaniu wywołań zwrotnych zdarzeń. Jednak responsywność ma kluczowe znaczenie dla wygody użytkowników w całym cyklu życia strony, ponieważ użytkownicy spędzają około 90% czasu na stronie po jej wczytaniu.
INP mierzy czas, jaki zajmuje stronie internetowej reakcja na interakcje użytkownika od momentu rozpoczęcia interakcji do momentu wyświetlenia kolejnej klatki na ekranie. Mamy nadzieję, że dzięki INP będziemy mogli udostępnić zbiorcze dane o opóźnieniu w przypadku wszystkich interakcji w cyklu życia strony. Uważamy, że INP zapewni dokładniejsze oszacowanie szybkości wczytywania stron internetowych i ich responsywności w czasie działania.
Ponieważ FID mierzy tylko opóźnienie wprowadzania danych w przypadku pierwszej interakcji, prawdopodobnie programiści nie zoptymalizowali w sposób proaktywny kolejnych interakcji w ramach procesu ulepszania CWV. Witryny, zwłaszcza te o wysokim stopniu interakcji, musiałyby się sporo napracować, aby osiągnąć dobre wyniki w tym zakresie.
Rola platform
Wiele witryn korzysta z JavaScriptu do zapewnienia interakcji, więc na wynik INP wpływa przede wszystkim ilość kodu JavaScript przetworzonego w głównym wątku. Frameworki JavaScriptu są niezbędną częścią nowoczesnego front-endu i dają deweloperom przydatne abstrakcje do obsługi routingu, zdarzeń i podziałów kodu JavaScriptu. Odgrywają więc kluczową rolę w optymalizacji szybkości działania i wygody użytkowników witryn, które ich używają.
Platformy mogły już wcześniej podjąć działania w kierunku poprawy responsywności poprzez zwiększenie FID witryn. Teraz jednak muszą przeanalizować dostępne dane dotyczące szybkości działania i zająć się znalezionymi lukami. Ogólnie rzecz biorąc, INP ma zwykle niższe współczynniki przejścia, a różnica w procesie pomiarowym wymaga dodatkowej optymalizacji kodu. W tabeli poniżej znajdziesz wyjaśnienie.
Zespół Aurora w Chrome współpracuje z ramami internetowymi typu open source, aby pomóc deweloperom w ulepszaniu różnych aspektów wygody korzystania z witryn, w tym wydajności i danych CWV. Wraz z wprowadzeniem INP chcemy się przygotować na zmianę danych CWV w przypadku witryn opartych na ramach. W raportach CrUX zebraliśmy dane na podstawie eksperymentalnego wskaźnika szybkości reakcji. Udostępnimy statystyki i działania, które ułatwią Ci przejście na wskaźnik INP w przypadku witryn opartych na frameworku.
Eksperymentalne dane dotyczące wskaźnika responsywności
Wartość INP poniżej lub równa 200 milisekund oznacza dobrą szybkość reakcji. Dane z raportu na temat użytkowania Chrome oraz raportu dotyczącego technologii CWV z czerwca 2023 r. zawierają te informacje o responsywności w przypadku popularnych frameworków JavaScript.
Tabela pokazuje odsetek źródeł w ramach poszczególnych frameworków, które mają dobry wynik szybkości reakcji. Dane są zachęcające, ale wskazują, że jest jeszcze dużo miejsca na poprawę.
Jak JavaScript wpływa na INP?
Wartości INP w polu dobrze korelują z czasem całkowitego blokowania (TBT) zaobserwowanym w laboratorium. Może to oznaczać, że każdy skrypt, który blokuje wątek główny przez długi czas, jest szkodliwy dla INP. Intensywne wykonywanie kodu JavaScript po każdej interakcji może blokować główny wątek przez dłuższy czas i opóźniać odpowiedź na tę interakcję. Oto kilka typowych przyczyn blokowania skryptów:
Nie zoptymalizowany JavaScript: niepotrzebny kod lub niewłaściwe strategie dzielenia i ładowania kodu mogą powodować nadmierne rozrastanie się kodu JavaScript i blokowanie wątku głównego przez długi czas. Dzielenie kodu, wczytywanie 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ą blokować wątek główny i powodować niepotrzebne opóźnienia. Nadanie priorytetu niezbędnym skryptom może pomóc w ograniczeniu negatywnego wpływu skryptów innych firm.
Wiele elementów obsługujących zdarzenia: wiele elementów obsługujących zdarzenia powiązanych z każdą interakcją, z których każdy wykonuje inny skrypt, może zakłócać działanie innych i powodować długie opóźnienia. Niektóre z tych zadań mogą być nieistotne i można je zaplanować w ramach procesu web worker lub gdy przeglądarka jest nieaktywna.
Narzut frameworka na obsługę zdarzeń: frameworki mogą mieć dodatkowe funkcje lub składnię do obsługi zdarzeń. Na przykład Vue używa atrybutu v-on do dołączania odbiorników zdarzeń do elementów, a Angular otacza je elementami obsługującymi zdarzenia użytkownika. Wdrożenie tych funkcji wymaga dodatkowego kodu frameworku oprócz zwykłego kodu JavaScript.
Hydration: podczas korzystania z ramy JavaScript często zdarza się, że serwer generuje początkowy kod HTML strony, który musi zostać uzupełniony o obsługi zdarzeń i stan aplikacji, aby można było wyświetlić interaktywność w przeglądarce. Nazywamy to nawilżaniem. Może to być czasochłonny proces, w zależności od tego, jak długo trwa wczytywanie kodu JavaScript i zakończenie procesu nasycania. Może to też powodować, że strony wyglądają na interaktywne, choć tak nie jest. Często hydratyzacja odbywa się automatycznie podczas wczytywania strony lub leniwie (np. po interakcji użytkownika) i może wpływać na czas przetwarzania lub czas dodania danych wejściowych ze względu na planowanie zadań. W bibliotekach takich jak React możesz użyć
useTransition, aby część renderowania komponentu była wykonywana w kolejnych klatkach, a wszystkie droższe efekty uboczne były odkładane na później. W związku z tym aktualizacje w ramach przejścia, które prowadzą do bardziej pilnych aktualizacji, takich jak kliknięcia, mogą stanowić wzór, który może być przydatny w przypadku INP.Wstępne pobieranie: agresywne wstępne pobieranie zasobów potrzebnych do kolejnych nawigacji może przynieść poprawę wydajności, jeśli zostanie wykonane prawidłowo. Jeśli jednak zsynchronizujesz pobieranie i renderowanie ścieżek SPA, możesz negatywnie wpłynąć na INP, ponieważ wszystkie te kosztowne próby renderowania zostaną ukończone w pojedynczym klatce. W przeciwieństwie do tego nie pobieraj wstępnie trasy, tylko rozpocznij niezbędne działania (np.
fetch()) i odblokuj farbę. Zalecamy ponowne sprawdzenie, czy podejście Twojego frameworku do wstępnego pobierania zapewnia optymalne wrażenia użytkownika i jak (jeśli w ogóle) może to wpływać na INP.
Aby uzyskać dobry wynik INP, deweloperzy będą musieli skupić się na sprawdzaniu kodu, który jest wykonywany po każdej interakcji na stronie, oraz zoptymalizować podział na fragmenty, rehydratację, strategie wczytywania i rozmiar każdej aktualizacji renderowania() zarówno w przypadku skryptów własnych, jak i skryptów innych firm.
Jak Aurora i ramy rozwiązują problemy związane z interfejsami INP?
Aurora współpracuje z ramami, wykorzystując sprawdzone metody, aby dostarczać wbudowane rozwiązania typowych problemów. Współpracowaliśmy z Next.js, Nuxt.js, Gatsby i Angular nad rozwiązaniami, które zapewniają silne wartości domyślne w ramach platformy w celu optymalizacji wydajności. Oto najważniejsze wyniki naszych prac w tym zakresie:
React i Next.js: komponent Next.js Script pomaga rozwiązywać problemy spowodowane nieefektywnym wczytywaniem skryptów innych firm. W Next.js wprowadzono konkretne dzielenie na fragmenty, aby umożliwić tworzenie mniejszych fragmentów kodu współdzielonego. Pomaga to zmniejszyć ilość nieużywanego kodu wspólnego pobieranego na wszystkich stronach. Współpracujemy też z Next.js, aby udostępnić dane INP w ramach usługi Analytics.
Angular: zespół Aurora współpracuje z zespołem Angulara, aby zbadać możliwości renderowania po stronie serwera i ulepszania danych. Planujemy też wprowadzenie ulepszeń związanych z obsługą zdarzeń i wykrywaniem zmian, aby zwiększyć skuteczność INP.
Vue i Nuxt.js: badamy możliwości współpracy, głównie w zakresie wczytywania i renderowania skryptów.
Jak frameworki podchodzą do kwestii ulepszania INP?
React i Next.js
Cięcie czasowe w React.js, implementowane za pomocą funkcji startTransition i Suspense, umożliwia korzystanie z selektywnego lub progresywnego nawilżania. Oznacza to, że nawilżanie nie jest blokiem synchronicznym. Jest ona wykonywana w mniejszych odcinkach, które można przerwać w dowolnym momencie.
Pomoże to poprawić INP i przyspieszyć reagowanie na naciśnięcia klawiszy, efekty najechania kursorem podczas przejścia i kliknięcia. Pomaga też zachować responsywność aplikacji React nawet w przypadku dużych przejść, takich jak autouzupełnianie.
Next.js wdrożył nową platformę routingu, która domyślnie używa startTransition do przechodzenia między ścieżkami. Dzięki temu właściciele witryn Next.js mogą stosować dzielenie czasu w React i poprawiać szybkość reakcji podczas przełączania tras.
Angular
Zespół Angulara bada kilka pomysłów, które powinny ułatwić tworzenie interfejsów INP:
- Bez stref: zmniejsza początkowy rozmiar pakietu i wymagany kod, który musi zostać załadowany, zanim aplikacja będzie mogła coś renderować.
- Nawodnienie: nawodnienie w stylu wyspy, aby ograniczyć obszar aplikacji, który musi być aktywowany do interakcji.
- Zmniejszanie nakładów związanych z CD: na przykład obniżanie kosztów wykrywania zmian, znajdowanie sposobów na ograniczenie sprawdzania aplikacji i wykorzystywanie sygnałów reaktywnych dotyczących zmian.
- Bardziej szczegółowe dzielenie kodu: zmniejsz początkowy pakiet.
- Lepsze obsługiwanie wskaźników wczytywania: na przykład podczas ponownego renderowania SSR, podczas nawigacji po trasie i w operacjach ładowania opóźnionego.
- Narzędzia do profilowania: ulepszone narzędzia dla programistów, które ułatwiają zrozumienie kosztów interakcji, zwłaszcza kosztów wykrywania zmian w przypadku konkretnych interakcji.
Dzięki tym ulepszeniom możemy rozwiązywać różne problemy, które powodują niską responsywność i niezadowolenie użytkowników, oraz poprawiać wskaźniki CWV i nowy wskaźnik INP w przypadku witryn opartych na frameworku.
Podsumowanie
Oczekujemy, że wynik INP będzie w przyszłości stanowić dla właścicieli witryn lepszy kompas, dzięki któremu będą oni mogli poprawiać responsywność i wydajność swoich witryn. W 2023 r. opracujemy na podstawie dotychczasowego przewodnika po INP więcej praktycznych wskazówek dla twórców frameworków. Mamy nadzieję, że uda nam się to osiągnąć dzięki:
- Tworzenie kanałów zapewniających łatwy dostęp do danych w polu w ramach INP dla programistów frameworków i programistów stron internetowych.
- Pracuj z ramami, aby tworzyć funkcje, które domyślnie poprawiają INP.
Zapraszamy użytkowników frameworka do dzielenia się opiniami na początku ich podróży w kierunku optymalizacji INP.