Standardowy WordPress + Elementor + 25 wtyczek = średnio 4,8 sekundy ładowania na mobile. Po naszej optymalizacji ten sam stack zwykle daje 1,2–1,8 s. Bez zmiany hostingu, bez przepisywania motywu. Pokażę Ci dokładnie 12 zmian, które dają tę różnicę.
W skrócie
- Zacznij od pomiaru — nie optymalizujesz tego, czego nie mierzysz.
- 80% problemów to: brak cache, niezoptymalizowane obrazy, blokujący JavaScript.
- Średnia poprawa LCP po naszych 12 krokach: z 4,5 s do 1,5 s.
- Czas wykonania samodzielnie: 4–8 godzin dla średniej witryny.
Najpierw zmierz
Otwórz pagespeed.web.dev i zapisz dla home page i 2 najważniejszych podstron:
- LCP (Largest Contentful Paint) — cel <2,5 s
- INP (Interaction to Next Paint) — cel <200 ms
- CLS (Cumulative Layout Shift) — cel <0,1
- Wynik mobilny i desktopowy
To Twój baseline. Po każdej zmianie wracaj i porównaj.
1. Włącz cache strony
Największy zysk z 1 zmianą. Bez cache każde wejście użytkownika wywołuje PHP, łączy się z bazą danych, generuje HTML — 1–3 sekundy strat.
Wtyczki, które polecam (w kolejności preferencji):
- WP Rocket (płatny, 59 USD/rok) — sensowne defaulty, działa od razu
- LiteSpeed Cache (darmowa) — jeśli masz hosting na LiteSpeed (mydevil, cyberFolks)
- W3 Total Cache (darmowa) — dla zaawansowanych, dużo opcji do skonfigurowania
Realny zysk: -50–70% czasu ładowania. LCP spada zwykle o 1,5–2,5 s.
2. Skonfiguruj lazy loading
WordPress 6.x ma natywny lazy loading dla obrazów (loading="lazy"), ale nie dla iframe i tła CSS. Iframe (np. mapa Google, YouTube) ładuje się od razu przy wejściu — kilkaset KB skryptu.
Co zrobić:
- Włącz lazy loading w wtyczce cache (WP Rocket robi to automatycznie)
- Dla YouTube użyj Lazy Load for Videos by WP YouTube Lyte — wstawia tylko thumbnail, JS YouTube ładuje się po kliknięciu
- Dla Google Maps zastąp iframe statycznym obrazem mapy + link „Otwórz w Google Maps”
Realny zysk: -300–800 ms LCP, jeśli miałeś iframe na home.
3. Zoptymalizuj obrazy
Najczęstszy „zabójca” prędkości WordPress: ktoś wgrywa zdjęcie 4 000 × 3 000 px wprost z aparatu (8 MB), a strona wyświetla je w 800 × 600 px.
3 kroki:
- Resize — wgrywaj obrazy w docelowych rozmiarach (max szerokość 1920 px dla full-width, 800 px dla w-tekście)
- Konwersja na WebP/AVIF — wtyczka ShortPixel lub Imagify robi to automatycznie. Oszczędność wagi: 30–60%
- CDN — Cloudflare, BunnyCDN. Obrazy serwowane z najbliższego serwera użytkownikowi
Realny zysk: -1–2 s LCP, jeśli miałeś nieoptymalne obrazy.
4. Wyłącz emoji, embedy, RSS
WordPress domyślnie ładuje sporo bzdurnych skryptów (emoji.js, oEmbed, RSS) — nawet jeśli nie używasz. Każdy skrypt to 10–80 KB pobranego niepotrzebnie.
Wtyczka: Perfmatters (24 USD/rok) — wyłącza wszystko jednym kliknięciem. Alternatywa: kod do functions.php:
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
remove_action('wp_head', 'wp_oembed_add_discovery_links');
Realny zysk: -200–400 ms.
5. Zoptymalizuj fonty
Google Fonts ładowane przez <link> to 2 dodatkowe requesty + zewnętrzny serwer fonts.googleapis.com. Każdy request to 200–500 ms.
Co zrobić:
- Hostuj fonty lokalnie — pobierz z google-webfonts-helper.herokuapp.com, wgraj na serwer, podlinkuj jako CSS
- Preload kluczowych fontów:
<link rel="preload" href="/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin>
- Używaj font-display: swap — strona pokazuje się od razu z fontem fallback, font webowy doładuje się „w tle”
Realny zysk: -300–700 ms LCP, mniejsze CLS.
6. Defer / async dla JavaScript
JavaScript domyślnie blokuje renderowanie strony. Tagi <script> w <head> zatrzymują parser HTML, dopóki skrypt się nie pobierze i wykona.
Rozwiązanie:
asyncdla skryptów niezależnych (Analytics, Tag Manager)deferdla skryptów modyfikujących DOM po załadowaniu (większość widgetów)- Lazy load dla skryptów, których używa się dopiero na interakcję (np. chat livechat)
W WP Rocket robi się to w 1 checkboxie. Bez wtyczki — wpisz w functions.php filtry script_loader_tag.
Realny zysk: -500–1500 ms LCP.
7. Wyczyść bazę danych
Po 2 latach bloga baza WP ma:
– Setki rewizji postów (każda zmiana = nowa rewizja)
– Tysiące transientów (cache, który nie wygasł)
– Spam komentarzy (nawet jeśli usuwany — zostaje w trash)
– Logi wtyczek
Wtyczka: WP-Optimize (darmowa). Włącz raz na 2 miesiące:
– Usuń rewizje starsze niż 30 dni
– Usuń wygasłe transients
– Defragmentuj tabele MySQL
Realny zysk: -100–300 ms TTFB (Time to First Byte).
8. Włącz GZIP / Brotli
Kompresja zmniejsza wagę przesyłanych plików o 60–80%. Większość hostingów ma to włączone domyślnie, ale warto sprawdzić w GIDNetwork tester.
Jeśli wyłączone — w .htaccess:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>
9. Wyrzuć ciężki Theme builder
Visual Composer i Divi to powolne konstruktory generujące brzydki HTML z 15 wagonów <div>. Każdy widget = osobny request CSS i JS.
Alternatywy:
– Elementor (wciąż najszybszy z popularnych)
– GeneratePress / Astra + Gutenberg (lekkie tematy)
– Bricks Builder (najszybszy nowy konstruktor)
Migracja z Visual Composer na Elementor to 1–3 dni pracy. Realny zysk LCP: -1–2 s.
10. Sprawdź wtyczki — która zwalnia stronę
Wtyczka Query Monitor (darmowa) pokazuje, które wtyczki najwięcej „kosztują” w czasie ładowania.
Najczęstsze winowajcy:
– Wtyczki social share (Easy Social Share, Sassy Social Share)
– Wtyczki „popup builder” ładowane na wszystkich podstronach
– Wtyczki backup robiące kopię w trakcie ruchu
Co zrobić: wyłączyć selektywnie na podstronach, gdzie nie potrzeba (Asset CleanUp lub Perfmatters).
11. Hosting — czy obecny daje radę
Hostingi shared za 9 zł/mies. mają zwykle stary PHP 7.4, brak NVMe, brak OPcache. Migracja na lepszy hosting potrafi obniżyć TTFB z 1,5 s do 200 ms.
Polskie hostingi dające realny zysk:
– mydevil.net — LiteSpeed, NVMe, OPcache, dobry stosunek ceny do jakości
– cyberFolks — WP-managed, free CDN, automatyczne backup
– Hostido — premium WP hosting, drogi ale szybki
Realny zysk z migracji: -300–1000 ms.
12. CDN — Cloudflare, BunnyCDN
CDN serwuje statyki (obrazy, CSS, JS) z najbliższego użytkownikowi serwera. Dla witryny w PL z odbiorcami w UK — różnica 200–600 ms.
Cloudflare — ma darmowy plan, dla większości witryn wystarczający. Włącza się w 5 minut (zmiana DNS).
Realny zysk: -100–400 ms LCP, lepszy INP.
Co dalej — kolejność wdrażania
Robisz w tej kolejności (od największego zysku do najmniejszego):
- Cache → 2. Optymalizacja obrazów → 3. Defer JavaScript → 4. Lazy loading → 5. Lokalne fonty → 6. WP-Optimize → 7. Wyłącz emoji/embed → 8. Asset CleanUp → 9. CDN → 10. Test, czy hosting nie ogranicza → 11. Theme builder migration → 12. Cache CSS
Pomiar po każdej zmianie. Jeśli coś psuje stronę — cofnij.
Optymalizacja Core Web Vitals to standard w naszych projektach — średnia z 12 ostatnich wdrożeń to 97/100 PageSpeed. Sprawdź pakiety opieki lub zamów audyt prędkości.
