Szybkość strony decyduje o klientach. Jak mieć PageSpeed 90+

Klient szuka w Google usługi, którą oferujesz. Klika w twoją stronę na telefonie, ekran jest biały, coś się kręci. Po trzech sekundach wraca do wyników i klika konkurencję. Nikt tego nie zapisał w żadnym raporcie — dla ciebie ta osoba nigdy nie istniała.

Tak wygląda koszt wolnej strony. Nie widać go w statystykach, bo mierzysz tylko tych, którzy doczekali załadowania. Ci, którzy uciekli wcześniej, po prostu znikają. A szybkość strony internetowej to nie kwestia gustu ani „wrażenia” — to mierzalna właściwość techniczna, którą Google sprawdza na każdej stronie i bierze pod uwagę w rankingu.

W tym artykule wyjaśniam, co dokładnie mierzy Google, dlaczego typowa strona firmowa te pomiary obleje, i co trzeba zmienić w architekturze, żeby wynik 90+ w PageSpeed był normą, a nie osiągnięciem.

Co mierzy Google: Core Web Vitals po ludzku

Google od lat zbiera dane o tym, jak strony zachowują się u prawdziwych użytkowników Chrome’a. Z tych danych powstał zestaw trzech metryk nazwany Core Web Vitals. Każda odpowiada na jedno konkretne pytanie, które zadaje sobie (nieświadomie) każdy odwiedzający.

LCP — jak szybko widać treść

LCP (Largest Contentful Paint) mierzy czas od kliknięcia w link do momentu, w którym na ekranie pojawi się największy element strony — zwykle zdjęcie w nagłówku albo główny blok tekstu. To odpowiedź na pytanie: „czy ta strona w ogóle działa?”.

Google uznaje wynik za dobry, gdy LCP wynosi maksymalnie 2,5 sekundy. Powyżej 4 sekund — źle. Na telefonie z przeciętnym internetem mobilnym większość stron firmowych w Polsce mieści się gdzieś pomiędzy, czyli w strefie „wymaga poprawy”.

INP — czy strona reaguje na dotyk

INP (Interaction to Next Paint) mierzy, ile czasu mija od twojego kliknięcia lub tapnięcia do widocznej reakcji strony. Rozwijasz menu — czy otwiera się od razu, czy po zauważalnej pauzie? W 2024 roku ta metryka zastąpiła starszą FID, bo lepiej oddaje frustrację użytkownika.

Dobry wynik to maksymalnie 200 milisekund. Brzmi jak drobiazg, ale opóźnienie rzędu pół sekundy człowiek wyraźnie czuje — strona sprawia wrażenie zaciętej. Głównym winowajcą jest tu prawie zawsze JavaScript: przeglądarka jest zajęta przetwarzaniem skryptów i nie ma kiedy odpowiedzieć na dotyk.

CLS — czy treść skacze po ekranie

CLS (Cumulative Layout Shift) mierzy stabilność układu. Znasz to: czytasz akapit, nagle doładowuje się baner i tekst zjeżdża w dół. Albo chcesz kliknąć przycisk, a w ostatniej chwili wskakuje nad niego zdjęcie i klikasz reklamę. Każde takie przesunięcie podnosi wynik CLS.

Dobra strona ma CLS poniżej 0,1 — czyli praktycznie nic się nie rusza po pierwszym wyświetleniu. Przyczyna skakania jest banalna: obrazki i osadzone elementy bez zadeklarowanych wymiarów. Przeglądarka nie wie, ile miejsca zarezerwować, więc przesuwa treść, gdy plik w końcu dotrze.

Te trzy metryki Google zbiera z realnego ruchu (raport CrUX) i ocenia każdy adres osobno. To nie jest teoretyczny test w laboratorium — to zapis tego, czego faktycznie doświadczyli twoi odwiedzający przez ostatnie 28 dni.

Co szybkość zmienia w biznesie

Dwie rzeczy: pozycje w Google i zachowanie ludzi, którzy już weszli.

Pozycje. Google oficjalnie potwierdziło, że page experience — z Core Web Vitals na czele — jest sygnałem rankingowym. Nie najważniejszym: dobra treść wygra z szybką pustką. Ale przy porównywalnej treści, a tak wygląda większość lokalnych rynków usługowych, szybsza strona ma przewagę. W konkurencyjnej frazie typu „księgowa Toruń” każdy sygnał się liczy, bo różnice między stronami z pierwszej dziesiątki są niewielkie.

Zachowanie użytkowników. Tu dane są jednoznaczne co do kierunku: im dłużej strona się ładuje, tym większy odsetek ludzi rezygnuje przed zobaczeniem czegokolwiek. Badania Google nad ruchem mobilnym pokazują, że prawdopodobieństwo porzucenia rośnie gwałtownie z każdą kolejną sekundą ładowania — a większość ruchu na stronach firmowych to dziś właśnie telefony, często na słabym łączu w terenie. Branżowe analizy konwersji potwierdzają ten sam kierunek: szybsze strony sprzedają lepiej, bo mniej osób odpada po drodze do formularza czy numeru telefonu.

Jest jeszcze trzeci efekt, trudniejszy do zmierzenia: wiarygodność. Strona, która ładuje się natychmiast i nie skacze, sprawia wrażenie zadbanej. Strona, która się dławi, podświadomie sugeruje, że firma podobnie traktuje resztę swoich obowiązków.

Dlaczego typowa strona firmowa jest wolna

Większość stron firmowych w Polsce stoi na WordPressie z page builderem (Elementor, Divi) albo na kreatorze typu Wix. To wygodne narzędzia do składania stron, ale ich architektura pracuje przeciwko szybkości — i to nie z powodu błędów, tylko z założenia.

Motyw uniwersalny musi obsłużyć tysiące różnych zastosowań, więc ładuje style i skrypty na wszystko, czego twoja strona nigdy nie użyje. Każda dodana wtyczka dorzuca własny CSS i JavaScript — zwykle na każdej podstronie, niezależnie od tego, czy jest tam potrzebna. Page builder generuje głęboko zagnieżdżony HTML i dowozi własny silnik renderujący w JavaScripcie. Do tego dochodzi serwer: przy każdym wejściu WordPress składa stronę na nowo z bazy danych, a współdzielony hosting robi to powoli.

Suma jest zawsze podobna: kilkaset kilobajtów JavaScriptu do pobrania i przetworzenia, style blokujące renderowanie, zdjęcia prosto z aparatu ważące po dwa megabajty i czcionki dociągane z zewnętrznych serwerów. Na szybkim laptopie w biurze tego nie widać. Na średnim telefonie z LTE — widać wszystko.

Typowe objawy i ich prawdziwe przyczyny:

Objaw	Przyczyna	Rozwiązanie
Długi biały ekran przed pojawieniem się czegokolwiek	CSS i JS motywu blokują renderowanie; serwer wolno odpowiada	Wydzielić krytyczny CSS, odroczyć skrypty, serwować statyczny HTML
Główne zdjęcie ładuje się z opóźnieniem	Plik 2 MB w formacie JPG, skalowany dopiero w przeglądarce	Konwersja do WebP, wymiary dopasowane do ekranu, preload dla zdjęcia hero
Treść skacze podczas ładowania (wysoki CLS)	Obrazki bez atrybutów szerokości i wysokości, czcionki podmieniane w locie	Zadeklarowane wymiary każdego obrazka, font-display: swap i zarezerwowane miejsce
Strona nie reaguje na kliknięcia przez pierwsze sekundy (słaby INP)	Przeglądarka mieli setki kilobajtów JavaScriptu z wtyczek i buildera	Usunąć zbędne skrypty; docelowo architektura, która JS-u prawie nie wysyła
Wolno nawet przy kolejnych wejściach	Brak CDN, każde żądanie idzie do jednego serwera, często obciążonego	Cache na węzłach CDN blisko użytkownika

Część z tych rzeczy da się załatać na istniejącym WordPressie: wtyczka cache, kompresja obrazków, wycięcie zbędnych dodatków. To realnie pomaga i warto to zrobić. Ale jest sufit, którego łataniem się nie przebije — bo problemem nie jest konfiguracja, tylko sama architektura. Szerzej porównujemy oba podejścia w artykule WordPress czy strona statyczna.

Architektura, która jest szybka z natury

Wynik 90+ w PageSpeed nie bierze się z heroicznej optymalizacji. Bierze się z tego, że strona od początku nie robi rzeczy, które spowalniają. Cztery elementy składają się na całość.

Strona statyczna zamiast generowanej na żywo

W podejściu statycznym (u nas: generator Astro) wszystkie podstrony powstają raz, w momencie publikacji — jako gotowe pliki HTML. Serwer niczego nie składa przy wejściu użytkownika, nie odpytuje bazy danych, nie wykonuje kodu PHP. Po prostu wysyła plik. Czas odpowiedzi spada z setek milisekund do kilkudziesięciu, a strona zaczyna się rysować niemal natychmiast.

Drugi skutek jest równie ważny: strona statyczna wysyła JavaScript tylko tam, gdzie jest naprawdę potrzebny — na przykład do obsługi formularza. Menu, treść, stopka to czysty HTML i CSS. Przeglądarka telefonu nie ma czego mielić, więc INP schodzi do wartości, których nie da się poczuć.

CDN — pliki serwowane z Polski, nie z drugiego końca świata

Statyczne pliki trafiają do sieci CDN (w naszym przypadku Amazon CloudFront), która trzyma ich kopie na serwerach rozsianych po świecie, w tym w Warszawie. Użytkownik z Polski dostaje stronę z węzła oddalonego o kilkadziesiąt kilometrów, nie z pojedynczego hostingu, który akurat obsługuje pięćset innych stron. Do tego dochodzi cache: raz pobrany plik jest serwowany kolejnym odwiedzającym bez dotykania źródła.

Obrazy w WebP, w rozmiarze, w którym będą wyświetlone

Format WebP daje pliki o kilkadziesiąt procent mniejsze od JPG przy tej samej jakości widocznej okiem. Ale sam format to połowa roboty. Druga połowa: obrazek wyświetlany w szerokości 800 pikseli nie powinien być wysyłany w 4000 pikseli. Przy budowaniu strony każde zdjęcie jest konwertowane i skalowane do faktycznych rozmiarów użycia, z wariantami pod różne ekrany, i dostaje zadeklarowane wymiary — więc nic nie skacze, a CLS zostaje przy zerze.

Czcionki z własnego serwera, przycięte do potrzeb

Standardowe podpięcie Google Fonts oznacza dodatkowe połączenie z obcym serwerem i pobranie pełnych plików ze znakami dla kilkudziesięciu języków. Zamiast tego czcionki serwuje się z własnej domeny, przycięte (subset) do polskich znaków i łaciny, tylko w tych grubościach, które strona faktycznie stosuje. Różnica bywa większa niż dziesięciokrotna: kilkadziesiąt kilobajtów zamiast kilkuset. Tekst pojawia się od razu, bez podmianek psujących układ.

Żaden z tych elementów nie jest egzotyczny. Sęk w tym, że na WordPressie z page builderem każdy wymaga walki z narzędziem, a w architekturze statycznej wszystkie są naturalnym stanem rzeczy.

Jak samemu sprawdzić swoją stronę

Wejdź na pagespeed.web.dev i wpisz adres swojej strony. To oficjalne, darmowe narzędzie Google — PageSpeed Insights. Wynik dostaniesz po kilkunastu sekundach i warto umieć go przeczytać.

Dwa rodzaje danych. Na górze raportu są dane terenowe: pomiary z prawdziwych użytkowników Chrome’a z ostatnich 28 dni, o ile strona ma wystarczający ruch. To właśnie te wartości Google bierze pod uwagę. Niżej jest test laboratoryjny (Lighthouse): symulacja wejścia na średnim telefonie z przyduszonym łączem, podsumowana wynikiem od 0 do 100.

Co znaczą liczby. Wynik 90–100 to zieleń — strona szybka. 50–89 to pomarańcz — działa, ale traci użytkowników i punkty w oczach Google. Poniżej 50 — czerwień, poważny problem. Patrz przede wszystkim na wynik mobilny: test mobilny jest znacznie surowszy od desktopowego i to on odpowiada warunkom, w których większość klientów zobaczy twoją stronę. Strona z desktopowym 95 potrafi mieć mobilne 40.

Jak czytać zalecenia. Pod wynikiem PageSpeed wypisuje konkretne możliwości poprawy: „Wyeliminuj zasoby blokujące renderowanie”, „Wyświetlaj obrazy w formatach nowej generacji”, „Zmniejsz ilość nieużywanego JavaScriptu”. Jeśli szukałeś frazy „pagespeed jak poprawić” — to jest twoja lista zadań, posortowana według szacowanego zysku. Zwróć uwagę, ile pozycji dotyczy JavaScriptu i obrazków: na typowej stronie z kreatora to zwykle 80% listy.

Trzy praktyczne uwagi. Po pierwsze, sprawdź nie tylko stronę główną — podstrona z ofertą czy kontaktem bywa wolniejsza. Po drugie, wyniki między kolejnymi testami wahają się o kilka punktów; to normalne, liczy się rząd wielkości. Po trzecie, jeśli danych terenowych brak (mały ruch), kieruj się testem laboratoryjnym — jest ostrożniejszy, więc dobry wynik w laboratorium niemal gwarantuje dobre Core Web Vitals w terenie.

Jeżeli twoja strona dostaje mobilnie 40–60 punktów, a lista zaleceń wygląda jak spis treści tego artykułu — problem prawie na pewno leży w architekturze, nie w pojedynczych ustawieniach.

Szybkość jako standard, nie projekt optymalizacyjny

Można iść drogą łatania: audyt, wtyczki, kompresja, kilka tygodni poprawek i wynik podniesiony z 45 na 70. Można też postawić stronę na architekturze, w której 90+ jest punktem wyjścia.

Strony budowane w Sitario mają ten drugi model wbudowany w standard: statyczny Astro, hosting na infrastrukturze AWS z CloudFront, obrazy automatycznie konwertowane do WebP z zadeklarowanymi wymiarami, czcionki self-hostowane z polskim subsetem. Wynik PageSpeed 90+ na urządzeniach mobilnych jest u nas kryterium odbioru każdej strony — sprawdzanym przed oddaniem, nie obiecywanym w ofercie.

Bo klient, który kliknął i nie doczekał — nie wraca. A ten, któremu strona otworzyła się natychmiast, właśnie zaczął czytać o twojej firmie.