Jak przyspieszyć stronę WordPress — z 55 do 94 punktów w Google PageSpeed

Wynik mobilny Google PageSpeed Insights poniżej 60 oznacza zwykle to samo: strona ładuje się zbyt długo, użytkownicy odchodzą przed pierwszym kontaktem z treścią, a wskaźniki Core Web Vitals (LCP, CLS, INP) są słabe. Pytanie „jak przyspieszyć stronę WordPress” słyszymy co tydzień.

Poniżej opisujemy konkretne wdrożenie: anonimowa strona firmowa na WordPress, kilkadziesiąt podstron, sklep, formularze i integracje. Bez zmian wizualnych, bez przebudowy treści, bez wymiany motywu. Trzy świeże pomiary mobilne PageSpeed przed: 50–55, po: 91, 92 i 94. Piszemy tylko to, co naprawdę zostało zrobione — w kolejności, w jakiej wykonywaliśmy działania.

Jeśli zależy Ci po prostu na wyniku, sprawdź naszą usługę Szybka strona 90+ — gwarantujemy PageSpeed mobile ≥ 90 (trzy kolejne pomiary) albo zwrot. Jeśli wolisz zrozumieć, co się zmieniło i dlaczego, czytaj dalej.

Dlaczego „strona wolno się ładuje” najczęściej oznacza coś więcej

Wynik PageSpeed Insights to nie cel sam w sobie. Za nim stoją trzy konkretne sygnały, które Google mierzy od 2021 w ramach Core Web Vitals:

• LCP (Largest Contentful Paint) — czas, w jakim pojawia się największy element widoczny od razu (hero, baner, duży obraz). Cel: ≤ 2,5 s.
• CLS (Cumulative Layout Shift) — czy elementy strony „skaczą” podczas ładowania (np. fonty, banery, obrazy bez rozmiaru). Cel: ≤ 0,1.
• INP (Interaction to Next Paint) — jak szybko strona reaguje na kliknięcia i dotknięcia. Cel: ≤ 200 ms.

Jeśli przeglądasz stronę na telefonie i widzisz „białą plamę” przez 3–4 sekundy, a potem wszystko nagle skacze — to znak, że te trzy wskaźniki są powyżej progów. Google potwierdza: ponad 50% użytkowników mobilnych porzuca stronę, jeśli ładuje się dłużej niż 3 sekundy. W połączeniu z algorytmem Page Experience ta liczba ma też realny wpływ na pozycje.

Wniosek: „jak przyspieszyć stronę internetową” to nie kosmetyka — to pytanie o konwersję i widoczność.

Co dokładnie zmierzyliśmy (i co zaskoczyło)

Przed zmianami wykonaliśmy trzy pomiary mobilne PageSpeed (Lighthouse, profil mobilny, ten sam URL, strona główna). Wynik wahał się od 50 do 55, najczęściej 55. To mediana — typowy wynik „przeciętnej” strony firmowej na WordPress, która ma kilka lat, dużo wtyczek i dawno niezmieniane media.

Co konkretnie blokowało wynik:

• Obrazy w PNG/JPG bez WebP — jeden baner 1,16 MB decydował o LCP na telefonie.
• 11 fontów ładowanych z Google Fonts — opóźniały pierwsze wyrenderowanie tekstu.
• 59 plików CSS i 66 plików JS — w tym oba warianty reCAPTCHA i kilka nieużywanych bibliotek.
• Brak lazy-load dla obrazów poniżej folda.
• Motyw ładujący font ikon z zewnętrznego CDN nawet dla zalogowanych użytkowników.

Audyt wyraźnie wskazywał, że to nie „silnik” jest problemem, tylko sposób podawania treści. Ten sam hosting, ten sam WordPress, ta sama treść — wystarczyło zmienić sposób ładowania.

Plan naprawy: co zrobiliśmy (i w jakiej kolejności)

Działaliśmy w jednej iteracji, na kopii strony, z migawką „przed”. To pozwala w każdej chwili wrócić do stanu wyjściowego, gdyby coś poszło nie tak. Kolejność była celowa: najpierw to, co daje największy zysk na PageSpeed, na końcu rzeczy wymagające testów formularzy.

1. Obrazy: WebP obok oryginałów + reguły nginx

Dla każdego dużego obrazu (hero, baner, zdjęcia zespołu, realizacje) wygenerowaliśmy wersję WebP i zostawiliśmy oryginał. Na poziomie nginx dodaliśmy regułę: jeśli przeglądarka wysyła nagłówek Accept: image/webp, serwer zwraca WebP. Efekt: ten sam obraz wizualnie, ale o 60–80% lżejszy. Na telefonie z LCP = baner 250 kB zamiast 1,16 MB.

2. WP Rocket: delay JS, lazy-load i cache

Aktywowaliśmy cache stron, lazy-load obrazów i filmów (w tym natywny lazy-load) oraz Delay JS — skrypty, które nie są potrzebne do pierwszego wyrenderowania (analytics, widgety, piksele) ładują się dopiero po interakcji użytkownika. Efekt: blokujący JS renderowanie spada z 66 plików do kilkunastu.

3. Perfmatters: RUCSS i wyłączanie niepotrzebnych wtyczek

Perfmatters wyłącza to, czego strona nie potrzebuje: emoji, embedy, XML-RPC, wersje skryptów, dashicons na froncie. Największy zysk dał RUCSS (Remove Unused CSS) — narzędzie, które analizuje użycie klas CSS na stronach i zostawia tylko to, co faktycznie jest używane. CSS spadł z 59 plików do kilku mniejszych paczek.

4. Elementor: CSS wewnętrzny i lokalne fonty Google

Elementor domyślnie ładuje fonty z Google Fonts. Po przejściu na local Google Fonts fonty są hostowane lokalnie, z kontrolą nad font-display. Dodatkowo kluczowe style Elementora weszły do krytycznego CSS, więc ładują się inline w pierwszej odpowiedzi HTML.

5. Fonty ikon: minimum + fallback dla zalogowanych

Pełny zestaw font ikon (często ponad 1000 glifów) ładował się nawet dla gościa strony. Ograniczyliśmy go do glifów faktycznie używanych na froncie, a pełny zestaw zostaje dla zalogowanych użytkowników (admin nadal widzi panel).

6. Dwa małe mu-pluginy zamiast modyfikacji motywu

Zamiast modyfikować pliki motywu (co znika przy aktualizacji), dodaliśmy dwa mu-pluginy: cx-wydajnosc.php i cx-dostepnosc.php. Drobne poprawki (np. rozmiar obrazu w HTML, porządek w stylach), bez zmiany treści w bazie. Dzięki temu wygląd strony się nie zmienia — a wszystko, co robimy, jest odwracalne jednym wyłączeniem wtyczki.

Co przyspieszyło stronę najbardziej — i co w ogóle nie dało wyniku

Z perspektywy wyniku mobilnego:

• Największy zysk: WebP dla obrazów hero + RUCSS. Razem odpowiadały za ponad połowę wzrostu PageSpeed.
• Duży zysk: Delay JS + lokalne fonty + cache HTML.
• Średni zysk: lazy-load, ograniczenie font ikon, porządek w mu-pluginach.
• Brak zysku lub regresja: dodatkowe „przyspieszacze CDN”, kolejne warstwy cache, agresywne minifikacje bez porządku w zasobach.

To ostatnie jest ważne. Samo dodanie CDN nie naprawi strony, która wysyła 1 MB obrazów i 60 plików JS. Najpierw porządek w zasobach, potem ewentualnie CDN. W naszym wdrożeniu CDN nie był potrzebny.

Kompromisy, które świadomie zaakceptowaliśmy

Każda zmiana coś kosztuje. W tym wdrożeniu:

• Pierwsza sekcja strony na telefonie nie ma animacji wejścia — animacja opóźniała LCP. Wygląd jest zachowany, ale bez efektu „fade-in”.
• Fonty tekstu mają font-display: optional — na bardzo wolnym łączu pierwsza wizyta może pokazać font zastępczy, a dopiero przy kolejnej stronie właściwy font. W zamian tekst pojawia się natychmiast.
• Ikona LinkedIn bez adresu URL została ukryta do czasu podania adresu przez właściciela.

To są decyzje, które warto rozważyć przed wdrożeniem. Dla stron, gdzie liczy się pierwsze wrażenie (LTV, premium), zostawiamy animacje kosztem milisekund. Dla stron, gdzie cel to szybka konwersja i SEO — priorytetem jest wynik PageSpeed.

Co z formularzami i integracjami (bo to się psuje przy „przyspieszaniu”)

To jest realne ryzyko przy każdej tego typu pracy. W naszym wdrożeniu:

• Formularze kontaktowe działają — testowaliśmy curl + zrzut ekranu.
• Integracje płatności nie zostały dotknięte.
• reCAPTCHA przenieśliśmy do Delay JS — formularz działa od razu, a skrypt ładuje się po interakcji.

Uwaga: agresywne minifikacje HTML, agresywny RUCSS bez ręcznej weryfikacji i cache bez wykluczeń potrafią zepsuć formularze, koszyk albo webhooki. Każdą zmianę testujemy na kopii, na trzech stronach: strona główna, strona z formularzem, strona z koszykiem.

Wynik: 55 → 94 w jednej iteracji

Po wdrożeniu wykonaliśmy trzy świeże pomiary mobilne PageSpeed tego samego URL. Wyniki: 91, 92, 94. Względem mediany bazowej 55 to skok o prawie 40 punktów. Wygląd strony bez zmian. Treść bez zmian. Hosting bez zmian. Zmienił się tylko sposób podawania zasobów.

Dodatkowo:

• Dostępność (a11y): 85 → 100.
• SEO: 92 → 100 (po drobnych porządkach w meta i schema).
• Dobre praktyki: 100.

To powtarzalny schemat. Nie jest to kwestia „magicznej wtyczki” — to konkretne działania w konkretnej kolejności, na konkretnej stronie. Powtarzalność oznacza, że możemy to samo zrobić na Twojej stronie i zagwarantować wynik.

Najczęstsze pytania

Jak szybko mogę przyspieszyć swoją stronę WordPress?

Dla typowej strony firmowej (do 30 podstron) zmiany robimy w 3 dni robocze. Dla większych serwisów i sklepów — w 5 dni. Po wdrożeniu robimy trzy pomiary, żeby potwierdzić wynik.

Czy zmieni się wygląd mojej strony?

Nie. Pracujemy na warstwie zasobów: obrazy, fonty, CSS, JS, cache. Treść i układ zostają bez zmian. Animacje, które opóźniają LCP, konsultujemy i zwykle upraszczamy.

Czy muszę zmieniać hosting?

Zwykle nie. W naszym wdrożeniu testowym wystarczył optymalny nginx + reguły + cache HTML. Jeśli hosting jest bardzo słaby, dajemy znać po audycie.

Czy to jest bezpieczne dla SEO?

Tak — wręcz przeciwnie. Szybsza strona = lepsze Core Web Vitals = lepsza ocena Google. Nie zmieniamy adresów URL, struktury nagłów, ani treści. Robimy migawkę „przed”, więc cofnięcie jest możliwe w 5 minut.

Ile to kosztuje?

Od 790 zł netto (do 300 podstron, do 3 dni roboczych). Szczegóły i bezpłatny pomiar w 24 h znajdziesz na stronie oferty Szybka strona 90+.

Chcesz, żebyśmy sprawdzili Twoją stronę?

Jeśli Twoja strona WordPress pokazuje PageSpeed mobile poniżej 70 i zastanawiasz się, co z tym zrobić, zacznij od bezpłatnego pomiaru. W 24 h dostajesz raport: aktualny PageSpeed (mobile i desktop), listę tego, co blokuje wynik, oraz krótki plan naprawy z wyceną.

Sprawdź ofertę Szybka strona 90+ — gwarantujemy PageSpeed mobile ≥ 90 (trzy kolejne pomiary) albo zwrot. Bez zmian wizualnych, bez zmian treści, z kopią zapasową stanu wyjściowego.