PageSpeed 97/100, a Core Web Vitals niezdane. Jak zielony wynik może ukrywać wolną stronę

97 punktów na 100 za wydajność. Zielone kółko. SEO 100. CLS idealne. Na pierwszy rzut oka wszystko wygląda świetnie. Problem w tym, że prawdziwi użytkownicy tej samej strony czekają ponad cztery sekundy na pojawienie się głównej treści, a Google oznacza Core Web Vitals jako niezdane. Jak oba te wyniki mogą być prawdziwe jednocześnie?

To nie jest hipotetyczny przykład wymyślony na potrzeby artykułu. To rzeczywista strona na WordPressie, zbudowana na OceanWP i Elementorze, sprzedana jako indywidualny projekt za około 400 euro. I właśnie na niej bardzo dobrze widać, dlaczego zielony wynik w PageSpeed Insights nie jest jeszcze dowodem na to, że strona faktycznie działa szybko. Dlatego dziś postaram Ci się wytłumaczyć o co w tym chodzi.

97 punktów. Czyli szybko?

Niekoniecznie. A właściwie na podstawie samego wyniku 97 nie da się tego uczciwie stwierdzić. PageSpeed Insights pokazuje bowiem obok siebie dwa zupełnie różne rodzaje danych. Jedne pochodzą z testu laboratoryjnego Lighthouse wykonywanego w konkretnym momencie i w określonych warunkach. To właśnie z niego pochodzi efektowne zielone kółko z wynikiem 97/100.

Drugie dane pochodzą od rzeczywistych użytkowników Chrome (CRUX) i obejmują poprzednie 28 dni. W tym przypadku opowiadają one zupełnie inną historię. Largest Contentful Paint, czyli czas potrzebny na pojawienie się największego elementu widocznego na ekranie, wynosi 4,4 sekundy. First Contentful Paint to 4 sekundy, a Time to First Byte aż 3,9 sekundy. Jednocześnie INP wynosi bardzo dobre 97 ms, a CLS jest równy 0.

Core Web Vitals przechodzą dopiero wtedy, gdy wszystkie trzy podstawowe wskaźniki mieszczą się w dobrym zakresie na 75. percentylu pomiarów. Tutaj INP i CLS są dobre, ale LCP przekracza 4 sekundy, czyli znajduje się już w zakresie uznawanym przez Google za słaby. I właśnie ten zestaw mówi znacznie więcej niż samo zielone 97.

Ważna uwaga – strona z małym i nieregularnym ruchem może nie mieć dostępnych danych z CRUX. Ale to nie znaczy, że problem jej nie dotyczy.

Przez prawie cztery sekundy przeglądarka czeka

Najbardziej interesującą liczbą na tym ekranie nie jest nawet LCP. Jest nią TTFB wynoszące 3,9 sekundy. Time to First Byte mówi w dużym uproszczeniu, jak długo przeglądarka czeka od wysłania żądania do momentu, w którym serwer zaczyna przesyłać odpowiedź.

Jeżeli pierwszy fragment treści pojawia się po około czterech sekundach, a odpowiedź zaczyna docierać dopiero po około 3,9 sekundy, to nie mamy sytuacji, w której przeglądarka przez cztery sekundy mozolnie układa sekcje Elementora, zdjęcia i przyciski. Przez większość tego czasu po prostu czeka, aż cokolwiek dostanie. Dopiero później zaczyna faktycznie renderować stronę.

To ważna różnica, bo bardzo łatwo zobaczyć wolnego WordPressa z Elementorem i od razu stwierdzić: “No tak, page builder”. Tylko że liczby z tego konkretnego przypadku nie wskazują na frontend jako główne źródło opóźnienia. Wręcz przeciwnie. Gdy odpowiedź wreszcie zaczyna docierać, pierwsza treść pojawia się niemal natychmiast, a do LCP potrzeba już tylko około pół sekundy.

To wina hostingu? Wcale nie musi

Wysoki TTFB często kończy się bardzo prostą diagnozą: słaby hosting. Czasami rzeczywiście tak jest, ale w WordPressie to tylko jedna z wielu możliwych przyczyn. Zanim serwer zacznie wysyłać gotowy HTML do przeglądarki, WordPress może mieć do wykonania bardzo dużo pracy.

Uruchamiane jest PHP, ładowany jest WordPress, motyw i aktywne wtyczki, wykonywane są zapytania do bazy danych, pobierane są opcje i budowana jest zawartość strony. Niektóre wtyczki wykonują również połączenia do zewnętrznych usług. Jeżeli jeden z tych elementów działa źle, odpowiedź może zostać zatrzymana na kilka sekund, mimo że sam serwer jako maszyna nie jest szczególnie wolny.

Bardzo realnym winowajcą może być na przykład baza danych. Jeśli jest zapchana, zawiera ogromną ilość automatycznie ładowanych danych albo któraś wtyczka wykonuje ciężkie zapytania przy każdym wejściu, WordPress może długo czekać na dane potrzebne do zbudowania strony. Efekt dla użytkownika będzie dokładnie taki sam: kliknięcie, cisza, cisza, cisza i dopiero po kilku sekundach pojawia się strona.

Podobny efekt może dać nieskuteczny cache, regularne cache missy, przeciążony worker PHP, źle napisana wtyczka albo zewnętrzne API, na którego odpowiedź WordPress czeka przed wyrenderowaniem dokumentu. Hosting jest więc jednym z podejrzanych, ale na podstawie samego TTFB nie można go jeszcze skazać.

Skoro jest tak źle, skąd 97 punktów?

I tutaj ten przypadek robi się naprawdę interesujący. Pojedynczy test Lighthouse może trafić na warunki zupełnie inne niż przeciętny użytkownik. Test może dostać gotową stronę z cache, podczas gdy część rzeczywistych odwiedzających trafia na “surową” stronę. CDN może mieć już potrzebne zasoby w pamięci, serwer może akurat nie być obciążony, a strona mogła zostać wygenerowana chwilę wcześniej. Wszystko to są normalne powody, dla których jeden pomiar laboratoryjny może wyglądać znacznie lepiej od danych terenowych.

Jest jednak jeszcze jedna możliwość, o której warto mówić, szczególnie przy usługach sprzedawanych jako “optymalizacja PageSpeed”. Na rynku istnieje cała grupa rozwiązań, których głównym celem nie zawsze jest poprawa rzeczywistej szybkości strony. Ich celem bywa przede wszystkim podniesienie wyniku testu.

Można agresywnie opóźnić JavaScript, przesunąć ładowanie części CSS, odroczyć skrypty, zablokować elementy niepotrzebne na początku renderowania albo w określonych warunkach dostarczać stronę w inny sposób. Część takich optymalizacji jest oczywiście całkowicie prawidłowa i rzeczywiście pomaga użytkownikowi. Problem zaczyna się wtedy, gdy cały wysiłek skupia się na tym, żeby bot Lighthouse zobaczył jak najmniej, jak najpóźniej i jak najszybciej przyznał zielone kółko. To trochę jak naklejenie sportowej naklejki na na samochód – nie spowoduje nagle, że ze 150km zrobi się 300.

W ekstremalnych przypadkach rozwiązania optymalizacyjne mogą nawet próbować rozpoznawać narzędzia testujące i zachowywać się wobec nich inaczej. Rozbieżność jest jednak na tyle duża, że warto zadać pytanie: czy zoptymalizowano stronę, czy przede wszystkim wynik PageSpeed?

Drugi wykres robi się jeszcze ciekawszy

Gdybyśmy mieli tylko jeden test, można byłoby założyć, że złapaliśmy stronę w wyjątkowo dobrym albo wyjątkowo złym momencie. Drugi screenshot pokazuje jednak zachowanie Core Web Vitals na urządzeniach mobilnych w dłuższym okresie.

Stabilność wizualna pozostaje dobra. Interaktywność również wypada dobrze, chociaż wykres pokazuje pewne pogorszenie. Natomiast loading performance przez długi czas utrzymuje się w czerwonym obszarze. To już nie wygląda jak pojedynczy pechowy pomiar wykonany wtedy, gdy serwer miał gorszy dzień.

Co więcej, taki profil jest dość charakterystyczny. Strona nie skacze podczas ładowania. Po załadowaniu dobrze reaguje na działania użytkownika. Problemem jest przede wszystkim to, jak długo trzeba czekać, zanim faktycznie zacznie się pojawiać. To zupełnie inna sytuacja niż strona, która jest ciężka pod każdym względem i jednocześnie ma fatalny JavaScript, przesuwający się layout, ciężkie obrazy i opóźnione interakcje. Tutaj mamy znacznie bardziej konkretne miejsce do szukania problemu.

“PageSpeed 90+” nie jest celem biznesowym

I właśnie dlatego obietnica “zrobię Ci 90+ w PageSpeed” zawsze powinna zapalać małą lampkę ostrzegawczą. Dobry wynik Lighthouse jest oczywiście czymś pozytywnym. Sama chcę go widzieć po dobrze wykonanej optymalizacji. Problem pojawia się wtedy, kiedy liczba zaczyna być traktowana jak cel sam w sobie.

Klient nie zarabia pieniędzy dlatego, że Lighthouse przyznał stronie 97 punktów. Na stronę przychodzi człowiek, często na zwykłym telefonie i przez mobilne połączenie. Jeżeli po kliknięciu przez cztery sekundy niewiele się dzieje, użytkownika nie interesuje screenshot zielonego kółka wysłany przez wykonawcę podczas odbioru projektu.

Dlatego pytanie “ile masz w PageSpeed?” jest dużo mniej interesujące niż pytanie “jak strona działa u prawdziwych użytkowników?”. PageSpeed Insights dostarcza danych do odpowiedzi na oba pytania. Trzeba tylko patrzeć trochę dalej niż na największą zieloną liczbę na ekranie.

Elementor tym razem nie dostaje całej winy

Ten przykład dobrze pokazuje też problem z automatycznym obwinianiem technologii. Elementor potrafi wygenerować ciężką stronę. Można z jego pomocą zrobić projekt przeładowany JavaScriptem, wielkimi obrazami i niepotrzebnymi widgetami. To samo dotyczy praktycznie każdego dużego page buildera.

Tyle że dane z tego przypadku nie pozwalają uczciwie powiedzieć, że LCP 4,4 sekundy wynika po prostu z użycia Elementora. INP jest bardzo dobre, CLS wynosi zero, a po otrzymaniu odpowiedzi z serwera zawartość pojawia się stosunkowo szybko. Największe opóźnienie występuje wcześniej.

Można więc wyrzucić Elementora, zbudować wszystko od nowa i nadal mieć wolną stronę, jeżeli prawdziwym problemem jest baza danych, PHP, brak cache albo jedna źle zachowująca się wtyczka. Najpierw trzeba ustalić, co faktycznie trwa te kilka sekund. Dopiero później można sensownie zdecydować, co naprawiać.

Jak sprawdzić, co naprawdę się dzieje?

Pierwszym krokiem jest rozdzielenie danych laboratoryjnych od danych terenowych i sprawdzenie, czy pokazują podobny obraz. Jeśli Lighthouse regularnie daje świetne wyniki, a prawdziwi użytkownicy mają bardzo słaby TTFB, warto zacząć od backendu WordPressa, cache i bazy danych, zamiast bez końca zmniejszać kolejne pliki CSS.

Przy takiej stronie należałoby sprawdzić czas generowania dokumentu HTML, działanie page cache, zapytania do bazy, wielkość danych ładowanych automatycznie z wp_options, czas pracy PHP oraz zachowanie aktywnych wtyczek. Warto również zobaczyć, czy WordPress nie wykonuje podczas ładowania strony zewnętrznych requestów, które blokują przygotowanie odpowiedzi.

Jeżeli nadal pozostaje duża różnica między zwykłym wejściem a wynikiem Lighthouse, można pójść dalej i porównać odpowiedzi serwera, HTML oraz zasoby ładowane w normalnej przeglądarce z tym, co otrzymuje narzędzie testujące. Dopiero takie porównanie pozwala sensownie ocenić, czy mamy do czynienia z normalnym efektem cache i warunków pomiaru, czy może z konfiguracją nastawioną przede wszystkim na osiągnięcie wyniku.

Zielone kółko jest miłe. Użytkownik jest ważniejszy

PageSpeed Insights nie kłamie. Problem zaczyna się wtedy, kiedy z całego raportu wybieramy jedną liczbę, największą i najbardziej zieloną, a potem pokazujemy ją jako dowód, że strona jest szybka.

W tym przykładzie mamy jednocześnie 97/100 w Lighthouse, niezdane Core Web Vitals, LCP na poziomie 4,4 sekundy oraz TTFB wynoszące 3,9 sekundy. Żaden z tych wyników nie musi być błędny. Po prostu mierzą coś innego i powstały na podstawie innych danych.

Dlatego dobry wynik PageSpeed powinien być skutkiem dobrze działającej strony, a nie celem optymalizacji. Jeżeli strona szybko odpowiada, sprawnie się renderuje, nie przesuwa treści i dobrze reaguje na działania użytkownika, zielone kółko jest przyjemnym potwierdzeniem wykonanej pracy. Jeżeli natomiast cała optymalizacja kończy się na zdobyciu zielonego kółka, można dostać dokładnie taki efekt jak tutaj: 97 punktów w teście i użytkownika, który nadal czeka na załadowanie strony.

Komentarz WebsiteGarage

97 wygląda świetnie na screenshocie i bardzo dobrze sprzedaje usługę “optymalizacji”. Tyle że użytkownik strony nie jest screenshotem. Jeśli przez cztery sekundy czeka, aż WordPress, baza danych, wtyczka albo serwer wreszcie zdecydują się odpowiedzieć, zielony wynik Lighthouse niewiele mu pomoże.

Dlatego przy optymalizacji nie interesuje mnie wyłącznie to, czy udało się zrobić zielone kółko. Interesuje mnie przede wszystkim, dlaczego strona potrzebuje tyle czasu i co dzieje się z nią wtedy, kiedy korzysta z niej prawdziwy człowiek.