Co to jest PageSpeed Insights i jak poprawnie analizować szybkość strony?

PageSpeed Insights to narzędzie Google służące do analizy wydajności stron internetowych. Po podaniu adresu URL otrzymuję między innymi informacje o szybkości ładowania, responsywności interfejsu, stabilności układu oraz potencjalnych problemach technicznych. Najbardziej widocznym elementem raportu jest wynik Performance w skali od 0 do 100, ale właśnie ta liczba jest również najczęściej źle interpretowaną częścią całego narzędzia.

PageSpeed Insights nie jest testem, który wydaje prosty werdykt „strona jest szybka” albo „strona jest wolna”. Łączy różne rodzaje danych i pokazuje problemy, które trzeba później zinterpretować w kontekście konkretnego serwisu. Strona z wynikiem 100 może nadal mieć problemy biznesowe i techniczne, a strona osiągająca 80 punktów nie musi wymagać przebudowy. PageSpeed jest przede wszystkim narzędziem diagnostycznym, a nie grą polegającą na zdobyciu maksymalnej liczby punktów.

Co to jest PageSpeed Insights?

PageSpeed Insights, często skracany do PSI, to bezpłatne narzędzie Google analizujące wydajność konkretnej podstrony. Po wpisaniu adresu narzędzie wykonuje test i prezentuje między innymi:

• dane dotyczące rzeczywistych użytkowników, jeżeli są dostępne,
• wyniki testu laboratoryjnego Lighthouse,
• ocenę wydajności,
• wybrane metryki szybkości i responsywności,
• problemy wpływające na ładowanie strony,
• diagnostykę zasobów CSS i JavaScript,
• informacje dotyczące obrazów i fontów,
• sugestie możliwych optymalizacji.

Raport może więc wskazać, że duży obraz opóźnia pojawienie się głównej treści, część JavaScriptu blokuje przeglądarkę, serwer odpowiada zbyt wolno albo elementy strony przesuwają się podczas ładowania. Nie oznacza to jednak, że każda sugestia wymaga natychmiastowego wdrożenia. PageSpeed pokazuje objawy i potencjalne miejsca do sprawdzenia. Dopiero analiza pozwala ustalić, które z nich są rzeczywistym problemem.

Jak uruchomić test PageSpeed Insights?

Wystarczy wejść do PageSpeed Insights, podać pełny adres podstrony i uruchomić analizę. Ważne jest słowo „podstrony”. PageSpeed Insights nie wykonuje jednego zbiorczego testu całego serwisu. Jeżeli analizuję stronę główną, wynik opisuje stronę główną. Nie oznacza to automatycznie, że identycznie działa:

• karta produktu,
• kategoria produktów,
• blog,
• formularz kontaktowy,
• landing page,
• koszyk,
• checkout,
• panel klienta.

Każdy z tych widoków może korzystać z innych skryptów, obrazów, zapytań i funkcji. W sklepie internetowym karta produktu może być szybka, a lista produktów wyjątkowo ciężka przez filtry. Strona główna może mieć świetny wynik, podczas gdy checkout ładuje kilkanaście zewnętrznych integracji. Dlatego nie oceniam całego serwisu na podstawie jednego URL.

Co oznacza wynik PageSpeed od 0 do 100?

Najbardziej charakterystyczna liczba w raporcie pochodzi z Lighthouse. To syntetyczna ocena wydajności wyliczana na podstawie kilku metryk mierzonych podczas konkretnego testu laboratoryjnego. Wynik jest prezentowany w skali od 0 do 100. W uproszczeniu:

• 90 do 100 oznacza dobry wynik,
• 50 do 89 oznacza wynik wymagający uwagi,
• 0 do 49 oznacza słabą wydajność laboratoryjną.

Nie traktuję jednak tych zakresów jak ocen szkolnych. 89 punktów nie oznacza złej strony tylko dlatego, że nie pojawił się zielony kolor. Podobnie 100 punktów nie oznacza, że projekt został technicznie zakończony. Wynik Performance jest rezultatem modelu Lighthouse, a nie bezpośrednim pomiarem sprzedaży, UX, jakości kodu czy wszystkich rzeczywistych wizyt.

Czy 100/100 w PageSpeed oznacza idealną stronę?

Nie. To jeden z najważniejszych mitów związanych z PageSpeed Insights. Wynik 100 oznacza, że w konkretnym uruchomieniu testu laboratoryjnego strona bardzo dobrze wypadła według zestawu metryk i sposobu ich ważenia stosowanego przez Lighthouse. Nie oznacza, że:

• każdy użytkownik zobaczy stronę równie szybko,
• serwer nigdy nie będzie przeciążony,
• wszystkie podstrony mają podobną wydajność,
• strona nie posiada błędów JavaScript,
• proces zakupowy działa prawidłowo,
• formularze są wygodne,
• SEO zostało dobrze wdrożone,
• strona dobrze konwertuje,
• kod jest łatwy w dalszym utrzymaniu.

Można mieć bardzo lekką stronę zawierającą logo i dwa zdania, która osiąga idealny wynik, ale biznesowo nie robi praktycznie nic. Można też posiadać rozbudowany sklep, który musi obsługiwać warianty, filtry, płatności, analitykę, zgody, wyszukiwarkę i dynamiczne dane, a mimo to zapewnia użytkownikom bardzo dobre doświadczenie przy wyniku niższym niż 100. Optymalizacja powinna służyć stronie. Strona nie powinna być projektowana wyłącznie po to, aby służyć testowi PageSpeed.

PageSpeed Insights pokazuje dwa różne rodzaje danych

To klucz do poprawnego czytania raportu. PageSpeed może prezentować:

• dane rzeczywistych użytkowników,
• dane laboratoryjne.

Te dwa zestawy mogą znacząco się od siebie różnić. I nie musi to oznaczać błędu.

Dane rzeczywistych użytkowników

Field data, czyli dane terenowe, pochodzą z prawdziwych wizyt użytkowników Chrome i są agregowane w Chrome User Experience Report. Pokazują, jak strona działała w rzeczywistych warunkach. Użytkownicy mogą korzystać z różnych:

• telefonów,
• komputerów,
• procesorów,
• połączeń internetowych,
• lokalizacji,
• wersji przeglądarki,
• stanów pamięci podręcznej.

To ogromna różnica względem pojedynczego testu wykonywanego w kontrolowanych warunkach. Jeżeli tysiące osób odwiedzają stronę na realnych urządzeniach, właśnie te dane najlepiej pokazują rzeczywiste doświadczenie użytkowników. Szerzej opisuję je we wpisie o Core Web Vitals.

Dane laboratoryjne

Lab data pochodzą z testu Lighthouse uruchamianego podczas analizy. Narzędzie odtwarza określone warunki urządzenia i połączenia, a następnie obserwuje proces ładowania strony. Laboratorium ma bardzo dużą zaletę. Mogę wykonać test teraz, zmienić kod i uruchomić go ponownie kilka minut później. Dzięki temu szybko sprawdzam, czy konkretna modyfikacja wpłynęła na wynik. Dane rzeczywistych użytkowników nie aktualizują się w ten sposób natychmiast. Dlatego oba rodzaje pomiaru mają inne zastosowanie. Field data mówią mi, jak wygląda rzeczywistość. Lab data pomagają mi szukać przyczyny.

Dlaczego PageSpeed pokazuje świetny wynik, a Core Web Vitals są słabe?

Bo nie jest to ten sam pomiar. Wynik Performance 95 może pochodzić z pojedynczego testu Lighthouse wykonanego przed chwilą. Ocena Core Web Vitals może natomiast wynikać z dużej liczby rzeczywistych wizyt z wcześniejszego okresu. Możliwa jest więc sytuacja, w której właśnie zoptymalizowałem stronę. Lighthouse od razu pokazuje poprawę. Dane rzeczywistych użytkowników nadal zawierają jednak wizyty sprzed optymalizacji. Jest również możliwa sytuacja odwrotna. Pojedynczy test laboratoryjny może wypaść gorzej przez chwilowe warunki, mimo że większość prawdziwych użytkowników regularnie otrzymuje dobry wynik. Dlatego nie zestawiam tych dwóch wartości tak, jakby mierzyły dokładnie to samo.

Co to są Core Web Vitals w PageSpeed Insights?

Core Web Vitals to zestaw trzech podstawowych wskaźników opisujących wybrane elementy doświadczenia użytkownika. Obecnie są to:

• LCP, czyli Largest Contentful Paint,
• INP, czyli Interaction to Next Paint,
• CLS, czyli Cumulative Layout Shift.

Każdy mierzy inny problem. LCP dotyczy ładowania głównej treści. INP dotyczy szybkości reakcji strony. CLS dotyczy stabilności układu. Strona może mieć doskonały LCP i jednocześnie bardzo słaby INP. Może również szybko reagować na kliknięcia, ale podczas ładowania przesuwać elementy po całym ekranie. Dlatego Core Web Vitals zawsze analizuję jako zestaw.

Co oznacza LCP?

Largest Contentful Paint mierzy czas, po którym użytkownik widzi największy istotny element treści znajdujący się w początkowym obszarze strony. Często będzie nim:

• duże zdjęcie hero,
• baner,
• grafika produktu,
• zdjęcie wyróżniające,
• duży blok tekstu.

Dobry LCP powinien wynosić maksymalnie około 2,5 sekundy. Jeżeli główny baner pojawia się dopiero po pięciu sekundach, użytkownik przez znaczną część czasu patrzy na stronę, która wygląda na niedokończoną. Przyczyną nie musi być sam obraz. Problem może leżeć w:

• wolnej odpowiedzi serwera,
• zbyt dużym pliku graficznym,
• błędnym priorytecie ładowania,
• blokującym CSS,
• JavaScripcie,
• zewnętrznym foncie,
• źle wdrożonym lazy loadingu,
• łańcuchu kolejnych żądań.

PageSpeed może wskazać element LCP, ale nadal trzeba ustalić, dlaczego pojawia się zbyt późno.

Co oznacza INP?

Interaction to Next Paint mierzy responsywność interfejsu. Użytkownik wykonuje działanie, na przykład klika przycisk, otwiera menu albo wybiera wariant produktu. Strona powinna szybko pokazać efekt tej interakcji. Dobry INP wynosi do około 200 milisekund. Problem pojawia się wtedy, gdy przeglądarka jest zajęta wykonywaniem innych zadań i nie może szybko obsłużyć kliknięcia. Częstą przyczyną jest zbyt dużo JavaScriptu. W rozbudowanych stronach i sklepach mogą jednocześnie działać:

• slider,
• popup,
• chat,
• analityka,
• remarketing,
• mapa,
• filtry,
• wyszukiwarka,
• animacje,
• system zgód,
• zewnętrzne widgety.

Każdy element może być uzasadniony osobno. Problem pojawia się, gdy wszystkie próbują wykonywać pracę jednocześnie.

Co oznacza CLS?

Cumulative Layout Shift mierzy nieoczekiwane przesunięcia elementów strony. Klasyczny przykład: użytkownik chce kliknąć produkt, ale w tym momencie ładuje się baner znajdujący się wyżej. Cała zawartość przesuwa się w dół i użytkownik trafia w inny element. Dobry CLS powinien wynosić maksymalnie około 0,1. Problemy często wynikają z:

• obrazów bez zarezerwowanych wymiarów,
• ładowanych później reklam,
• banerów cookies,
• fontów zmieniających rozmiar tekstu,
• pasków promocyjnych,
• dynamicznych formularzy,
• elementów dołączanych przez JavaScript.

CLS bardzo dobrze pokazuje, że szybkość strony nie oznacza wyłącznie liczby sekund. Strona może załadować się szybko, ale nadal być irytująca w użyciu.

Co to jest FCP?

First Contentful Paint mierzy moment pojawienia się pierwszej treści na ekranie. Może to być tekst, obraz, SVG albo inny widoczny element. FCP pomaga ocenić, jak długo użytkownik patrzy na pustą stronę. Nie należy jednak mylić go z LCP. FCP pyta mniej więcej: kiedy pojawiło się cokolwiek? LCP pyta: kiedy pojawiła się główna treść? Strona może bardzo szybko wyświetlić logo, osiągając dobry FCP, a później przez kilka sekund ładować właściwe hero. Dlatego jeden wskaźnik nie wystarcza do opisania całego procesu.

Co to jest TBT?

Total Blocking Time pokazuje, jak długo główny wątek przeglądarki był blokowany przez długie zadania podczas laboratoryjnego testu. To bardzo przydatna metryka podczas diagnozowania JavaScriptu. Jeżeli przeglądarka przez długi czas wykonuje skrypty, użytkownik może widzieć stronę, ale interfejs nie reaguje prawidłowo. Kliknięcie menu pozornie nic nie robi. Przycisk reaguje z opóźnieniem. Animacja zaczyna się zacinać. TBT jest metryką laboratoryjną i nie jest jednym z trzech Core Web Vitals, ale potrafi pomóc znaleźć przyczyny problemów z responsywnością.

Co to jest Speed Index?

Speed Index próbuje opisać, jak szybko wizualna zawartość strony pojawia się podczas ładowania. Nie chodzi więc wyłącznie o jeden element. Narzędzie obserwuje, jak kolejne części widoku są renderowane w czasie. Dwie strony mogą zakończyć ładowanie w podobnym momencie, ale jedna będzie stopniowo pokazywać treść od początku, a druga przez kilka sekund pozostanie prawie pusta i dopiero później wyświetli większość elementów. Dla użytkownika te doświadczenia są zupełnie inne.

Dlaczego wyniki PageSpeed zmieniają się pomiędzy testami?

To normalne. Test nie odbywa się w próżni. Na wynik mogą wpływać między innymi:

• czas odpowiedzi serwera,
• aktualne obciążenie hostingu,
• cache,
• zewnętrzne API,
• czas odpowiedzi usług trzecich,
• kolejność wykonywania skryptów,
• dynamiczne treści,
• banery,
• reklamy,
• chwilowe różnice w środowisku testowym.

Dlatego nie podejmuję decyzji na podstawie jednego uruchomienia. Jeżeli wynik wynosi kolejno 92, 89, 94, 90 i 93, nie mam problemu polegającego na tym, że strona „straciła trzy punkty”. Patrzę na powtarzający się wzorzec. Jeżeli natomiast większość testów pokazuje LCP około dwóch sekund, a jeden nagle pokazuje osiem sekund, sprawdzam, co wydarzyło się podczas tego konkretnego uruchomienia.

PageSpeed na telefonie i komputerze

Wyniki mobile i desktop potrafią znacząco się różnić. To również jest normalne. Telefon może posiadać:

• słabszy procesor,
• wolniejsze połączenie,
• mniej pamięci,
• inne wymiary ekranu,
• inne obrazy,
• inne elementy interfejsu.

Strona, która na nowoczesnym komputerze działa perfekcyjnie, może mieć problemy na przeciętnym telefonie. Właśnie dlatego nie testuję wyłącznie desktopu. Jeżeli większość klientów sklepu korzysta z telefonu, wynik mobilny jest zwykle znacznie ważniejszy biznesowo. Sama responsywność układu również nie wystarczy, jeśli mobilna wersja pozostaje ciężka i powolna.

Dlaczego mobilny PageSpeed jest zwykle niższy?

Test mobilny celowo stawia stronie trudniejsze warunki niż typowy szybki komputer podłączony do światłowodu. Chodzi o ujawnienie problemów, które na wydajnym sprzęcie są łatwe do przeoczenia. Ciężki JavaScript może być prawie niewidoczny na mocnym procesorze. Na słabszym telefonie dokładnie ten sam kod zaczyna blokować interakcję. Zdjęcie ważące kilka megabajtów może pobrać się szybko na szybkim łączu. W sieci komórkowej różnica staje się bardzo wyraźna. Dlatego słabszy wynik mobilny nie oznacza, że PageSpeed „czepia się telefonu”. Pokazuje raczej, jak bardzo projekt polega na zasobach urządzenia użytkownika.

Co oznaczają Opportunities i Diagnostics?

PageSpeed Insights pokazuje szereg sugestii i elementów diagnostycznych. Mogą dotyczyć między innymi:

• nieużywanego JavaScriptu,
• nieużywanego CSS,
• rozmiaru obrazów,
• formatów grafik,
• blokowania renderowania,
• czasu odpowiedzi serwera,
• dużych zasobów sieciowych,
• długich zadań JavaScript,
• łańcuchów żądań,
• cache przeglądarki.

To bardzo wartościowe informacje. Nie są jednak listą poleceń. Nie wykonuję mechanicznie każdej sugestii tylko dlatego, że PageSpeed pokazał ją na czerwono.

Czy trzeba poprawić każdy komunikat PageSpeed?

Nie. To jedna z najważniejszych zasad pracy z tym narzędziem. Każda optymalizacja ma koszt. Może wymagać:

• czasu programisty,
• zmiany architektury,
• przebudowy funkcji,
• usunięcia narzędzia zewnętrznego,
• zmiany sposobu ładowania zasobów,
• dodatkowych testów.

Jeżeli wdrożenie skomplikowanej zmiany zajmie dwa dni i poprawi wynik z 97 do 98 bez mierzalnej różnicy dla użytkownika, może nie być najlepszym wykorzystaniem czasu. Jeżeli natomiast jedna poprawka skraca LCP z sześciu do dwóch sekund, sytuacja wygląda zupełnie inaczej. PageSpeed pomaga znaleźć kandydatów do optymalizacji. Priorytet nadal trzeba ustalić samodzielnie.

Co oznacza „Reduce unused JavaScript”?

Narzędzie zauważyło, że pobierana jest część kodu JavaScript, która nie była potrzebna podczas analizowanego fragmentu wizyty. W WordPressie jest to bardzo częste. Motyw albo wtyczka może ładować swój skrypt na każdej podstronie, mimo że konkretna funkcja występuje tylko w jednym miejscu. Przykładowo biblioteka slidera może zostać pobrana również na stronie, na której nie istnieje żaden slider. Rozbudowana wtyczka formularzy może ładować kod na stronach bez formularza. Nie oznacza to jednak, że wystarczy znaleźć plik na liście i go usunąć. Najpierw trzeba sprawdzić zależności. Kod pozornie niewykorzystywany podczas testu może być potrzebny po późniejszej interakcji użytkownika.

Co oznacza „Eliminate render-blocking resources”?

Przeglądarka natrafiła na zasoby, które musi pobrać lub przetworzyć, zanim będzie mogła kontynuować renderowanie ważnej części strony. Najczęściej dotyczy to CSS i JavaScriptu. Optymalizacja może obejmować:

• zmianę kolejności ładowania,
• wydzielenie krytycznych stylów,
• opóźnienie części skryptów,
• usunięcie niepotrzebnych zależności.

Trzeba jednak robić to ostrożnie. Agresywne opóźnienie JavaScriptu potrafi poprawić liczbę w PageSpeed, a jednocześnie zepsuć menu, formularz, filtr produktów albo koszyk. To klasyczny przypadek optymalizacji testu kosztem strony.

Co oznacza problem z obrazami?

Obrazy są jedną z najczęstszych przyczyn ciężkiego frontendu. PageSpeed może zasugerować:

• zmniejszenie wymiarów,
• lepszą kompresję,
• użycie nowocześniejszego formatu,
• lazy loading,
• prawidłowe dopasowanie obrazu do ekranu.

Jeżeli użytkownik ogląda zdjęcie o szerokości 600 pikseli, nie zawsze ma sens wysyłanie mu pliku o szerokości 5000 pikseli. Jednocześnie nie ściskam każdego obrazu tak mocno, aby wyglądał źle. W sklepie internetowym jakość zdjęcia produktu jest częścią sprzedaży. Optymalizacja musi zachować balans pomiędzy wagą a jakością.

Czy lazy loading zawsze poprawia PageSpeed?

Nie. Lazy loading oznacza opóźnione pobieranie zasobu do momentu, gdy jest potrzebny. Działa świetnie w przypadku zdjęć znajdujących się daleko poniżej pierwszego ekranu. Może jednak zaszkodzić, jeśli zostanie zastosowany do najważniejszego obrazu widocznego od razu. Jeżeli główne zdjęcie hero jest elementem LCP, opóźnianie jego pobierania może spowodować dokładnie odwrotny efekt. Dlatego nie włączam lazy loadingu bezmyślnie dla wszystkich obrazów.

PageSpeed a cache

Cache może znacząco poprawić wydajność strony. Nie jest jednak uniwersalnym rozwiązaniem wszystkich problemów. Jeżeli serwer generuje tę samą publiczną stronę przy każdej wizycie, cache może ograniczyć ilość wykonywanej pracy i skrócić czas odpowiedzi. Nie naprawi natomiast automatycznie:

• ciężkich obrazów,
• dużej ilości JavaScriptu w przeglądarce,
• niestabilnego układu,
• źle przygotowanych fontów,
• błędów interfejsu.

Można więc mieć świetnie skonfigurowany cache i nadal uzyskiwać słaby PageSpeed.

PageSpeed a hosting

Hosting wpływa przede wszystkim na część pracy wykonywaną po stronie serwera. Jeżeli serwer długo przygotowuje odpowiedź, użytkownik zaczyna cały proces z opóźnieniem. Dobry hosting może pomóc, ale również tutaj nie działa magia. Przeniesienie strony na znacznie szybszy serwer nie naprawi automatycznie frontendu zawierającego kilka megabajtów JavaScriptu i ogromne zdjęcia. Podobnie perfekcyjnie zoptymalizowany frontend może nadal czekać na bardzo wolną aplikację po stronie serwera. Wydajność jest wynikiem całego łańcucha.

PageSpeed a CDN

CDN może dostarczać wybrane zasoby z infrastruktury położonej bliżej użytkownika i ograniczać obciążenie serwera źródłowego. Może to poprawić czasy ładowania szczególnie wtedy, gdy użytkownicy znajdują się w różnych lokalizacjach. Nie oznacza to jednak, że samo podłączenie CDN automatycznie daje 100 punktów. Jeżeli przesyłam użytkownikowi zbyt duży plik, CDN może dostarczyć go sprawniej, ale plik nadal pozostaje zbyt duży. Najpierw trzeba zrozumieć problem. Później dobiera się rozwiązanie.

PageSpeed a WordPress

WordPress sam w sobie nie ma jednego stałego wyniku PageSpeed. Można zbudować na nim bardzo szybką stronę. Można również stworzyć niezwykle ciężki serwis. Na końcową wydajność wpływają między innymi:

• motyw,
• wtyczki,
• hosting,
• liczba zapytań,
• sposób budowania szablonów,
• obrazy,
• zewnętrzne skrypty,
• cache,
• jakość własnego kodu.

Dlatego pytanie „jaki PageSpeed ma WordPress?” nie ma większego sensu. Trzeba przetestować konkretną stronę.

Czy duża liczba wtyczek obniża PageSpeed?

Nie automatycznie. Tak samo jak opisuję to szerzej przy wtyczkach WordPress, ważniejsza od samej liczby dodatków jest ich jakość i sposób działania. Jedna ciężka wtyczka może dokładać więcej zasobów niż dziesięć prostych. Problemem są dodatki, które:

• ładują zasoby wszędzie,
• wykonują kosztowne operacje,
• generują wiele zapytań,
• dodają duże biblioteki,
• powielają funkcje innych narzędzi.

Liczenie wtyczek jest znacznie prostsze niż ich analiza. Nie znaczy, że jest bardziej użyteczne.

PageSpeed a Elementor

Elementor pozwala szybko budować rozbudowane layouty, ale sposób użycia ma duży wpływ na ilość generowanego frontendu. Problemem mogą być nadmiernie złożone struktury, duża liczba widgetów, dodatki do Elementora i funkcje ładowane globalnie. Nie oznacza to, że każdą stronę z Elementorem trzeba przepisać od zera. Najpierw sprawdzam, co faktycznie odpowiada za słaby wynik. Czasami problemem jest jeden obraz hero. Czasami zewnętrzny chat. Czasami motyw. Czasami kilkanaście dodatków ładowanych jednocześnie. A czasami ograniczeniem staje się sama architektura projektu.

PageSpeed w WooCommerce

WooCommerce jest trudniejszym środowiskiem niż prosta strona informacyjna. Sklep musi obsługiwać między innymi:

• produkty,
• warianty,
• ceny,
• stany magazynowe,
• sesję klienta,
• koszyk,
• checkout,
• płatności,
• dostawy,
• analitykę.

Do tego dochodzą filtry, rekomendacje, popupy, systemy opinii, czaty, marketing i integracje. Nie traktuję więc sklepu tak samo jak statycznej wizytówki. Właśnie dlatego przy budowie sklepu internetowego wydajność trzeba projektować razem z funkcjonalnością, a nie próbować ratować ją dopiero po uruchomieniu całego systemu.

Czy PageSpeed wpływa na SEO?

Szybkość i doświadczenie użytkownika są częścią jakości technicznej strony, ale nie istnieje prosty wzór: 100 PageSpeed = pierwsze miejsce w Google. Tak to nie działa. Strona musi również posiadać:

• wartościową treść,
• prawidłową strukturę,
• odpowiednie linkowanie,
• poprawną indeksację,
• dopasowanie do intencji użytkownika.

Dlatego PageSpeed traktuję jako element szerszego SEO technicznego, a nie samodzielną strategię pozycjonowania. Szybka strona może wspierać doświadczenie użytkownika. Nie zastępuje jednak dobrego SEO.

Czy wynik PageSpeed wpływa na sprzedaż?

Nie bezpośrednio w taki sposób, że poprawa z 84 do 94 punktów automatycznie zwiększy sprzedaż o określony procent. Znacznie ważniejsze są konkretne doświadczenia użytkownika. Jeżeli klient:

• czeka kilka sekund na produkt,
• nie może szybko otworzyć menu,
• klika przycisk, który nie reaguje,
• trafia w zły element przez przesunięcie layoutu,
• rezygnuje przed załadowaniem checkoutu,

wydajność zaczyna mieć bardzo realne znaczenie biznesowe. Właśnie dlatego nie optymalizuję liczby. Optymalizuję problem stojący za liczbą.

Dlaczego strona może być wolna mimo dobrego PageSpeed?

PageSpeed bada określony adres i określone scenariusze. Nie wykonuje całej ścieżki użytkownika. Może nie zauważyć problemu pojawiającego się:

• po zalogowaniu,
• po zastosowaniu filtra,
• po dodaniu produktu do koszyka,
• po otwarciu popupu,
• po załadowaniu danych z API,
• podczas wyszukiwania,
• przy dużym obciążeniu serwera.

Dlatego PageSpeed nie zastępuje testów funkcjonalnych, monitoringu ani audytu technicznego strony. Jest jednym z elementów diagnostyki.

Dlaczego strona może wyglądać na szybką mimo słabego wyniku?

Może się tak zdarzyć, szczególnie podczas testowania na własnym komputerze. Administrator często posiada:

• bardzo szybkie łącze,
• wydajny komputer,
• nowoczesną przeglądarkę,
• pliki zapisane już w cache.

Może również znajdować się geograficznie blisko serwera. Jego doświadczenie nie musi być reprezentatywne. Dlatego zdanie „u mnie strona działa szybko” nie jest pomiarem wydajności. Jest obserwacją jednego użytkownika.

Jak prawidłowo testować stronę w PageSpeed?

Najpierw wybieram reprezentatywne podstrony. Nie tylko homepage. W serwisie firmowym mogą to być:

• strona główna,
• oferta,
• ważny landing page,
• artykuł.

W sklepie:

• strona główna,
• kategoria,
• produkt,
• koszyk,
• checkout.

Następnie wykonuję kilka testów. Porównuję mobile i desktop. Sprawdzam field data. Patrzę na Lighthouse. Identyfikuję najgorsze metryki. Dopiero potem zaglądam do szczegółowych sugestii. Taka kolejność ogranicza ryzyko spędzenia kilku godzin nad alertem, który praktycznie nie wpływa na rzeczywiste doświadczenie użytkownika.

Jak poprawiać PageSpeed krok po kroku?

Nie włączam dwudziestu optymalizacji jednocześnie. Jeżeli po zmianie coś się zepsuje, nie będę wiedział, która modyfikacja była przyczyną. Zaczynam od największego problemu. Jeżeli LCP jest słaby, analizuję element LCP. Jeżeli TBT jest ogromny, sprawdzam JavaScript. Jeżeli CLS jest słaby, szukam przesuwających się elementów. Jeżeli serwer odpowiada wolno, zaczynam od backendu, hostingu i cache. Po każdej większej zmianie wykonuję kolejny test. Porównuję wyniki. Sprawdzam również działanie samej strony. Optymalizacja bez testów funkcjonalnych jest proszeniem się o problemy.

Najczęstsze błędy podczas optymalizacji PageSpeed

Polowanie na 100 punktów

Projekt osiąga już bardzo dobrą wydajność, ale kolejne godziny są poświęcane na zdobycie ostatnich dwóch punktów. Koszt pracy zaczyna być większy niż potencjalna korzyść.

Testowanie tylko strony głównej

Homepage otrzymuje 98 punktów, więc cały serwis zostaje uznany za szybki. Nikt nie sprawdza kategorii, produktów ani checkoutu.

Włączanie wszystkich funkcji wtyczki optymalizacyjnej

Minifikacja, opóźnianie, łączenie, lazy loading i usuwanie CSS są uruchamiane jednocześnie. PageSpeed rośnie. Menu przestaje działać.

Usuwanie potrzebnych funkcji dla punktów

Wyłączenie narzędzia poprawia wynik, więc funkcja jest kasowana bez sprawdzenia jej znaczenia biznesowego. Szybsza strona, która gorzej sprzedaje, nie jest sukcesem optymalizacyjnym.

Ignorowanie danych rzeczywistych

Właściciel widzi zielone 98 w Lighthouse i przestaje analizować Core Web Vitals. Tymczasem prawdziwi użytkownicy nadal mają problemy.

Ignorowanie mobile

Desktop wygląda idealnie, więc temat zostaje zamknięty. Większość klientów korzysta jednak z telefonu.

Zmiana wielu rzeczy jednocześnie

Po optymalizacji wynik wzrósł, ale nie wiadomo dlaczego. Albo wynik spadł i również nie wiadomo dlaczego. Dobra diagnostyka wymaga kontrolowania zmian.

PageSpeed nie zastępuje audytu wydajności

Raport PageSpeed jest świetnym punktem startowym. Nie widzi jednak całego systemu. W prawdziwym audycie technicznym mogę dodatkowo sprawdzić:

• sieć żądań w przeglądarce,
• kod JavaScript,
• zapytania do bazy danych,
• PHP,
• logi serwera,
• konfigurację cache,
• CDN,
• działanie API,
• obciążenie hostingu,
• wtyczki,
• konflikty,
• zachowanie dynamicznych funkcji.

Dwa serwisy mogą mieć podobny wynik PageSpeed i wymagać zupełnie różnych napraw. Dlatego sam screenshot z wynikiem rzadko wystarcza do sensownej diagnozy.

PageSpeed a strony statyczne

Architektura strony ma duże znaczenie dla jej wydajności. W serwisie statycznym gotowy HTML może być przygotowany wcześniej i dostarczony użytkownikowi bez generowania całej strony przy każdej wizycie. Eliminuje to część pracy wykonywanej przez dynamiczny backend. Nie oznacza jednak, że każda strona statyczna automatycznie jest szybka. Nadal można dodać:

• ogromne obrazy,
• ciężkie animacje,
• duże biblioteki JavaScript,
• zewnętrzne widgety,
• źle ładowane fonty.

Lekka architektura daje dobry fundament. Nie zwalnia z myślenia o frontendzie. Właśnie z tego powodu strony statyczne traktuję jako jedno z rozwiązań architektonicznych, a nie magiczny sposób na zielony PageSpeed.

Co jest ważniejsze: PageSpeed czy doświadczenie użytkownika?

Doświadczenie użytkownika. PageSpeed jest jednym ze sposobów jego pomiaru. Jeżeli narzędzie wskazuje problem, który użytkownicy realnie odczuwają, warto go naprawić. Jeżeli jedynym efektem bardzo kosztownej zmiany będzie podniesienie wyniku z 99 do 100, nie widzę powodu, aby traktować ją jako priorytet. Technologia ma służyć człowiekowi korzystającemu ze strony. Nie odwrotnie.

Jak podchodzę do PageSpeed Insights w praktyce?

Nie zaczynam od pytania: „Jak zrobić 100?” Zaczynam od: „Dlaczego ta strona działa tak, jak działa?” Patrzę na dane rzeczywistych użytkowników. Sprawdzam Lighthouse. Porównuję mobile i desktop. Analizuję LCP, INP i CLS. Sprawdzam zasoby sieciowe, kod, obrazy, serwer, cache i architekturę. Dopiero wtedy ustalam kolejność poprawek. Czasami wystarczy zoptymalizować jeden obraz. Czasami trzeba zmienić sposób ładowania JavaScriptu. Czasami problemem jest hosting. A czasami PageSpeed tylko ujawnia większy problem: strona przez lata była rozbudowywana bez kontroli i każda kolejna funkcja dokładała nową warstwę kodu. Wtedy nie próbuję na siłę doprowadzić starej konstrukcji do 100 punktów za pomocą kolejnych sztuczek optymalizacyjnych. Sprawdzam, czy bardziej opłaca się naprawiać objawy, czy przebudować fundament. Przy projektowaniu stron internetowych wydajność traktuję od początku jako część architektury, a nie zadanie do wykonania dzień przed publikacją. PageSpeed Insights jest wtedy bardzo dobrym narzędziem kontrolnym. Pokazuje, gdzie warto zajrzeć. Nie podejmuje jednak decyzji za mnie.