Panel Wydajność w Chrome: jak samodzielnie znaleźć przyczynę wolnej strony

Czym jest panel Wydajność i kiedy warto po niego sięgnąć

Panel Wydajność to jedna z kart narzędzi dla programistów w Chrome (w angielskiej wersji przeglądarki nosi nazwę Performance), która rejestruje pracę przeglądarki podczas wyświetlania strony i przedstawia ją na osi czasu. W odróżnieniu od narzędzi wystawiających ocenę punktową pokazuje, w której sekundzie i z jakiego powodu strona się zatrzymała.

Większość właścicieli stron zaczyna od raportów, które podają wynik i listę zaleceń. Opisujemy je we wpisach o tym, jak czytać raport PageSpeed Insights, oraz o tym, jak uruchomić audyt Lighthouse w Chrome. Te raporty odpowiadają na pytanie, czy jest problem. Panel Wydajność odpowiada na pytanie następne: gdzie dokładnie ten problem powstaje. Sięga się po niego wtedy, gdy wiadomo już, że któryś ze wskaźników jest słaby, ale nie wiadomo, co za to odpowiada.

Warto od razu ustalić, czego panel nie pokaże. Wynik pochodzi z jednego komputera i jednego wczytania strony, jest więc pomiarem lokalnym. Google ocenia strony na podstawie danych od rzeczywistych użytkowników, o czym piszemy w tekście wyjaśniającym, dlaczego wynik testu różni się od danych od użytkowników. Panel służy do szukania przyczyn, a nie do stwierdzania, czy strona spełnia progi w oczach wyszukiwarki.

Panel jest zbudowany wokół trzech wskaźników. LCP (Largest Contentful Paint, czyli wyrenderowanie największego elementu treści) mierzy szybkość wczytywania. INP (Interaction to Next Paint, czyli czas od interakcji do kolejnego wyrenderowania) mierzy szybkość reakcji strony. CLS (Cumulative Layout Shift, czyli skumulowane przesunięcie układu) mierzy stabilność wizualną. Według opisu wskaźników w serwisie web.dev dobry wynik to LCP w ciągu 2,5 sekundy, INP na poziomie 200 milisekund lub mniej oraz CLS równy 0,1 lub niższy.

Jak otworzyć panel i przygotować przeglądarkę do pomiaru

Panel otwiera się skrótem klawiszowym Ctrl + Shift + I w systemach Windows i Linux albo Cmd + Option + I na komputerach Mac, a następnie przez wybranie karty Wydajność w górnym pasku narzędzi. Te skróty podaje samouczek analizy wydajności w dokumentacji Chrome.

Przed pierwszym pomiarem warto zadbać o czyste warunki. Dokumentacja zaleca otwarcie strony w oknie incognito, ponieważ w tym trybie rozszerzenia przeglądarki nie zakłócają pomiaru. Programy blokujące reklamy czy menedżery haseł wstrzykują na stronę własne skrypty, a panel je rejestruje. Bez okna incognito łatwo przypisać stronie winę za coś, co pochodzi z przeglądarki osoby testującej. Kto bada wersję mobilną, powinien też przed nagraniem włączyć tryb urządzenia dostępny w narzędziach dla programistów, ponieważ na wąskim ekranie przeglądarka wybiera inny układ i inne obrazy.

Co pokazuje podgląd wskaźników na żywo, zanim cokolwiek zostanie nagrane

Zaraz po otwarciu panel wyświetla ekran z trzema kartami: LCP, CLS i INP, i od razu mierzy je dla strony otwartej w tej karcie przeglądarki. Jak podaje omówienie panelu w dokumentacji Chrome, wartości LCP i CLS pojawiają się natychmiast, a INP dopiero po pierwszej interakcji ze stroną. Każda wartość otrzymuje ocenę: dobry, wymaga poprawy albo zły.

To najprostszy sposób pracy z panelem i w wielu sprawach wystarcza. Po najechaniu kursorem na wskaźnik LCP przeglądarka podświetla na stronie element uznany za największy, co opisuje wykaz funkcji panelu. Często już ta jedna czynność przynosi odpowiedź: największym elementem okazuje się na przykład duże zdjęcie w nagłówku, baner zgody na pliki cookie albo akapit tekstu czekający na czcionkę.

Pod kartami wskaźników znajdują się dwie zakładki z dziennikiem zdarzeń. Zakładka Interakcje wymienia kolejne kliknięcia i naciśnięcia klawiszy wraz z elementem, czasem i podziałem na fazy. Zakładka podpisana Zmiany układu albo Przesunięcia układu wymienia przesunięcia wraz z elementami i wynikiem każdego z nich. Obie listy uzupełniają się w czasie rzeczywistym, więc wystarczy poruszać się po stronie tak, jak robi to klient: otworzyć menu, rozwinąć filtr, dodać produkt do koszyka.

Ten tryb przydaje się do problemów, które pojawiają się tylko w określonych sytuacjach. Wyobraźmy sobie hipotetyczny sklep z Poznania, w którym raport ogólny pokazuje słaby INP, ale strona główna reaguje sprawnie. Przejście przez sklep z otwartą zakładką interakcji może pokazać, że wolne jest dopiero kliknięcie w filtr rozmiaru na liście produktów.

Dane z terenu obok danych lokalnych

Obok własnego pomiaru panel potrafi pokazać dane od rzeczywistych użytkowników pochodzące z raportu na temat użytkowania Chrome (CrUX). Włącza się je w części Dane z terenu przyciskiem konfiguracji, po zapoznaniu się z informacją o prywatności. Od tej chwili przy każdym wskaźniku widać dwie wartości: lokalną i zebraną od użytkowników.

Zestawienie obu liczb pokazuje, czy lokalny test przypomina to, czego doświadczają klienci. Jeżeli lokalnie LCP wypada dużo lepiej niż w danych z terenu, komputer testującego jest szybszy niż urządzenia odwiedzających i trzeba pomiar utrudnić. Panel sam podpowiada, jakie urządzenie i jakie spowolnienie ustawić, a gdy wyniki zbliżają się do siebie, podpowiedź znika.

Po co spowalniać procesor i sieć przed pomiarem

Spowolnienie procesora i sieci służy temu, aby komputer testującego zachowywał się podobnie do przeciętnego telefonu odwiedzającego stronę. Na nowym laptopie podłączonym do światłowodu prawie każda strona działa płynnie, a kłopoty ujawniają się dopiero na słabszym urządzeniu i wolniejszym łączu. Bez spowolnienia panel często nie pokaże niczego niepokojącego, choć klienci realnie czekają.

Ustawienia znajdują się w dwóch miejscach. Na ekranie wskaźników na żywo jest część Ustawienia środowiska z polami Procesor i Sieć. W widoku nagrania te same pola kryją się pod ikoną koła zębatego opisaną jako Ustawienia przechwytywania. W polu sieci wybiera się gotowy profil łącza, w dokumentacji jako przykład podano Szybką sieć 4G. W polu procesora wybiera się krotność spowolnienia: samouczek Chrome używa czterokrotnego spowolnienia, a omówienie panelu podaje jako przykład dwudziestokrotne dla słabszych urządzeń.

Dokumentacja zaznacza dwie ważne rzeczy. Po pierwsze spowolnienie procesora jest względne, czyli liczone wobec mocy komputera, na którym działa test. Czterokrotne spowolnienie na wydajnej stacji roboczej i na kilkuletnim laptopie biurowym daje więc dwa różne wyniki. Po drugie narzędzia nie odwzorowują w pełni procesorów mobilnych, więc jest to przybliżenie, a nie symulacja konkretnego telefonu. Dlatego w polu procesora dostępna jest kalibracja: po jej uruchomieniu przeglądarka sama dobiera gotowe ustawienia odpowiadające urządzeniom mobilnym niskiej i średniej klasy dla danego komputera.

Jakie ustawienia przyjąć na początek? Rozsądnym punktem wyjścia jest to, co podpowiada sam panel po włączeniu danych z terenu. Gdy strona ma zbyt mały ruch i danych z terenu brakuje, w praktyce agencji stosujemy profil szybkiej sieci komórkowej i skalibrowane ustawienie procesora dla urządzeń średniej klasy, a wybrane wartości zawsze zapisujemy w notatce do pomiaru.

Jak nagrać ładowanie strony i pracę użytkownika na stronie

Panel oferuje dwa rodzaje nagrania: nagranie ładowania, które samo odświeża stronę i samo się kończy, oraz nagranie w czasie działania, które rozpoczyna i kończy osoba testująca. Pierwsze służy do badania LCP i przesunięć układu przy wczytywaniu, drugie do badania wolnych kliknięć, przewijania i animacji.

Nagranie ładowania uruchamia przycisk z ikoną odświeżania, opisany jako rejestrowanie z ponownym załadowaniem strony. Według wykazu funkcji panelu przeglądarka przechodzi wtedy najpierw na pustą stronę about:blank, potem wczytuje badany adres, a nagrywanie zatrzymuje się samo kilka sekund po zakończeniu wczytywania. Nie trzeba niczego klikać w trakcie.

Nagranie w czasie działania uruchamia przycisk z ikoną kółka. Po jego naciśnięciu należy wykonać na stronie dokładnie tę czynność, która sprawia kłopot, na przykład rozwinąć menu albo dodać produkt do koszyka, a następnie zakończyć nagranie tym samym przyciskiem lub przyciskiem zatrzymania. Im krótsze nagranie, tym łatwiej je potem czytać. Kilka sekund z jedną czynnością jest warte więcej niż minuta chaotycznego klikania.

Przed nagraniem warto zaznaczyć pole Zrzuty ekranu. Przeglądarka zapisuje wtedy obraz każdej klatki, a po najechaniu kursorem na oś czasu widać, jak strona wyglądała w danym momencie. To ułatwia rozmowę z osobami nietechnicznymi: zamiast liczby milisekund można pokazać kadr, na którym po dwóch sekundach wciąż nie ma zdjęcia produktu.

1. Otwarcie strony w oknie incognito

   Rozszerzenia przeglądarki nie zakłócają wtedy pomiaru.

2. Ustawienie warunków testu

   Tryb urządzenia dla wersji mobilnej, profil sieci, spowolnienie procesora i zaznaczone zrzuty ekranu.

3. Wybór rodzaju nagrania

   Nagranie z ponownym wczytaniem dla problemów z ładowaniem albo nagranie ręczne dla jednej wybranej czynności na stronie.

4. Powtórzenie pomiaru

   Pojedyncze nagranie bywa przypadkowe. W praktyce agencji wykonujemy co najmniej trzy i wnioski wyciągamy z tego, co się powtarza.

5. Zapis pliku nagrania

   Zapisany ślad można otworzyć ponownie albo przekazać programiście.

Po zakończeniu nagrania przeglądarka przez chwilę przetwarza dane, a potem wyświetla wynik: u góry przegląd osi czasu, pod nim ścieżki, a obok karty ze szczegółami. Do codziennej diagnozy wystarcza znajomość kilku części tego widoku, które omawiamy niżej.

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

Jak czytać nagranie: przegląd osi czasu, ścieżki i wątek główny

Nagranie czyta się od góry do dołu: najpierw przegląd całości, potem wybór podejrzanego fragmentu, na końcu szczegóły w ścieżce wątku głównego. Przegląd osi czasu zawiera wykresy obciążenia procesora, liczby klatek i ruchu sieciowego dla całego nagrania. Fragment do zbadania zaznacza się przeciągnięciem myszy, a przybliża i przesuwa klawiszami W, S, A i D.

Na wykresie procesora kolory odpowiadają rodzajom pracy. Dokumentacja podaje, że skrypty oznaczone są kolorem ciemnożółtym, a renderowanie fioletowym. Gdy wykres jest wypełniony na całą wysokość, procesor pracował na granicy możliwości.

Ścieżka wątku głównego

Ścieżka wątku głównego to wykres płomieniowy, czyli układ prostokątów leżących jeden pod drugim. Oś pozioma to czas, więc szerokość prostokąta odpowiada czasowi trwania zdarzenia. Oś pionowa to stos wywołań: zdarzenie położone wyżej uruchomiło to, które leży pod nim.

Długie zadania panel oznacza czerwonym trójkątem w prawym górnym rogu, a część zadania przekraczająca 50 milisekund jest zacieniowana na czerwono. To te zadania sprawiają, że strona przez chwilę nie reaguje, co opisujemy we wpisie o tym, co blokuje główny wątek przeglądarki. Kliknięcie w prostokąt otwiera kartę Podsumowanie ze szczegółami zdarzenia.

Dla osoby, która nie programuje, najcenniejsza jest informacja o pochodzeniu skryptu. Karta Podsumowanie zawiera tabelę dzielącą aktywność na podmioty wewnętrzne i zewnętrzne. Pozwala to odróżnić kod własnej strony od kodu dostawców: czatu, mapy, narzędzi pomiarowych czy pikseli reklamowych. Jeśli najdłuższe zadania należą do skryptów obcych, rozmowa dotyczy tego, które dodatki są naprawdę potrzebne i kiedy powinny się ładować. Szerzej piszemy o tym w tekście o skryptach zewnętrznych.

Karty ze szczegółami i statystyki

Obok karty Podsumowanie dostępne są trzy tabele: Od dołu do góry, Drzewo wywołań i Dziennik zdarzeń. Pokazują tę samą aktywność w postaci listy i są przeznaczone głównie dla programisty.

Największą pomocą dla początkujących jest karta Statystyki, w której panel sam wskazuje prawdopodobne przyczyny. Według wykazu statystyk wydajności w dokumentacji Chrome znajdują się tam między innymi zestawienie LCP i zestawienie INP z podziałem na części, wykrywanie żądania LCP, przyczyny przesunięć układu, żądania blokujące renderowanie, czas oczekiwania na dokument, wyświetlanie czcionki i dostarczanie obrazów. Te same statystyki pojawiają się w raporcie Lighthouse.

Jak odczytać element LCP, przesunięcia układu i wolne interakcje

Każdy z trzech wskaźników ma w nagraniu swoje miejsce: LCP w zestawieniu z podziałem na części, przesunięcia w osobnej ścieżce z rombami, a interakcje w ścieżce z paskami podzielonymi na fazy. Cel jest zawsze ten sam: ustalić, którego elementu strony dotyczy problem i która część czasu jest za długa.

Element LCP i cztery części jego czasu

Przy LCP najpierw ustala się, co jest największym elementem, a dopiero potem, dlaczego pojawia się późno. Serwis web.dev w tekście o optymalizacji największego wyrenderowania treści dzieli ten czas na cztery części: czas do pierwszego bajtu, opóźnienie ładowania zasobu, czas wczytywania zasobu i opóźnienie renderowania elementu. Podaje też orientacyjny rozkład dla dobrze zoptymalizowanej strony: czas do pierwszego bajtu i czas wczytywania zasobu po około 40 procent, a oba opóźnienia poniżej 10 procent każde, z zastrzeżeniem, że są to wskazówki, a nie ścisłe reguły.

Zestawienie od razu podpowiada kierunek. Duży udział pierwszej części wskazuje na serwer, o czym piszemy w tekście o czasie odpowiedzi serwera. Duże opóźnienie ładowania zasobu oznacza, że przeglądarka późno dowiedziała się o głównym obrazie, na przykład dlatego, że jest ładowany leniwie albo wstawiany skryptem. Długie wczytywanie to zwykle zbyt ciężki plik, a duże opóźnienie renderowania oznacza, że obraz już jest, ale przeglądarka jest zajęta skryptami. Sposoby naprawy zebraliśmy we wpisie o tym, co opóźnia wyświetlenie największego elementu.

Przesunięcia układu

Przesunięcia układu odczytuje się ze ścieżki o tej samej nazwie. Po kliknięciu w romb panel podaje czas, wynik przesunięcia, elementy, które zmieniły położenie, oraz przyczyny, jeżeli udało się je ustalić. W połączeniu ze zrzutami ekranu widać dosłownie, co przeskoczyło: tekst zepchnięty przez obraz bez podanych wymiarów albo przycisk przesunięty przez późno dodany pasek z informacją.

Nagranie ładowania pokazuje tylko przesunięcia z pierwszych sekund. Te, które powstają przy przewijaniu lub po kliknięciu, wymagają nagrania ręcznego albo obserwacji na ekranie wskaźników na żywo. Trwałe sposoby usuwania przeskoków opisujemy w tekście o tym, skąd biorą się przeskoki układu strony.

Wolne interakcje

Wolne interakcje widać w ścieżce Interakcje jako paski z czerwonym trójkątem. Każdy pasek dzieli się na trzy fazy. Serwis web.dev w opisie wskaźnika INP wyjaśnia je następująco: opóźnienie wejścia to czas od działania użytkownika do rozpoczęcia obsługi zdarzenia, czas przetwarzania to wykonanie kodu obsługującego zdarzenie, a opóźnienie wyświetlania to czas do narysowania kolejnej klatki.

Podział na fazy mówi, gdzie szukać. Długie opóźnienie wejścia oznacza, że w chwili kliknięcia wątek główny był zajęty czymś innym, często skryptem niezwiązanym z klikniętym elementem. Długi czas przetwarzania wskazuje na kod samego przycisku lub formularza. Długie opóźnienie wyświetlania oznacza, że przeglądarka musiała przeliczyć i narysować dużą część strony. Wystarczy spojrzeć na ścieżkę wątku głównego pod paskiem interakcji, aby ustalić, które zadania wypełniły ten czas. Więcej zawiera wpis o tym, dlaczego strona reaguje z opóźnieniem na kliknięcie.

Jak przygotować zgłoszenie dla programisty

Dobre zgłoszenie zawiera plik nagrania, opis warunków testu, adres podstrony, nazwę wskaźnika i wskazanie elementu, którego dotyczy problem. Programista, który dostanie taki komplet, może otworzyć nagranie u siebie i od razu przejść do przyczyny, zamiast odtwarzać sytuację od początku na własnym, zwykle dużo szybszym komputerze.

Nagranie zapisuje się przyciskiem pobierania na pasku u góry panelu, a następnie poleceniem zapisu śladu. Strona dokumentacji o zapisywaniu śladów opisuje cztery opcje. Dołączenie adnotacji, czyli notatek naniesionych na nagranie, jest domyślnie włączone. Dołączenie zawartości zasobów, a więc plików HTML, JavaScript i CSS, jest domyślnie wyłączone, podobnie jak zależne od niego dołączenie map źródeł skryptów. Kompresja gzip jest domyślnie włączona i zmniejsza plik.

Sam plik nie wystarczy, bo odbiorca nie wie, w jakich warunkach powstał. Do zgłoszenia warto dołączyć krótki opis, który odpowiada na pytania z poniższej listy.

• Pełny adres badanej podstrony oraz informacja, czy była to wersja na telefon, czy na komputer.
• Wersja przeglądarki Chrome i informacja o oknie incognito.
• Ustawienia spowolnienia: profil sieci i krotność spowolnienia procesora.
• Rodzaj nagrania: ładowanie strony czy konkretna czynność, na przykład kliknięcie filtra koloru na liście produktów.
• Wskaźnik, którego dotyczy zgłoszenie, oraz jego wartość lokalna i wartość z danych z terenu, jeżeli jest dostępna.
• Element wskazany przez panel: element LCP, element przesunięty albo element, którego kliknięcie trwało zbyt długo.
• Obserwacja z nagrania: która część czasu jest najdłuższa i od jakiego dostawcy pochodzi najdłuższe zadanie.
• Liczba powtórzeń pomiaru i informacja, czy wynik był za każdym razem podobny.

Jak mogłoby to wyglądać w praktyce? Weźmy hipotetyczną kancelarię z Krakowa, której strona główna ma słaby LCP na telefonach. Zgłoszenie oparte na panelu brzmiałoby tak: na stronie głównej w widoku telefonu, przy profilu szybkiej sieci komórkowej i czterokrotnym spowolnieniu procesora, elementem LCP jest zdjęcie zespołu w nagłówku; w zestawieniu LCP największy udział ma opóźnienie ładowania zasobu; w ścieżce sieci zdjęcie zaczyna się pobierać dopiero po skrypcie suwaka; wynik powtórzył się w trzech nagraniach, plik śladu w załączniku. Taki opis zajmuje kilka zdań, a prowadzi wprost do miejsca, które trzeba poprawić.

Jakie pomyłki zdarzają się najczęściej i kiedy potrzebna jest pomoc

Najczęstszą pomyłką jest wyciąganie wniosków z pojedynczego pomiaru wykonanego na szybkim komputerze, z włączonymi rozszerzeniami i bez spowolnienia. Taki pomiar zwykle wygląda dobrze i prowadzi do błędnego przekonania, że strona nie ma problemu, choć dane od użytkowników mówią co innego.

Druga pomyłka to mylenie pomiaru lokalnego z oceną strony przez Google. Serwis web.dev podaje, że strona spełnia wymagania, gdy osiąga zalecane wartości na 75. percentylu wczytań dla wszystkich trzech wskaźników, osobno na urządzeniach mobilnych i komputerach. Jedno udane nagranie nie jest więc dowodem, że problem zniknął. Ostateczne potwierdzenie przynoszą dopiero dane z terenu, które można śledzić między innymi w raporcie Podstawowe wskaźniki internetowe w Search Console.

Trzecia pomyłka dotyczy zakresu badania. Często sprawdzana jest wyłącznie strona główna, podczas gdy klienci z wyszukiwarki trafiają głównie na podstrony usług, kategorie i karty produktów. Każdy typ podstrony ma inny szablon, inny element LCP i inne skrypty. W hipotetycznym przykładzie hydraulika z Łodzi strona główna może działać poprawnie, a podstrona cennika z osadzoną mapą i formularzem wyceny wypadać znacznie gorzej.

Zdarzają się też zbyt długie nagrania i próby zrozumienia każdego prostokąta na wykresie. Do diagnozy wystarczą trzy rzeczy: element, którego dotyczy wskaźnik, najdłuższa część czasu i pochodzenie najdłuższych zadań. Błędem jest również zmienianie kilku rzeczy naraz między pomiarami, przez co nie wiadomo, która zmiana pomogła.

Pomoc specjalisty jest potrzebna wtedy, gdy przyczyna leży w kodzie motywu, wtyczek lub serwera, a także wtedy, gdy wyniki lokalne i dane z terenu wyraźnie się rozchodzą mimo spowolnienia. Szybkość jest jednym z wielu obszarów, które obejmuje SEO techniczne, a jej ocenę na tle indeksowania, struktury serwisu i treści przynosi kompleksowy audyt SEO. Nie obiecujemy przy tym określonych pozycji: szybsza strona jest wygodniejsza dla odwiedzających, ale o widoczności decyduje wiele czynników jednocześnie.

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