Wydajność

PageSpeed: co mierzy i co poprawić najpierw?

PageSpeed pokazuje problemy z ładowaniem, reakcją i stabilnością strony. Naucz się czytać LCP, INP i CLS bez pogoni za wynikiem 100/100.

Opublikowano 24 lipca 2026 · zaktualizowano 31 lipca 2026 · 13 min czytania · Opracowanie: PanWWW

PageSpeed Insights pomaga znaleźć problemy z szybkością i wygodą działania strony, ale sam wynik od 0 do 100 nie jest celem biznesowym. Najważniejsze są realne doświadczenia użytkowników: czy główna treść pojawia się szybko, czy strona reaguje po kliknięciu i czy elementy nie przesuwają się podczas ładowania. Najpierw sprawdź dane terenowe, potem odtwórz problem na telefonie i popraw przyczynę. Dopiero na końcu porównaj kolejny test.

Najważniejsze wnioski

PageSpeed Insights może pokazywać dane z prawdziwych wizyt i osobny test laboratoryjny.
Trzy podstawowe Core Web Vitals to LCP, INP i CLS.
Zielone progi są pomocą diagnostyczną, nie gwarancją wyższej pozycji ani większej sprzedaży.
Najpierw naprawiaj problem widoczny dla klienta, na przykład spóźniony przycisk lub skaczący formularz.
Obraz główny, fonty, skrypty zewnętrzne, ciężki motyw i hosting to częste źródła opóźnień.
Nie każda wolna strona wymaga przebudowy. Czasem wystarcza kilka celnych zmian, ale trzeba mierzyć przed i po.

Co właściwie pokazuje PageSpeed Insights

PageSpeed Insights analizuje adres strony osobno dla urządzeń mobilnych i komputerów. Raport może zawierać dwa różne rodzaje danych:

Dane terenowe, czyli informacje z rzeczywistych wizyt użytkowników zebrane w Chrome User Experience Report, jeśli dla danego adresu lub domeny jest ich wystarczająco dużo.
Dane laboratoryjne, czyli pojedynczą symulację wykonaną przez Lighthouse w określonych warunkach.

Te części mogą dawać odmienny obraz. Laboratorium jest przydatne do powtarzalnej diagnozy, ale nie reprezentuje każdego klienta. Dane terenowe obejmują zróżnicowane telefony, sieci i zachowania, lecz są agregowane w czasie. Mała lub nowa strona może w ogóle nie mieć wystarczającego zestawu danych terenowych.

Dlatego czerwony wynik z jednego testu nie oznacza automatycznie, że każdy klient widzi identyczny problem. Zielony wynik również nie dowodzi, że strona jest idealna. Sprawdź, która część raportu sygnalizuje problem i czy da się go odtworzyć w realnym scenariuszu.

Lokalny punkt odniesienia pokazuje nasz anonimowy benchmark 50 stron firm z Kielc. Wyniki są laboratoryjne i nie służą do tworzenia rankingu firm, ale pomagają zobaczyć skalę najczęstszych problemów w zróżnicowanej próbie.

LCP, INP i CLS po ludzku

Google opisuje Core Web Vitals jako zestaw wskaźników dotyczących ładowania, reakcji i stabilności wizualnej. Aktualne definicje oraz sposób oceny są opisane w dokumentacji Web Vitals.

Wskaźnik	Co mierzy	Dobry wynik	Jak problem odczuwa klient
LCP	Czas pojawienia się największego ważnego elementu	do 2,5 s	Nagłówek lub główne zdjęcie długo pozostaje niewidoczne
INP	Opóźnienie reakcji na interakcje	do 200 ms	Menu, przycisk albo formularz reaguje z opóźnieniem
CLS	Nieoczekiwane przesunięcia układu	do 0,1	Użytkownik chce kliknąć przycisk, ale ten nagle zmienia pozycję

Progi odnoszą się do 75. percentyla wizyt, osobno dla urządzeń mobilnych i komputerów. Szczegółowe uzasadnienie podaje materiał Defining Core Web Vitals thresholds.

LCP: kiedy główna treść pojawia się za późno

Elementem LCP bywa duży nagłówek, zdjęcie w hero albo inny widoczny fragment u góry strony. Częstą przyczyną opóźnienia jest ciężki obraz, nieprawidłowe priorytety pobierania, wolna odpowiedź serwera albo kod, który blokuje renderowanie.

Nie wystarczy skompresować wszystkich zdjęć. Najpierw ustal, który element jest LCP. Jeśli jest nim główny obraz, powinien mieć odpowiedni rozmiar, nowoczesny format i jasny priorytet ładowania. Jeśli jest nim tekst, problem może leżeć w fontach lub arkuszach stylów.

INP: kiedy strona nie odpowiada po kliknięciu

INP dotyczy reakcji na działania użytkownika podczas wizyty. Ciężkie skrypty mogą blokować główny wątek przeglądarki, przez co kliknięcie menu albo wybór opcji w formularzu wydaje się nieskuteczny.

W praktyce warto testować konkretne ścieżki:

otwarcie menu na telefonie,
kliknięcie przycisku wyceny,
rozwinięcie cennika,
wpisywanie w formularzu,
zaakceptowanie zgody,
przejście między elementami interaktywnymi.

Sam raport może wskazać długie zadania w JavaScript, ale decyzja o poprawce powinna wynikać z funkcji potrzebnej klientowi.

CLS: kiedy układ ucieka spod palca

Przesunięcia powstają między innymi wtedy, gdy zdjęcie nie ma zarezerwowanego miejsca, font zmienia rozmiar tekstu po pobraniu albo baner pojawia się nad istniejącą treścią.

CLS nie jest tylko sprawą estetyki. Gdy użytkownik omyłkowo kliknie inny element, doświadczenie staje się nieprzewidywalne. Rozwiązaniem bywa określenie wymiarów mediów, rezerwowanie przestrzeni na elementy dynamiczne i ostrożne ładowanie fontów.

A co oznacza wynik 0 do 100

Wynik wydajności Lighthouse jest złożoną oceną kilku pomiarów laboratoryjnych. Może zmienić się między uruchomieniami przez warunki urządzenia, sieci, serwera lub zewnętrznych usług. Nie jest prostym procentem szybkości strony.

Wynik 100 może być użyteczny jako efekt dobrze zoptymalizowanej, prostej strony, ale nie powinien zastępować decyzji projektowej. Usunięcie potrzebnego formularza albo mapy tylko po to, aby poprawić punktację, może pogorszyć skuteczność witryny. Z drugiej strony ciężki element, którego nikt nie używa, nie powinien pozostawać bez pytania wyłącznie dlatego, że wygląda efektownie.

Google w przewodniku Understanding page experience in Google Search results wyjaśnia, że Core Web Vitals są używane przez systemy rankingowe, ale dobry wynik nie gwarantuje wysokiej pozycji. Najważniejsza nadal jest trafna, pomocna treść. Szybkość i doświadczenie strony wspierają całość, nie zastępują oferty, reputacji ani odpowiedzi na potrzebę klienta.

Jak czytać pozostałe pomiary

W raporcie laboratoryjnym pojawiają się też wskaźniki pomocnicze:

FCP wskazuje, kiedy przeglądarka wyświetla pierwszy fragment treści.
TBT szacuje czas blokowania głównego wątku w teście laboratoryjnym.
Speed Index opisuje tempo wizualnego wypełniania ekranu.
TTFB dotyczy czasu do pierwszego bajtu odpowiedzi i pomaga rozpoznać problemy serwera, cache lub połączenia.

Nie traktuj ich jako osobnych celów do odhaczenia. Są śladami prowadzącymi do przyczyny. Na przykład wolny TTFB może opóźnić LCP, a długie zadania w JavaScript mogą pogorszyć reakcję strony.

Metoda PanWWW: diagnoza bez pogoni za punktami

Stosujemy cztery kolejne pytania.

1. Co widzi prawdziwy użytkownik

Sprawdź dane terenowe, jeśli są dostępne, analitykę urządzeń oraz najważniejsze strony wejścia. Strona główna może działać szybko, podczas gdy rozbudowana podstrona usługi lub formularz są wyraźnie cięższe.

Nie ograniczaj się do jednego adresu. Wybierz co najmniej:

stronę główną,
najważniejszą usługę,
stronę kontaktu lub wyceny,
jeden dłuższy poradnik,
stronę z największą liczbą grafik.

2. Gdzie klient odczuwa problem

Otwórz stronę na telefonie, najlepiej także przy słabszym połączeniu. Wykonaj główne zadanie: znajdź usługę, poznaj warunki i przejdź do kontaktu. Zapisz moment, w którym coś pojawia się zbyt późno, przesuwa albo nie reaguje.

Taki test nie zastępuje narzędzi, ale nadaje pomiarom kontekst. LCP ma znaczenie dlatego, że klient czeka na ofertę, a nie dlatego, że liczba jest czerwona.

3. Jaka jest przyczyna techniczna

Połącz symptom z raportem. Przykładowo:

Symptom	Możliwa przyczyna	Pierwszy test
Główne zdjęcie pojawia się późno	Za duży plik lub niski priorytet	Sprawdź element LCP i rozmiar pobranego obrazu
Menu reaguje z opóźnieniem	Długie zadanie JavaScript	Nagraj wydajność podczas otwarcia menu
Przycisk przeskakuje	Brak miejsca na obraz lub baner	Wyłącz kolejno elementy dynamiczne
Pierwsza odpowiedź jest wolna	Serwer, cache lub praca backendu	Porównaj TTFB kilku podstron
Tekst zmienia układ	Sposób ładowania fontu	Przetestuj font systemowy lub inną strategię fontów

4. Czy poprawka pomogła w zadaniu

Zmierz ten sam adres w podobnych warunkach i ponownie wykonaj ścieżkę użytkownika. Zapisz zmianę przed oraz po. Jeśli wynik laboratoryjny poprawił się, ale formularz nadal reaguje źle, problem nie jest rozwiązany.

Najczęstsze przyczyny wolnej strony

Obrazy bez właściwego rozmiaru

Zdjęcie powinno być dostarczone w rozmiarze zbliżonym do miejsca, w którym jest wyświetlane. Przesyłanie pełnego pliku z aparatu do małej karty marnuje transfer. Pomagają formaty takie jak WebP lub AVIF, responsywne warianty i właściwe wymiary.

Nie ładuj jednak z opóźnieniem obrazu, który jest głównym elementem widocznym od razu. Lazy loading jest dobry dla dalszych sekcji, ale użyty bezmyślnie może opóźnić LCP.

Fonty i nadmiar odmian

Każda rodzina, grubość i styl może oznaczać kolejny plik. Dwie dobrze dobrane grubości często wystarczą stronie usługowej. Jeśli font jest kluczowy dla marki, trzeba zaplanować jego ładowanie oraz zachowanie tekstu przed pobraniem pliku.

Skrypty zewnętrzne

Widżety czatu, mapy, piksele reklamowe, narzędzia śledzące, filmy i systemy rezerwacji mogą działać poza kontrolą serwisu. Najpierw ustal, czy są potrzebne na każdej podstronie. Często da się uruchamiać je dopiero po interakcji albo tylko tam, gdzie mają zastosowanie.

Motyw i wtyczki

Na WordPressie problemem bywa nakładanie się kreatora, pakietu dodatków i kilku narzędzi wykonujących podobną funkcję. Oficjalny przewodnik Optimization opisuje między innymi cache, obrazy, pliki statyczne i ograniczanie zbędnej pracy.

Jeśli nie wiesz, za co odpowiadają elementy instalacji, zacznij od poznania budowy strony na WordPressie. Nie wyłączaj losowo wtyczek na działającej stronie bez kopii i środowiska testowego.

Hosting i praca serwera

Optymalizacja frontu nie naprawi serwera, który długo generuje każdą podstronę. Trzeba sprawdzić cache, wersję środowiska, bazę, zadania wykonywane przy żądaniu i zasoby hostingu. Sama zmiana pakietu na droższy nie gwarantuje poprawy, jeśli przyczyną jest kod lub zapytania do bazy.

Jak szybkość wpływa na pozyskanie klienta

Nie trzeba wymyślać jednego procentu utraconej sprzedaży, aby zobaczyć ryzyko. Na stronie usługowej szybkość wpływa na konkretne momenty:

użytkownik nie widzi od razu, czym zajmuje się firma,
przycisk kontaktu pojawia się po długiej chwili,
układ przesuwa się podczas próby kliknięcia,
formularz reaguje z opóźnieniem,
ciężka strona zużywa więcej transferu na telefonie,
przejście między ofertą a wyceną wydaje się niespójne.

Każdy z tych problemów można zweryfikować w konkretnym scenariuszu. Po poprawce warto mierzyć nie tylko wynik Lighthouse, lecz także przejścia do kontaktu, rozpoczęcia formularza, błędy wysłania i wartościowe zapytania. Gdy analityka nie jest skonfigurowana, zacznij od technicznego audytu strony i planu pomiaru.

Optymalizować czy przebudować

Optymalizacja zwykle wystarczy, gdy struktura strony i technologia są zdrowe, a problem ma kilka rozpoznawalnych źródeł. Przykładem może być nieprawidłowy obraz główny, zbędny skrypt albo brak cache.

Przebudowę warto rozważyć, gdy:

poprawki wymagają ciągłej walki z ciężkim kreatorem,
wiele wtyczek realizuje nakładające się zadania,
zmiana treści łatwo psuje układ,
strona nie ma logicznej ścieżki do kontaktu,
wersja mobilna wymaga osobnego łatania,
wykonawca nie ma dostępu do źródeł albo licencji,
po kolejnych poprawkach nadal nie da się bezpiecznie rozwijać witryny.

Wtedy problemem nie jest jeden obraz, lecz architektura rozwiązania. Zobacz, jak projektujemy lekkie strony premium oraz jak wygląda proces tworzenia strony internetowej.

Jeżeli spowolnienie pojawiło się nagle po aktualizacji albo razem z błędami, najpierw trzeba ustabilizować serwis. W takim przypadku właściwą ścieżką może być naprawa strony WordPress, a dopiero później optymalizacja kolejnych wskaźników.

Krótka checklista po każdej zmianie

Po wdrożeniu poprawki sprawdź:

tę samą podstronę w PageSpeed dla telefonu i komputera,
element LCP oraz diagnostykę głównego wątku,
menu, przyciski i formularz na prawdziwym telefonie,
przesunięcia po załadowaniu fontów, obrazów i zgód,
działanie formularza od wpisania danych do potwierdzenia,
najważniejszą ścieżkę od wejścia do kontaktu,
czy analityka i integracje nadal działają,
czy poprawka nie pogorszyła dostępności lub czytelności.

Wydajność nie jest jednorazowym zadaniem. Nowe zdjęcie, osadzony film lub kolejny skrypt mogą zmienić wynik. Warto więc ustalić prosty standard publikacji materiałów i okresową kontrolę ważnych adresów.

Jeśli chcesz ustalić, czy potrzebna jest poprawka, czy większa przebudowa, opisz nam problem ze stroną. Dołącz adres i informację, na jakim urządzeniu problem jest najbardziej widoczny.