Co zrobić, gdy strona ma niski wynik w PageSpeed Insights

Niski wynik w PageSpeed Insights nie zawsze oznacza, że strona jest „zła”. Czasem oznacza tylko tyle, że konkretny szablon, zdjęcie hero, skrypt analityczny albo wtyczka robią coś za wolno w warunkach testowych. Problem zaczyna się wtedy, gdy raport pokazuje słabe Core Web Vitals, użytkownicy długo czekają na treść, a właściciel strony losowo instaluje kolejne wtyczki „do przyspieszania”. To zwykle kończy się gorzej: rozjechanym layoutem, konfliktami JavaScriptu i wynikiem, który raz jest zielony, a raz znowu czerwony.

Dobra optymalizacja nie polega na gonieniu za 100/100 za wszelką cenę. Polega na usunięciu wąskich gardeł, które realnie spowalniają stronę: ciężkich obrazów, blokującego CSS, nadmiaru JavaScriptu, słabego hostingu, źle ustawionego cache i elementów, które przesuwają się podczas ładowania.

Jak czytać wynik PageSpeed Insights, żeby nie naprawiać złych rzeczy

Pierwsza decyzja: nie zaczynaj od samego koloru wyniku. PageSpeed Insights pokazuje dwa typy danych i trzeba je rozróżniać.

Dane z rzeczywistych użytkowników, czyli field data, pochodzą z Chrome UX Report, jeśli strona ma wystarczająco dużo ruchu. To ważniejsze źródło przy ocenie realnego doświadczenia użytkowników, bo pokazuje, jak strona działała na prawdziwych urządzeniach, sieciach i przeglądarkach.

Dane laboratoryjne, czyli lab data, pochodzą z testu Lighthouse. Są świetne do diagnozy technicznej, ale nie zawsze oddają pełny obraz. Test może być wykonany w warunkach wolniejszego urządzenia, z symulowaną siecią i bez historii cache użytkownika. Dlatego wynik może się różnić między testami.

Najważniejsze metryki, które trzeba sprawdzić w pierwszej kolejności:

• LCP — Largest Contentful Paint: powinien wynosić maksymalnie 2,5 s. Pokazuje, kiedy ładuje się największy ważny element widoczny nad zgięciem ekranu, najczęściej zdjęcie, baner, nagłówek albo blok tekstu.
• INP — Interaction to Next Paint: powinien wynosić maksymalnie 200 ms. Mierzy responsywność strony po kliknięciu, dotknięciu lub wpisaniu czegoś przez użytkownika.
• CLS — Cumulative Layout Shift: powinien wynosić maksymalnie 0,1. Pokazuje, czy elementy strony przesuwają się podczas ładowania.
• FCP — First Contentful Paint: informuje, kiedy pojawia się pierwszy widoczny element treści.
• TBT — Total Blocking Time: przydaje się w danych laboratoryjnych, bo pomaga diagnozować zbyt ciężki JavaScript.

W praktyce warto przyjąć taką kolejność:

1. Najpierw sprawdź Core Web Vitals.
2. Potem zobacz, która metryka psuje wynik: LCP, INP czy CLS.
3. Dopiero później analizuj listę zaleceń typu „Usuń nieużywany JavaScript”, „Wyeliminuj zasoby blokujące renderowanie” albo „Udostępniaj obrazy w formatach nowej generacji”.

Błąd, który widzę często: ktoś widzi wynik 48/100 i od razu instaluje wtyczkę cache. A problemem bywa jeden obraz w sekcji hero ważący 1,8 MB, font ładowany z kilku wariantów albo slider, który odpala skrypty na każdej podstronie. Wtedy cache tylko pudruje problem, ale go nie usuwa.

Dlaczego strona ma niski wynik i które problemy blokują ją najczęściej

Najczęstszy winowajca to zbyt ciężki pierwszy ekran. Jeśli użytkownik wchodzi na stronę i od razu musi pobrać wielkie zdjęcie, kilka fontów, animację, skrypty śledzące, kod slidera i style z motywu, przeglądarka nie ma jak szybko pokazać treści.

Największe problemy zwykle mieszczą się w kilku kategoriach.

1. Obrazy są za duże albo źle ładowane

To klasyk. Zdjęcie wrzucone prosto z aparatu lub banku zdjęć może mieć 3000–5000 px szerokości i ważyć kilka megabajtów. Na stronie mobilnej często wystarcza wersja 800–1200 px.

Co zrobić:

• używać formatów WebP lub AVIF, jeśli strona i przeglądarki użytkowników je obsługują;
• ustawić różne rozmiary obrazów przez srcset;
• kompresować zdjęcia przed publikacją;
• nie stosować lazy loadingu dla głównego obrazu LCP, jeśli jest widoczny od razu po wejściu;
• dodać stałe atrybuty szerokości i wysokości, żeby ograniczyć CLS.

Granica decyzyjna jest prosta: jeśli największy element nad zgięciem ekranu jest obrazem, a LCP przekracza 2,5 s, obraz jest jednym z pierwszych podejrzanych.

2. JavaScript blokuje reakcję strony

Dużo stron nie jest wolnych dlatego, że „serwer nie wyrabia”. Są wolne, bo przeglądarka musi przetworzyć za dużo kodu. Cookie baner, czat, mapa, remarketing, piksele reklamowe, formularz, slider i biblioteka animacji potrafią uruchomić się naraz.

Objawy:

• wysoki TBT w Lighthouse;
• słaby INP;
• opóźnienia po kliknięciu menu, przycisku lub filtra;
• strona wizualnie się załadowała, ale przez chwilę nie reaguje.

Co zrobić:

• usunąć skrypty, które nie są potrzebne na danej podstronie;
• ładować ciężkie skrypty dopiero po interakcji użytkownika;
• ograniczyć liczbę narzędzi marketingowych;
• podzielić kod na mniejsze paczki;
• opóźnić elementy typu czat, mapa, widget opinii, jeśli nie są potrzebne od razu.

Tu trzeba uważać. Bezmyślne ustawienie defer lub delay JS dla wszystkiego może popsuć formularz, koszyk, menu mobilne albo płatności. Najpierw test na kopii strony, potem wdrożenie produkcyjne.

3. CSS i fonty blokują szybkie wyrenderowanie treści

Jeśli strona ładuje duże pliki CSS z całego motywu, nawet na prostej podstronie przeglądarka musi je pobrać i przetworzyć przed pokazaniem treści. Do tego dochodzą fonty: kilka rodzin, kilka grubości, kursywa, ikony jako font — i robi się ciężko.

Co zrobić:

• ograniczyć liczbę odmian fontów, np. do 400 i 700;
• używać font-display: swap;
• usunąć nieużywany CSS;
• ładować krytyczny CSS dla pierwszego ekranu;
• nie używać bibliotek ikon, jeśli wystarczy kilka plików SVG.

W praktyce największy zysk daje redukcja tego, co ładuje się przed pierwszym renderem. Nie trzeba od razu przebudowywać całej strony. Najpierw warto odchudzić pierwszy ekran.

4. Hosting lub konfiguracja serwera spowalniają start

Jeżeli TTFB, czyli czas odpowiedzi serwera, jest wysoki, przeglądarka późno dostaje pierwszy HTML. Wtedy nawet dobrze zoptymalizowane obrazy nie uratują wyniku.

Typowe przyczyny:

• tani hosting współdzielony z przeciążonym serwerem;
• brak cache po stronie serwera;
• ciężkie zapytania do bazy danych;
• zbyt dużo wtyczek w CMS;
• brak aktualnej wersji PHP;
• brak CDN przy ruchu z różnych lokalizacji.

Co sprawdzić:

• czas odpowiedzi dokumentu HTML w DevTools;
• działanie cache pełnej strony;
• wersję PHP i limity hostingu;
• liczbę zapytań do bazy;
• czy strona nie generuje każdej odsłony od zera.

Nie zawsze trzeba od razu zmieniać hosting. Jeśli strona na WordPressie ma 45 aktywnych wtyczek, ciężki motyw i brak cache, migracja na droższy serwer może tylko zamaskować bałagan. Najpierw audyt, potem decyzja.

5. Layout przesuwa się podczas ładowania

Słaby CLS zwykle bierze się z elementów, które pojawiają się za późno i wypychają treść: reklamy, banery, fonty, obrazy bez wymiarów, popupy, paski promocyjne, osadzone filmy.

Co zrobić:

• rezerwować miejsce na reklamy, iframe i embed;
• dodawać wymiary obrazów;
• nie wstrzykiwać banerów nad treścią po załadowaniu strony;
• unikać zmian wysokości nagłówka po wczytaniu fontu;
• sprawdzić cookie baner na mobile, bo często psuje układ.

CLS bywa zdradliwy, bo na szybkim komputerze problemu prawie nie widać. Na telefonie ze słabszym procesorem użytkownik widzi już skaczące przyciski i tekst.

Co robić, a czego nie robić przy optymalizacji szybkości strony

Najrozsądniejszy plan działania wygląda tak:

Krok 1: Zrób pomiar bazowy

Przed zmianami zapisz wynik dla najważniejszych typów podstron:

• strona główna;
• kategoria lub listing;
• artykuł blogowy;
• karta produktu;
• landing page;
• koszyk lub formularz, jeśli są istotne biznesowo.

Nie testuj tylko strony głównej. W wielu serwisach główna wypada dobrze, a problem siedzi w listingach produktów albo artykułach z ciężkimi reklamami.

Krok 2: Znajdź jeden główny problem

Nie naprawiaj wszystkiego naraz. Jeśli LCP jest słaby, zacznij od elementu LCP. Jeśli INP jest słaby, szukaj ciężkiego JavaScriptu. Jeśli CLS jest słaby, sprawdź przesunięcia layoutu.

Prosta mapa decyzji:

• słaby LCP → obraz hero, TTFB, blokujący CSS, fonty, preload;
• słaby INP → JavaScript, event listenery, skrypty zewnętrzne, ciężkie komponenty;
• słaby CLS → brak wymiarów, reklamy, popupy, fonty, dynamiczne banery;
• wysoki TBT → zbyt dużo pracy głównego wątku;
• duży rozmiar strony → obrazy, biblioteki, nieużywany kod, wtyczki.

Krok 3: Usuń rzeczy zbędne, zanim zaczniesz dokładać narzędzia

Największy błąd to instalowanie kolejnych optymalizatorów bez usunięcia przyczyny. Jeśli strona ładuje trzy slidery, dwa systemy analityczne, czat, mapę i pięć wariantów fontu, kolejna wtyczka cache nie rozwiąże problemu strukturalnego.

Najpierw usuń lub ogranicz:

• nieużywane wtyczki;
• skrypty ładowane globalnie;
• stare piksele reklamowe;
• niepotrzebne animacje;
• duplikujące się biblioteki;
• ciężkie widgety widoczne dopiero na dole strony.

Krok 4: Optymalizuj elementy pierwszego ekranu

Pierwszy ekran ma największy wpływ na odczucie szybkości. Tu liczy się dyscyplina.

Dobre decyzje:

• obraz LCP w odpowiednim rozmiarze;
• preload dla kluczowego obrazu lub fontu, ale tylko jeśli faktycznie jest krytyczny;
• ograniczona liczba fontów;
• krótki, krytyczny CSS;
• brak ciężkiego slidera w hero;
• brak automatycznie ładowanej mapy lub filmu nad zgięciem ekranu.

Zła decyzja: ładowanie filmu w tle na mobile, a potem walka o zielony wynik. Da się to czasem obejść miniaturą i uruchomieniem filmu po kliknięciu, ale automatyczne wideo jako pierwszy element zwykle kosztuje dużo.

Krok 5: Włącz cache, CDN i kompresję, ale po sprawdzeniu skutków

Techniczne ustawienia, które zwykle pomagają:

• cache pełnej strony;
• cache przeglądarki dla statycznych zasobów;
• kompresja Brotli lub Gzip;
• HTTP/2 lub HTTP/3, jeśli hosting obsługuje;
• CDN dla obrazów i plików statycznych;
• minifikacja CSS i JS;
• opóźnienie ładowania niekrytycznych skryptów.

Ale jest warunek: po każdej zmianie trzeba przejść stronę ręcznie. Menu, formularze, koszyk, płatności, wyszukiwarka, filtry, popupy i zgody cookies muszą działać. Wynik 95/100 nie ma wartości, jeśli formularz kontaktowy przestał wysyłać zapytania.

Krok 6: Testuj po jednej grupie zmian

Dobra praktyka:

1. Zrób kopię zapasową.
2. Wdróż jedną grupę zmian, np. obrazy.
3. Przetestuj stronę.
4. Zmierz wynik ponownie.
5. Zapisz efekt.
6. Dopiero potem przejdź do JavaScriptu, CSS lub cache.

Nie ma gwarancji, że każda zmiana poprawi wynik. Czasem optymalizacja obrazów daje ogromny efekt, a czasem prawie żaden, bo blokadą jest serwer albo JavaScript. Dlatego trzeba mierzyć, a nie zgadywać.

Czego nie robić

• Nie gon za 100/100 kosztem funkcji strony.
• Nie instaluj kilku wtyczek cache naraz.
• Nie opóźniaj całego JavaScriptu bez testów.
• Nie usuwaj skryptów analitycznych, jeśli są potrzebne do kampanii, bez ustalenia konsekwencji.
• Nie oceniaj strony po jednym teście.
• Nie ignoruj wersji mobilnej, bo to ona najczęściej pokazuje prawdziwy problem.
• Nie traktuj PageSpeed Insights jako jedynego narzędzia. Do głębszej diagnostyki użyj też Chrome DevTools, Search Console, WebPageTest albo danych z własnej analityki.

Najlepszy pierwszy ruch? Otwórz raport PageSpeed Insights, znajdź najgorszą z trzech metryk LCP / INP / CLS i napraw dokładnie tę rzecz, która ją psuje. Jeśli LCP jest słaby, zacznij od pierwszego ekranu. Jeśli INP jest słaby, tnij i porządkuj JavaScript. Jeśli CLS jest słaby, ustabilizuj layout. Dopiero po tym warto dopieszczać szczegóły.

FAQ: najczęstsze pytania o niski wynik w PageSpeed Insights

Czy niski wynik PageSpeed Insights zawsze szkodzi SEO?
Nie zawsze wprost i nie zawsze natychmiast. Szybkość oraz Core Web Vitals są częścią oceny doświadczenia strony, ale nie zastępują jakości treści, linkowania, intencji użytkownika i technicznej indeksowalności. Słaby wynik jest jednak sygnałem ostrzegawczym, szczególnie gdy dotyczy wielu adresów URL.

Czy trzeba mieć 100/100 w PageSpeed Insights?
Nie. W praktyce lepiej mieć stabilną, szybką stronę z dobrymi Core Web Vitals niż polować na idealny wynik kosztem analityki, formularzy, reklam lub funkcji sprzedażowych. Wynik 90+ jest dobry, ale nie każda strona musi realnie dojść do 100.

Dlaczego wynik zmienia się między testami?
Bo test laboratoryjny zależy od wielu czynników: obciążenia serwera, zasobów zewnętrznych, reklam, fontów, cache, chwilowej odpowiedzi API i warunków symulacji. Dlatego warto robić kilka pomiarów i patrzeć na powtarzalne problemy, a nie na pojedynczy wynik.

Co poprawić jako pierwsze, jeśli nie wiem, od czego zacząć?
Najpierw sprawdź LCP na mobile. Jeżeli największy element ładuje się za wolno, zoptymalizuj obraz, CSS, fonty i czas odpowiedzi serwera. To najczęściej daje bardziej odczuwalny efekt niż drobne porządki w stopce strony.

Czy wtyczka cache wystarczy, żeby naprawić niski wynik?
Czasem pomaga, ale rzadko wystarcza sama. Cache nie zmniejszy źle przygotowanego obrazu, nie usunie zbędnego JavaScriptu i nie naprawi przesuwającego się layoutu. Może przyspieszyć odpowiedź serwera, ale nie zastąpi technicznego porządku.

Czy PageSpeed Insights pokazuje dokładnie to samo, co widzi użytkownik?
Nie w pełni. Dane rzeczywistych użytkowników są bliższe prawdy, ale pojawiają się tylko wtedy, gdy jest wystarczająco dużo danych. Test Lighthouse jest diagnostyczny — pomaga znaleźć problemy, lecz nie powinien być jedyną podstawą decyzji.

Kiedy warto zlecić audyt techniczny zamiast poprawiać stronę samodzielnie?
Gdy strona zarabia, ma kampanie reklamowe, sklep, formularze leadowe albo wiele podstron z różnymi szablonami. Samodzielne klikanie ustawień optymalizacyjnych może wtedy uszkodzić konwersję. Audyt ma sens także wtedy, gdy po podstawowej kompresji obrazów i cache wynik nadal jest słaby.

Więcej informacji na stronie: https://szymonsarnecki.pl