INP: nowy krytyczny miernik zastępujący FID
12 marca 2024 r. firma Google zakończyła przenoszenie podstawowych wskaźników internetowych: FID (opóźnienie pierwszego wejścia) i wyszedłem, INP (interakcja z następną farbą) i wszedłem. Cicha zmiana paneli Google Search Console, która jednak ma realny wpływ na ranking SEO milionów witryn. Według I dane z raportu dotyczącego użytkowania przeglądarki Chrome (CrUX), 43% stron internetowych nadal nie działa Próg INP „Dobry” (poniżej 200 ms), znacznie wyższa liczba niż do 30% zakładów, które nie zdały egzaminu FID.
FID zmierzył jedynie opóźnienie do pierwszego wejścia: ile czasu minęło od użytkownika kliknięto po raz pierwszy, gdy przeglądarka rozpoczęła przetwarzanie tego zdarzenia. Wskaźnik ten był łatwy do pobicia, ponieważ mierzył tylko pierwszą interakcję i nie sprawdzał się rachunek za kolejną farbę. INP jest radykalnie inne: zmierz responsywność ogólnie przez cały czas trwania sesji, wybierając jako wynik końcowy najgorszy percentyl interakcji.
Czego się nauczysz
- Czym INP różni się od FID i dlaczego mierzy rzeczywistą reakcję
- Progi INP dobre/wymagające poprawy/słabe (200 ms / 500 ms)
- Jak mierzyć INP za pomocą Chrome DevTools, web-vitals.js i PageSpeed Insights
- Pięć najczęstszych wzorców JavaScript, które eksplodują INP
- Jak interpretować dane terenowe CrUX w porównaniu z danymi syntetycznymi Lighthouse
- Przepływ pracy debugowania pozwalający znaleźć i naprawić powolne interakcje
Jakie środki INP: definicja techniczna
INP obserwuje wszystkie interakcje użytkownika ze stroną podczas wizyty: kliknięcia, dotknięcia i naciśnięcia klawiszy. Dla każdej interakcji zmierz czas od wejścia użytkownika w momencie przeglądarki maluje następną klatkę to odzwierciedla wizualną reakcję na to wejście. Ten przedział nazywa się opóźnienie interakcji i składa się z trzech części:
- Opóźnienie wejścia: czas, jaki upływa, zanim przeglądarka rozpocznie przetwarzanie zdarzenia (główny wątek był zajęty)
- Czas przetwarzania: czas wykonania procedur obsługi zdarzeń JavaScript
- Opóźnienie prezentacji: czas potrzebny przeglądarce na ułożenie, pomalowanie i złożenie nowej ramki
INP bierze 98. percentyl wszystkich interakcji w sesji (lub najgorszej wartość, jeśli jest mniej niż 50 interakcji). Nie średnia, nie typowa wartość: prawie najgorsza. To sprawia, że INP jest znacznie bardziej wrażliwy na skoki opóźnień niż FID.
Progi INP
| Ocena | Wartość INP | Wpływ SEO |
|---|---|---|
| Dobry | < 200 ms | Pozytywnie wpływa na ranking |
| Wymaga poprawy | 200 ms - 500 ms | Neutralny, obszar do poprawy |
| Słaby | > 500ms | Kara za ranking Google |
FID vs INP: zasadnicza różnica
Aby zrozumieć, dlaczego przejście z FID na INP jest ważną zmianą, rozważ następujący scenariusz: masz stronę e-commerce. Przy pierwszym załadowaniu użytkownik klika „Dodaj do koszyka” i zdarzenie jest przetwarzane w ciągu 50 ms (doskonały FID). Następnie poruszaj się po stronie, filtruj produkty, otwiera menu rozwijane kategorii. Ta druga interakcja zajmuje 800 ms, ponieważ wymaga dużych obliczeń działa na głównym wątku.
Con FID: wynik wynosił 50 ms - Dobry.
Con wejście: wynik to 800 ms - Słaby.
INP odzwierciedla rzeczywiste wrażenia użytkownika podczas całej sesji, a nie tylko pierwsze kliknięcie. To dlatego wiele zakładów, które miały doskonały FID, ma teraz problematyczne INP.
Jak mierzyć INP
1. Chrome DevTools – Panel wydajności
Najdokładniejszym sposobem zdiagnozowania INP jest panel Wydajność w Chrome DevTools. Postępuj w ten sposób:
- Otwórz DevTools (F12) i przejdź do zakładki Wydajność
- Kliknij czerwone kółko, aby rozpocząć nagrywanie
- Uruchom interakcje, które chcesz mierzyć (kliknięcia, pisanie itp.)
- Zatrzymaj nagrywanie
- W wyświetlonym panelu poszukaj czerwonych pasków w sekcji Interakcje
- Kliknij interakcję, aby zobaczyć podział: opóźnienie wejścia, czas przetwarzania, opóźnienie prezentacji
2. Biblioteka JS Web Vitals (dane terenowe)
Biblioteka web-vitals Google pozwala mierzyć rzeczywisty INP użytkowników w środowisku produkcyjnym.
Dodaj go do swojego projektu i wyślij dane do punktu końcowego analizy:
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights i CruUX
PageSpeed Insights pokazuje prawdziwe dane CrUX dla Twojej domeny w sekcji „Dane terenowe”. Należy pamiętać, że dane CrUX dotyczą użytkowników przeglądarki Chrome, którzy mają włączoną synchronizację, dlatego odzwierciedlają rzeczywiste doświadczenia na rzeczywistych urządzeniach, a nie syntetyczne wyniki Lighthouse które działają na sterowaniu sprzętowym.
Dane laboratoryjne a dane terenowe
Lighthouse i PageSpeed Insights w trybie „Lab” symulują urządzenie mobilne średniej klasy na wolnym połączeniu 4G. Dane CrUX (Field Data) odzwierciedlają rzeczywistych użytkowników Twojej witryny. Rozbieżności pomiędzy obydwoma pomiarami wynoszą 30–50%, co jest zjawiskiem normalnym. Użyj danych terenowych jako wskaźnika podstawowe przy podejmowaniu decyzji dotyczących SEO, a dane laboratoryjne do debugowania technicznego.
Najczęstsze wzorce powodujące wysoki INP
1. Długie zadania w wątku głównym
Głównym winowajcą wysokiego INP jest obecność Długie zadania: Zadania JavaScript
które trwają dłużej niż 50 ms. Każde długie zadanie blokuje główny wątek przeglądarki, uniemożliwiając jej odpowiedź
do danych wejściowych użytkownika. Najprostszym sposobem na ich identyfikację jest panel DevTools Performance
lub API PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. Obsługa ciężkich zdarzeń
Programy obsługi kliknięć wykonujące synchronicznie ciężkie obliczenia są częstą przyczyną wysokiego INP. Typowym wzorcem jest procedura obsługi, która:
- Filtruj lub przekształcaj duże tablice w pamięci
- Masowo renderuj DOM (dodaj setki elementów)
- Oblicz złożone układy lub wymuś przeładowanie przeglądarki
- Analizuje duży plik JSON
3. Nie zoptymalizowano wykrywania reakcji/zmiany kąta
W frameworkach takich jak React czy Angular pojedyncze zdarzenie może wywołać cykl wykrywania zmian który ponownie oblicza całe drzewo komponentów. W złożonych komponentach lub przy braku zapamiętywania jest to właściwe, może to zająć 100–400 ms.
W Angularze rozwiązaniem jest ChangeDetectionStrategy.OnPush i wykorzystanie sygnałów do
reaktywność ziarnista. W Reagowaniu, React.memo, useMemo e useCallback
są to kluczowe narzędzia.
4. Skrypty stron trzecich
Analityka, widżety czatu, skrypty reklam i inne skrypty innych firm często działają w głównym wątku i może blokować reakcję na dane wejściowe. Aby je zidentyfikować, w panelu DevTools Performance szukaj długich zadań pochodzących z domen stron trzecich.
5. Hydratacja w ramach SSR
W aplikacjach z SSR (Next.js, Angular Universal, Nuxt) faza hydratacji może być drogie. Podczas hydratacji framework ponownie dołącza procedury obsługi zdarzeń do renderowanego modelu DOM po stronie serwera. Jeśli ta faza nakłada się na interakcję z użytkownikiem, INP cierpi.
Przepływ pracy debugowania INP
Oto zalecany przepływ pracy w celu diagnozowania i korygowania wysokiego NPI:
- Zidentyfikuj problematyczne interakcje za pomocą panelu Wydajność przez DevTools. Poszukaj interakcji z opóźnieniem > 200 ms w sekcji Interakcje.
- Przeanalizuj podział: który z trzech elementów (opóźnienie wejścia, przetwarzanie, prezentacja) jest największy?
- Jeśli i opóźnienie wejścia: W tym czasie w głównym wątku działało coś innego kliknięcia. Poszukaj długich zadań poprzedzających interakcję na osi czasu.
-
Jeśli i czas przetwarzania: Twoje procedury obsługi zdarzeń są zbyt wolne.
USA
scheduler.yield()aby je złamać (patrz następny artykuł). - Jeśli i opóźnienie prezentacji: Renderowanie klatek jest powolne. Poszukaj miażdżących układów, drogich animacji CSS lub nadmiernych warstw kompozycji.
INP i SEO: prawdziwy wpływ
Firma Google potwierdziła, że podstawowe wskaźniki internetowe, w tym INP, są czynnikami rankingowymi. Waga Dokładnie nie jest to informacja publiczna, ale dowody empiryczne pokazują, że przejście od „złego” do „dobrego” w INP może przynieść 2-5% poprawę rankingu konkurencyjnych stron. W przypadku witryn z ruchem znaczące organiczne, co przekłada się na wymierny wzrost ruchu.
Najwyższym priorytetem musi być umieszczenie wszystkich stron głównych (strony głównej, stron kategorii, strony produktów) do oceny „Dobry” (< 200 ms). Strony z treściami statycznymi rzadko je mają problemy z INP; problemy skupiają się na stronach ze złożonymi interaktywnymi interfejsami.
Następne kroki
Teraz, gdy wiesz, jak mierzyć i identyfikować problemy związane z INP, następnym krokiem jest nauczenie się, jak to zrobić
napraw je: następny artykuł z tej serii wyjaśnia, jak z nich korzystać scheduler.yield()
aby rozdzielić długie zadania i uwolnić główny wątek pomiędzy jedną interakcją a drugą.
Jeśli chodzi o renderowanie, artykuł dotyczący optymalizacji LCP opisuje techniki zmniejszania prezentacja opóźnia i przyspiesza malowanie pierwszej znaczącej klatki.
Wnioski
INP reprezentuje zmianę paradygmatu w pomiarze wydajności sieci: to nie wystarczy aby strona ładowała się szybko, musi również odpowiedź szybko przez cały czas czas trwania sesji. 43% witryn, które nie przekroczyły progu Dobrego INP, ma szansę konkretny sposób na poprawę zarówno doświadczenia użytkownika, jak i rankingu SEO.
Punktem wyjścia jest zawsze pomiar: instalacja web-vitals.js w twoim
witryny, zbieraj prawdziwe dane użytkowników i używaj Chrome DevTools do diagnozowania interakcji
problemy. Tylko na podstawie konkretnych danych będziesz mógł podejmować świadome decyzje optymalizacyjne.