Szybkość WordPress to nie kosmetyka. To pieniądze które tracisz codziennie. Wyobraź sobie potencjalnego klienta. Zobaczył reklamę na Facebooku w przerwie obiadowej. Kliknął, wszedł na Twoją stronę produktu. Telefon w jednej ręce, kanapka w drugiej.
Twoja strona ładuje się 5 sekund.
W trzeciej sekundzie klient zaczyna patrzeć w bok. W czwartej myśli „może później”. W piątej wraca do Facebooka. Już go nie ma. Reklama która kosztowała Cię złotówki za kliknięcie właśnie wyparowała.
To nie jest moja teoria. To dane Google: 53% mobilnych użytkowników opuszcza stronę, która ładuje się dłużej niż 3 sekundy (źródło: web.dev / DoubleClick Mobile Speed Insights).
TL;DR · 30 SEKUND
Sześć technik na lepszą szybkość WordPress. Każda do zrobienia w 15-30 minut, łącznie 2-3 godziny pracy. Spodziewany efekt: spadek czasu ładowania o 2-4 sekundy, wzrost PageSpeed mobile o 20-40 punktów.
Plus uczciwie: kiedy te techniki nie wystarczą i warto oddać to komuś z gwarancją wyniku.
Większość polskich stron WordPressowych dla biznesu mieści się w PageSpeed Insights mobile w przedziale 30-60 punktów. Powyżej 90 to wyjątek. Punkty PageSpeed to nie kosmetyka. To ranking factor w Google od czerwca 2021, to Quality Score reklam Google Ads, to konwersja z ruchu który już zapłaciłeś.
Poniżej sześć konkretnych technik. Każda mierzalna, każda do zrobienia bez agencji w dwie-trzy godziny. Plus uczciwie: kiedy ich nie wystarczy.
|
Wolisz oddać to komuś z gwarancją? Speed Boost: 2 500 PLN, tydzień, 90+ albo 100% zwrotu. Pre-check 15 minut bezpłatnie. |
Sprawdź pre-check → |
Jak zmierzyć szybkość WordPress (zanim zaczniesz hackować)
Otwórz pagespeed.web.dev, wpisz swoją domenę, zrób screenshot wyniku mobile i desktop. To Twój punkt zero. Bez tego nie wiesz czy hacki cokolwiek zrobiły.
Patrz konkretnie na cztery metryki:
- LCP (Largest Contentful Paint) – kiedy największy element pojawia się na ekranie. Cel: pod 2,5 sekundy.
- FCP (First Contentful Paint) – pierwsze cokolwiek widzialne. Cel: pod 1,8 sekundy.
- TBT (Total Blocking Time) – jak długo strona jest „zablokowana” przez JavaScript. Cel: pod 200 ms.
- CLS (Cumulative Layout Shift) – czy układ skacze podczas ładowania. Cel: pod 0,1.
Każdy z sześciu hacków poniżej wpływa na jedną lub dwie z tych metryk. Po każdej zmianie wracaj na pagespeed.web.dev i mierz różnicę. Jeśli wynik nie drgnął, hack nie zadziałał (zwykle problem konfiguracyjny, sprawdź czy wtyczka jest faktycznie aktywna).
Hack 1: Włącz cache headers + kompresję Brotli/gzip
Pierwsza rzecz którą sprawdzam u nowego klienta to nagłówki HTTP. Otwórz DevTools w Chrome (F12), zakładka Network, wpisz swoją domenę, F5. Kliknij na pierwszy plik (HTML strony głównej), patrz na „Response Headers”.
Powinno tam być coś w stylu:
cache-control: max-age=3600(lub więcej)content-encoding: bralbogzip
Jeśli widzisz cache-control: no-cache albo brak content-encoding, masz problem. Strona jest pobierana w całości za każdym razem, niespakowana.
Wklejka do pliku .htaccess w katalogu głównym WordPressa (zrób kopię zapasową przed edycją):
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json text/xml image/svg+xml
</IfModule>
<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json text/xml
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>Spodziewany efekt: spadek wagi pierwszego załadowania o 60-80%. LCP zwykle szybsze o 1-1,5 sekundy. Mierz przed i po na pagespeed.web.dev, różnicę zobaczysz w pierwszym pomiarze.
Jeden warunek. Część hostingów (głównie tańsze shared) nie ma włączonego mod_brotli na poziomie serwera. Wtedy Brotli się nie uruchomi, ale gzip i tak da 60-70% kompresji. Sprawdź po wdrożeniu w DevTools czy content-encoding się pojawiło.
Hack 2: Optymalizacja zdjęć – najczęstszy zabójca PageSpeed
Trzy z czterech wolnych stron WordPress które oglądam mają to samo. Hero image 8 MB JPEG wgrane prosto z aparatu albo iPhone’a. Marketingowiec myślał że „lepsza jakość = lepiej”. Google myśli inaczej.
Co zrobić, w trzech krokach.
Krok 1: kompresja. Wszystkie nowe zdjęcia przed wrzuceniem na stronę przepuszczaj przez squoosh.app (darmowe narzędzie Google) lub kompresor wbudowany we wtyczkę. ShortPixel, Imagify, Smush – każda z tych wtyczek robi to dobrze, wybierz jedną. Dla wcześniej wgranych zdjęć większość tych wtyczek ma „Bulk Optimize”, przeoptymalizuje wszystko w bibliotece mediów.
Krok 2: WebP. Format obrazów który waży o 30-50% mniej niż JPEG przy tej samej jakości wizualnej. WordPress 6.0+ natywnie generuje WebP, ale upewnij się że wtyczka kompresji ma to włączone. Test: wejdź na swoją stronę, prawym przyciskiem na obrazek, „Inspect Element”, patrz czy src kończy się na .webp zamiast .jpg.
Krok 3: leniwe ładowanie (lazy loading). WordPress od wersji 5.5 dodaje loading="lazy" automatycznie do wszystkich obrazków poniżej pierwszego ekranu. Sprawdź czy żadna wtyczka nie nadpisuje tego ustawienia. Zdjęcie hero (pierwsze, widoczne od razu) powinno mieć loading="eager" lub w ogóle bez atrybutu. Leniwe ładowanie tego obrazu paradoksalnie spowalnia LCP.
Spodziewany efekt: po samej optymalizacji obrazów PageSpeed mobile w górę o 15-25 punktów na większości stron e-commerce i firmowych z dużą galerią. To zwykle największy pojedynczy skok w naszych audytach.
Hack 3: Audyt wtyczek, usuń 30% których nie używasz
Otwórz panel WordPress, wejdź w Wtyczki. Zlicz aktywne. Jeśli masz powyżej 25, prawie na pewno 7-10 z nich nie używasz, a one ładują JavaScript i CSS na każdej stronie.
Klasyczni winowajcy:
- Slider Revolution wgrany dla jednego slidera w 2019, ładuje swój skrypt globalnie do dziś.
- Visual Composer lub WPBakery którego zostawiłeś bo „kiedyś jeszcze użyję”.
- Wtyczki do statystyk lub map kliknięć (Hotjar, Microsoft Clarity, dwie nawzajem zastępujące).
- Contact Form 7 i WPForms równolegle bo jeden zespół wziął jedno, drugi drugie.
Jak rozeznać kto ładuje co? Wtyczka Query Monitor (darmowa, neutralna, robi tylko audyt) pokazuje listę enqueue’owanych skryptów per strona. Włącz na 24 godziny na produkcji albo na lokalnej kopii, otwórz stronę produktu, sprawdź zakładkę „Scripts” i „Styles”. Każdy plik tam to dodatkowe żądanie HTTP do serwera.
Reguła: wtyczka aktywna ale niewidoczna w żadnym aktywnym shortcode lub widget = kandydat do usunięcia. Wyłącz na tydzień, sprawdź czy nic nie odpadło, potem usuń.
Spodziewany efekt: po usunięciu 5-10 wtyczek spadek czasu ładowania o 0,5-1,5 sekundy na sam Total Blocking Time.
Hack 4: font-display swap + preload kluczowych fontów
Czy znasz to uczucie gdy strona ładuje się, ale tekst jest niewidoczny przez 2-3 sekundy, a potem nagle wyskakuje?
FOIT (Flash of Invisible Text) – moment gdy przeglądarka czeka aż pobierze font, zanim wyrenderuje jakikolwiek tekst. Te 2-3 sekundy ciemnoty zabijają LCP. Rozwiązanie ma dwa kroki.
Krok 1: font-display: swap. W pliku CSS Twojego motywu (najczęściej style.css lub w pliku w katalogu motywu odpowiadającym za fonty) znajdź deklaracje @font-face i dodaj jedną linijkę:
@font-face {
font-family: 'TwojaCzcionka';
src: url('fonts/twojaczcionka.woff2') format('woff2');
font-display: swap;
}font-display: swap mówi przeglądarce: wyświetl tekst od razu fontem systemowym, podmień na docelowy gdy się pobierze. Tekst widoczny od razu, LCP w dół.
Krok 2: preload kluczowych fontów. W pliku header.php motywu, w sekcji <head>, dodaj:
<link rel="preload" href="/wp-content/themes/twoj-motyw/fonts/twojaczcionka.woff2" as="font" type="font/woff2" crossorigin>Tylko 1-2 fonty, te które są używane w pierwszym ekranie (zwykle headline i podstawowy tekst). Preload pięciu fontów to przesada i blokuje krytyczne zasoby.
Spodziewany efekt: LCP w dół o 0,3-0,8 sekundy, znika niepokojący „rzut tekstem”.
Hack 5: Krytyczny CSS i odroczenie JavaScript
To najtrudniejszy hack z listy, ale daje też największy boost.
Krytyczny CSS to ten kawałek stylów który MUSI być załadowany żeby pierwszy ekran wyglądał poprawnie. Reszta CSS może być załadowana asynchronicznie po wyrenderowaniu.
Wariant prostszy (z wtyczką): Autoptimize i WP Rocket mają opcję „Generate Critical CSS” wbudowaną. Włączasz, klikasz, czekasz aż wygeneruje. Sprawdź po stronie czy nie zepsuło układu (typowe objawy: przesunięte hero, zniknięte przyciski). Jeśli zepsuło, wyłącz tylko Critical CSS, reszta optymalizacji zostaje.
Wariant manualny: narzędzie web.dev/measure pokazuje konkretne pliki CSS które blokują render. Możesz inline’ować ich zawartość ręcznie w <style> w <head>, a oryginalne <link rel="stylesheet"> zmienić na asynchroniczne:
<link rel="preload" href="style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">Defer JavaScript: wszystkie skrypty które nie są krytyczne dla pierwszego ekranu powinny mieć atrybut defer. W WordPressie najprościej przez filtr w functions.php:
add_filter( 'script_loader_tag', function( $tag, $handle ) {
$exclude = array( 'jquery-core' ); // skrypty które MUSZĄ być natychmiast
if ( in_array( $handle, $exclude, true ) ) return $tag;
return str_replace( ' src=', ' defer src=', $tag );
}, 10, 2 );Spodziewany efekt: spadek Total Blocking Time o 50-70%, PageSpeed mobile w górę o 10-20 punktów. To często moment kiedy strona z 50 punktami przeskakuje na 75-80.
Ważne ostrzeżenie
Defer JavaScript i krytyczny CSS to dwa miejsca gdzie najłatwiej coś zepsuć. Testuj na lokalnej kopii albo staging, nie wprost na produkcji. Jeśli zauważysz że formularz przestał działać, slider się nie animuje, lub menu nie rozwija się na mobile, prawdopodobnie zdeferowałeś skrypt który musi działać synchronicznie.
Hack 6: Cleanup bazy danych (transienty, rewizje, spam)
WordPress przez lata zbiera w bazie danych mnóstwo śmieci. Transients które wygasły rok temu ale nie zostały usunięte. Rewizje postów (każdy edytowany post ma kilkanaście rewizji w bazie). Spam w komentarzach. Wygasłe sesje użytkowników.
Sama waga bazy nie wpływa katastrofalnie na PageSpeed, ale wpływa na czas każdego zapytania SQL, a tych przy ładowaniu strony WordPress robi 50-150.
Wtyczka WP-Optimize robi to za Ciebie w trzy kliknięcia. Backup bazy przed (zawsze), potem Run All Optimizations.
Dla bardziej technicznych, manualny SQL przez phpMyAdmin lub Adminer:
-- Usuń wygasłe transienty
DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();
-- Usuń rewizje starsze niż 30 dni
DELETE FROM wp_posts WHERE post_type = 'revision'
AND post_date < DATE_SUB(NOW(), INTERVAL 30 DAY);
-- Wyczyść spam w komentarzach
DELETE FROM wp_comments WHERE comment_approved = 'spam';Spodziewany efekt: marginalny dla PageSpeed (1-3 punkty), ale realny dla wewnętrznej szybkości panelu administracyjnego, szybkości wyszukiwarki na stronie i czasu robienia kopii zapasowej. Zrób raz na kwartał.
Co zrobić gdy DIY nie wystarczy?
Powyższe sześć technik wykonanych sumiennie zwykle przesuwa stronę WordPress z PageSpeed mobile 35 na 65-75. To duża zmiana. Ale są strony gdzie po wykonaniu wszystkiego nadal nie widać 80+, a tym bardziej 90+.
Typowe przyczyny:
- Ciężki motyw kupiony na ThemeForest. Niektóre motywy mają wbudowane 5 builderów stron i ładują assets dla wszystkich, nawet jeśli używasz jednego. Czasem łatwiej przebudować od nowa na lżejszym motywie niż wycinać.
- Słaby hosting. Shared hosting po 15 zł miesięcznie z TTFB 800 ms+ nie da się wyciągnąć żadnym hackiem po stronie kodu. Trzeba migrować na VPS lub managed WP hosting.
- Custom JavaScript dorzucony dla jednej funkcji, ale ładowany globalnie. Wymaga audytu kodu motywu lub wtyczki.
- Osadzone filmy z YouTube/Vimeo na każdej stronie. Każdy filmik wstrzykuje 1-2 MB JavaScriptu z domeny Google.
Jeśli zrobiłeś sześć hacków i widzisz wciąż PageSpeed poniżej 70, to znaczy że jest głębszy problem którego ten artykuł nie rozwiąże. Albo poświęcasz kolejnych 20-30 godzin na audyt kodu i hostingu, albo oddajesz to komuś.
My oferujemy Speed Boost, jednorazową usługę dla stron WordPress. 2 500 PLN netto, do 7 dni roboczych, gwarancja 90+ mobile na PageSpeed Insights strony głównej albo 100% zwrotu pieniędzy. Zakres prac to sześć technicznych punktów wgrywanych przez FTPS bez ruszania panelu, bez instalowania nowych wtyczek. Pre-check 15 minut przed zapłatą, żeby ocenić czy strona w ogóle się kwalifikuje.
|
Sprawdź swoją stronę Pre-check 15 minut, bezpłatny Sprawdzamy czy strona się kwalifikuje do Speed Boost. Wynik zielony lub czerwony, bez ściemy. |
Nie teraz Zapisz się na newsletter Jeden mail tygodniowo. Porady techniczne dla owner’ów stron B2B, bez sprzedaży. |
Nie naciskamy. Jeśli pre-check pokaże że da się to zrobić sześcioma hackami z tego artykułu, powiemy wprost: zrób sam, oszczędź 2 500 PLN. Jeśli pokaże że jest głębszy problem, wtedy mamy o czym rozmawiać.
Najczęstsze pytania
Czy wtyczki typu WP Rocket załatwią to wszystko?
W dużej części tak. WP Rocket, Autoptimize, W3 Total Cache, Perfmatters – każda z tych wtyczek robi 60-70% pracy z tego artykułu automatycznie po konfiguracji. Klucz jest w słowie „konfiguracja”. Domyślne ustawienia rzadko dają dobry wynik, trzeba świadomie wybrać które opcje włączyć, a które wyłączyć. Plus każda wtyczka cache’ująca dodaje swoje 0,5-1 sekundy do panelu admin i komplikacje przy aktualizacjach.
Ile czasu zajmie wdrożenie wszystkich sześciu hacków?
Dla osoby która ma podstawową wiedzę o WordPressie i nie boi się edytować plików motywu – 2-3 godziny czystej pracy. Plus drugie tyle na testowanie po każdej zmianie i naprawianie tego co się rozjechało (typowo coś się rozjedzie po deferowaniu JavaScript).
Mam Elementora lub WPBakery. Czy te hacki dla mnie zadziałają?
Tak, ale z mniejszym efektem. Buildery stron ładują dużo własnego CSS i JavaScriptu których nie da się łatwo usunąć bez psucia layoutu. Realny pułap PageSpeed dla strony zbudowanej na Elementorze z dużą liczbą widgetów to 70-80 mobile, rzadko więcej. Jeśli celujesz w 90+, prawdopodobnie trzeba zmienić podejście do budowy strony (np. migracja na bloki Gutenberga lub HTML własny).
Czy wtyczki do optymalizacji nie zabijają same w sobie szybkości?
To zależy od wtyczki i konfiguracji. Wtyczki typu cache (WP Rocket, W3TC) generują pliki statyczne i nie ładują się przy odwiedzinach użytkownika końcowego, więc w czasie wyświetlania strony są neutralne. Wtyczki do statystyk i map kliknięć (Hotjar, Microsoft Clarity) ładują własny JavaScript na każdej stronie i mogą obciążać. Dla każdej zainstalowanej wtyczki warto zadać pytanie: czy ona jest aktywna gdy klient wchodzi na stronę, czy tylko buduje cache po stronie serwera?
Jak zmierzyć postęp po każdej zmianie?
Otwórz pagespeed.web.dev przed wdrożeniem zmiany, zrób screenshot wyniku mobile i desktop. Wdroż zmianę. Poczekaj 5 minut (PSI ma cache, czasem trzeba dać czas). Zmierz ponownie. Patrz konkretnie na metryki LCP, FCP, TBT, CLS. Każda z tych powinna spaść po każdym hacku z tego artykułu. Jeśli nie spadła, hack nie zadziałał (zwykle problem konfiguracyjny).
Czy 90+ utrzyma się długo po wdrożeniu?
Niestety nie. PageSpeed to dynamiczny pomiar, zmienia się gdy zmieniasz stronę. Typowa strona WordPress po profesjonalnej optymalizacji trzyma 90+ przez 4-6 tygodni, potem zaczyna spadać o 5-15 punktów przez nowe wtyczki, niezoptymalizowane zdjęcia w postach, dodatkowe skrypty śledzące. Co kwartał warto zrobić mini-audit i posprzątać co się zebrało.
Co zapamiętać
Sześć technik na szybszego WordPressa, łącznie 2-3 godziny pracy, spodziewany boost 20-40 punktów PageSpeed mobile dla typowej strony B2B.
- Cache headers + Brotli/gzip w
.htaccess - Optymalizacja zdjęć (kompresja + WebP + lazy loading)
- Audyt wtyczek, usuń 30%
font-display: swap+ preload kluczowych fontów- Krytyczny CSS + defer JavaScript
- Cleanup bazy danych
Zacznij od pomiaru. Wejdź na pagespeed.web.dev, wpisz swoją domenę, zrób screenshot wyniku. Potem hack po hacku, po każdym mierz różnicę. Jeśli po wszystkich sześciu nadal jesteś poniżej 80, zerknij na pre-check Speed Boost. 15 minut, bezpłatnie, wynik zielony lub czerwony bez ściemy.
Sprawdź swoją stronę za darmo →
Powodzenia z PageSpeed.
Autor: Jędrzej Siewierski, CEO JSON Crew. Od 2018 roku robimy z zespołem konfiguratory produktowe, aplikacje webowe i optymalizacje WordPress dla firm B2B w Polsce. Speed Boost jest naszą jednorazową usługą dla stron WP które tracą ruch przez wolne ładowanie.
