PageSpeed Insights: jak czytać raport i które zalecenia mają realne znaczenie

Czym jest PageSpeed Insights i co właściwie mierzy

PageSpeed Insights to dostępne bez opłat narzędzie Google, które dla podanego adresu pokazuje, jak strona działa na telefonach i komputerach, oraz podpowiada, co można poprawić. Nie wymaga logowania ani instalacji. Wystarczy otworzyć stronę narzędzia, wkleić adres podstrony w jedyne pole na ekranie i uruchomić analizę przyciskiem obok pola.

Według opisu narzędzia w dokumentacji Google raport składa się z dwóch rodzajów danych. Pierwszy to dane od rzeczywistych użytkowników, zbierane w raporcie Chrome User Experience Report, w skrócie CrUX, czyli zestawieniu anonimowych pomiarów z przeglądarki Chrome. Drugi to dane laboratoryjne, powstające w chwili testu w narzędziu Lighthouse, które wczytuje stronę na jednym symulowanym urządzeniu przy stałych warunkach sieci.

To rozróżnienie jest kluczem do całego raportu. Większość nieporozumień bierze się z tego, że właściciel strony patrzy wyłącznie na kolorowe koło z liczbą punktów, czyli na dane laboratoryjne, i pomija część, która opisuje jego prawdziwych klientów.

Warto od razu wiedzieć, w jakich warunkach odbywa się test. Dokumentacja podaje, że dla telefonów Lighthouse emuluje urządzenie średniej klasy w sieci komórkowej o ograniczonej przepustowości, a dla komputerów połączenie przewodowe. Sam test jest wykonywany z jednego z trzech regionów: Azji, Europy lub Ameryki Północnej. Dla strony hydraulika z Łodzi oznacza to, że pomiar może zostać wykonany z serwera oddalonego od Polski, na symulowanym telefonie wolniejszym niż aparaty wielu jego klientów.

Jak uruchomić test i jak poruszać się po raporcie

Test uruchamia się dla jednego, konkretnego adresu, a nie dla całej witryny, dlatego zawsze trzeba badać kilka różnych typów podstron. Strona główna kancelarii z Krakowa może wypaść dobrze, a podstrona z długim wpisem na blogu i kilkunastoma zdjęciami znacznie gorzej. W sklepie warto osobno zbadać stronę główną, kategorię, kartę produktu i koszyk.

Po zakończeniu analizy u góry raportu znajdują się dwie zakładki: dla urządzeń mobilnych i dla komputerów. Każda ma własne dane i własną ocenę. Widok mobilny zwykle wypada słabiej, ponieważ test symuluje wolniejsze urządzenie i sieć komórkową. Jeśli większość klientów trafia na stronę z telefonu, właśnie ta zakładka powinna być punktem odniesienia.

Niżej raport układa się w trzy części. Pierwsza to dane od rzeczywistych użytkowników z informacją, czy strona przechodzi ocenę podstawowych wskaźników internetowych. Druga to ocena wydajności z testu: koło z liczbą od 0 do 100, pięć pomiarów laboratoryjnych i podgląd kolejnych klatek wczytywania. Trzecia to diagnostyka i zalecenia, a pod nimi pozostałe kategorie: dostępność, sprawdzone metody i SEO.

W części z danymi od użytkowników można przełączać widok między badanym adresem a całą witryną, którą narzędzie nazywa źródłem. Dokumentacja wyjaśnia, że jeśli dla pojedynczego adresu nie ma wystarczającej liczby pomiarów, narzędzie pokazuje dane dla całego źródła, a gdy i tych brakuje, część z danymi od użytkowników pozostaje pusta. Dzieje się tak na stronach nowych, rzadko odwiedzanych albo niedostępnych publicznie.

Dane od rzeczywistych użytkowników: pierwsza i najważniejsza część raportu

Górna część raportu odpowiada na pytanie, czy prawdziwi odwiedzający mają na stronie dobre wrażenia, i to od niej należy zaczynać lekturę. Pokazuje ona trzy podstawowe wskaźniki internetowe, po angielsku Core Web Vitals: LCP, czyli czas wyświetlenia największego elementu treści, INP, czyli czas reakcji strony na działanie użytkownika, oraz CLS, czyli miarę przesunięć układu. Obok nich raport podaje dwa wskaźniki pomocnicze: FCP, czyli czas pojawienia się pierwszej treści, oraz TTFB, czyli czas do otrzymania pierwszego bajtu odpowiedzi serwera, oznaczony w dokumentacji jako eksperymentalny.

Dane obejmują okres ostatnich 28 dni i według dokumentacji są w narzędziu aktualizowane codziennie. Każdy wskaźnik ma pasek w trzech kolorach: zielonym, bursztynowym i czerwonym. Szerokość kolorów pokazuje, jaka część wizyt mieściła się w danym przedziale. Jeśli w bursztynowej części paska LCP widnieje 11 procent, to znaczy, że tyle zaobserwowanych wczytań trwało od 2,5 do 4 sekund.

Co oznacza liczba nad paskiem

Liczba widoczna nad każdym paskiem to 75. percentyl, czyli wartość, której nie przekracza trzy czwarte wizyt. Dokumentacja tłumaczy ten wybór tak: chodzi o to, by ocena obejmowała większość odwiedzających, w tym osoby na słabszych urządzeniach i wolniejszych łączach. Średnia byłaby tu myląca, ponieważ kilku klientów z bardzo szybkim internetem ukryłoby kłopoty pozostałych.

Kiedy strona przechodzi ocenę

Strona przechodzi ocenę podstawowych wskaźników internetowych, gdy 75. percentyl każdego z trzech wskaźników, czyli LCP, INP i CLS, mieści się w przedziale dobrym. Wystarczy jeden wskaźnik poza tym przedziałem, by ocena była negatywna. Jeżeli dla INP brakuje danych, narzędzie ocenia stronę na podstawie dwóch pozostałych. Każdemu z tych wskaźników poświęciliśmy osobne omówienia: o przyczynach wolnego LCP, o opóźnionej reakcji mierzonej przez INP oraz o przeskokach układu, czyli CLS.

Dlaczego ta część jest ważniejsza od koła z punktami? Google w dokumentacji dla właścicieli witryn zaleca dbanie o dobre podstawowe wskaźniki internetowe i wyjaśnia, że jego systemy rankingowe starają się nagradzać dobre wrażenia użytkowników razem z innymi aspektami jakości strony. Mowa tam o trzech wskaźnikach i ich progach, a nie o liczbie punktów z testu. Liczba punktów jest narzędziem diagnostycznym dla osoby, która stronę naprawia.

Ocena wydajności: skąd bierze się liczba od 0 do 100

Liczba w kolorowym kole to średnia ważona pięciu pomiarów z jednego testu laboratoryjnego, a nie ocena całej witryny ani ocena wystawiana przez wyszukiwarkę. Zielony kolor oznacza wynik od 90 do 100, pomarańczowy od 50 do 89, a czerwony od 0 do 49.

Sposób liczenia opisuje dokumentacja punktacji Lighthouse. Na ocenę składa się pięć pomiarów, a każdy ma inną wagę. Trzy z nich to wskaźniki znane z górnej części raportu, tyle że zmierzone w teście: FCP, LCP i CLS. Dwa pozostałe występują tylko w laboratorium. Speed Index, czyli wskaźnik szybkości, opisuje, jak szybko zawartość strony staje się widoczna w trakcie wczytywania. Total Blocking Time, w skrócie TBT, czyli całkowity czas blokowania, mierzy, jak długo podczas wczytywania przeglądarka była zajęta i nie mogła reagować na działania użytkownika.

Z tabeli wynikają dwa praktyczne wnioski. Trzy pomiary, czyli TBT, LCP i CLS, odpowiadają łącznie za 80 procent oceny, więc to one decydują o kolorze koła. Drugi wniosek dotyczy skryptów: największą pojedynczą wagę ma czas blokowania, dlatego strony obciążone wieloma dodatkami, czatami, mapami i kodami śledzącymi tracą punkty nawet wtedy, gdy zdjęcia są wzorowo przygotowane.

Dlaczego test pokazuje co innego niż dane od użytkowników

Różnice między obiema częściami raportu są normalne i nie oznaczają błędu narzędzia. Opracowanie web.dev o różnicach między danymi laboratoryjnymi a rzeczywistymi wymienia kilka przyczyn. Test wczytuje stronę z pustą pamięcią podręczną, a powracający klienci mają już część plików zapisaną w przeglądarce, więc u nich strona otwiera się szybciej. Największym elementem treści może być co innego na dużym, a co innego na małym ekranie. Przesunięcia układu test mierzy głównie podczas wczytywania górnej części strony, podczas gdy u prawdziwych użytkowników liczą się także te, które pojawiają się przy przewijaniu. Wreszcie INP zależy od tego, kiedy i w co klient kliknie, czego laboratorium nie przewidzi. Czas blokowania jest jedynie przybliżeniem, które pomaga szukać przyczyn słabego INP.

To samo opracowanie radzi, jak postępować przy rozbieżnościach: o kolejności napraw powinny decydować dane od użytkowników, a dane laboratoryjne służą do odtwarzania kłopotu i sprawdzania poprawek przed ich wdrożeniem. Dobry wynik u użytkowników przy słabym teście nie jest powodem do niepokoju, choć test może podpowiedzieć usprawnienia warte wykonania. Sytuacja odwrotna, czyli zielone koło i czerwone paski u góry, wymaga działania, bo to klienci odczuwają kłopot.

Dlaczego wynik 100 punktów nie jest celem

Sto punktów nie jest celem, ponieważ ostatnie punkty kosztują nieproporcjonalnie dużo pracy, a nie przekładają się na odczuwalną różnicę dla klienta. Dokumentacja punktacji Lighthouse stwierdza, że idealny wynik jest wyjątkowo trudny do uzyskania i nie należy go oczekiwać, a za dobry uznaje każdy wynik od 90 w górę.

Ta sama dokumentacja opisuje zjawisko malejących korzyści. Mniej więcej od 96 punktów krzywa punktacji wypłaszcza się i dalsza poprawa wymaga coraz większych zmian w pomiarach. Podany tam przykład dobrze to obrazuje: przejście z 99 na 100 punktów wymaga mniej więcej takiej samej poprawy pomiaru jak przejście z 90 na 94.

W praktyce pogoń za setką prowadzi do decyzji, które szkodzą firmie. Sklep z Poznania może uzyskać lepszy wynik testu, usuwając ze strony moduł opinii, wyszukiwarkę produktów i narzędzia do mierzenia sprzedaży, ale straci funkcje, dzięki którym klienci kupują, i dane, na podstawie których właściciel podejmuje decyzje. Strona ma sprzedawać i odpowiadać na pytania, a szybkość jest warunkiem, który to ułatwia, nie celem samym w sobie. Szerzej o tym związku piszemy we wpisie o wygodzie użytkownika i jej wpływie na widoczność oraz sprzedaż.

Rozsądny cel wygląda inaczej. Po pierwsze, zielona ocena podstawowych wskaźników internetowych w danych od użytkowników na telefonach. Po drugie, wynik testu, który nie spada po kolejnych zmianach na stronie. Po trzecie, brak czerwonych pomiarów na najważniejszych typach podstron.

Diagnostyka i zalecenia: jak czytać dolną część raportu

Dolna część raportu to lista wskazówek, które tłumaczą, dlaczego pomiary wypadły tak, a nie inaczej, i nie jest to lista obowiązkowych zadań. Najważniejsza zasada pochodzi z dokumentacji punktacji Lighthouse: do oceny wydajności wchodzą bezpośrednio wyłącznie pomiary. Zalecenia i diagnostyka nie są punktowane. Ich wykonanie zwykle poprawia pomiary, więc związek z oceną istnieje, ale jest pośredni.

Wynika z tego, że liczba pozycji na liście nie mówi nic o stanie strony. Można wykonać dziesięć drobnych zaleceń i nie zmienić żadnego pomiaru, a można wykonać jedno i przesunąć LCP o sekundę. Dlatego każdą wskazówkę warto czytać z pytaniem: który pomiar poprawi i o ile.

Jak zbudowana jest pojedyncza wskazówka

Każda pozycja ma tytuł, znacznik koloru oraz strzałkę rozwijającą szczegóły. Po rozwinięciu pojawia się krótkie wyjaśnienie z odsyłaczem do dokumentacji oraz, co najcenniejsze, tabela konkretnych plików lub elementów strony: adresy obrazów, skryptów i arkuszy stylów wraz z ich rozmiarem albo czasem, który zajmują. Przy części wskazówek narzędzie podaje szacowaną oszczędność w kilobajtach lub milisekundach. To szacunek z jednego testu, a nie obietnica wyniku.

Nazwy i układ tej części zmieniają się wraz z kolejnymi wersjami Lighthouse, dlatego nie warto przywiązywać się do konkretnych tytułów. Z naszej praktyki wynika, że wskazówki niezmiennie dotyczą kilku tych samych obszarów: czasu odpowiedzi serwera, zasobów wstrzymujących wyświetlenie strony, obrazów, kodu JavaScript i CSS, skryptów zewnętrznych, czcionek, pamięci podręcznej oraz elementów bez określonych wymiarów. Nad listą bywa dostępny filtr, który pozwala wyświetlić tylko wskazówki związane z wybranym pomiarem. To najszybszy sposób, by przy słabym LCP nie czytać pozycji, które go nie dotyczą.

Pozostałe kategorie: dostępność, sprawdzone metody i SEO

Pod wydajnością raport pokazuje trzy kolejne kategorie z własnymi ocenami od 0 do 100. Dostępność dotyczy tego, czy ze strony mogą korzystać osoby z niepełnosprawnościami. Sprawdzone metody obejmują podstawowe zasady poprawnego budowania stron. Kategoria SEO sprawdza podstawowe warunki techniczne.

Z naszej praktyki: wynik 100 w kategorii SEO oznacza jedynie, że strona spełnia ten podstawowy zestaw warunków. Nie mówi nic o treściach, doborze fraz, linkach ani konkurencji, więc nie jest oceną pozycjonowania. Pełny obraz daje dopiero analiza opisana we wpisie o tym, co powinien zawierać audyt SEO.

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

Które zalecenia mają realne znaczenie, a które są kosmetyczne

Realne znaczenie ma zalecenie, które spełnia dwa warunki: dotyczy wskaźnika, który u rzeczywistych użytkowników jest poza przedziałem dobrym, i ma w szczegółach dużą szacowaną oszczędność albo wskazuje element widoczny zaraz po otwarciu strony. Wszystko inne można odłożyć albo pominąć.

Praca z listą powinna więc zaczynać się od góry raportu. Jeśli u użytkowników czerwony jest LCP, pierwszeństwo mają wskazówki o czasie odpowiedzi serwera, o zasobach wstrzymujących wyświetlenie strony i o głównym obrazie. Jeśli kłopotem jest INP, liczą się wskazówki o kodzie JavaScript i skryptach zewnętrznych. Jeśli CLS, najważniejsze są obrazy, reklamy i ramki bez podanych wymiarów oraz czcionki. Kolejność prac dla wszystkich trzech wskaźników omawiamy we wpisie o poprawianiu Core Web Vitals na stronie firmy.

Przykład z życia. Gabinet stomatologiczny z Bydgoszczy otrzymuje raport z kilkunastoma wskazówkami. U użytkowników słaby jest tylko LCP. Po rozwinięciu szczegółów okazuje się, że głównym elementem jest zdjęcie gabinetu o wadze kilku megabajtów, wczytywane w pełnej rozdzielczości także na telefonach. Jedna zmiana, czyli przygotowanie zdjęcia w mniejszych wymiarach i nowocześniejszym formacie, rozwiązuje główny kłopot. Pozostałe pozycje, dotyczące kilku kilobajtów w stylach, nie zmienią odczuć pacjentów. O przygotowaniu zdjęć piszemy szerzej we wpisie o obrazach na stronie i ich wpływie na SEO.

Jest też grupa wskazówek, które wyglądają na drobiazg, a nim nie są. Opracowanie web.dev zwraca uwagę, że na stronach nieprzystosowanych do telefonów przeglądarka może doliczać do każdego dotknięcia opóźnienie około 300 milisekund. Wlicza się ono do INP, a test laboratoryjny go nie wychwytuje. Zapobiega temu jeden wiersz w nagłówku strony, który informuje przeglądarkę, że układ dopasowuje się do szerokości ekranu. Na starszych, samodzielnie budowanych stronach bywa on pomijany, a jego uzupełnienie należy do podstaw SEO technicznego.

<meta name="viewport" content="width=device-width, initial-scale=1">

Jak porównywać wyniki przed zmianą i po niej

Rzetelne porównanie wymaga kilku pomiarów tego samego adresu w tych samych warunkach przed zmianą i po niej, a następnie odczekania, aż zmiana będzie widoczna w danych od użytkowników. Pojedynczy test przed i pojedynczy po niczego nie dowodzi, bo wynik zmienia się między przebiegami nawet wtedy, gdy na stronie nic się nie zmieniło.

Dokumentacja PageSpeed Insights wyjaśnia, że zmienność bierze się między innymi z warunków sieci, zasobów sprzętowych i rywalizacji o te zasoby w chwili testu. Dokumentacja punktacji Lighthouse dopisuje do tej listy testy A/B i zmieniające się reklamy na stronie, zmiany tras w sieci, testowanie na różnych urządzeniach, a także rozszerzenia przeglądarki i programy antywirusowe. Zaleca też, by o wydajności myśleć jak o rozkładzie wyników, a nie o jednej liczbie.

1. Ustalenie listy adresów

   Po jednym przedstawicielu każdego typu podstrony: strona główna, usługa lub kategoria, produkt lub wpis. Zawsze ten sam, pełny adres.

2. Pomiar wyjściowy

   Kilka przebiegów dla każdego adresu, osobno dla telefonu. Z naszej praktyki: do notatek trafia wartość środkowa, a nie najlepsza.

3. Jedna zmiana naraz

   Wdrożenie jednej poprawki albo jednej grupy poprawek, tak by było wiadomo, co przyniosło efekt.

4. Pomiar kontrolny

   Ta sama liczba przebiegów dla tych samych adresów, po wyczyszczeniu pamięci podręcznej strony i serwera.

5. Kontrola danych od użytkowników

   Obserwacja górnej części raportu przez kolejne tygodnie, aż okno 28 dni obejmie wyłącznie wizyty po zmianie.

Co porównywać, a czego nie

Porównywać należy przede wszystkim poszczególne pomiary, a dopiero w drugiej kolejności ocenę ogólną. Jeśli poprawka dotyczyła głównego zdjęcia, miarą sukcesu jest LCP w sekundach. Jeśli dotyczyła skryptów, jest nią czas blokowania w milisekundach. Ocena ogólna jest średnią ważoną, więc może drgnąć o kilka punktów z powodów niezwiązanych z wykonaną pracą. Nie należy też zestawiać wyniku mobilnego z komputerowym ani pomiarów dwóch różnych adresów, bo każdy z nich powstaje w innych warunkach.

Ile czekać na zmianę w danych od użytkowników

Dane laboratoryjne zmieniają się natychmiast po wdrożeniu poprawki, natomiast dane od użytkowników obejmują okres 28 dni. Przez pierwsze tygodnie po zmianie w tym oknie mieszczą się jeszcze wizyty sprzed poprawki, dlatego paski u góry raportu przesuwają się stopniowo. Pełny efekt widać dopiero wtedy, gdy całe okno obejmuje okres po wdrożeniu. Ocenianie poprawki po trzech dniach na podstawie górnej części raportu prowadzi do błędnego wniosku, że praca nic nie dała.

• Ten sam pełny adres w każdym pomiarze, z tym samym zakończeniem i protokołem.
• Ta sama zakładka raportu: urządzenia mobilne albo komputery.
• Kilka przebiegów przed zmianą i tyle samo po niej.
• Zapisane wartości poszczególnych pomiarów, nie tylko ocena ogólna.
• Zapisany dzień pomiaru i opis wdrożonej zmiany.
• Brak innych zmian na stronie w okresie porównania, w tym nowych dodatków i skryptów.
• Ocena danych od użytkowników dopiero po upływie pełnego okna 28 dni.

Typowe pomyłki przy czytaniu raportu i kiedy potrzebna jest pomoc

Najczęstszą pomyłką jest ocenianie strony po jednej liczbie z jednego testu, z pominięciem danych od użytkowników. Wynikają z niej prawie wszystkie pozostałe błędy, które spotykamy w rozmowach z właścicielami stron.

Pierwszy to badanie wyłącznie strony głównej. Klienci z wyszukiwarki często trafiają od razu na podstronę usługi, kategorię lub wpis, a te bywają zbudowane inaczej i cięższe. Drugi to patrzenie tylko na zakładkę komputerową, ponieważ wygląda lepiej. Trzeci to traktowanie listy wskazówek jak spisu obowiązków i wymaganie od wykonawcy usunięcia każdej pozycji, bez pytania o jej wpływ na pomiary.

Czwarta pomyłka to działania pod test zamiast pod klienta: opóźnianie wszystkich skryptów do pierwszego ruchu użytkownika albo usuwanie potrzebnych funkcji. Z naszych obserwacji wynika, że koło robi się wtedy zielone, a dane od użytkowników pozostają bez zmian lub się pogarszają, bo pierwsze kliknięcie trafia na stronę, która dopiero zaczyna wczytywać kod.

Piąta pomyłka dotyczy wniosków: przekonanie, że poprawa oceny z 60 na 90 punktów sama podniesie pozycje. Szybkość jest jednym z elementów dobrych wrażeń ze strony, a o widoczności decyduje wiele czynników jednocześnie. Nie da się uczciwie obiecać określonej pozycji w zamian za określony wynik testu.

Kiedy warto poprosić o pomoc

Samodzielnie można zwykle uporać się ze zdjęciami, nadmiarem dodatków i podstawowymi ustawieniami pamięci podręcznej. Pomoc specjalisty jest potrzebna, gdy raport wskazuje na czas odpowiedzi serwera, kod motywu lub skrypty, których nie da się wyłączyć bez utraty funkcji, gdy wskaźniki u użytkowników pozostają czerwone mimo wykonanych poprawek, a także gdy wyniki różnych podstron tego samego typu znacznie się od siebie różnią. W takich sytuacjach analiza szybkości jest zwykle częścią szerszego przeglądu, który opisujemy na stronie kompleksowego audytu SEO: obok wydajności obejmuje on indeksowanie, strukturę witryny i treści, dzięki czemu wiadomo, czy szybkość jest rzeczywiście najpilniejszą sprawą.

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