Na telefonie stronę najczęściej spowalniają cztery rzeczy: za ciężkie zdjęcie na pierwszym ekranie, czcionki wczytywane w złej kolejności, okno cookies i skrypty, które blokują telefon na starcie. Wiem to z własnej strony. We wrześniu 2026 roku roland4foto.com miała na telefonie 80 punktów w Google PageSpeed, po pierwszych poprawkach 98, a kilka dni później 100. Poniżej opisuję, co dokładnie zmieniłem.
Jak zmierzyć szybkość strony
Wejdź na pagespeed.web.dev, wklej adres i otwórz wynik dla telefonu. Wynik od 90 do 100 punktów Google uznaje za dobry i pokazuje na zielono.
Nie zdziw się, jeśli wynik jest gorszy, niż sugeruje Twój telefon. PageSpeed udaje telefon ze średniej półki na wolnym 4G, z procesorem spowolnionym czterokrotnie. Tak widzi Twoją stronę klient z tańszym telefonem w tramwaju. Na nowym iPhonie i domowym Wi-Fi tego problemu nie zobaczysz, dlatego mierz w PageSpeed zamiast na oko.
Pod wynikiem raport pokazuje kilka wskaźników. Te mówią najwięcej:
- FCP, czyli kiedy na ekranie pojawi się cokolwiek.
- LCP, czyli kiedy pokaże się największy element, zwykle główne zdjęcie albo nagłówek. Dobry wynik to do 2,5 sekundy.
- CLS, czyli o ile treść przeskakuje w trakcie wczytywania, na przykład gdy tekst zjeżdża w dół, bo doczytała się czcionka. Dobry wynik to do 0,1.
- TBT, czyli jak długo telefon jest zajęty skryptami i nie reaguje na dotyk. Im bliżej zera, tym lepiej.
Główne zdjęcie: wczytuj najpierw to, które widać
Pierwszy błąd na roland4foto.com siedział w jednej linijce. Strona podpowiadała przeglądarce, żeby w pierwszej kolejności pobrała zdjęcie z sekcji „O mnie”, która leży kilka ekranów niżej. Zdjęcie z pierwszego ekranu czekało w kolejce. Po poprawce przeglądarka od razu bierze się za to, co klient zobaczy najpierw.
Druga sprawa to waga zdjęć. Zdjęcie na pierwszy ekran telefonu powinno mieć szerokość ekranu telefonu i być zapisane w formacie WebP albo AVIF. Zdjęcie prosto z aparatu, szerokie na 6000 pikseli, telefon i tak pomniejszy, ale najpierw musi je całe pobrać. Pozostałe zdjęcia przeglądarka może doczytać dopiero wtedy, gdy klient do nich przewinie (atrybut loading="lazy").
Trzecia, najmniej oczywista: sposób dekodowania. Główne zdjęcie było rozpakowywane synchronicznie, więc na ten czas telefon przestawał reagować. Zmiana na decoding="async" zdjęła z wyniku 400 milisekund blokowania.
Okno cookies, które kosztowało 5 sekund
Okno z pytaniem o zgodę na cookies siedziało w kodzie strony ukryte, a pokazywał je skrypt wczytywany na samym końcu. Okno pojawiało się więc z opóźnieniem, a na małym ekranie było największym elementem, który PageSpeed brał pod uwagę. LCP wynosił przez to 5 sekund.
Poprawka: okno jest teraz w kodzie zaraz na początku strony i pokazuje się od razu, jeśli klient nie wybrał jeszcze, na co się zgadza. Na małych ekranach wyłączyłem też rozmycie tła pod oknem (backdrop-filter), bo słabszy procesor rysuje je wolno.
Najszybsze okno cookies to takie, którego nie ma. Websly.pl nie ma statystyk ani reklam, więc okna z pytaniem o zgodę w ogóle nie potrzebuje.
Czcionki: z 190 KB do 27 KB
Strona wczytywała sześć plików z czcionkami, razem około 190 KB. Każdy zawierał pełny zestaw znaków i wszystkie grubości liter. Przygotowałem własne wersje: tylko litery potrzebne w polskim tekście i tylko te grubości, których strona używa. Zostały trzy pliki, razem około 27 KB. Leżą na tym samym serwerze co strona, więc przeglądarka nie łączy się dodatkowo z Google Fonts.
Czcionki potrafią też przesuwać treść. Gdy właściwa czcionka doczytuje się po chwili, tekst zmienia szerokość i wszystko pod nim skacze. Na roland4foto.com dawało to CLS 0,192, prawie dwa razy więcej niż dopuszczalne 0,1. Pomogła czcionka zastępcza dopasowana rozmiarem do docelowej (reguła size-adjust): tekst zajmuje to samo miejsce przed doczytaniem i po nim. Dla jednej czcionki ustawiłem też font-display: optional, bo jej podmiana przesuwała okno cookies o CLS 0,086.
Skrypty i animacje na pierwszym ekranie
Animacje elementów wjeżdżających przy przewijaniu wyglądają ładnie, ale na pierwszym ekranie opóźniają chwilę, w której klient widzi treść. Na roland4foto.com zostawiłem je tylko niżej na stronie. Skrypt, który je uruchamia, nie mierzy już przy starcie wysokości całej strony, bo zmuszało to telefon do przeliczenia układu, zanim cokolwiek pokazał.
Do tego każda podstrona dostaje tylko tę część arkusza stylów, której używa. Strona usługi nie pobiera stylów potrzebnych wyłącznie na stronie głównej.
Pułapka: PageSpeed mierzył inną stronę
Na roland4foto.com przez chwilę poprawiałem jedną stronę, a mierzyłem drugą. Strona przekierowywała odwiedzających na wersję językową według ustawień przeglądarki, a narzędzie Google lądowało na wersji angielskiej. Teraz automaty dostają dokładnie ten adres, który wpisały. Zanim zaczniesz poprawiać, sprawdź w raporcie, jaki adres naprawdę został zmierzony.
Co sprawdzisz sam, bez programisty
- Zmierz stronę główną i jedną podstronę usługi na pagespeed.web.dev, w wyniku dla telefonu.
- Zobacz, co raport wskazuje jako element LCP. Jeśli to zdjęcie, sprawdź jego wagę. Zdjęcie na pierwszy ekran telefonu zwykle mieści się w 100–200 KB.
- Otwórz stronę na telefonie, na internecie komórkowym, w trybie prywatnym. Tak wchodzi nowy klient.
- Jeśli masz WordPressa, policz wtyczki i wyłącz te, których nie używasz. Każda może dokładać własne skrypty i style.
- Sprawdź, czy okno cookies pojawia się od razu, czy po chwili.
Poprawiać czy budować od nowa?
Wolną stronę zwykle da się przyspieszyć bez przebudowy: zdjęcia, czcionki, kolejność wczytywania, pamięć podręczna. Wyjątek to strona na ciężkim motywie, który na każdej podstronie ładuje kilka bibliotek i kreator stron. Wtedy odchudzanie bywa droższe od nowej strony. Mówię to po pierwszym pomiarze, zanim wystawię wycenę. Jeśli zastanawiasz się nad nową stroną, przeczytaj też, kiedy wybrać WordPressa, a kiedy stronę pisaną od zera.
Wyślij mi adres swojej strony przez formularz. Zmierzę ją na telefonie i odpiszę, co ją spowalnia i czy opłaca się to poprawiać. Jak podchodzę do szybkości nowych stron, opisuję na stronie o stronach internetowych.