Jak przyspieszyć WordPressa? Optymalizacja krok po kroku

WordPress napędza większość stron internetowych w Polsce — i większość z nich działa wolniej, niż powinna. Dobra wiadomość: wolny WordPress to niemal zawsze suma kilku typowych zaniedbań, a nie wada samej platformy. W tym przewodniku przechodzimy przez pełną optymalizację krok po kroku: od diagnozy (co konkretnie spowalnia Twoją stronę), przez fundamenty (hosting, PHP, cache), po szczegóły, które oddzielają strony „szybkie” od „błyskawicznych”. Wszystko w kolejności od największego efektu przy najmniejszym wysiłku — tak, żebyś po pierwszej godzinie pracy widział różnicę, a po dniu miał stronę, której nie wstydzi się ani użytkownik, ani Google.

Dlaczego szybkość WordPressa to pieniądze, nie kosmetyka

Zanim przejdziemy do „jak”, krótko o „po co”. Wolna strona kosztuje Cię na trzech frontach jednocześnie. Po pierwsze, użytkownicy: badania konsekwentnie pokazują, że wraz z każdą sekundą ładowania rośnie odsetek porzuceń, a na urządzeniach mobilnych strona ładująca się ponad 3 sekundy traci znaczną część odwiedzających, zanim cokolwiek zobaczą. Po drugie, Google: wskaźniki Core Web Vitals — LCP, INP i CLS — są sygnałem rankingowym i bramką do dobrego indeksowania (szczegółowo rozłożyliśmy je w osobnym przewodniku po Core Web Vitals). Po trzecie, reklamy: wynik jakości w Google Ads uwzględnia jakość strony docelowej, więc wolny WordPress dosłownie podbija Ci stawki za kliknięcie.

Krok 0: Diagnoza — zmierz, zanim zaczniesz naprawiać

Optymalizacja bez pomiaru to błądzenie po omacku. Trzy narzędzia wystarczą:

• PageSpeed Insights — wpisz adres i zanotuj wyniki wyjściowe: LCP, INP, CLS z danych terenowych oraz punktację laboratoryjną z listą zaleceń. To Twój punkt odniesienia „przed”.
• GTmetrix lub WebPageTest — wykres wodospadowy (waterfall) pokaże, które zasoby ładują się najdłużej: konkretne obrazy, skrypty, zapytania do serwera.
• Query Monitor (wtyczka) — od środka pokaże wolne zapytania do bazy danych i wskaże wtyczki, które je generują.

Zwróć szczególną uwagę na TTFB (czas do pierwszego bajtu): jeśli przekracza 800 ms, Twój problem zaczyna się na serwerze i żadna wtyczka optymalizacyjna go nie rozwiąże. Jeśli TTFB jest niski, a strona i tak wolna — winowajcy siedzą we frontendzie: obrazach, skryptach i motywie.

Krok 1: Hosting — fundament, którego nie przeskoczysz

Zacznijmy od niewygodnej prawdy: najczęstszą przyczyną wolnego WordPressa w Polsce jest hosting za 80–150 zł rocznie, na którym strona dzieli zasoby z setkami innych. Objawy: TTFB ponad sekundę, losowe spowolnienia w godzinach szczytu, wolny panel administracyjny.

Na co patrzeć przy wyborze lub zmianie hostingu pod WordPressa:

• serwer LiteSpeed (lub nginx) — LiteSpeed w duecie z wtyczką LiteSpeed Cache to obecnie najlepszy stosunek efektu do ceny na polskim rynku,
• dyski NVMe — kilkukrotnie szybsze operacje niż na starych SSD, odczuwalne przy bazie danych,
• aktualne PHP z OPcache i wystarczającym limitem pamięci (min. 256 MB),
• HTTP/2 lub HTTP/3 — równoległe ładowanie zasobów,
• lokalizacja serwera — dla polskiego ruchu serwer w Polsce/Europie Środkowej to dziesiątki milisekund przewagi na każdym zapytaniu,
• realne limity — procesy PHP, pamięć, inode’y; „nielimitowany” transfer przy zduszonych procesach to marketing, nie parametr.

Dobry hosting współdzielony pod WordPressa kosztuje 300–600 zł rocznie. Ta różnica ceny — mniej niż złotówka dziennie — potrafi samodzielnie skrócić TTFB z 1200 do 300 ms. Żadna inna pojedyncza zmiana nie daje takiego skoku.

Krok 2: Wersja PHP — darmowe przyspieszenie w 5 minut

Każda główna wersja PHP jest szybsza od poprzedniej — przeskok ze starych wersji 7.x na aktualne 8.x daje typowo kilkadziesiąt procent szybszego wykonywania kodu, za darmo. Sprawdź w panelu hostingu (lub w WordPressie: Narzędzia → Zdrowie witryny), na jakiej wersji działasz, i podnieś ją do najnowszej wspieranej przez Twój motyw i wtyczki. Bezpieczna procedura: zrób kopię zapasową, przełącz wersję, przeklikaj stronę i panel; w razie błędów wróć do poprzedniej i zaktualizuj najpierw problematyczne wtyczki. Przy okazji upewnij się, że OPcache jest włączony — buforuje skompilowany kod PHP i znacząco odciąża serwer.

Krok 3: Cache — jedna dobra wtyczka zamiast trzech

Cache to mechanizm, dzięki któremu serwer nie buduje strony od zera przy każdej wizycie, tylko serwuje gotową, statyczną wersję. Efekt bywa spektakularny: strona generowana 1,5 sekundy potrafi wychodzić z cache w 100–200 ms.

• Na hostingu LiteSpeed: LiteSpeed Cache — darmowa, najgłębiej zintegrowana z serwerem, z optymalizacją obrazów i CSS w pakiecie. Wybór oczywisty.
• Na pozostałych: WP Rocket (płatny, ~250–400 zł/rok, najprzyjaźniejszy w konfiguracji) albo darmowe W3 Total Cache / WP Super Cache dla cierpliwych.

Kluczowe ustawienia niezależnie od wtyczki: cache stron dla niezalogowanych, kompresja GZIP/Brotli, cache przeglądarki (długie nagłówki wygasania dla obrazów, CSS, JS), wstępne generowanie cache (preload) po publikacji zmian. I żelazna zasada z naszych audytów: jedna wtyczka cache, nigdy dwie — duplikaty potrafią nawzajem unieważniać swoje bufory i spowalniać stronę bardziej, niż gdyby cache nie było wcale.

Krok 4: Obrazy — najwięcej zmarnowanych megabajtów

W typowym audycie obrazy odpowiadają za 50–70% wagi strony. Plan naprawczy:

• Format WebP/AVIF — o 25–50% lżejsze od JPG przy tej samej jakości; konwersję zrobi LiteSpeed Cache, ShortPixel, Imagify lub Converter for Media,
• wymiary pod wyświetlanie — zdjęcie 4000 px szerokości w kolumnie o szerokości 800 px to czterokrotnie zmarnowany transfer; wgrywaj przeskalowane pliki,
• kompresja stratna — poziom ~75–85% jest nieodróżnialny wizualnie, a tnie wagę o połowę,
• lazy loading — natywny w WordPressie; upewnij się tylko, że NIE obejmuje obrazu hero (głównego zdjęcia u góry) — to podręcznikowy błąd psujący LCP,
• wymiary w kodzie — atrybuty width/height zapobiegają skakaniu układu (CLS).

Masowa optymalizacja istniejącej biblioteki mediów jednym kliknięciem wtyczki potrafi odchudzić serwis o setki megabajtów.

Krok 5: Motyw i builder — ile kosztuje wygoda

Motywy-kombajny i page buildery (Elementor, Divi, WPBakery) kupują wygodę edycji ceną dziesiątek plików CSS/JS i rozdmuchanego kodu HTML. Nie namawiamy do panicznej przesiadki — ale przy okazji redesignu wybór lekkiego fundamentu (GeneratePress, Kadence, Astra, bloki Gutenberga) potrafi zdjąć ze strony 1–2 sekundy. Jeśli zostajesz przy builderze: używaj jego wbudowanych opcji wydajności (Elementor ma m.in. ładowanie warunkowe), ogranicz liczbę widgetów na stronie, unikaj zagnieżdżania sekcji w sekcjach i nie instaluj pięciu dodatków z „ekstra elementami”, z których używasz dwóch.

Krok 6: Wtyczki — audyt szczerości

Nie liczba wtyczek zabija stronę, lecz ich jakość — jedna źle napisana potrafi kosztować więcej niż dwadzieścia porządnych. Zrób przegląd: usuń (nie tylko dezaktywuj) nieużywane; znajdź duplikaty funkcji (dwie wtyczki SEO, dwa buildery, trzy od bezpieczeństwa); sprawdź Query Monitorem, które generują najwolniejsze zapytania; zastąp kombajny lżejszymi odpowiednikami (np. ciężkie wtyczki statystyk — zwykłym Google Analytics). Szczególni podejrzani: wtyczki „related posts” liczące powiązania na żywo, słabe wtyczki bezpieczeństwa skanujące wszystko przy każdym wejściu oraz stare wtyczki nieaktualizowane od lat.

Krok 7: Baza danych — sprzątanie po latach

Baza WordPressa z czasem obrasta: dziesiątki rewizji każdego wpisu, transienty, kosz, spam, tabele po dawno usuniętych wtyczkach. Porządki (WP-Optimize, Advanced Database Cleaner lub moduł w LiteSpeed Cache): ogranicz liczbę przechowywanych rewizji (define(’WP_POST_REVISIONS’, 5) w wp-config.php), usuń stare transienty i śmieci, przejrzyj tabele osieroconych wtyczek. Przy sklepach WooCommerce dochodzi pilnowanie tabel sesji i logów. Efekt rzadko bywa spektakularny na froncie, ale panel administracyjny i wyszukiwanie potrafią wyraźnie odżyć — a kopia zapasowa robi się szybciej i taniej.

Krok 8: CSS, JavaScript i fonty — walka o milisekundy, które widać

• minifikacja i łączenie — wtyczka cache zminifikuje CSS/JS; łączenie plików stosuj ostrożnie (przy HTTP/2 nie zawsze pomaga),
• defer dla JavaScriptu — skrypty nieblokujące renderowania to lepszy LCP i INP,
• usuwanie nieużywanego CSS — funkcje typu „Generate critical CSS”/„Remove unused CSS” w WP Rocket i LiteSpeed Cache potrafią zdjąć setki kilobajtów stylów buildera,
• opóźnione ładowanie skryptów firm trzecich — czaty, mapy, piksele marketingowe ładuj po interakcji użytkownika lub z opóźnieniem; to często największy pojedynczy zysk dla INP,
• fonty lokalnie — Google Fonts hostowane u siebie (np. wtyczką OMGF), z font-display: swap i preloadem głównego kroju; mniej połączeń zewnętrznych, zero przeskoków tekstu.

Krok 9: CDN — kiedy ma sens

CDN (Content Delivery Network) serwuje statyczne zasoby z serwera najbliższego użytkownikowi. Dla strony obsługującej wyłącznie ruch z Polski, hostowanej w Polsce, zysk bywa umiarkowany — ale darmowy plan Cloudflare i tak warto rozważyć dla dodatkowej warstwy cache, kompresji i ochrony przed atakami. Przy ruchu międzynarodowym lub sklepie z ambicjami zagranicznymi CDN przestaje być opcją, a staje się standardem. Uwaga na konfigurację: podwójny cache (CDN + wtyczka) wymaga poprawnego czyszczenia przy publikacji zmian, inaczej klienci zobaczą stare wersje stron.

Zaawansowane techniki — gdy podstawy już działają

• Object cache (Redis/Memcached) — buforuje wyniki zapytań do bazy; duży zysk dla sklepów i serwisów z zalogowanymi użytkownikami, gdzie cache stron nie działa w pełni,
• wyłączenie nieużywanych funkcji WP — emoji, oEmbed, XML-RPC, dashicons na froncie — drobiazgi, które sumują się w zapytania,
• ograniczenie Heartbeat API — częste odpytywanie serwera przez panel potrafi zjadać zasoby,
• preload i preconnect — wskazówki dla przeglądarki, co ładować w pierwszej kolejności (obraz hero, kluczowy font, domena analityki),
• cache fragmentów (ESI) — na LiteSpeed pozwala cache’ować strony z dynamicznymi elementami (koszyk!) — kluczowe dla WooCommerce,
• monitoring uptime i wydajności — darmowy UptimeRobot plus cykliczny test szybkości wychwycą regres po aktualizacjach.

WooCommerce — dodatkowa lista dla sklepów

Sklep to WordPress na sterydach obciążenia: koszyk wyłącza cache, sesje mnożą zapytania, a katalog produktów rozdyma bazę. Poza wszystkim powyżej: włącz cache z wykluczeniem koszyka/checkoutu (lub ESI na LiteSpeed), pilnuj liczby wariantów ładowanych na listach, ogranicz widgety „ostatnio oglądane” liczące na żywo, regularnie czyść sesje wygasłe i tabele logów, a fragmenty koszyka (cart fragments AJAX) wyłącz na stronach, gdzie koszyk nie występuje. Przy kilkuset+ produktach rozważ object cache jako standard, nie opcję. I mierz na kartach produktów oraz w checkoutcie — to tam decydują się pieniądze, nie na stronie głównej.

Czego nie robić — antyporadnik

• nie instaluj kilku wtyczek optymalizacyjnych „na zapas” — konflikty cache i podwójna minifikacja to klasyka zepsutych stron,
• nie włączaj wszystkich opcji wtyczki naraz — agresywna optymalizacja JS potrafi wysypać slidery i formularze; włączaj funkcję po funkcji z testem,
• nie optymalizuj bez kopii zapasowej,
• nie goń za 100/100 w Lighthouse — po przekroczeniu zielonych progów CWV dalsze punkty nie przekładają się na nic mierzalnego,
• nie ufaj jednemu pomiarowi — testuj kilka podstron, o różnych porach, na mobile,
• nie zapominaj o panelu — wolny wp-admin to często pierwszy sygnał problemów z hostingiem lub wtyczką.

Ile kosztuje przyspieszenie WordPressa

Samodzielnie: lepszy hosting (300–600 zł/rok) plus ewentualnie WP Rocket (~300 zł/rok) i kilka wieczorów pracy według tego przewodnika. U specjalisty: jednorazowa optymalizacja strony firmowej to zwykle 500–2000 zł, sklepu — 1500–5000 zł, zależnie od skali problemów. Zwrot bywa szybki i mierzalny: więcej konwersji z istniejącego ruchu, tańsze kliknięcia w Google Ads, lepsze zachowanie strony w wynikach wyszukiwania. Jeśli wolisz oddać temat w ręce zespołu, który robi to na co dzień — napisz do nas; optymalizacja szybkości to stały element naszych wdrożeń i audytów SEO.

Plan godzinowy: przyspieszenie WordPressa w jeden dzień

Dla porządku — cała procedura ułożona w realny harmonogram jednego dnia pracy:

• 9:00–9:30 — pomiar wyjściowy i kopia. PageSpeed Insights dla 3 kluczowych podstron (zapisz wyniki!), pełny backup plików i bazy.
• 9:30–10:30 — fundamenty serwera. Podniesienie PHP do 8.x, weryfikacja OPcache, ewentualna decyzja o migracji hostingu (samą migrację można zlecić — dobre hostingi przenoszą za darmo).
• 10:30–12:00 — cache. Instalacja i konfiguracja jednej wtyczki cache: cache stron, kompresja, cache przeglądarki, preload. Test strony po każdej włączonej opcji.
• 12:00–14:00 — obrazy. Masowa konwersja biblioteki do WebP, kompresja, kontrola obrazu hero (bez lazy loadingu, z preloadem).
• 14:00–15:30 — skrypty i wtyczki. Audyt listy wtyczek (usuwanie, zamiany), defer dla JS, opóźnienie czatu i pikseli, fonty lokalnie.
• 15:30–16:00 — baza danych. Czyszczenie rewizji, transientów, kosza; limit rewizji w wp-config.php.
• 16:00–16:30 — pomiar końcowy. Te same 3 podstrony, porównanie z rana; notatka, co jeszcze zostało (CDN? object cache?) na kolejną iterację.

Realistyczne oczekiwania po takim dniu: LCP niżej o 40–60%, waga strony mniejsza o połowę, wynik Lighthouse wyżej o 20–40 punktów. Resztę — potwierdzenie w danych terenowych — przyniesie 28-dniowe okno CrUX.

Najszybsze motywy WordPress — co wybrać przy redesignie

Pytanie o „najszybszy motyw” wraca przy każdej przebudowie. Czołówka od lat jest stabilna: GeneratePress (ok. 30 KB wagi bazowej, świetny kod), Kadence (bogatszy wizualnie, wciąż lekki), Astra (największa popularność i ekosystem), Blocksy (nowoczesny, szybki) oraz budowanie bezpośrednio na blokach Gutenberga z motywem typu Twenty Twenty-Five dla purystów. Wszystkie te motywy w czystej instalacji osiągają wyniki Lighthouse w okolicach 95–100 punktów — różnice robią dopiero dodatki, które na nie nałożysz. Praktyczna rada: zamiast szukać „naj” w rankingach, wybierz dowolny z wymienionych i pilnuj dyscypliny dodatków — to ona decyduje o końcowym wyniku. I odwrotnie: jeśli Twój obecny motyw-kombajn działa, a strona po optymalizacji spełnia progi CWV, przesiadka „dla zasady” nie jest warta ryzyka i kosztów.

Wolny panel administracyjny — osobny przypadek

Częsty scenariusz: strona dla odwiedzających działa znośnie (ratuje ją cache), ale praca w wp-admin to męczarnia. Cache stron tu nie pomaga — panel zawsze generuje się dynamicznie. Sprawdź kolejno: wersję PHP i limit pamięci (panel lubi 256 MB+), wtyczki dashboardu (widgety statystyk, buildery ładujące zasoby wszędzie), Heartbeat API (ogranicz częstotliwość), liczbę rewizji i rozmiar bazy (wielka tabela options z autoload potrafi dusić każde wejście — Query Monitor pokaże jej wagę), a przy WooCommerce — tabele sesji i logów. Jeśli panel muli tylko o określonych porach, to niemal na pewno przeciążony hosting współdzielony: sąsiedzi zjadają zasoby. Wolny panel to nie „uroda WordPressa”, tylko objaw — i cenny sygnał diagnostyczny.

Studium przypadku: strona usługowa z 5,9 s do 1,6 s

Konkretny przebieg z naszej praktyki — strona firmy instalacyjnej: motyw z ciężkim builderem, 43 wtyczki, hosting „z pakietu z domeną”, LCP 5,9 s na mobile, pozycje w stagnacji mimo dobrych treści.

• Dzień 1: migracja na hosting LiteSpeed (TTFB: 1420 → 310 ms), PHP 7.4 → 8.2, LiteSpeed Cache skonfigurowany z preloadem. LCP spadł do 3,4 s.
• Dzień 2: konwersja 1100 obrazów do WebP (biblioteka: 780 → 240 MB), poprawka hero (preload, bez lazy), usunięcie 14 wtyczek, defer JS, czat ładowany po interakcji. LCP: 2,1 s, INP: 380 → 190 ms.
• Dzień 3 (dwie godziny): fonty lokalnie, czyszczenie bazy (2,1 GB → 340 MB — głównie stare rewizje i transienty po wtyczkach), wymiary obrazów w sekcjach buildera (CLS: 0,24 → 0,05). Finalnie LCP 1,6 s.

Wynik biznesowy po dwóch miesiącach: czas na stronie z organika wyższy o jedną czwartą, współczynnik konwersji formularza z 2,1% na 3,4%, a koszt kliknięcia w prowadzonej równolegle kampanii Google Ads spadł o kilkanaście procent dzięki lepszemu wynikowi jakości. Koszt całej operacji: 600 zł rocznie drożej za hosting plus ok. 12 godzin pracy. To dlatego optymalizację szybkości traktujemy jako pierwszy krok każdej współpracy — zanim zaczniemy budować nowe treści, upewniamy się, że istniejące mają na czym stać.

Utrzymanie tempa — jak nie wrócić do punktu wyjścia

Strona zoptymalizowana raz nie pozostaje szybka sama z siebie — degradację przynoszą kolejne wtyczki, wgrywane bez kompresji obrazy i aktualizacje motywu. Wpisz w kalendarz kwartalny rytuał (30 minut): test PageSpeed trzech kluczowych podstron i porównanie z notatkami, przegląd nowych wtyczek z pytaniem „czy nadal potrzebne”, kontrola wagi ostatnio dodanych podstron, rzut oka na raport CWV w Search Console. Do tego dwie reguły zespołowe: każdy nowy obraz przechodzi przez kompresję przed wgraniem, a każda nowa wtyczka ma uzasadnienie i datę przeglądu. Taki reżim kosztuje dwie godziny rocznie i oszczędza wielogodzinne „akcje ratunkowe” co dwa lata.

Optymalizacja a bezpieczeństwo i SEO — trzy prace, jeden fundament

Warto połączyć optymalizację szybkości z dwiema sąsiednimi pracami, bo wykonuje się je tymi samymi rękami i w tym samym miejscu. Po pierwsze, bezpieczeństwo: aktualizacje PHP i porządek we wtyczkach to jednocześnie największe kroki przeciwwłamaniowe (statystycznie to właśnie stare wtyczki są bramą większości ataków na WordPressa); przy okazji migracji hostingu skonfiguruj automatyczne kopie zapasowe poza serwerem. Po drugie, technikalia SEO: skoro już przeglądasz stronę od zaplecza, sprawdź poprawność canonicali, mapę XML, przekierowania wariantów domeny i indeksowanie — czyli punkty z naszej checklisty audytu SEO. Szybkość, bezpieczeństwo i technika SEO to trzy ściany tego samego fundamentu — remontowane razem kosztują mniej niż osobno.

Kiedy optymalizacja nie wystarczy — sygnały, że czas na nową stronę

Uczciwie: bywa, że lepiej zbudować od nowa, niż optymalizować. Sygnały ostrzegawcze: motyw i builder porzucone przez autorów (brak aktualizacji od 2+ lat), strona sklejona z trzech różnych builderów po kolejnych „poprawkach”, krytyczne funkcje zależne od martwych wtyczek, brak wersji mobilnej z prawdziwego zdarzenia albo koszt doprowadzenia do zieleni CWV przekraczający koszt nowego wdrożenia. W takiej sytuacji rachunek jest prosty: nowa, lekka strona na sprawdzonym fundamencie (z przekierowaniami 301 chroniącymi SEO) zwróci się szybciej niż reanimacja. Jeśli nie masz pewności, po której stronie granicy jest Twój przypadek — pomagamy podjąć tę decyzję na podstawie audytu, nie przeczucia.

Ściąga: 15 szybkich zwycięstw do odhaczenia

• 1. PHP 8.x + OPcache włączony
• 2. TTFB poniżej 600 ms (jeśli nie — hosting)
• 3. Jedna wtyczka cache, poprawnie skonfigurowana
• 4. Kompresja Brotli/GZIP aktywna
• 5. Obrazy w WebP, skompresowane, we właściwych wymiarach
• 6. Obraz hero: preload, bez lazy loadingu
• 7. Lazy loading dla reszty mediów
• 8. Defer dla JavaScriptu
• 9. Czat/piksele ładowane z opóźnieniem lub po interakcji
• 10. Fonty lokalnie z font-display: swap
• 11. Wtyczki: zero nieużywanych, zero duplikatów funkcji
• 12. Rewizje ograniczone, baza wyczyszczona
• 13. Wymiary width/height przy obrazach (CLS)
• 14. Cloudflare lub inny CDN rozważony świadomie
• 15. Pomiar zapisany przed i po — i data następnego przeglądu w kalendarzu

Piętnaście kresek na tej liście to w praktyce strona szybsza od 90% konkurencji — bo większość nie zrobi nigdy nawet pierwszych pięciu.

FAQ

Dlaczego mój WordPress działa wolno?

Najczęstsze przyczyny, w kolejności: słaby hosting (TTFB ponad 800 ms), brak cache, nieoptymalizowane obrazy, przeładowany motyw lub builder, nadmiar wtyczek i skryptów zewnętrznych oraz stara wersja PHP. Diagnozę zacznij od PageSpeed Insights i sprawdzenia TTFB — to rozstrzyga, czy problem leży na serwerze, czy we frontendzie.

Jaka wtyczka najlepiej przyspiesza WordPressa?

Na hostingu z serwerem LiteSpeed — darmowa LiteSpeed Cache (cache, optymalizacja obrazów, CSS i bazy w jednym). Na pozostałych serwerach najwygodniejszy jest płatny WP Rocket, a darmową alternatywą W3 Total Cache. Kluczowa zasada: jedna wtyczka cache — nigdy dwie równolegle.

Czy zmiana hostingu naprawdę przyspiesza stronę?

To zwykle największa pojedyncza poprawa: przejście z przeciążonego hostingu współdzielonego na solidny serwer z LiteSpeed i NVMe potrafi skrócić TTFB z ponad sekundy do 300–400 ms, co bezpośrednio poprawia LCP każdej podstrony. Żadna wtyczka nie nadrobi wolnego serwera.

Jak zoptymalizować obrazy w WordPressie?

Trzy działania: konwersja do formatu WebP (wtyczką — LiteSpeed Cache, ShortPixel, Converter for Media), wgrywanie plików w wymiarach zbliżonych do wyświetlanych oraz kompresja stratna na poziomie ~80%. Lazy loading zostaw włączony, ale wyklucz z niego główny obraz u góry strony — inaczej pogorszysz LCP.

Czy dużo wtyczek spowalnia WordPressa?

Liczy się jakość, nie liczba: 30 lekkich wtyczek może być szybsze niż 5 ciężkich. Realnie spowalniają: wtyczki generujące wolne zapytania do bazy, ładujące skrypty na każdej podstronie i duplikujące funkcje. Audyt Query Monitorem wskaże winowajców po nazwie.

Po jakim czasie zobaczę efekty w Google?

Efekt dla użytkowników jest natychmiastowy. Dane terenowe Core Web Vitals (CrUX), na które patrzy Google, odświeżają się w oknie 28-dniowym — pełne potwierdzenie poprawy w Search Console zobaczysz więc po ok. miesiącu. Ewentualne korzyści rankingowe przychodzą stopniowo w kolejnych tygodniach.

« wróć na bloga