INP: dlaczego strona reaguje z opóźnieniem na kliknięcie i jak skrócić ten czas

Czym jest INP i co dokładnie mierzy

INP to wskaźnik, który mówi, ile czasu mija od działania użytkownika do chwili, gdy na ekranie pojawia się pierwsza widoczna reakcja strony. Pełna nazwa brzmi Interaction to Next Paint, co w dokumentacji Google przetłumaczono jako interakcję do kolejnego wyrenderowania. Jest to jeden z trzech podstawowych wskaźników internetowych, znanych pod nazwą Core Web Vitals, obok szybkości wczytywania i stabilności układu.

Według opisu wskaźnika w serwisie web.dev do INP liczą się trzy rodzaje działań: kliknięcia myszą, dotknięcia ekranu dotykowego oraz naciśnięcia klawiszy, zarówno na zwykłej klawiaturze, jak i na ekranowej. Nie liczy się samo przewijanie strony, najechanie kursorem ani powiększanie widoku. Wskaźnik dotyczy więc tych chwil, w których odwiedzający czegoś od strony oczekuje: otwiera menu, wpisuje nazwę produktu w wyszukiwarce sklepu, zaznacza zgodę w formularzu albo dokłada towar do koszyka.

Dlaczego liczy się następna klatka, a nie koniec operacji

Pomiar kończy się w chwili, gdy przeglądarka namaluje pierwszą klatkę po interakcji. Jest to najwcześniejsza okazja, by pokazać człowiekowi, że strona przyjęła jego polecenie. Wskaźnik nie czeka na zakończenie wszystkiego, co dzieje się w tle, na przykład na pobranie danych z serwera. Ma to praktyczne znaczenie: jeśli po kliknięciu w przycisk wysyłający formularz od razu pojawia się informacja o trwającym wysyłaniu, interakcja może uzyskać dobry wynik, nawet gdy odpowiedź serwera nadejdzie później.

Jak z wielu interakcji powstaje jedna liczba

W trakcie jednej wizyty użytkownik wykonuje zwykle wiele działań, a INP podaje dla niej jedną wartość. Dokumentacja wyjaśnia, że jest to najdłuższa zaobserwowana interakcja, przy czym na każde 50 interakcji pomijana jest jedna najgorsza, aby pojedynczy wyjątkowy przypadek nie zniekształcał obrazu. Wcześniejszy wskaźnik responsywności, FID, oceniał wyłącznie opóźnienie przy pierwszej interakcji. INP obejmuje cały czas korzystania ze strony, dlatego lepiej oddaje to, co odczuwa klient przeglądający ofertę przez kilka minut.

Zdarza się też, że strona nie ma żadnej wartości INP. Dzieje się tak, gdy odwiedzający niczego nie kliknął i nie nacisnął żadnego klawisza, gdy jedynie przewijał treść albo gdy stronę odwiedził robot.

Jakie progi INP podaje Google

Google uznaje INP za dobry, gdy wynosi najwyżej 200 milisekund, za wymagający poprawy, gdy mieści się między 200 a 500 milisekund, i za słaby, gdy przekracza 500 milisekund. Te same przedziały podaje zarówno serwis web.dev, jak i pomoc Search Console.

Ocena nie dotyczy pojedynczej wizyty. Google bierze pod uwagę 75. percentyl wczytań strony, osobno dla urządzeń mobilnych i osobno dla komputerów. W prostych słowach: aby strona została uznana za dobrą, co najmniej trzy czwarte wizyt musi zmieścić się w progu 200 ms. Jeden szybki komputer w biurze niczego tu nie przesądza, ponieważ liczą się urządzenia rzeczywistych klientów, w tym starsze telefony. Wynik na komputerze i wynik na telefonie to dwie osobne oceny i należy je czytać oddzielnie.

Warto od razu ustalić, jakie znaczenie ma ten wskaźnik dla widoczności w wyszukiwarce. W dokumentacji Google Search Central można przeczytać, że Google zdecydowanie zaleca właścicielom witryn dążenie do dobrych podstawowych wskaźników internetowych, a jego systemy rankingowe starają się nagradzać dobre wrażenia użytkowników razem z innymi cechami jakości strony. Nie wynika z tego obietnica wyższych pozycji. Dobry INP jest jednym z wielu sygnałów, a jego wartość widać przede wszystkim w wygodzie klienta, który bez przeszkód otwiera menu i wypełnia formularz. Szersze tło wszystkich trzech wskaźników opisaliśmy we wpisie o tym, jak poprawić Core Web Vitals na stronie firmy.

Z jakich trzech faz składa się opóźnienie interakcji

Każda interakcja składa się z opóźnienia wejścia, czasu przetwarzania i opóźnienia prezentacji, a INP jest sumą tych trzech odcinków. Rozróżnienie jest ważne, ponieważ każdą fazę naprawia się innymi środkami. Bez wiedzy o tym, która z nich trwa najdłużej, programista działa po omacku.

Opóźnienie wejścia to czas od działania użytkownika do chwili, w której przeglądarka zaczyna obsługiwać zdarzenie. Kliknięcie musi poczekać, ponieważ przeglądarka wykonuje większość pracy w jednym wątku głównym i zajmuje się w danej chwili tylko jednym zadaniem. Jeśli akurat przetwarza duży skrypt, kliknięcie stoi w kolejce. Dlatego ta faza bywa najdłuższa w pierwszych sekundach po otwarciu strony, gdy wczytują się i uruchamiają pliki JavaScript.

Czas przetwarzania to okres, w którym wykonuje się kod przypisany do danego zdarzenia, czyli to, co programista zaplanował po kliknięciu. Może to być otwarcie panelu, przeliczenie ceny, sprawdzenie poprawności pola albo wysłanie informacji do narzędzia analitycznego. Im więcej pracy mieści się w tej jednej chwili, tym dłużej użytkownik czeka.

Opóźnienie prezentacji to czas od zakończenia kodu do namalowania następnej klatki. Przeglądarka musi wtedy przeliczyć style, ustalić układ elementów i narysować zmiany. Na stronie złożonej z bardzo wielu elementów ten etap potrafi trwać dłużej niż sam kod.

Dla ilustracji: w sklepie z Poznania, w którym kliknięcie filtra przebudowuje listę kilkudziesięciu produktów, najdłuższa będzie zapewne prezentacja. Na stronie hydraulika z Łodzi z oknem czatu, mapą i kilkoma skryptami pomiarowymi należy spodziewać się raczej długiego opóźnienia wejścia tuż po otwarciu.

Gdzie sprawdzić INP swojej strony

Wynik INP od rzeczywistych użytkowników najłatwiej odczytać w dwóch miejscach: w publicznym narzędziu PageSpeed Insights oraz w raporcie Core Web Vitals w Google Search Console. Oba korzystają z tego samego zbioru danych, czyli raportu wrażeń użytkowników Chrome, oznaczanego skrótem CrUX. Są to anonimowe pomiary zbierane podczas zwykłych wizyt w przeglądarce Chrome.

PageSpeed Insights

Narzędzie jest dostępne bez opłat i bez logowania pod adresem pagespeed.web.dev. Na ekranie startowym znajduje się jedno pole na adres strony oraz przycisk uruchamiający analizę. Wynik składa się z dwóch części. Górna pokazuje dane od rzeczywistych użytkowników, o ile strona ma wystarczający ruch, a wśród nich wartość INP z oceną. Dolna to test laboratoryjny wykonany w tej chwili przez automat. Wynik można przełączać między urządzeniami mobilnymi a komputerami.

Trzeba przy tym rozumieć jedno ograniczenie. Test laboratoryjny wczytuje stronę, ale niczego na niej nie klika, dlatego sam z siebie nie mierzy INP. Dokumentacja web.dev zaznacza, że pomocniczo można patrzeć na całkowity czas blokowania, oznaczany skrótem TBT, jednak nie zastępuje on pomiaru interakcji. Jeśli więc górna część wyniku jest pusta, o responsywności mówi dopiero ręczne badanie w przeglądarce, opisane w następnej sekcji.

Raport Core Web Vitals w Search Console

W Search Console raport znajduje się w menu po lewej stronie pod nazwą Podstawowe wskaźniki internetowe (w pomocy Google występuje jako raport dotyczący Core Web Vitals). Ma dwie osobne części: Urządzenie mobilne oraz Komputer. Po otwarciu jednej z nich widać wykres oraz listę problemów, a adresy otrzymują jeden z trzech stanów: Dobrej jakości, Wymagana poprawa albo Słabej jakości.

Z pomocy Search Console wynika kilka zasad, które ułatwiają czytanie raportu. Dane obejmują ostatnie 28 dni. Raport nie pokazuje każdego adresu osobno, tylko grupy podobnych stron z przykładowymi adresami, a grupa otrzymuje stan swojego najsłabszego wskaźnika. Jeśli więc karty produktów mają dobry czas wczytania, ale słaby INP, cała grupa trafi do stanu Słabej jakości. Komunikat o braku dostępnych danych oznacza, że usługa została dodana niedawno albo że w zbiorze CrUX jest za mało pomiarów dla danego typu urządzenia.

Po wdrożeniu poprawek można w szczegółach problemu uruchomić weryfikację. Search Console rozpoczyna wtedy okres obserwacji trwający 28 dni i uznaje poprawkę za skuteczną, jeśli w tym czasie problem nie wystąpi na żadnym adresie z grupy. Efektu nie widać więc następnego dnia.

Oba narzędzia mówią, czy problem istnieje i na jakim typie stron. Nie mówią, który przycisk działa wolno ani dlaczego. Dokumentacja web.dev opisuje to wprost: dane CrUX wskazują, że kłopot występuje, ale nie podają jego przyczyny.

Jak znaleźć wolne interakcje w narzędziach Chrome

Wolną interakcję najszybciej znajduje się w panelu Wydajność w Narzędziach deweloperskich Chrome, który na bieżąco pokazuje czas każdego kliknięcia wraz z podziałem na trzy fazy. Narzędzia są częścią przeglądarki i otwiera się je klawiszem F12. Nie trzeba niczego instalować ani umieć programować, żeby wykonać pierwszy pomiar i przekazać jego wynik wykonawcy strony.

Sposób pracy opisuje instrukcja ręcznego diagnozowania powolnych interakcji w serwisie web.dev. Poniżej przedstawiamy ją w uporządkowanej kolejności.

1. Otwarcie panelu Wydajność

   Po otwarciu badanej strony i Narzędzi deweloperskich należy przejść do karty Wydajność. Przy pierwszym otwarciu pojawia się widok danych na żywo z bieżącymi wartościami wskaźników, w tym INP.

2. Spowolnienie procesora i sieci

   Komputer w biurze jest zwykle szybszy niż telefon klienta. W panelu dostępne jest ograniczanie procesora oraz ograniczenie wykorzystania sieci, które przybliżają warunki do tych, w jakich stronę oglądają odwiedzający.

3. Przejście typowej ścieżki klienta

   Należy wykonać to, co robi klient: otworzyć menu, wpisać frazę w wyszukiwarce, wypełnić formularz, dołożyć produkt do koszyka. Każde działanie pojawia się w dzienniku interakcji, a najwolniejsze jest wyróżnione jako INP.

4. Odczytanie podziału na fazy

   Każdy wpis w dzienniku można rozwinąć. Widać wtedy, ile trwało opóźnienie wejścia, ile przetwarzanie, a ile prezentacja.

5. Powtórzenie próby podczas wczytywania

   Dokumentacja zaleca sprawdzanie interakcji także w trakcie ładowania strony, ponieważ wątek główny jest wtedy najbardziej obciążony. Wystarczy odświeżyć stronę i od razu kliknąć w menu.

6. Nagranie szczegółowego profilu

   Gdy wiadomo już, która interakcja jest wolna, można uruchomić nagrywanie przyciskiem rejestrowania w lewym górnym rogu panelu, powtórzyć kliknięcie i zatrzymać zapis. To nagranie jest materiałem dla programisty.

Co widać w nagraniu

W górnej części nagrania znajduje się podsumowanie aktywności, a czerwone paski oznaczają w nim długie zadania. Niżej widoczna jest ścieżka Interakcje. Po najechaniu kursorem na wybraną interakcję pojawia się etykieta z czasem każdej części. Interakcja jest narysowana jako blok z dwiema cienkimi liniami po bokach: lewa linia to opóźnienie wejścia, blok pośrodku to czas przetwarzania, a prawa linia to opóźnienie prezentacji. Pasek pokazuje też, o ile interakcja przekroczyła 200 ms. Na osi wątku głównego bloki fioletowe i zielone oznaczają przeliczanie stylów, układ i malowanie, czyli pracę przy prezentacji, a wpisy zdarzenia kliknięcia z czerwonym trójkątem w rogu wskazują kod, który wykonywał się zbyt długo.

Wynik badania warto zapisać w prosty sposób: adres strony, nazwa klikniętego elementu, urządzenie, łączny czas oraz najdłuższa faza. Taka notatka daje programiście znacznie więcej niż ogólne zgłoszenie, że strona działa wolno.

Pomiar u rzeczywistych użytkowników

Ręczne badanie pokazuje to, co udało się odtworzyć na jednym urządzeniu. Pełniejszy obraz daje pomiar u prawdziwych odwiedzających, do którego służy biblioteka web-vitals. Jak opisuje instrukcja znajdowania powolnych interakcji w terenie, jej wersja z atrybucją przekazuje nie tylko wartość INP, ale też selektor elementu, którego dotyczyła interakcja, jej rodzaj oraz czas każdej z trzech faz. Dane wysyła się do własnego narzędzia analitycznego. Wdrożenie wymaga programisty, a zakres zbieranych informacji warto uzgodnić z osobą odpowiedzialną w firmie za ochronę danych.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jaki udział mają skrypty zewnętrzne

Skrypty zewnętrzne, czyli kod wczytywany z serwerów innych firm, wydłużają przede wszystkim opóźnienie wejścia, ponieważ zajmują wątek główny przeglądarki w chwili, gdy użytkownik próbuje coś kliknąć. Należą do nich narzędzia analityczne, kody reklamowe, piksele sieci społecznościowych, okna czatu, mapy, osadzone filmy, przyciski udostępniania oraz narzędzia do testów wersji strony. Każdy z osobna bywa niewielki, ale na stronach firmowych zbiera się ich z czasem wiele.

Mechanizm jest prosty. Serwis web.dev w opisie długich zadań podaje, że każde zadanie trwające dłużej niż 50 milisekund jest długim zadaniem. Wątek główny przetwarza jedno zadanie naraz i doprowadza je do końca, więc kliknięcie, które trafi w środek takiego zadania, musi poczekać w kolejce. Skrypt zewnętrzny może wywołać długie zadanie w chwili, gdy przeglądarka go pobiera, analizuje i uruchamia, oraz później, gdy wykonuje własną pracę w tle. Instrukcja diagnozowania w serwisie web.dev podaje właśnie taki przykład: opóźnienie wejścia spowodowane zadaniem, które uruchomił licznik czasu ze skryptu innej firmy.

Drugi sposób wpływu jest mniej oczywisty. Skrypty zewnętrzne często podłączają własną obsługę zdarzeń do kliknięć na stronie, na przykład aby je policzyć. Wtedy wydłużają także czas przetwarzania, chociaż sam przycisk i kod strony są napisane poprawnie. Da się to rozpoznać po adresie pliku, z którego pochodzi wykonywany kod: jeśli jest to domena inna niż domena strony, źródłem jest dostawca zewnętrzny.

Jak ograniczyć ich wpływ

Najskuteczniejszym działaniem jest przegląd i usunięcie tego, co niepotrzebne. Zalecenia Google dotyczące wczytywania kodu JavaScript innych firm mówią wprost, by usuwać skrypty, które nie wnoszą wyraźnej wartości. Na stronach zostają nieraz kody zakończonych kampanii, piksel sieci, w której firma już się nie reklamuje, albo dwa narzędzia mierzące to samo. Jeśli firma prowadzi kampanie w Google Ads, listę kodów warto uzgodnić z osobą prowadzącą reklamy, żeby nie usunąć pomiaru konwersji.

To, co zostaje, powinno wczytywać się w sposób, który nie wstrzymuje strony. Służą do tego atrybuty async i defer w znaczniku skryptu. Według tych samych zaleceń async nadaje się do skryptów, które powinny uruchomić się wcześnie, jak analityka, a defer do mniej pilnych zasobów. Elementy widoczne dopiero po przewinięciu, jak film albo reklama w dolnej części strony, można wczytywać dopiero wtedy, gdy użytkownik się do nich zbliża. Dokumentacja zastrzega, że same atrybuty nie rozwiążą kłopotu, gdy skryptów jest bardzo wiele.

<!-- skrypt pomiarowy: uruchamia się wcześnie, ale nie blokuje wczytywania -->
<script async src="https://przyklad-analityka.example/pomiar.js"></script>

<!-- okno czatu: uruchamia się po przetworzeniu dokumentu -->
<script defer src="https://przyklad-czat.example/okno.js"></script>

Osobnej uwagi wymaga menedżer tagów. Wczytuje on kody asynchronicznie, co jest zaletą, ale zalecenia Google ostrzegają, że nadmiar tagów i brak kontroli nad tym, kto je dokłada, może pogorszyć wydajność.

Dlaczego rozbudowane menu i formularze spowalniają reakcję strony

Rozbudowane menu i formularze spowalniają reakcję z dwóch powodów: zwiększają liczbę elementów, które przeglądarka musi przeliczyć przy każdej zmianie, i zwykle wiążą z jednym kliknięciem dużo kodu. Pierwszy powód wydłuża opóźnienie prezentacji, drugi czas przetwarzania. Menu i formularz to jednocześnie miejsca, w których klient klika najczęściej, dlatego to od nich warto zaczynać badanie.

Liczba elementów na stronie

Strukturę wszystkich elementów strony przeglądarka przechowuje w postaci drzewa nazywanego DOM. Serwis web.dev w opisie tego, jak duże rozmiary DOM wpływają na interaktywność, podaje, że narzędzie Lighthouse zaczyna ostrzegać przy 800 węzłach, a rozmiar powyżej 1400 węzłów uznaje za nadmierny. Im większe drzewo, tym droższe jest zarówno pierwsze wyświetlenie, jak i każda późniejsza zmiana, a interakcje zmieniające stronę uruchamiają kosztowne przeliczanie stylów, układu i malowania. Pracę tę dodatkowo zwiększają złożone reguły CSS.

Duże menu rozwijane łatwo staje się źródłem nadmiaru. Sklep z kilkuset kategoriami może umieszczać w kodzie każdej podstrony pełne drzewo kategorii, osobno dla wersji na komputer i osobno dla wersji na telefon, choć odwiedzający widzi w danej chwili tylko jeden poziom. Ukryte elementy nadal należą do drzewa. Podobny skutek dają szablony, w których każdy blok treści jest opakowany w kilka zagnieżdżonych pojemników.

Dokumentacja wskazuje kilka sposobów ograniczenia tej pracy. Pierwszy to spłaszczenie struktury, czyli usunięcie zbędnych zagnieżdżeń. Drugi to dokładanie elementów dopiero w chwili interakcji: zawartość podmenu powstaje wtedy, gdy użytkownik je otwiera, a nie przy wczytaniu każdej strony. Trzeci to właściwość CSS o nazwie content-visibility, która pozwala przeglądarce odroczyć rysowanie fragmentów znajdujących się poza ekranem. Czwarty to prostsze selektory CSS.

Formularze i pola wyszukiwania

W formularzu każde naciśnięcie klawisza jest osobną interakcją liczoną do INP. Jeśli po każdej wpisanej literze strona sprawdza poprawność wszystkich pól, przelicza cenę, przeszukuje listę podpowiedzi i wysyła zdarzenie do narzędzia analitycznego, to cała ta praca wchodzi w czas przetwarzania. Szczególnie uważnie warto zbadać wyszukiwarki z podpowiedziami w sklepach, kalkulatory wyceny oraz formularze zamówienia z wieloma polami zależnymi od siebie.

Rozwiązanie polega na tym, by w chwili naciśnięcia klawisza wykonywać tylko to, co konieczne do pokazania wpisanej litery, a resztę odłożyć. Sprawdzenie pola można przeprowadzić po jego opuszczeniu, a podpowiedzi wyświetlić po krótkiej przerwie w pisaniu. Zalecenia dotyczące optymalizacji INP opisują tę zasadę ogólnie: najpierw aktualizacja potrzebna do następnej klatki, a pozostała praca w osobnym zadaniu. Te same dokumenty opisują jeszcze jedną pułapkę, czyli wymuszone przeliczenie układu. Powstaje ona, gdy kod zmienia wygląd elementu i zaraz potem odczytuje jego wymiary, co zmusza przeglądarkę do natychmiastowego przeliczenia układu w środku interakcji.

Dla ilustracji można wyobrazić sobie stronę kancelarii z Krakowa z formularzem kontaktowym, który zawiera długą listę specjalizacji i zabezpieczenie przed automatami uruchamiane przy pierwszym dotknięciu dowolnego pola. Pierwsze dotknięcie formularza na telefonie może wtedy trwać wyraźnie dłużej niż kolejne, a przyczyna leży w dodatku, o którym właściciel strony dawno nie myśli. Jeśli formularz lub menu trzeba zaprojektować od nowa, warto połączyć prace programistyczne z projektowaniem UX, bo prostszy układ zwykle oznacza też mniej kodu.

Co zlecić programiście, żeby skrócić INP

Programiście należy zlecić skrócenie tej fazy, która w pomiarze trwa najdłużej, i od razu wskazać konkretną interakcję, urządzenie oraz stronę. Ogólna prośba o przyspieszenie strony łatwo kończy się kompresją obrazów, która poprawia wczytywanie, ale nie zmienia reakcji na kliknięcie. Dobre zlecenie opiera się na wyniku z panelu Wydajność i na zaleceniach Google dotyczących optymalizacji INP, które porządkują działania według trzech faz.

Podział długich zadań

Podział długich zadań polega na tym, że kod co pewien czas oddaje sterowanie przeglądarce, aby mogła obsłużyć oczekujące kliknięcie i odświeżyć ekran, a potem wraca do pracy. Dokumentacja opisuje dwa sposoby. Starszy korzysta z funkcji setTimeout, która przenosi dalszą część pracy do nowego zadania. Nowszy to funkcja scheduler.yield, która dodatkowo dba o to, by przerwana praca została wznowiona przed innymi oczekującymi zadaniami. Według serwisu web.dev obsługują ją przeglądarki Chrome i Edge od wersji 129 oraz Firefox od wersji 142, a Safari jej nie obsługuje, dlatego potrzebne jest rozwiązanie zastępcze.

function oddajSterowanie() {
  if (globalThis.scheduler && scheduler.yield) {
    return scheduler.yield();
  }
  return new Promise(function (dalej) { setTimeout(dalej, 0); });
}

przycisk.addEventListener('click', async function () {
  pokazPanelFiltrow();        // zmiana widoczna od razu
  await oddajSterowanie();    // przeglądarka rysuje klatkę
  przeliczListeProduktow();   // cięższa praca
  await oddajSterowanie();
  wyslijZdarzenieDoAnalityki();
});

Nazwy funkcji w przykładzie są umowne. Istotna jest kolejność: użytkownik od razu widzi otwarty panel, a przeliczenie listy i wysłanie pomiaru odbywa się chwilę później, już po narysowaniu klatki.

Lista do przekazania wykonawcy

Poniższe punkty można potraktować jako zakres rozmowy z wykonawcą strony. Nie każdy będzie potrzebny w każdym serwisie, a o kolejności powinien zdecydować wynik pomiaru.

• Pomiar INP na telefonie i komputerze przed zmianami, z zapisem najwolniejszych interakcji i ich faz.
• Spis skryptów zewnętrznych z decyzją dla każdego: usunąć, opóźnić wczytanie czy pozostawić.
• Atrybuty async lub defer dla skryptów, które nie są konieczne do wyświetlenia strony.
• Wczytywanie czatu, mapy i filmów dopiero wtedy, gdy są potrzebne lub widoczne.
• Podział długich zadań w kodzie menu, filtrów, koszyka i formularzy.
• Natychmiastowa widoczna reakcja na każde kliknięcie, na przykład wskaźnik wczytywania.
• Mniej elementów w menu i w szablonach, bez zbędnych zagnieżdżeń.
• Sprawdzanie pól formularza po ich opuszczeniu, a nie po każdej literze.
• Ponowny pomiar po wdrożeniu i uruchomienie weryfikacji w Search Console.

W serwisach opartych na WordPressie i WooCommerce warto przejrzeć także wtyczki, ponieważ każda z nich może dołączać własne skrypty. W sklepach dobrze zacząć od karty produktu, listy kategorii i koszyka, bo tam interakcji jest najwięcej. Jeśli obecny szablon wytwarza bardzo rozbudowany kod, przebudowa bywa rozsądniejsza niż poprawki. Taką decyzję dobrze podjąć wspólnie z zespołem odpowiedzialnym za tworzenie stron, a w handlu w sieci za sklep internetowy.

Typowe pomyłki i sytuacje, w których potrzebna jest pomoc

Najczęstsza pomyłka polega na ocenianiu responsywności po wyniku testu laboratoryjnego, który niczego na stronie nie klika. Wysoka ocena w takim teście nie oznacza dobrego INP. Miarodajne są dane od rzeczywistych użytkowników oraz ręczne badanie z włączonym spowolnieniem procesora.

Druga pomyłka to badanie strony wyłącznie na szybkim komputerze i po pełnym wczytaniu, podczas gdy wątek główny jest najbardziej obciążony w pierwszych sekundach po otwarciu strony. Trzecia to mylenie INP z szybkością wczytywania. Mniejsze pliki graficzne pomagają innemu wskaźnikowi, o czym piszemy we wpisie o obrazach na stronie, natomiast na reakcję po kliknięciu wpływa przede wszystkim kod JavaScript i wielkość drzewa elementów.

Czwarta pomyłka to oczekiwanie natychmiastowej zmiany w raportach, choć dane obejmują 28 dni. Piąta to usuwanie skryptów bez uzgodnienia z osobami odpowiedzialnymi za marketing, co grozi utratą pomiaru kampanii. Szósta to wstrzymywanie reakcji strony do chwili, gdy serwer odpowie: skoro pomiar kończy się na pierwszej narysowanej klatce, wystarczy od razu pokazać użytkownikowi, że polecenie zostało przyjęte.

Warto też zachować proporcje. INP nie zastąpi wartościowej treści ani dobrej oferty, a jego poprawa nie jest obietnicą wyższych pozycji. Jeśli ruch z wyszukiwarki maleje, przyczyn należy szukać szerzej, co opisujemy we wpisie o tym, jak znaleźć przyczynę spadku ruchu z Google.

Pomoc z zewnątrz jest potrzebna wtedy, gdy raport pokazuje stan Słabej jakości dla dużej grupy adresów, a wykonawca strony nie potrafi wskazać przyczyny, gdy nikt w firmie nie ma dostępu do kodu strony, gdy nie wiadomo, które skrypty zewnętrzne są używane, albo gdy planowana jest przebudowa serwisu. W ramach usługi SEO techniczne wykonujemy pomiar, wskazujemy interakcje do naprawy i przygotowujemy opis prac dla programisty, a po wdrożeniu sprawdzamy wynik ponownie.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl