Klient wchodzi na Twoją stronę z telefonu, w zasięgu LTE, w przerwie między jedną a drugą sprawą. Jeśli przez trzy sekundy patrzy na biały ekran, wraca do wyników i klika w konkurencję. Nie napisze Ci, że strona była wolna. Po prostu go nie zobaczysz.
Szybkość jest też czynnikiem rankingowym. Google mierzy ją zestawem wskaźników Core Web Vitals i uwzględnia przy ustalaniu pozycji. Przy dwóch stronach o zbliżonej treści szybsza wygrywa, choć warto pamiętać, że szybkość to jeden z wielu czynników rankingowych, nie jedyny.
Ten tekst rozbiera dwanaście rzeczy w kolejności od największego zysku do najmniejszego. Kilka z nich zrobisz sam w godzinę.
Czym mierzyć i co znaczą te liczby
PageSpeed Insights
Darmowe narzędzie Google pod adresem pagespeed.web.dev. Wklejasz adres, dostajesz wynik od 0 do 100 osobno dla telefonu i komputera.
Patrz na wynik mobilny. Jest zawsze niższy, bo test symuluje słabszy procesor i wolniejsze łącze, i to on odpowiada temu, co widzi większość Twoich odwiedzających.
Wynik dzieli się na dwie części, które łatwo pomylić. Sekcja z danymi terenowymi pokazuje pomiary od prawdziwych użytkowników z ostatnich 28 dni i pojawia się tylko przy stronach z odpowiednim ruchem. Sekcja z danymi laboratoryjnymi to pojedynczy test na symulowanym urządzeniu. Ta pierwsza mówi prawdę o Twoich klientach, druga służy do diagnozy.
Nie goń za setką. Różnica między 92 a 98 jest dla użytkownika niezauważalna, a kosztuje nieproporcjonalnie dużo pracy. Przeskok z 40 na 85 zmienia wszystko.
LCP, INP i CLS po ludzku
LCP to moment, w którym pojawia się największy element widoczny na pierwszym ekranie, zwykle zdjęcie w nagłówku albo duży tekst. Odpowiada na pytanie „kiedy widzę, że coś się dzieje". Cel: poniżej 2,5 sekundy.
INP zastąpiło w 2024 roku starsze FID i mierzy, ile czeka strona na reakcję po Twoim kliknięciu. Odpowiada na pytanie „czy ta strona reaguje". Cel: poniżej 200 milisekund.
CLS mierzy, ile treść przeskakuje w trakcie ładowania. Znasz to uczucie, gdy chcesz kliknąć przycisk, a w tym momencie doładuje się baner i klikasz w reklamę. Cel: poniżej 0,1.
Do tego dochodzi TTFB, czyli czas do pierwszego bajtu odpowiedzi serwera. Nie jest wskaźnikiem Core Web Vitals, ale wpływa na wszystkie pozostałe. Cel: poniżej 800 milisekund.
Dwanaście kroków w kolejności od największego zysku
1. Obrazy: format, wymiary, kompresja
To zwykle połowa problemu. Zdjęcie z aparatu ma 4000 pikseli szerokości i cztery megabajty, a wyświetla się w kontenerze o szerokości 800 pikseli. Przeglądarka pobiera całe cztery megabajty i dopiero potem je zmniejsza.
Przeskaluj obrazy do rozmiaru, w jakim faktycznie się pokazują, i zapisz w formacie WebP albo AVIF. WebP daje zwykle 25 do 35 procent mniejszy plik niż JPEG przy tej samej jakości i jest obsługiwany przez wszystkie aktualne przeglądarki. W WordPressie zrobi to wtyczka konwertująca przy wgrywaniu, w stronie pisanej ręcznie po prostu konwertujesz przed wrzuceniem.
2. Lazy loading dla obrazów poniżej pierwszego ekranu
Obrazy, których użytkownik jeszcze nie widzi, nie muszą się ładować od razu. Atrybut loading="lazy" odkłada ich pobranie do momentu, gdy zbliżą się do widoku.
Jeden wyjątek: obraz w nagłówku, który jest Twoim elementem LCP, musi ładować się natychmiast. Daj mu fetchpriority="high" i nie nakładaj lazy loadingu. Ustawienie lazy na obrazie z pierwszego ekranu to najczęstszy błąd, jaki widzę w audytach, i potrafi pogorszyć LCP o pełną sekundę.
3. Wymiary obrazów w kodzie
Każdy obraz powinien mieć w kodzie podaną szerokość i wysokość albo proporcje w CSS. Bez tego przeglądarka nie wie, ile miejsca zarezerwować, i treść przeskakuje po doładowaniu zdjęcia. To najprostszy sposób na naprawę CLS.
4. Audyt wtyczek
W WordPressie wtyczki są najczęstszą przyczyną spowolnienia. Nie chodzi o liczbę, tylko o to, że każda ładuje własny CSS i JavaScript na wszystkich podstronach, nawet tam, gdzie nie działa. Wtyczka formularza kontaktowego ładuje swoje pliki na stronie głównej, bloga i w każdym wpisie, choć formularz jest tylko na jednej podstronie.
Zrób przegląd: wyłącz wtyczki po kolei i mierz różnicę. Usuń te, których nie używasz, i te, które dublują funkcje. Trzy wtyczki od SEO robią to samo, ale ładują się wszystkie trzy.
5. Hosting i czas odpowiedzi serwera
Najtańszy hosting współdzielony za pięćdziesiąt złotych rocznie oznacza, że na jednym serwerze siedzi kilkaset stron. Gdy sąsiad dostanie ruch, Twoja strona zwalnia.
Sprawdź TTFB w PageSpeed Insights. Powyżej sekundy problem jest po stronie serwera i żadna optymalizacja obrazów tego nie naprawi. Przejście na przyzwoity hosting z SSD i aktualnym PHP potrafi ściąć TTFB kilkukrotnie. Jeśli wolisz, żeby ktoś to za Ciebie pilnował, to dokładnie to robię w ramach opieki nad stroną.
Przy okazji sprawdź wersję PHP. Różnica między 7.4 a 8.3 to realny zysk wydajności, a wiele stron wciąż stoi na przestarzałych wersjach, bo nikt tego nie ruszył.
6. Cache
Cache zapisuje gotową wersję strony, zamiast generować ją od nowa przy każdym wejściu. W WordPressie załatwia to wtyczka cache'ująca, na hostingach z LiteSpeed zwykle wbudowany mechanizm.
Do tego cache przeglądarki, ustawiany nagłówkami. Powracający użytkownik nie pobiera ponownie logo, fontów i arkusza stylów.
7. Kompresja Brotli albo Gzip
Pliki tekstowe, czyli HTML, CSS i JavaScript, kompresują się bardzo dobrze. Brotli daje zwykle o 15 do 20 procent lepszy wynik niż starszy Gzip. Włącza się to po stronie serwera, na większości hostingów jednym przełącznikiem w panelu.
8. Fonty
Font wczytywany z zewnętrznego serwera oznacza dodatkowe połączenie i dodatkowe opóźnienie. Pobierz pliki i hostuj je u siebie.
Ogranicz liczbę krojów i grubości. Trzy kroje po cztery grubości to dwanaście plików, z których realnie używasz czterech. Dodaj font-display: swap, żeby tekst był widoczny natychmiast w foncie zastępczym, zamiast czekać na pobranie właściwego.
Jeśli używasz tylko znaków łacińskich, wytnij z pliku pozostałe zestawy znaków. Potrafi to zmniejszyć font o połowę.
9. Nieużywany CSS i JavaScript
PageSpeed Insights pokazuje w zakładce z oszczędnościami, ile kilobajtów CSS i JS nigdy się nie wykonuje. Na stronach zbudowanych page builderem bywa to 70 procent arkusza stylów.
W stronie pisanej ręcznie po prostu tego nie wysyłasz. W WordPressie z page builderem walka jest trudniejsza i sprowadza się do wyłączania modułów, których nie używasz, oraz warunkowego ładowania plików tylko tam, gdzie są potrzebne.
10. Odroczenie skryptów
Skrypt w sekcji nagłówka blokuje renderowanie strony do czasu, aż się pobierze i wykona. Przenieś skrypty na koniec dokumentu albo dodaj atrybut defer.
Dotyczy to zwłaszcza narzędzi zewnętrznych: analityki, pikseli, czatów, map. Każde z nich to osobne połączenie do obcego serwera. Osadzona mapa Google potrafi dołożyć do strony ponad megabajt. Zamiast niej wstaw statyczny obrazek, który po kliknięciu ładuje właściwą mapę.
11. Preconnect i preload
preconnect mówi przeglądarce, żeby nawiązała połączenie z zewnętrzną domeną, zanim faktycznie będzie potrzebne. preload każe pobrać konkretny zasób z wyprzedzeniem.
Używaj oszczędnie, na dwa, trzy najważniejsze zasoby. Nadmiar preloadów daje efekt odwrotny, bo wszystko rywalizuje o to samo pasmo.
12. Przekierowania i ich łańcuchy
Każde przekierowanie to dodatkowa runda komunikacji z serwerem. Łańcuch typu adres bez www prowadzi do wersji z www, ta prowadzi do wersji z ukośnikiem, a ta do wersji szyfrowanej, kosztuje trzy dodatkowe rundy, zanim cokolwiek się załaduje.
Ustaw jedną wersję kanoniczną i przekierowuj do niej bezpośrednio, jednym skokiem.
Sprawdź
Chcesz wiedzieć, co konkretnie spowalnia stronę?
Wypełnij krótki formularz wyceny - napisz adres swojej strony, a ja odeślę rozpisaną listę problemów w kolejności od największego zysku, razem z konkretną kwotą.
Wyceń projektKiedy przyspieszanie nie ma sensu
Czasem taniej napisanie strony od nowa, niż ratowanie istniejącej.
Sygnały: motyw kupiony w marketplace, którego autor przestał aktualizować. Page builder, który generuje po dziesięć zagnieżdżonych kontenerów na każdą sekcję. Trzydzieści wtyczek, z których połowa nie ma aktualizacji od dwóch lat. Wynik mobilny poniżej 25 punktów mimo podstawowych optymalizacji.
W takich przypadkach optymalizacja jest walką z fundamentem. Doprowadzisz stronę do 55 punktów przy sporym nakładzie pracy, a strona napisana od zera startuje z 95 i tam zostaje.
Granica przebiega mniej więcej tam, gdzie koszt optymalizacji zbliża się do połowy kosztu nowej strony. Jeśli audyt szybkości strony i poprawki to 1500 zł, a nowa strona firmowa od 2500 zł, wybór jest raczej oczywisty. Jeśli decydujesz się na nową stronę, warto wcześniej sprawdzić, jak wybrać wykonawcę, żeby nie powtórzyć tego samego błędu za rok.
FAQ - najczęstsze pytania
Źródła: Podstawowe wskaźniki internetowe a wyniki wyszukiwania Google, Largest Contentful Paint (web.dev).