Szybkość strony internetowej: jak czytać PageSpeed bez pogoni za wynikiem 100
Opublikowano
Aktualizacja
PageSpeed Insights potrafi zamienić rozmowę o jakości strony w rozmowę o jednej liczbie. Wynik 62 wygląda jak problem, a 94 jak sukces. Tyle że ta liczba opisuje pojedynczy test laboratoryjny wykonany w określonych warunkach. Nie mówi jeszcze, czy prawdziwi klienci czekają na najważniejszą treść, czy przycisk reaguje z opóźnieniem ani dlaczego układ przesuwa się tuż przed kliknięciem.
Lepsze pytanie brzmi: który fragment doświadczenia jest wolny, dla kogo i z jakiej przyczyny? Dopiero odpowiedź pozwala wybrać pracę wartą budżetu. Czasem będzie nią kompresja obrazu, czasem krótsze zadanie JavaScript, a czasem szybsza odpowiedź serwera. Pogoń za 100 punktami może natomiast zużyć czas na drobne audyty, które nie rozwiązują realnego problemu użytkownika.
Najpierw ustal, jakie dane oglądasz
PageSpeed Insights może pokazać dwa rodzaje dowodów. Dane terenowe pochodzą z Chrome User Experience Report i opisują zagregowane doświadczenia prawdziwych użytkowników w ostatnim okresie. Dane laboratoryjne pochodzą z Lighthouse: kontrolowanego testu przydatnego do odtwarzania problemów i sprawdzania zmian.
Te zbiory nie muszą się zgadzać. Rzeczywisty ruch obejmuje różne telefony, sieci, lokalizacje, zalogowanych użytkowników i działania po załadowaniu. Test laboratoryjny ma jeden profil urządzenia i sieci oraz ograniczony przebieg. Dobra diagnoza wykorzystuje oba:
- dane terenowe odpowiadają, czy problem dotyka użytkowników i jak często;
- laboratorium pomaga znaleźć przyczynę, odtworzyć ją i porównać wersję przed oraz po zmianie;
- własna analityka wydajności, jeśli istnieje, dodaje kontekst strony, szablonu, urządzenia i konkretnej interakcji.
Brak danych terenowych dla pojedynczego adresu nie oznacza, że strona jest szybka. Może oznaczać zbyt małą próbę. PageSpeed może wtedy pokazać dane dla całej domeny albo tylko laboratorium. Przed wnioskiem sprawdź etykietę zakresu.
Pierwszy raport możesz uzyskać przez bezpłatny audyt strony. Traktuj go jak punkt startowy, nie certyfikat jakości.
Trzy Core Web Vitals opisują różne awarie
Aktualny zestaw Core Web Vitals obejmuje LCP, INP i CLS. Google ocenia progi na 75. percentylu osobno dla urządzeń mobilnych i komputerów. Oznacza to, że pojedynczy szybki test nie równoważy wolnego doświadczenia istotnej części odbiorców.
Largest Contentful Paint (LCP) opisuje moment wyrenderowania największego istotnego elementu widocznego na początku. Zalecany próg „dobry” wynosi do 2,5 sekundy. Słaby LCP może wynikać z wolnego serwera, zasobu blokującego renderowanie, późno odkrytego obrazu głównego albo ciężkiego komponentu.
Interaction to Next Paint (INP) mierzy responsywność interakcji w czasie wizyty. Dobry wynik to maksymalnie 200 ms. Jeżeli menu, filtr lub formularz reaguje późno, przyczyną często jest zajęty główny wątek: długie zadanie JavaScript, kosztowne renderowanie albo zbyt dużo pracy wykonywanej w jednej reakcji.
Cumulative Layout Shift (CLS) opisuje nieoczekiwane przesunięcia układu. Dobry wynik wynosi do 0,1. Typowe źródła to obrazy bez wymiarów, banery i widgety bez zarezerwowanego miejsca, późno wstawiana treść oraz zmiana fontu.
Nie sumuj tych metryk w abstrakcyjną ocenę. Każda reprezentuje inny rodzaj szkody i wymaga innego śledztwa.
Macierz: od wyniku do następnego testu
Poniższa tabela jest krótką instrukcją triage. Nie przesądza przyczyny; zawęża następny krok.
| Objaw | Najpierw sprawdź | Częste przyczyny | Następny test |
|---|---|---|---|
| LCP słaby w polu i laboratorium | element LCP oraz TTFB | serwer, obraz główny, CSS lub font blokujący renderowanie | waterfall sieci i timing zasobu LCP |
| LCP słaby tylko w polu | segment urządzeń i krajów | wolniejsze telefony, sieci, cache albo różne szablony | dane według typu strony i urządzenia |
| INP słaby w polu | konkretne interakcje | długie zadania, ciężki kod dostawcy, renderowanie dużego DOM | profil wydajności podczas kliknięcia lub pisania |
| CLS słaby tylko w polu | przesunięcia po scrollowaniu i interakcji | lazy loading, banery, personalizacja, SPA | nagranie dłuższego przepływu użytkownika |
| Lighthouse słaby, pole dobre | stabilność kolejnych testów | sztuczne ograniczenia testu albo rzadki przypadek | kilka powtórzeń i test na słabszym urządzeniu |
| Wynik dobry, klienci narzekają | konkretną drogę do celu | wolny etap po starcie, API, wyszukiwarka lub formularz | pomiar pełnego zadania, nie tylko wejścia |
Najważniejsza zasada: szukaj zgodności między objawem a poprawką. Jeżeli LCP jest tekstem, konwersja wszystkich zdjęć może niczego nie zmienić. Jeżeli INP psuje widget czatu, optymalizacja CSS nie usunie długiego zadania.
Ustal priorytet według drogi klienta
Nie każda strona i nie każda milisekunda mają tę samą wartość. Najpierw wybierz szablony prowadzące do zapytania, rezerwacji lub zakupu: stronę usługi, kategorię, produkt, koszyk i formularz. Następnie połącz trzy kryteria:
- Zasięg: ilu użytkowników doświadcza problemu?
- Dotkliwość: czy blokuje zobaczenie oferty, interakcję czy stabilne kliknięcie?
- Koszt i ryzyko poprawki: czy zmiana jest lokalna, czy wymaga przebudowy platformy?
Szybka poprawka na mało odwiedzanej stronie może być dobrym zadaniem porządkowym, ale nie powinna wypierać problemu na głównym szablonie sprzedażowym. Z drugiej strony duży projekt infrastrukturalny nie zawsze wygrywa, jeśli kilka ciężkich skryptów można ograniczyć bez migracji technologii.
Wynik Lighthouse jest użyteczny jako regresyjny punkt kontrolny. Uruchamiaj test w podobnych warunkach i porównuj medianę kilku prób. Nie przedstawiaj różnicy dwóch punktów jako pewnego efektu, gdy sam test naturalnie się waha.
Obrazy poprawiaj wtedy, gdy są częścią problemu
Obrazy często wpływają na LCP i CLS, ale hasło „zmniejsz zdjęcia” jest zbyt ogólne. Sprawdź, czy przeglądarka pobiera plik odpowiadający rzeczywistemu rozmiarowi wyświetlenia, czy obraz główny nie jest omyłkowo ładowany leniwie i czy w HTML podano wymiary pozwalające zarezerwować miejsce.
Dla zestawu wariantów możesz użyć generatora obrazów responsywnych. Poprawny srcset i sizes pozwala przeglądarce wybrać rozsądny plik, ale nie zastępuje odpowiedniego kadru, kompresji, formatu ani priorytetu ładowania. Obraz znajdujący się daleko poniżej pierwszego ekranu zwykle może być lazy-loaded; kandydat LCP nie powinien czekać bez potrzeby.
Wymiary width i height nie zmuszają obrazu do stałego rozmiaru, jeśli CSS zachowuje responsywność. Dostarczają proporcje, dzięki którym przeglądarka może zarezerwować przestrzeń przed pobraniem pliku i ograniczyć CLS.
Kolejność wdrożenia, która ogranicza zgadywanie
Praktyczny cykl optymalizacji może wyglądać tak:
- wybierz dwa lub trzy ważne szablony i zapisz stan bazowy;
- odczytaj zakres i datę danych terenowych, a potem wynik laboratorium;
- nazwij metrykę oraz element albo interakcję, która ją tworzy;
- sformułuj hipotezę, np. „obraz główny jest odkrywany zbyt późno”;
- zmień jedną grupę przyczyn i porównaj testy laboratoryjne;
- po publikacji monitoruj dane rzeczywistych użytkowników przez wystarczający okres;
- sprawdź również wskaźnik biznesowy, błędy i zachowanie kluczowego formularza.
Nie obiecuj, że zielone Core Web Vitals automatycznie podniosą pozycje albo konwersję. Wydajność jest częścią doświadczenia i jednym z wielu sygnałów wyszukiwania. Jej poprawa ma wartość przede wszystkim wtedy, gdy usuwa realne oczekiwanie, niestabilność lub opóźnienie na drodze użytkownika.
Jeżeli raport wskazuje kilka nakładających się przyczyn i potrzebujesz przełożyć je na kolejność zmian, zobacz zakres usług projektowych i developerskich albo opisz stronę oraz najważniejszy cel. Dobrze postawiona diagnoza jest mniejsza i bardziej użyteczna niż ogólne „przyspieszenie wszystkiego”.
Źródła
Twój sklep traci klientów gdzieś między intencją a zakupem?
Pomogę zamienić objawy w konkretny plan techniczny.
Napisz, co nie działa ↗