Klient klika w Twoją reklamę albo wynik w Google, patrzy na biały ekran i po kilku sekundach wraca do wyników wyszukiwania. Za kliknięcie zapłaciłeś, a zapytania nie ma. Szybkość strony internetowej decyduje o tym, czy ktoś w ogóle zobaczy Twoją ofertę, a Google mierzy ją u prawdziwych użytkowników i bierze pod uwagę przy ocenie strony.
W tym artykule wyjaśniamy, co oznaczają wskaźniki Core Web Vitals, jak czytać wynik w PageSpeed Insights i jak przyspieszyć stronę WordPress w 10 krokach. Na końcu pokazujemy, co zrobiliśmy z własną stroną i kiedy pogoń za kolejnymi punktami w teście przestaje się opłacać.
Dlaczego szybkość strony internetowej wpływa na sprzedaż
Każda sekunda czekania to moment, w którym klient może się rozmyślić. Na telefonie, przy słabym zasięgu i z kciukiem nad przyciskiem „wstecz”, cierpliwość kończy się szybko. Wolna strona traci ludzi, zanim przeczytają nagłówek.
Problem uderza najmocniej tam, gdzie płacisz za ruch:
- Reklamy. Za kliknięcie w kampanii Meta czy Google płacisz, nawet jeśli strona nie zdąży się załadować. Wolna strona podnosi realny koszt pozyskania klienta.
- Formularze i rezerwacje. Przycisk, który reaguje z opóźnieniem, wygląda na zepsuty. Część osób kliknie dwa razy, część zamknie kartę.
- Pierwsze wrażenie. Skaczący układ, mrugające fonty i wolno doczytywane zdjęcia sprawiają, że firma wygląda mniej profesjonalnie, choć oferta jest dobra.
Dlatego przy projektowaniu stron, które mają sprzedawać, traktujemy wydajność jako część oferty. Jeśli planujesz nową stronę, zobacz, jak podchodzimy do tworzenia stron internetowych nastawionych na sprzedaż.
Core Web Vitals: LCP, INP i CLS w prostych słowach
Core Web Vitals to trzy wskaźniki, którymi Google opisuje doświadczenie użytkownika na stronie. Każdy odpowiada na inne pytanie: jak szybko widać treść, jak szybko strona reaguje i czy układ jest stabilny. Od 2024 roku miejsce wskaźnika FID zajął INP (web.dev).
- LCP (Largest Contentful Paint) mierzy, po jakim czasie pojawia się największy element w widocznej części ekranu. Zwykle jest to zdjęcie w nagłówku albo duży blok tekstu.
- INP (Interaction to Next Paint) mierzy, jak szybko strona pokazuje reakcję po kliknięciu, dotknięciu lub naciśnięciu klawisza. Liczy się przez cały czas wizyty, a nie tylko przy pierwszym kliknięciu.
- CLS (Cumulative Layout Shift) mierzy, jak bardzo elementy przesuwają się w trakcie ładowania. Typowy przykład: chcesz kliknąć link, a w ostatniej chwili wyskakuje nad nim baner.
Progi poniżej pochodzą z dokumentacji Google na web.dev. Strona przechodzi ocenę, gdy co najmniej 75% wizyt (75. percentyl) mieści się w zakresie „dobry”, osobno dla telefonów i komputerów.
| Wskaźnik | Dobry | Do poprawy | Słaby |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Zwróć uwagę na 75. percentyl. Średnia może wyglądać dobrze, a jednocześnie co czwarty klient, zwykle ten na starszym telefonie, ma bardzo słabe doświadczenie. Google patrzy właśnie na tę grupę.
PageSpeed Insights: dane laboratoryjne a dane użytkowników
PageSpeed Insights pokazuje dwa zestawy liczb i wiele osób je myli. To najczęstsza przyczyna nieporozumień w rozmowach o wydajności.
Dane użytkowników (dane terenowe)
Górna część raportu pochodzi z raportu Chrome User Experience (CrUX). To pomiary od prawdziwych użytkowników Chrome, zbierane z ostatnich 28 dni (web.dev). Te dane widzi Google przy ocenie Core Web Vitals. Mała strona z niewielkim ruchem może ich nie mieć wcale, wtedy raport pokazuje tylko test laboratoryjny.
Z 28-dniowego okna wynika praktyczna rzecz: po wdrożeniu poprawek dane terenowe zmieniają się stopniowo. Pełny efekt zobaczysz po około czterech tygodniach.
Dane laboratoryjne (Lighthouse)
Dolna część raportu i wynik od 0 do 100 to test Lighthouse: jedno ładowanie strony na symulowanym telefonie i łączu. Wynik jest średnią ważoną kilku wskaźników. Największą wagę ma Total Blocking Time (30%), potem LCP i CLS (po 25%), a FCP i Speed Index mają po 10% (dokumentacja Lighthouse).
Test laboratoryjny nie zmierzy INP, bo nie wie, kiedy prawdziwy użytkownik kliknie. Zamiast tego pokazuje TBT, czyli czas, przez który przeglądarka była zablokowana przez skrypty. To dobry sygnał ostrzegawczy, ale nie to samo, co realna reakcja strony.
Co z tego wynika dla Ciebie:
- Wynik laboratoryjny służy do diagnozy. Pokazuje, co poprawić i czy poprawka zadziałała.
- Dane użytkowników pokazują, jak jest naprawdę. Na nie patrzy Google.
- Wynik potrafi skakać o kilka punktów między kolejnymi testami. Wpływają na to m.in. sieć, rozszerzenia przeglądarki i reklamy na stronie. Testuj kilka razy i patrz na trend.
Ciekawostka. W badaniu Deloitte i agencji 55, zleconym przez Google, przeanalizowano 37 stron dużych marek i ponad 30 milionów sesji. Skrócenie czasu ładowania mobilnej strony o zaledwie 0,1 sekundy wiązało się ze wzrostem konwersji o 8,4% w sklepach i o 10,1% w serwisach turystycznych. Jedna dziesiąta sekundy to mniej niż mrugnięcie oka (źródło: web.dev, Milliseconds make millions).
Jak przyspieszyć stronę WordPress w 10 krokach
Poniższe kroki ułożyliśmy od tych, które dają najwięcej przy najmniejszym ryzyku. Przed każdą zmianą zrób kopię zapasową i sprawdź stronę na telefonie, bo optymalizacja potrafi popsuć menu, slider albo formularz.
1. Włącz cache strony
Cache zapisuje gotową wersję podstrony, więc serwer nie musi jej składać z bazy danych przy każdej wizycie. To zwykle największa i najtańsza poprawa. Wystarczy jedna sprawdzona wtyczka cache albo cache po stronie hostingu. Nie instaluj dwóch naraz, bo będą sobie przeszkadzać.
2. Połącz i zminifikuj CSS oraz JavaScript
Minifikacja usuwa z plików spacje i komentarze. Łączenie zmniejsza liczbę osobnych plików, po które przeglądarka musi sięgnąć. Przy protokole HTTP/2 łączenie daje mniej niż kiedyś, więc testuj: czasem lepiej połączyć tylko pliki ładowane na każdej podstronie.
3. Odrocz ładowanie JavaScript (defer)
Skrypty w nagłówku strony blokują jej wyświetlanie. Atrybut defer pozwala przeglądarce najpierw pokazać treść, a skrypty uruchomić później. To bezpośrednio poprawia FCP i LCP. Sprawdź potem, czy działają menu mobilne, slidery i formularze.
4. Opóźnij widżety zewnętrzne
Czat, mapa Google, osadzony film z YouTube, piksele reklamowe i widżet opinii ładują własne skrypty z cudzych serwerów. Część z nich możesz uruchomić dopiero po pierwszym ruchu użytkownika albo po kliknięciu. Zamiast odtwarzacza wideo pokaż miniaturę z przyciskiem, a mapę wczytaj dopiero po kliknięciu. Piksele i analitykę opóźniaj ostrożnie, żeby nie zgubić danych o konwersjach.
5. Zamień zdjęcia na WebP i dopasuj ich wymiary
WebP przy tej samej jakości waży zwykle wyraźnie mniej niż JPG czy PNG. Równie ważny jest wymiar: zdjęcie o szerokości 4000 pikseli wyświetlane w okienku 400 pikseli to czysta strata transferu. WordPress tworzy mniejsze wersje obrazów, pilnuj tylko, żeby motyw z nich korzystał.
6. Włącz lazy loading, ale nie dla pierwszego ekranu
Leniwe ładowanie wczytuje obrazy dopiero wtedy, gdy użytkownik do nich przewija. WordPress robi to domyślnie. Wyjątek stanowi zdjęcie w nagłówku, które często jest elementem LCP. Ono ma się ładować od razu, najlepiej z wysokim priorytetem.
7. Uporządkuj fonty i ustaw font-display
Każda grubość i odmiana fontu to osobny plik. Zostaw tylko te, których naprawdę używasz, a fonty Google trzymaj lokalnie na swoim serwerze. Ustaw font-display: swap, żeby tekst był widoczny od razu w kroju zastępczym, zamiast czekać na pobranie fontu.
8. Usuń zbędne wtyczki
Wiele wtyczek ładuje swoje skrypty i style na każdej podstronie, także tam, gdzie nic nie robią. Przejrzyj listę i usuń to, czego nie używasz. Dla pozostałych sprawdź, czy da się wyłączyć ich zasoby na podstronach, gdzie są zbędne, na przykład skrypty formularza poza stroną kontaktu.
9. Zadbaj o wymiary elementów, żeby układ nie skakał
Podawaj szerokość i wysokość obrazów oraz rezerwuj miejsce na banery, reklamy i osadzone treści. Dzięki temu przeglądarka zna układ, zanim pobierze pliki, a wskaźnik CLS pozostaje niski.
10. Sprawdź hosting
Gdy serwer długo odpowiada na pierwsze zapytanie (wskaźnik TTFB), żadna wtyczka tego nie nadrobi. Zwróć uwagę na aktualną wersję PHP, dyski SSD lub NVMe, cache po stronie serwera i lokalizację serwerowni blisko Twoich klientów. Tani hosting współdzielony bywa najdroższą oszczędnością w całym projekcie.
Case study: jak przyspieszyliśmy efektywnymarketing.pl
W październiku 2026 przyjrzeliśmy się własnej stronie. Pomiar pokazał, że przeglądarka musiała pobrać 138 plików i 2,8 MB danych, zanim strona była kompletna. Na telefonie pierwsza treść pojawiała się po 3,8 sekundy.
Pracowaliśmy według listy z poprzedniej sekcji:
- wyłączyliśmy animację ładowania motywu, która zasłaniała treść, i połączyliśmy oraz zminifikowaliśmy pliki CSS i JavaScript (cache stron działał już wcześniej),
- odroczyliśmy skrypty, które nie są potrzebne do wyświetlenia pierwszego ekranu,
- opóźniliśmy widżety zewnętrzne do momentu, gdy użytkownik zacznie korzystać ze strony,
- przekonwertowaliśmy grafiki do WebP i ustawiliśmy lazy loading poniżej pierwszego ekranu,
- usunęliśmy nieużywane fonty i ustawiliśmy font-display: swap,
- usunęliśmy wtyczki i zasoby, które nic już nie wnosiły.
| Pomiar | Przed | Po |
|---|---|---|
| Liczba zapytań | 138 | ok. 45 |
| Rozmiar strony | 2,8 MB | 0,9 MB |
| PageSpeed mobile | 69 | 79 |
| FCP (mobile) | 3,8 s | 2,2 s |
Strona pobiera teraz około trzy razy mniej plików i trzy razy mniej danych. Pierwsza treść pojawia się o 1,6 sekundy szybciej. Z perspektywy użytkownika telefonu to różnica między „coś się ładuje” a „widzę ofertę”.
Kiedy dalsze punkty w PageSpeed się nie opłacają
Wynik 79 nie jest zielony. Mogliśmy walczyć dalej, ale uczciwie policzyliśmy, ile by to kosztowało. Kolejne punkty wymagałyby wbudowania w kod strony osobnych stylów pierwszego ekranu i pilnowania ich przy każdej zmianie wyglądu albo rezygnacji z części funkcji, które pomagają nam sprzedawać.
Sam Google pisze, że wynik 100 jest bardzo trudny do osiągnięcia i nie jest oczekiwany (dokumentacja Lighthouse). W wytycznych dla wyszukiwarki dodaje, że dobre Core Web Vitals nie gwarantują pierwszego miejsca, a wyszukiwarka zawsze stara się pokazać najbardziej trafną treść, nawet jeśli strona działa gorzej (Google Search Central).
Z naszego doświadczenia dalsza optymalizacja przestaje się opłacać, gdy:
- dane użytkowników w PageSpeed Insights lub Search Console są już w zakresie „dobry”, a poprawiasz tylko wynik laboratoryjny,
- kolejne punkty wymagają usunięcia czatu, wideo, kalkulatora lub innego elementu, który przynosi zapytania,
- koszt przebudowy motywu przekracza to, co możesz zyskać na konwersji przy obecnym ruchu,
- treści i oferta mają większe braki niż szybkość. Wtedy lepiej zainwestować w tekst, zdjęcia i strukturę strony.
Lepiej mieć szybką stronę z czatem, który odpowiada klientom, niż wynik 100 i stronę, z której nikt nie pisze. Takie decyzje podejmujemy też w projektach systemów rezerwacyjnych. W systemie, który zbudowaliśmy dla DMD Arena Częstochowa, klient układa salę na interaktywnym planie i widzi cenę na bieżąco. Taki moduł musi wczytać więcej skryptów niż zwykła wizytówka, więc ładujemy go tam, gdzie jest potrzebny, a nie na każdej podstronie. Więcej takich przykładów znajdziesz w naszych realizacjach.
Szybkość strony internetowej a reklamy i automatyzacje
Jeśli prowadzisz kampanie, sprawdź najpierw te podstrony, na które kierujesz ruch płatny. To tam każda sekunda kosztuje Cię pieniądze. Przy kampaniach Meta i Google zaczynamy od testu strony docelowej, zanim zwiększymy budżet.
Podobnie z asystentem AI czy czatem. Dobrze wdrożony wczytuje się po pierwszym ruchu użytkownika i nie spowalnia startu strony. Tak podchodzimy do wdrożeń w ramach automatyzacji i asystentów AI na stronach.
Najczęstsze pytania
Czy szybkość strony wpływa na pozycję w Google?
Tak, ale nie jako jedyny czynnik. Core Web Vitals są częścią oceny doświadczenia strony, którą biorą pod uwagę systemy rankingowe Google. Trafność treści ma pierwszeństwo, więc szybka strona ze słabą treścią nie wyprzedzi dobrej treści na wolniejszej stronie.
Jaki wynik w PageSpeed Insights jest dobry?
Lighthouse oznacza wynik 90–100 jako dobry, 50–89 jako do poprawy, a 0–49 jako słaby. Ważniejsze od tej liczby są jednak dane użytkowników w górnej części raportu i to, czy LCP, INP i CLS mieszczą się w zielonym zakresie.
Dlaczego mój wynik zmienia się przy każdym teście?
Test laboratoryjny to jedno ładowanie w określonych warunkach. Na wynik wpływają ruch w sieci, obciążenie serwera, reklamy i skrypty zewnętrzne. Zrób kilka pomiarów i porównuj wartości środkowe, a nie pojedynczy wynik.
Czy wystarczy zainstalować wtyczkę do optymalizacji?
Wtyczka cache i optymalizacji załatwia kroki od 1 do 4, a czasem też obrazy. Nie usunie jednak ciężkiego motywu, zbędnych wtyczek ani słabego hostingu. Każde ustawienie warto też sprawdzić ręcznie, bo agresywna optymalizacja potrafi zepsuć formularze i menu.
Ile kosztuje przyspieszenie strony WordPress?
To zależy od stanu strony. Czasem wystarczy kilka godzin konfiguracji, a czasem trzeba przebudować motyw lub zmienić hosting. Dlatego zaczynamy od pomiaru i listy poprawek z oceną, co da najwięcej za rozsądny koszt.
Sprawdź, ile tracisz na wolnej stronie
Wpisz adres swojej strony w PageSpeed Insights i porównaj LCP, INP i CLS z tabelą z tego artykułu. Jeśli wyniki są czerwone albo pomarańczowe, napisz do nas lub zadzwoń: 794 505 965 albo +48 22 602 25 32. Przeanalizujemy stronę i powiemy, które poprawki realnie przełożą się na zapytania, a które tylko podniosą wynik w teście.
'/%3E%3C/svg%3E){kind=small}