Jak przyspieszyć stronę na WordPressie? Optymalizacja krok po kroku

Aktualizacja: 19 października 2026.

Stronę na WordPressie przyspieszysz najpewniej w trzech krokach: najpierw zmierz, co ją spowalnia, potem zrób podstawy (obrazy, fonty, cache, zbędne skrypty), a dopiero na końcu sięgaj po ryzykowne optymalizacje ładowania skryptów i płatne usługi, takie jak CDN. Bardzo często największą różnicę daje też lepszy serwer. Ta kolejność ma znaczenie, bo idzie od działań najtańszych i najbezpieczniejszych do tych, które potrafią zepsuć funkcje strony.

Jak mierzę szybkość, zanim cokolwiek zmienię

Zaczynam od pomiaru, a nie od włączania opcji we wtyczce. Na wejściu używam PageSpeed Insights, bo jest najprostszy i każdy go zna. Do konkretnych poprawek sięgam po WebPageTest, który pokazuje kolejność ładowania zasobów, oraz po wtyczkę Query Monitor, która pokazuje powolne zapytania do bazy danych i ciężkie fragmenty kodu. Wynik punktowy to dopiero sygnał. Poprawiam przyczyny, a nie liczbę.

Patrz przede wszystkim na trzy wskaźniki Core Web Vitals. Według web.dev dobry wynik to:

• LCP (wczytanie największego elementu) do 2,5 sekundy,
• INP (reakcja na kliknięcie) do 200 milisekund,
• CLS (przesunięcia układu) do 0,1.

Te progi liczy się dla 75 procent wizyt, osobno na telefonach i komputerach. Wynik z jednego testu w PageSpeed Insights to symulacja, a dane z prawdziwych wizyt zobaczysz w raporcie Podstawowe wskaźniki internetowe w Google Search Console.

Kolejność optymalizacji, która nie psuje strony

1. Podstawy. Obrazy, fonty, cache strony, cache obiektowy i cache przeglądarki, minifikacja CSS, JS i HTML. Do tego wyłączenie zbędnych skryptów na stronach, które ich nie potrzebują: formularz kontaktowy nie musi ładować swoich plików na każdym wpisie.
2. Optymalizacja ładowania skryptów. Odraczanie i opóźnianie JavaScriptu daje duże zyski w wynikach, ale to moment, w którym zaczyna się ryzyko dla działania strony.
3. Na końcu CDN i płatne usługi. Nie jako pierwszy krok i nie jako domyślny element każdego wdrożenia.

Na blogu i stronie firmowej podstawy zwykle wystarczają do płynnego działania. Wyjątek to strony zbudowane z dużymi błędami, na przykład na kilku builderach naraz albo z wieloma wtyczkami, które ładują zewnętrzne skrypty. Wtedy zamiast kolejnej warstwy optymalizacji często potrzebna jest przebudowa.

Hosting i wersja PHP

Jeśli serwer odpowiada wolno, żadna wtyczka tego nie nadrobi. W praktyce zmiana hostingu bywa jednym z najtańszych działań, które dają największy skok szybkości. WordPress.org zaleca PHP w wersji 8.3 lub nowszej oraz MySQL 8.0 albo MariaDB 10.11 lub nowsze. Starsze wersje działają, ale nie mają już wsparcia.

Sprawdź też, czy hosting oferuje cache obiektowy, na przykład Redis. Przechowuje on wyniki zapytań do bazy w pamięci, więc odciąża stronę tam, gdzie zwykły cache strony nie działa: w panelu, koszyku i na kontach klientów. Na co zwracać uwagę przy wyborze serwera, opisuję w poradniku Jaki hosting wybrać dla WordPressa.

Obrazy

Obrazy to zwykle najcięższa część strony. Zadbaj o trzy rzeczy:

• Rozmiar dopasowany do miejsca. Zdjęcie wyświetlane w kolumnie szerokiej na 800 pikseli nie musi mieć 4000 pikseli szerokości.
• Nowoczesny format, czyli WebP albo AVIF zamiast ciężkiego JPG i PNG.
• Leniwe ładowanie obrazów poniżej pierwszego ekranu, ale nie dla głównego obrazu na górze strony. Ten obraz to często element LCP i powinien wczytać się od razu.

Więcej o kompresji i formatach piszę we wpisie Jak zoptymalizować obrazy i zdjęcia na stronie WordPress.

Fonty: przykład z tego bloga

Fonty potrafią jednocześnie blokować wyświetlenie strony i przesuwać jej układ. Pokażę to na pomiarze z tego bloga po migracji na nowy szablon. Sprawdzałem stronę główną w PageSpeed Insights i lokalnie w Lighthouse w trybie mobilnym, 19 października 2026.

• Przesunięcia układu (CLS) do 0,154. Font ładowany z zewnętrznego serwisu podmieniał się po wczytaniu, tekst w nagłówku łamał się inaczej i blok pod nim przeskakiwał.
• Zasoby blokujące wyświetlenie strony. Arkusz stylów fontów z zewnętrznej domeny zajmował około 780 ms, a skrypt Cloudflare, który ukrywa adresy e-mail przed botami, około 490 ms.

Co zmieniłem: deklaracje fontów przeniosłem do własnego arkusza z ustawieniem font-display: optional, dodałem wstępne ładowanie fontów pierwszego ekranu i kroje zastępcze o metrykach dopasowanych do docelowego fontu. Adresy e-mail w nagłówku i stopce wyłączyłem z ukrywania przez Cloudflare. Po zmianie CLS spadł do 0 na czterech z pięciu sprawdzanych adresów (na wpisie do 0,006), a oba zasoby blokujące zniknęły.

Ograniczenie: przy font-display: optional na bardzo wolnym łączu pierwsza strona może się wyświetlić krojem zastępczym, a docelowy font pokaże się od kolejnej. Dla mnie stabilny układ był ważniejszy.

Cache, czyli pamięć podręczna

Cache strony zapisuje gotowy HTML, więc serwer nie musi za każdym razem uruchamiać WordPressa i odpytywać bazy. Cache przeglądarki sprawia, że stałe pliki (style, skrypty, fonty) nie są pobierane przy każdej wizycie. Cache obiektowy, opisany wyżej, przyspiesza zapytania do bazy. Jak działają poszczególne rodzaje i jak je włączyć, opisuję w poradniku Czym jest pamięć podręczna (cache).

Uważaj na sklepy i strony z logowaniem: koszyk, zamówienie i konto klienta nie mogą trafić do cache strony, bo jeden klient zobaczy dane drugiego. Wiele wtyczek cache i hostingów wyklucza te strony domyślnie, ale przy Cloudflare i własnych regułach trzeba to sprawdzić.

Skrypty i style: ładuj tylko tam, gdzie są potrzebne

Wiele wtyczek ładuje swoje pliki na każdej podstronie, nawet jeśli działa na jednej. Usunięcie ich tam, gdzie są zbędne, to bezpieczna i skuteczna optymalizacja. Odraczanie i opóźnianie JavaScriptu to już drugi poziom: daje lepszy wynik w testach, ale potrafi zepsuć koszyk, formularze, popupy i analitykę.

Sklep na WooCommerce: gdzie naprawdę jest problem

W sklepie problem zwykle nie leży tam, gdzie wskazuje PageSpeed Insights. Najwolniejsze są strony koszyka i zamówienia oraz samo dodanie produktu do koszyka, czyli miejsca, których nie da się zapisać w cache strony. Dlatego w sklepie zaczynam od szukania powolnych zapytań do bazy w Query Monitor, a dopiero potem od nadmiarowych skryptów i stylów. Przebudowa sklepu bywa kosztowna, więc najczęściej robię podstawy i włączam cache obiektowy, o ile serwer na to pozwala. W nowszych sklepach warto też sprawdzić HPOS, czyli osobne tabele zamówień.

Lista testów po każdej zmianie

Sam fakt, że strona się ładuje i dobrze wygląda, niczego nie dowodzi. Po każdej zmianie w optymalizacji klikam ręcznie kluczowe akcje:

• dodanie produktu do koszyka i do listy życzeń,
• otwarcie koszyka i usunięcie z niego produktu,
• wysłanie formularza i sprawdzenie, czy dane doszły do panelu albo skrzynki,
• złożenie zamówienia testowego,
• popupy i ich zachowanie,
• rozwiązania zbudowane specjalnie dla tej strony.

Każdą akcję sprawdzam w trzech warunkach: jako zalogowany, niezalogowany i w oknie incognito. Różnica między nimi to najczęstsze miejsce, w którym chowa się awaria po optymalizacji. Tę listę stosuję od września 2026, kiedy powstała przy diagnozie sklepu klienta. Poprawa szybkości wchodzi też w zakres opieki i rozwoju strony, jeśli wolisz oddać to w stałe ręce.

Kiedy CDN nie pomoże

CDN, na przykład Cloudflare, skraca drogę plików do odwiedzającego. Nie naprawi jednak wolnego serwera ani ciężkiego buildera. W takiej sytuacji maskuje problem: zapłacisz za usługę i zobaczysz ładniejszy wykres zamiast szybszej strony. Najpierw hosting i sposób zbudowania strony, dopiero potem warstwy nad nimi.

Jeśli wolisz, żeby ktoś zmierzył i poprawił stronę za Ciebie, zajmuję się tym w ramach audytu SEO i optymalizacji. O tym, co działa w poprawie szybkości WordPressa, opowiadam też w zapisie mojego webinaru.

Najczęstsze pytania