Szybkość strony firmowej: jak interpretować PageSpeed Insights i Core Web Vitals?

Strona firmowa może szybko pokazać nagłówek, a mimo to długo wyświetlać główne zdjęcie lub reagować z opóźnieniem na otwarcie menu. Dlatego szybkość strony firmowej warto oceniać na kilku poziomach. PageSpeed Insights pomaga je rozróżnić, pod warunkiem że osobno odczytujemy wynik testu, dane rzeczywistych użytkowników i wskazówki dotyczące przyczyn problemów.

PageSpeed Insights: dwa różne obrazy tej samej strony

Po wpisaniu adresu do PageSpeed Insights otrzymujesz wyniki oparte na dwóch źródłach danych.

Dane rzeczywistych użytkowników pochodzą z raportu Chrome User Experience Report, czyli CrUX. Obejmują poprzednie 28 dni i pokazują działanie witryny podczas rzeczywistych odwiedzin: na różnych urządzeniach, połączeniach i przy różnych zachowaniach użytkowników.

Test laboratoryjny wykonuje Lighthouse w określonych, symulowanych warunkach. Pozwala znaleźć przyczyny spowolnień i szybko sprawdzić efekt zmian.

Zielony wynik wydajności, na przykład 95 punktów, dotyczy testu laboratoryjnego. Ocena Core Web Vitals wynika z danych użytkowników. Te oceny mogą się różnić, ponieważ opisują inne warunki i okresy.

Sprawdź urządzenie oraz zakres danych

Wyniki dla telefonów i komputerów analizuj osobno. Test mobilny uwzględnia ograniczenia urządzenia i połączenia, dlatego często ujawnia problemy niewidoczne na szybkim komputerze biurowym.

Sprawdź również, czy dane dotyczą badanego adresu, czy całego źródła — w praktyce stron działających pod tym samym protokołem i hostem. Dobra ocena zbiorcza może ukrywać problem konkretnej podstrony ofertowej.

Brak danych CrUX oznacza, że narzędzie nie ma wystarczających pomiarów do oceny. To częsta sytuacja w małych serwisach. Można wtedy korzystać z testów laboratoryjnych, sprawdzać najważniejsze działania na telefonie i wdrożyć własny monitoring użytkowników. Takie rozwiązania wykorzystują między innymi standardy pomiaru wydajności rozwijane przez W3C.

Core Web Vitals: jak interpretować LCP, INP i CLS?

Core Web Vitals obejmują trzy wskaźniki opisujące ładowanie treści, reakcję na działania oraz stabilność układu.

Wskaźnik	Co opisuje?	Dobry wynik	Wymaga poprawy	Słaby wynik
LCP	Pojawienie się największego elementu treści w widocznym obszarze	do 2,5 s	powyżej 2,5 s do 4 s	powyżej 4 s
INP	Opóźnienie reakcji wizualnej na interakcję	do 200 ms	powyżej 200 ms do 500 ms	powyżej 500 ms
CLS	Nieoczekiwane przesunięcia układu	do 0,1	powyżej 0,1 do 0,25	powyżej 0,25

Ocena danych użytkowników opiera się na 75. percentylu. Jeżeli LCP wynosi 2,4 sekundy, oznacza to, że co najmniej 75% uwzględnionych pomiarów osiągnęło taki lub lepszy rezultat. Pozostała część odwiedzin mogła przebiegać wolniej.

Przy dostępności kompletu danych zaliczenie oceny Core Web Vitals wymaga dobrego wyniku wszystkich trzech wskaźników. Korzystna średnia nie wystarczy.

LCP: kiedy użytkownik widzi główną treść?

Elementem LCP może być duże zdjęcie realizacji, fotografia produktu albo blok tekstu. Wskaźnik nie określa czasu pobrania wszystkich zasobów strony.

Jeżeli LCP jest słaby, zacznij od ustalenia, który element został zmierzony. W portfolio może to być wizualizacja projektu, a na stronie usługi — rozbudowany nagłówek.

Dalsza diagnoza powinna odpowiedzieć na trzy pytania: czy przeglądarka długo czekała na dokument, czy późno rozpoczęła pobieranie głównego zasobu oraz czy coś opóźniło jego wyświetlenie. Samo zmniejszenie zdjęcia pomoże tylko w części takich przypadków.

INP: jak sprawnie strona odpowiada na działanie?

INP opisuje opóźnienie od interakcji, takiej jak kliknięcie lub dotknięcie, do kolejnego wyświetlenia obrazu po jej obsłużeniu. Uwzględnia interakcje w ciągu wizyty, a nie tylko pierwsze kliknięcie.

Problemy mogą ujawnić się przy otwieraniu menu, rozwijaniu odpowiedzi, zmianie wariantu produktu czy używaniu filtrów.

Standardowy test ładowania Lighthouse nie mierzy INP. Pokazuje natomiast TBT, czyli łączny czas blokowania głównego wątku przeglądarki. Wysoki TBT może wskazywać problemy ze skryptami, ale nie jest zamiennikiem pomiaru reakcji podczas korzystania ze strony.

CLS: czy treść pozostaje na swoim miejscu?

CLS opisuje nieoczekiwane przesunięcia widocznych elementów. To sytuacje, w których tekst przeskakuje podczas czytania albo przycisk zmienia położenie tuż przed kliknięciem.

Wskaźnik nie ma jednostki. Wynik 0,2 nie oznacza 0,2 sekundy.

Częste przyczyny to zdjęcia bez zarezerwowanego miejsca, dołączane później moduły oraz zmiana kroju pisma po pobraniu fontu. CLS warto sprawdzać także po przewinięciu strony i podczas korzystania z jej funkcji. Krótki test ładowania może nie ujawnić późniejszych przesunięć.

Zdjęcia i skrypty: co najczęściej wymaga poprawy?

Zdjęcia dopasowane do miejsca wyświetlania

W serwisach usługowych i portfolio obrazy potrafią stanowić dużą część pobieranych danych. Zdjęcie przygotowane do druku zwykle wymaga dostosowania przed publikacją.

Praktyczna optymalizacja obejmuje:

• dopasowanie wymiarów obrazu do miejsca wyświetlania;
• przygotowanie mniejszych wariantów dla telefonów;
• porównanie jakości i rozmiaru plików w formatach WebP lub AVIF;
• określenie proporcji obrazu, aby przeglądarka zarezerwowała miejsce;
• opóźnione ładowanie zdjęć znajdujących się poza początkowym widokiem.

Głównego zdjęcia będącego elementem LCP nie należy ładować z opóźnieniem. Powinno zostać wykryte i pobrane odpowiednio wcześnie. Automatyczne zastosowanie jednej reguły do całej galerii może więc pogorszyć początek wizyty.

Skrypty, które konkurują o zasoby urządzenia

Czat, mapa, analityka, narzędzia reklamowe i rozbudowane animacje wymagają pracy przeglądarki. Znaczenie ma zarówno wielkość plików, jak i koszt wykonania ich kodu.

Zacznij od przeglądu dodatków: które są potrzebne, które się powielają, a które można uruchamiać dopiero wtedy, gdy użytkownik chce z nich skorzystać. Przykładem jest mapa ładowana po naciśnięciu przycisku.

Przy słabym INP wykonawca powinien zbadać konkretne opóźnione interakcje. Samo zmniejszenie plików JavaScript nie gwarantuje, że przeglądarka szybciej wykona zawarte w nich zadania.

Hosting i TTFB: kiedy szukać problemu na serwerze?

TTFB oznacza czas oczekiwania na pierwszy bajt odpowiedzi. Pomaga rozpoznać, czy opóźnienie zaczyna się jeszcze przed pobraniem głównej treści.

Wysoki TTFB może wynikać z przeciążenia serwera, wolnych zapytań do bazy danych, przekierowań, odległości od użytkownika albo warunków sieciowych. Nie przesądza automatycznie o konieczności zmiany hostingu.

Najpierw warto sprawdzić czas generowania dokumentu, działanie pamięci podręcznej publicznych podstron oraz zachowanie witryny przy większym ruchu. Dopiero te ustalenia pozwalają ocenić, czy potrzebna jest poprawa aplikacji, konfiguracji, czy parametrów usługi hostingowej.

Jak ustalić kolejność usprawnień?

Priorytety powinny wynikać z wpływu problemu na użytkowników i celu strony.

1. Wybierz najważniejsze podstrony. Zbadaj stronę główną, ofertę, kontakt oraz reprezentatywną realizację lub produkt.
2. Zapisz punkt wyjścia. Zachowaj datę, urządzenie, zakres danych i wartości wskaźników.
3. Wskaż konkretną przeszkodę. Może nią być późne wyświetlenie oferty, opóźnione otwarcie menu albo przesuwający się formularz.
4. Oceń zasięg przyczyny. Poprawka wspólnego nagłówka może pomóc wielu podstronom; zmiana pojedynczej galerii będzie miała węższy efekt.
5. Porównaj przewidywany wpływ z kosztem. Usunięcie zbędnego skryptu lub określenie wymiarów zdjęć może być rozsądnym pierwszym krokiem.

Przykładowo: jeśli oferta pojawia się szybko, lecz mobilne menu reaguje z wyraźnym opóźnieniem, analiza skryptów zasługuje na wyższy priorytet niż dalsza kompresja niewielkiego logo.

Jak potwierdzić efekt zmian?

Po wdrożeniu poprawek wykonaj kilka testów laboratoryjnych w porównywalnych warunkach. Porównuj konkretne wskaźniki i ich przyczyny; pojedynczy wynik punktowy może się wahać.

Sprawdź też ręcznie najważniejsze działania: otwarcie menu, wysłanie formularza, przeglądanie realizacji lub dodanie produktu do koszyka.

Dane rzeczywistych użytkowników będą zmieniały się stopniowo, ponieważ obejmują ruchome okno 28 dni. Pierwszego dnia po poprawce raport nadal uwzględnia wcześniejsze wizyty.

W zleceniu optymalizacji zapisz badane adresy, urządzenia, oczekiwane rezultaty oraz sposób ich sprawdzenia. Dzięki temu ocenę szybkości strony firmowej można powiązać z konkretną poprawą korzystania z oferty, kontaktu i zakupów.