Dlaczego Core Web Vitals i wydajność WordPressa są dziś kluczowe
Core Web Vitals po ludzku: LCP, CLS, INP
Core Web Vitals to trzy wskaźniki, które mówią, czy strona „czuje się” szybka i stabilna dla użytkownika. Nie są to abstrakcyjne techniczne parametry – każdy z nich odpowiada za realne odczucie wygody korzystania ze strony.
LCP (Largest Contentful Paint) mierzy, jak szybko ładuje się największy, główny element widoczny w oknie przeglądarki – zwykle jest to duży obraz, slider, sekcja hero lub duży nagłówek. Słaby LCP oznacza, że użytkownik długo czeka na „konkretną” treść, choć może już widzieć pasek ładowania czy szkielet strony.
CLS (Cumulative Layout Shift) mówi, jak bardzo „skacze” układ strony podczas ładowania. To te irytujące sytuacje, gdy chcesz kliknąć przycisk, a tu nagle wczytuje się reklama albo obraz, wszystko się przesuwa i klikasz coś innego. W WordPressie winne są często źle wstawione obrazki, dynamiczne bannery, zewnętrzne widgety i fonty.
INP (Interaction to Next Paint) zastąpił FID. Mierzy, jak szybko strona reaguje na akcje użytkownika – kliknięcia, wprowadzanie tekstu, gesty. W praktyce: czy po kliknięciu przycisku „Dodaj do koszyka” strona natychmiast reaguje, czy przez sekundę „myśli”. Na INP mocno wpływają ciężkie skrypty JS, page buildery i złożone wtyczki WooCommerce, analityka ładowana synchronicznie, rozbudowane menu i pop‑upy.
Wolny WordPress a SEO, konwersje i doświadczenie użytkownika
Wydajność strony opartej na WordPressie nie jest tylko „technikalią”. Bezpośrednio przekłada się na:
pozycje w Google – Core Web Vitals to element sygnału Page Experience; słabe wyniki mogą obniżać widoczność, zwłaszcza w konkurencyjnych branżach, gdzie wiele stron ma podobną jakość treści i linków,
konwersje – im dłużej ładuje się strona, tym więcej użytkowników rezygnuje przed zakupem czy wysłaniem formularza; szczególnie boleśnie widać to na mobile,
współczynnik odrzuceń – użytkownicy przyzwyczajeni do natychmiastowych reakcji aplikacji mobilnych nie czekają 5–8 sekund, aż WordPress „się namyśli”.
Przy słabej wydajności WordPressa dzieją się trzy rzeczy naraz: rosną koszty (więcej ruchu płatnego, żeby osiągnąć ten sam efekt), spadają przychody (mniej konwersji z ruchu organicznego i płatnego), a użytkownicy budują skojarzenie „ta marka = męcząca, wolna strona”.
Elastyczność WordPressa kontra „spuchnięte” strony
WordPress daje mnóstwo swobody: motywy, buildery, setki tysięcy wtyczek. Ta elastyczność ma jednak skutki uboczne. Najczęstszy scenariusz:
do tego kilka pakietów dodatków (addonsów) do buildera,
kilkanaście wtyczek „od wszystkiego”: popupy, social media, formularze, galerie,
hosting z dolnej półki, bez sensownego cache i szybkiego dysku.
Efekt: każdy element frontendu korzysta z własnych CSS i JS. Strona ładuje dziesiątki plików, często z duplikującą się funkcjonalnością (np. trzy różne biblioteki sliderów). Do tego dochodzą źle skompresowane obrazy, webfonty z kilkunastoma wariantami grubości, brak cache – i wyniki Core Web Vitals lecą w dół.
Praktyczny przykład: sklep WooCommerce przed i po optymalizacji
Typowy przypadek z praktyki: niewielki sklep WooCommerce na WordPressie, postawiony na motywie premium z wbudowanym builderem. Strona główna ma spory slider, kilka sekcji „bestsellery”, blog poniżej. Właściciel narzeka, że reklamy Google Ads słabo działają, a wyniki w Search Console pokazują „Słabe URL-e z powodu CWV”.
Po testach PageSpeed Insights i WebPageTest wychodzą problemy: LCP powyżej 4 s na mobile, wysoki CLS przez doskakujące banery i obrazki bez wymiarów, INP słaby, bo skrypty JS z buildera i kilku wtyczek do popupów blokują interakcje. Dodatkowo TTFB jest bardzo wysoki – hosting ledwo zipie.
Po przenosinach na lepszy serwer, włączeniu sensownej wtyczki cache, kompresji obrazów, odchudzeniu buildera (wyłączenie zbędnych widgetów) i wyrzuceniu dwóch ciężkich wtyczek popupów (zastąpionych lżejszym rozwiązaniem) LCP spada poniżej 2,5 s, CLS wraca do zielonej strefy, a INP poprawia się dzięki opóźnieniu ładowania części skryptów. Z tego samego ruchu sklep generuje znacznie więcej transakcji.
Co sprawdzić na start: szybki test PageSpeed i WebPageTest
Krok 1: uruchom PageSpeed Insights, wpisz adres strony głównej i jednego ważnego podstrony (np. produkt lub oferta). Zwróć uwagę na:
kolor wskaźników LCP, CLS, INP dla mobile i desktopu,
czas TTFB / „czas do pierwszego bajtu” (sekcja „Diagnostyka”),
wielkość transferu (obrazki, JS, CSS),
sekcje „Zwiększ wydajność obrazu”, „Usuń nieużywany kod JavaScript/CSS”.
Krok 2: uruchom WebPageTest (lub GTmetrix) z lokalizacją zbliżoną do twoich użytkowników, wybierz przeglądarkę mobilną i przetestuj stronę co najmniej 3 razy. Patrz przede wszystkim na:
TTFB – jeśli jest wysoki, to często wąskie gardło serwera,
„Fully Loaded Time” oraz „Largest Contentful Paint”,
liczbę zapytań (requests) i ogólny rozmiar strony (Total size).
Co sprawdzić: zanotuj (lub zrób zrzuty ekranu) wartości LCP, CLS, INP, TTFB oraz całkowity rozmiar strony – będą referencją po optymalizacji.
Jak prawidłowo diagnozować problemy wydajności w WordPressie
Pierwsza diagnoza to zawsze spojrzenie z zewnątrz. Najszybciej da się wyłapać, czy problem dotyczy frontendu (duże pliki, obrazy, CSS, JS), czy backendu (wydłużony czas generowania strony przez PHP i bazę danych).
Skuteczny schemat:
PageSpeed Insights – podstawowy test CWV, metryki polowe (jeśli strona ma ruch), rekomendacje optymalizacyjne.
czy LCP jest powyżej 2,5 s (zielona strefa), 4 s (pomarańczowa), czy jeszcze gorzej,
czy CLS przekracza 0,1 (wysokie przeskoki układu),
czy INP jest wyraźnie powyżej 200–300 ms (strona reaguje ospale),
czy TTFB przekracza 600–800 ms – jeśli tak, często problem leży w hostingu/serwerze lub ciężkim PHP,
ile jest zapytań (requests) i ilu z nich można uniknąć (niepotrzebne zewnętrzne skrypty, fonty, wtyczki).
Krok 2: Chrome DevTools – Performance i Network
Drugi krok to narzędzia wbudowane w przeglądarkę. Chrome DevTools pozwala podejrzeć, co realnie dzieje się podczas ładowania strony z perspektywy użytkownika.
Podstawowe działania:
otwórz stronę w Chrome,
CTRL+SHIFT+I (lub F12) → zakładka Network,
włącz „Disable cache”, odśwież stronę (CTRL+R),
posortuj zasoby po „Time” i „Size” – zobacz, które pliki są największe i ładują się najdłużej.
W zakładce Performance nagraj profil ładowania (Record → odśwież stronę → Stop). Interesują cię głównie:
czy JavaScript długo blokuje wątek główny (długie niebieskie/pomarańczowe bloki),
czy pierwsze renderowanie jest mocno opóźnione (First paint, First contentful paint),
czy widoczne są powtarzające się, ciężkie eventy (np. skrypty sliderów, animacje).
Jeżeli w zakładce Network widzisz jeden lub kilka plików JS/CSS, które dominują czas i rozmiar, to masz trop: strona jest przeładowana kodem – zwykle przez motyw, builder lub wtyczki.
Krok 3: Wtyczki i narzędzia serwerowe – Query Monitor, New Relic, logi
Jeśli TTFB jest wysoki, a nawet pusta strona generuje się powoli, trzeba zejść poziom niżej – do backendu.
Podstawowe narzędzia:
Query Monitor – wtyczka WordPress do analizy zapytań do bazy, czasu generowania strony, hooków i błędów PHP,
New Relic (lub podobne APM) – jeśli hosting daje dostęp, pozwala śledzić, które funkcje i wtyczki zużywają najwięcej zasobów,
Wejdź na stronę, która ładuje się wolno (np. produkt, archiwum kategorii).
Na górnej belce admina zobaczysz informację o czasie generowania, liczbie zapytań i użytej pamięci.
Kliknij Query Monitor i przejdź przez zakładki:
Queries – które zapytania są najwolniejsze,
Hooks – które akcje/filtery długo się wykonują,
HTTP API Calls – czy w czasie ładowania strona nie robi zewnętrznych zapytań (API, licencje wtyczek).
Jak odróżnić problemy frontendu od backendu
Przyspieszenie WordPressa idzie najsprawniej, gdy wiadomo, gdzie jest największy problem. Najprostsza reguła:
jeśli TTFB jest wysoki, a potem strona ładuje się w miarę szybko – wina po stronie backendu (hosting, PHP, baza, wtyczki wykonujące ciężkie operacje),
jeśli TTFB jest akceptowalny, ale całość trwa długo – problem leży głównie po stronie frontendu (za dużo JS, CSS, obrazów, zewnętrzne skrypty).
Dobry test to stworzenie prostego szablonu (np. plik page-szybki.php z minimalnym HTML, bez sidebarów, sliderów, buildera) i ustawienie go jako szablon konkretnej strony. Jeśli taki „goły” widok ładuje się błyskawicznie, to problem jest w motywie/builderze/wtyczkach frontendowych. Jeśli i tak jest wolno – trzeba przyjrzeć się serwerowi i logice PHP.
Co sprawdzić w diagnozie – pięć kluczowych metryk
Na etapie diagnostyki zapisz:
TTFB (czas do pierwszego bajtu) – z WebPageTest/DevTools,
LCP – z PageSpeed Insights i Lighthouse,
CLS – z PageSpeed Insights,
INP – z PageSpeed Insights (i ewentualnie CrUX, jeśli masz dane polowe),
liczbę zapytań i rozmiar strony – z GTmetrix/WebPageTest/DevTools.
Co sprawdzić: upewnij się, że masz wyniki dla mobile i desktopu, oraz że testowałeś:
stronę główną,
typową stronę treściową (np. wpis na blogu),
kluczową stronę biznesową (produkt, oferta, koszyk/kasa).
Źródło: Pexels | Autor: Markus Winkler
Błąd 1 – Zły lub zbyt słaby hosting pod WordPressa
Jak wyglądają typowe problemy taniego hostingu
Nawet najlepiej zoptymalizowany motyw i wtyczki nie nadrobią braków po stronie serwera. Tani hosting współdzielony ma często kilka poważnych wad:
wolne dyski (brak SSD/NVMe) – wszystko, co dotyczy bazy danych i plików, działa ospale,
brak cache na poziomie serwera – brak wbudowanego cache LiteSpeed/NGINX, brak obiektowego cache,
przeciążone serwery – zbyt wiele kont na jednej maszynie, co skutkuje losowymi „pikami” TTFB i spadkami wydajności w godzinach szczytu,
agresywne limity (CPU, RAM, I/O, liczba procesów) – przy większym ruchu strona dostaje „zadyszki”, pojawiają się 503/508 lub czas odpowiedzi rośnie kilkukrotnie,
stare wersje PHP i MySQL – brak wsparcia dla nowszych technologii oraz realnie wolniejsze wykonywanie skryptów.
Efekt w praktyce: LCP i INP skaczą bez wyraźnego powodu, a testy z różnych godzin dnia pokazują zupełnie inne wyniki. Zdarza się też, że panel hostingu wygląda nowocześnie, ale pod spodem wciąż działa przestarzała infrastruktura – różnicę widać dopiero po przejściu na lepszego dostawcę.
Jak rozpoznać, że to hosting jest wąskim gardłem
Krok 1: porównaj TTFB dla statycznego pliku (np. mały .html wrzucony do katalogu głównego) i dla strony WordPressa. Jeśli statyczny plik ma TTFB znacznie powyżej 300–400 ms, to serwer sam w sobie reaguje wolno. Jeśli statyczny plik jest szybki, a WordPress wolny – problemem jest aplikacja (motyw/wtyczki/baza).
Krok 2: uruchom proste testy obciążeniowe (np. loader.io, k6) lub wykorzystaj wbudowane narzędzia hostingu, jeśli są. Przy kilkunastu–kilkudziesięciu równoczesnych żądaniach słaby hosting zacznie szybko zwiększać czas odpowiedzi albo zwracać błędy 5xx. To sygnał, że skala zasobów jest niewystarczająca, zwłaszcza dla sklepu czy strony z kampanią reklamową.
Krok 3: sprawdź wersje oprogramowania: PHP (co najmniej 8.0+), typ bazy (MariaDB/MySQL w aktualnych wydaniach), typ serwera HTTP (Apache, LiteSpeed, NGINX). Hosting, który latami trzyma stare wersje i nie daje możliwości łatwej zmiany, będzie ograniczeniem przy każdej poważniejszej optymalizacji.
Co sprawdzić: zanotuj TTFB dla statycznego pliku i strony WordPress, stabilność czasu odpowiedzi przy kilku powtórzeniach testu oraz dostępne wersje PHP/MySQL w panelu hostingu.
Jak wybrać lepszy hosting pod WordPressa
Przy wyborze hostingu warto iść konkretnymi krokami, zamiast kierować się wyłącznie ceną lub „nielimitowanym transferem”.
Krok 1: szukaj hostingu z dyskami SSD/NVMe, cache na poziomie serwera (LiteSpeed Cache, NGINX microcache, Redis/Memcached) oraz jasnymi limitami zasobów (CPU, RAM, I/O).
Krok 2: sprawdź, czy dostawca ma lokalizację serwera blisko twoich użytkowników (np. DC w Polsce lub UE, jeśli masz ruch z Polski). Krótszy dystans to niższy RTT, a więc lepszy TTFB.
Krok 3: upewnij się, że hosting pozwala szybko przełączać wersje PHP, ma automatyczne kopie zapasowe oraz sensowne limity skrzynek e‑mail, procesów i baz danych.
Krok 4: przetestuj wersję trial lub miesięczny plan – wrzuć kopię strony, zrób testy PageSpeed/WebPageTest i porównaj z aktualnym serwerem.
Dla WordPressa zwykle najlepiej sprawdzają się: pół‑dedykowane plany współdzielone o wyższych parametrach, serwery VPS z zarządzaniem (dla większych projektów) albo specjalistyczne hostingi „managed WordPress”, które mają sensownie skonfigurowany cache i PHP-FPM.
Co sprawdzić: porównaj wyniki CWV (zwłaszcza LCP i TTFB) przed i po migracji testowej, oceń stabilność podczas ruchu oraz jakość wsparcia technicznego w sytuacjach awaryjnych.
Przy migracji unikaj chaotycznych działań. Krok 1: zrób pełną kopię zapasową (plików i bazy) i przetestuj przywracanie, najlepiej na środowisku testowym. Krok 2: przeprowadź przenosiny w godzinach najmniejszego ruchu, włącz tryb konserwacji i pilnuj, żeby DNS był przełączany dopiero po pozytywnym teście na nowym serwerze. Krok 3: po migracji wyczyść cache (na serwerze, w WordPressie i w CDN), odśwież permalinki i przeprowadź komplet testów wydajności oraz funkcjonalności (logowanie, zamówienia, formularze).
Częsty błąd przy zmianie hostingu to „wrzucenie” strony na nowy serwer bez dopasowania konfiguracji: brak włączonego opcache, niewykorzystany Redis/Memcached, PHP ustawione na domyślne, ale wolniejsze parametry. W efekcie płaci się za lepszą infrastrukturę, a realny zysk jest znikomy. Dobrze jest przejść przez checklistę optymalizacji: właściwa wersja PHP, włączone cache na poziomie serwera, poprawnie skonfigurowany WordPress i przetestowane CWV.
Jeśli po stronie hostingu wszystko jest ustawione poprawnie, a mimo to wyniki nadal są niezadowalające, strzałka winy przesuwa się na motyw, builder, wtyczki i konfigurację cache po stronie aplikacji. Solidny serwer daje wtedy „czyste tło” – masz pewność, że kolejne kroki optymalizacji nie rozbijają się o ograniczenia infrastruktury, tylko realnie poprawiają Core Web Vitals.
Dobrze dobrany hosting zdejmuje z barków sporą część technicznych problemów: stabilizuje TTFB, ułatwia konfigurację cache i zapewnia przewidywalność pod obciążeniem. Reszta pracy to już kwestia ustawienia WordPressa, motywu, wtyczek i frontendu tak, żeby całość wykorzystała potencjał serwera zamiast go marnować.
Błąd 2 – Przeładowany motyw i ciężki builder stron
Skąd się bierze „spuchnięty” motyw
Nowoczesne motywy i buildery kuszą gotowymi szablonami, animacjami i „robiącym wrażenie” designem. Technicznie jednak często oznacza to:
setki kilobajtów CSS i JS ładowanych na każdej podstronie, niezależnie od tego, czy dana funkcja jest używana,
dziesiątki requestów do plików motywu, child-theme i buildera,
duże biblioteki JS (np. jQuery UI, animacje, sliderowe frameworki) dorzucane „na wszelki wypadek”,
globalne style inline generowane przez builder na każdej podstronie,
ładowanie fontów i ikon zewnętrznie (np. Google Fonts, Font Awesome CDN) bez kontroli nad ich zakresem.
W praktyce LCP cierpi, bo przeglądarka musi wczytać i przeanalizować masę plików, zanim pokaże główny element strony. INP potrafi rosnąć, gdy ciężki JS buildera blokuje interakcje tuż po załadowaniu.
Jak rozpoznać, że motyw i builder są głównym problemem
Krok 1: przeanalizuj liczbę i rozmiar plików CSS/JS w DevTools lub GTmetrix. Jeśli:
<liłączny rozmiar JS idzie w setki kilobajtów lub megabajt,
masz wiele plików typu theme.css, global.css, builder-frontend.js, animations.js,
to sygnał, że motyw/builder robi dużo ponad to, czego potrzebujesz.
Krok 2: utwórz prostą stronę testową bez buildera (np. klasyczny edytor blokowy, zwykły tekst + obrazek) i przypisz jej najprostszy dostępny szablon (np. „Full Width” bez sidebara). Porównaj:
czas LCP i FCP,
liczbę requestów,
łączny rozmiar strony.
Jeśli prosta strona na tym samym motywie jest wyraźnie lżejsza i szybsza – winny jest głównie builder i użyte moduły. Jeśli nawet „goła” podstrona jest ciężka, problemem jest sam motyw (jego „core”).
Krok 3: włącz motyw domyślny WordPress (np. Twenty Twenty-Four) na klonie strony (staging). Jeśli wyniki CWV natychmiast się poprawią, a TTFB pozostaje podobny – głównym wąskim gardłem jest aktualny motyw/builder.
Co sprawdzić: porównaj LCP, liczbę requestów i rozmiar strony dla trzech wariantów – pełna strona z builderem, prosta strona na tym samym motywie, ta sama zawartość na motywie domyślnym.
Jak odchudzić istniejący motyw i builder
Jeżeli wymiana motywu „tu i teraz” jest zbyt ryzykowna, da się sporo wycisnąć z obecnej konfiguracji. Działaj etapami.
Krok 1: wyłącz nieużywane funkcje motywu
Sprawdź w panelu motywu (często „Theme Options”, „Performance”, „Optimization”), czy można wyłączyć:
animacje przy przewijaniu,
wbudowane slidery i karuzele,
ikony społecznościowe, jeśli i tak korzystasz z innej wtyczki,
portfolio, events, inne custom post types, których nie używasz.
Jeśli motyw pozwala włączyć ładowanie skryptów tylko tam, gdzie są potrzebne, włącz tę opcję (np. slider JS tylko na stronie głównej).
Krok 2: ogranicz nadmiar elementów buildera na podstronach
Częsty scenariusz: strona główna z 10 sekcjami, w każdej kilkanaście elementów, globalne nagłówki/stopki zbudowane w builderze, modalne pop‑upy, sticky bary, czaty. Każdy z nich dokłada CSS i JS.
Zredukuj liczbę sekcji – wiele z nich można połączyć lub przerobić na prostsze.
Usuń zbędne animacje „on scroll” i efekty paralaksy – obciążają renderowanie i zwiększają CLS.
Ogranicz globalne elementy buildera (np. wyskakujące okienka budowane w builderze) do naprawdę ważnych.
Krok 3: przenoś proste fragmenty z buildera do Gutenberga
Dla zwykłych wpisów blogowych lub prostych stron treściowych builder jest zazwyczaj armatą na muchę.
Nowe tekstowe podstrony twórz w edytorze blokowym, używając bloków kolumn, nagłówków, list, bez ciężkich widgetów.
Stare podstrony stopniowo przenoś z buildera do bloków – zacznij od tych najważniejszych dla ruchu (najczęściej odwiedzane, kluczowe w lejku sprzedażowym).
Co sprawdzić: po każdej większej zmianie zmierz rozmiar HTML, CSS i JS danej podstrony oraz LCP. Cel – konsekwentne obniżanie „wagi” strony bez utraty kluczowych funkcji.
Kiedy wymienić motyw lub builder
Przerabianie skrajnie ciężkiego motywu bywa droższe niż migracja na lżejsze rozwiązanie. Sygnały, że pora na zmianę:
brak opcji wyłączenia dużych modułów i skryptów,
brak wsparcia dla nowego edytora blokowego i FSE, wszystko „musi” być robione w builderze,
każda podstrona generuje ogrom HTML (dziesiątki tysięcy znaków) przez zagnieżdżone sekcje i divy,
po optymalizacjach nadal trudno zejść z LCP na mobile poniżej akceptowalnych wartości.
Przy planowaniu zmiany:
Postaw na lekki motyw startowy (np. motywy zoptymalizowane pod performance, integrujące się z Gutenbergiem lub lekkim builderem).
Twórz szablony blokowe (patterns) zamiast każdą stronę budować od zera w builderze.
Co sprawdzić: na wersji staging porównaj wyniki LCP/CLS/INP starego i nowego motywu dla tych samych treści oraz sprawdź, czy struktura HTML nie jest nadmiernie rozbudowana.
Jak motyw i builder wpływają na CLS i INP
Ciężkie motywy psują nie tylko szybkość ładowania, ale też stabilność wizualną i interaktywność.
CLS rośnie, gdy:
builder wstrzykuje style po załadowaniu (np. dynamiczne wysokości, lazy load bez rezerwacji miejsca),
nagłówek/nawigacja zmienia wysokość po wczytaniu fontów lub JS,
sekcje „hero” i slidery nie mają z góry określonej wysokości.
INP cierpi, gdy:
na starcie ładuje się dużo JS buildera (edytowanie inline, live‑preview), mimo że użytkownik na froncie tego nie potrzebuje,
każda interakcja (rozwinięcie akordeonu, przełączenie zakładki) idzie przez ciężkie skrypty.
Aby poprawić sytuację:
Włącz w builderze opcje typu „load JS/CSS on demand”, jeśli są dostępne.
Zadbaj o stałe wymiary kluczowych elementów (slidery, obrazy w hero, bannery), ustawiając wysokość/min-height w CSS lub proporcje obrazów.
Ogranicz liczbę interaktywnych bajerów – im mniej JS do obsługi animowanych elementów, tym lepszy INP.
Co sprawdzić: monitoruj CLS w PageSpeed, sprawdzaj, które elementy przesuwają layout (panel „Layout Shift Regions” w DevTools), oraz mierz INP po redukcji JS buildera i efektów.
Błąd 3 – Za dużo wtyczek i konflikty między nimi
Jak wtyczki zabijają wydajność
Każda wtyczka to dodatkowy kod PHP, potencjalne zapytania do bazy, własne pliki CSS/JS i często zewnętrzne połączenia (API, trackery, licencje). Problemy zaczynają się, gdy:
instalujesz kilka wtyczek robiących to samo (np. 3 różne wtyczki formularzy),
„na wszelki wypadek” trzymasz stare wtyczki, których już nie używasz,
duże pakiety „all‑in‑one” dorzucają dziesiątki funkcji, z których korzystasz tylko z dwóch.
Efekt: rośnie TTFB (więcej logiki PHP przed wygenerowaniem strony), a frontend dostaje extra CSS/JS z różnych źródeł. Dodatkowo konflikty między wtyczkami potrafią blokować cache, generować błędy i psuć Core Web Vitals bez oczywistej przyczyny.
Jak zdiagnozować wpływ konkretnych wtyczek
Krok 1: zrób pełną listę wtyczek i podziel je na kategorie:
krytyczne biznesowo (np. WooCommerce, płatności, LMS),
związane z wyglądem (shortcodes, galerie, slidery),
Krok 2: na środowisku testowym użyj wtyczek typu Query Monitor, Performance Profiler albo zewnętrznych narzędzi (np. New Relic, jeśli hosting pozwala), aby sprawdzić:
które wtyczki dodają najwięcej czasochłonnych hooków,
które generują najwięcej zapytaniń do bazy,
które ładują swoje CSS/JS na każdej podstronie.
Krok 3: wykonaj test A/B na stagingu:
zmierz LCP/TTFB na stronie kluczowej (np. produkt, oferta),
wyłącz grupę „dodatków” i ponownie zmierz,
jeśli różnica jest istotna – węższy krąg podejrzanych masz gotowy, potem wyłączaj pojedynczo.
Co sprawdzić: zanotuj, które wtyczki mają największy udział w czasie generowania strony i ile CSS/JS dorzucają, oraz porównaj wyniki CWV przed i po ich wyłączeniu.
Jak bezpiecznie odchudzić zestaw wtyczek
Usuwanie wtyczek na produkcji „na żywca” kończy się czasem niedziałającym koszykiem, utratą formularzy lub błędami 500. Potrzebny jest plan.
Krok 1: identyfikacja kandydatów do usunięcia
Wtyczki nieaktywne – w większości przypadków można je po prostu usunąć (zostaw jedynie te, których realnie używasz okazjonalnie i rozumiesz konsekwencje).
Duplikaty funkcji – jeśli masz dwie wtyczki cache, jedną do minifikacji i trzy od pop‑upów, zdecyduj się na jeden, dobrze skonfigurowany zestaw.
„Bajery” – suwak opinii, animowane liczniki, plugin do prostego efektu, który można odtworzyć jednym blokiem CSS/JS.
Krok 2: migracja funkcji z ciężkich wtyczek do lżejszych rozwiązań
Formularze – zamiast wielkiego buildera formularzy do prostego kontaktu, wykorzystaj lżejszą wtyczkę lub natywne bloki.
Social share – lżejsze przyciski udostępniania (bez śledzących skryptów JS) zamiast rozbudowanych widgetów.
Pop‑upy – jeśli to możliwe, korzystaj z rozwiązań wbudowanych w motyw lub builder, zamiast kolejnej wtyczki.
Krok 3: test po każdym usunięciu
Usuń jedną wtyczkę lub małą grupę,
przetestuj:
kluczowe funkcje (logowanie, zamówienia, formularze),
console w DevTools pod kątem błędów JS,
wyniki PageSpeed dla głównych podstron.
Co sprawdzić: po redukcji wtyczek porównaj liczbę zapytań, TTFB oraz INP. Dobrze przeprowadzona „dieta” wtyczkowa potrafi poprawić zarówno backend, jak i frontend.
Konflikty wtyczek a cache i Core Web Vitals
Dwie wtyczki cache, trzy od optymalizacji obrazów, plus skrypt do minifikacji JS zewnętrznie – typowy przepis na problemy. Objawy:
strona raz jest superszybka, a raz ładuje się w „gołej” wersji (bez stylów),
czasem widzisz zcache’owaną wersję, a czasem świeżą, przez co wyniki CWV „skaczą” między kolejnymi pomiarami,
minifikacja JS/CSS powoduje błędy w konsoli i rozjechany layout,
logi serwera pokazują losowe błędy 500 lub 503, szczególnie przy większym ruchu.
Żeby to ogarnąć, zacznij od uproszczenia stosu.
Krok 1: zostaw jeden silnik cache
Wyłącz wszystkie wtyczki cache i optymalizacji frontendu.
Włącz jedną wtyczkę cache (najlepiej tę rekomendowaną przez hosting lub taką, która dobrze współpracuje z serwerowym cache).
opcjonalnie: minifikacja i łączenie plików – ale na początek bez agresywnych opcji „combine everything”.
Krok 2: wyłącz duplikaty funkcji
Jeśli jedna wtyczka robi lazy load, druga minifikuje JS, a trzecia wstrzykuje własny CDN, bardzo łatwo o konflikt. Wybierz narzędzie nadrzędne i resztę funkcji wyłącz w innych wtyczkach. Przykład: gdy korzystasz z wtyczki cache z modułem optymalizacji obrazów, nie potrzebujesz drugiej, która robi to samo, chyba że masz jasno zaplanowany podział ról.
Krok 3: testuj kombinacje ustawień na stagingu
Agresywna minifikacja i opóźnianie JS potrafią poprawić wyniki w syntetycznych testach, ale zepsuć realne doświadczenie użytkownika (np. opóźnione pojawianie się koszyka, brak walidacji formularza). Dlatego:
przejdź cały podstawowy lejek (wejście > produkt/oferta > formularz/kasa),
sprawdź konsolę w DevTools,
uruchom test w PageSpeed i porównaj LCP/INP.
Krok 4: skonfiguruj wyjątki
Niektóre skrypty nie lubią być opóźniane lub łączone (np. bramki płatności, reCAPTCHA, chaty na żywo). Gdy widzisz, że po włączeniu opóźniania JS pojawiają się błędy lub coś „przestaje klikać”, dodaj te skrypty do wyjątków w ustawieniach cache/minifikacji. Zazwyczaj wystarczy wykluczyć konkretne pliki JS lub całe ścieżki URL (np. strony „/checkout/” czy „/konto/”).
Co sprawdzić: zweryfikuj, czy na stronie działa tylko jeden system cache (wtyczka + ewentualnie serwerowy), a funkcje takie jak lazy load, minifikacja i CDN nie dublują się. Po każdej zmianie wykonaj serię testów CWV i ręcznie przejdź newralgiczne podstrony, obserwując logi błędów i konsolę.
Jak działa cache w WordPressie i gdzie zwykle jest psuty
Cache w WordPressie działa na kilku poziomach, a problemy zaczynają się wtedy, gdy każdy poziom robi coś „po swojemu” albo w ogóle nie jest skonfigurowany. Typowy scenariusz: hosting ma własny cache, wtyczka cache dorzuca kolejną warstwę, a przeglądarka użytkownika za każdym razem ściąga wszystkie pliki od zera.
Trzy główne warstwy, na które trzeba spojrzeć:
cache strony (full page cache) – przechowuje gotowy HTML, ogranicza wykonywanie PHP i zapytań do bazy,
cache obiektów – zapamiętuje wyniki powtarzających się zapytań do bazy,
cache przeglądarki – mówi, jak długo użytkownik może trzymać CSS/JS/obrazy „u siebie”, zamiast pobierać je na nowo.
Bez spójnej konfiguracji TTFB rośnie, serwer robi w kółko tę samą pracę, a LCP i INP cierpią, bo przeglądarka musi „przemielić” dużo kodu przy każdym wejściu na stronę.
Cache strony (full page) – fundament szybkiego WordPressa
Cache strony to najprostszy sposób na obniżenie TTFB. Zamiast za każdym razem uruchamiać PHP, WordPress generuje HTML raz i potem serwuje go z cache. Brak cache strony przy ruchu produkcyjnym to jeden z najcięższych błędów wydajnościowych.
Krok 1: sprawdź, czy cache strony w ogóle działa
Włącz tryb incognito i odpal tę samą podstronę 2–3 razy w PageSpeed.
Porównaj TTFB – przy działającym cache różnica między pierwszym a kolejnymi testami jest wyraźna (TTFB spada).
Sprawdź nagłówki odpowiedzi w DevTools (zakładka „Network > Headers”). Szukaj informacji typu:
cache-control z rozsądnym max-age,
nagłówków wtyczki cache (np. x-cache, x-litespeed-cache, x-wp-cf-super-cache).
Krok 2: skonfiguruj cache strony w jednej warstwie
Jeśli hosting udostępnia swój system cache (np. LiteSpeed, NGINX cache, Varnish), zacznij od jego rekomendowanej wtyczki. Zasada jest prosta: jeden system główny, reszta wyłączona.
Ustaw czas życia cache dla stron statycznych (home, blog, landing) – np. od kilkunastu minut do kilku godzin, zależnie od tego, jak często zmieniasz treści.
Skonfiguruj automatyczne czyszczenie cache:
po publikacji/aktualizacji wpisu,
przy zmianie menu, widgetów, kluczowych ustawień motywu.
Wyklucz z cache:
strony typu: koszyk, kasa, logowanie, konto,
panelem klienta, panele subskrypcji, generatory treści personalizowanych.
Krok 3: unikaj pętli „cache > brak cache”
Częsty błąd: wtyczka cache czyści cały cache po każdej małej zmianie (np. dodanie produktu), przez co przy większym sklepie serwer prawie zawsze generuje stronę od nowa. Skutek – niestabilne TTFB i „losowe” wyniki CWV.
W ustawieniach wtyczki zamiast „czyść wszystko” ustaw czyszczenie selektywne (np. tylko powiązanych wpisów/kategorii).
Przy dużych aktualizacjach (import produktów) korzystaj z opcji:
tymczasowego wyłączenia automatycznego purge,
ręcznego przebudowania cache po zakończeniu importu (preload).
Co sprawdzić: sprawdź stałość TTFB w kilku kolejnych testach, nagłówki cache w DevTools oraz to, czy strony dynamiczne (kasa, konto) na pewno nie są cache’owane.
Cache obiektów – kiedy faktycznie ma sens
Cache obiektów (np. Redis, Memcached) pomaga przy rozbudowanych stronach: sklepy, LMS, portale z dużą liczbą zapytań do bazy. Na prostym blogu może niewiele zmienić, a przy złej konfiguracji nawet zaszkodzić.
Krok 1: oceń, czy naprawdę go potrzebujesz
Użyj Query Monitora na stronie o najwyższym obciążeniu (np. kategoria sklepu).
Sprawdź:
liczbę zapytań SQL,
czas sumaryczny zapytań,
powtarzające się (identyczne) zapytania w ramach jednego requestu.
Jeśli zapytań jest mało i są szybkie, inwestycja w Redis/Memcached raczej niewiele wniesie.
Krok 2: skonfiguruj jeden, stabilny backend cache obiektów
Sprawdź w panelu hostingu, czy jest dostępny Redis/Memcached i jaka jest zalecana wersja wtyczki.
Zainstaluj jedną wtyczkę do cache obiektów (np. oficjalną od hostingu lub popularnego rozwiązania) i:
włącz globalny cache obiektów,
zadbaj o solidny prefiks (gdy na tym samym Redisie pracuje kilka stron).
Wyłącz inne wtyczki „pseudo-performance”, które próbują robić własny cache obiektów w plikach.
Krok 3: kontroluj rozmiar i czyszczenie cache obiektów
Przepełniony lub źle czyszczony Redis potrafi spowodować spadki wydajności przy dużym ruchu.
W panelu hostingu lub narzędziu CLI sprawdzaj:
rozmiar używanej pamięci przez Redis,
liczbę kluczy,
ewentualne błędy „evicted keys”.
Ustaw sensowną politykę wygasania (TTL) – nie wszystko musi siedzieć w cache „na zawsze”.
Po większych zmianach struktury (migracje, przebudowa taksonomii) wykonaj pełne czyszczenie cache obiektów.
Co sprawdzić: porównaj czas generowania strony w Query Monitor przed i po włączeniu cache obiektów, liczbę i czas zapytań SQL oraz wpływ na TTFB w PageSpeed.
Cache przeglądarki – darmowe przyspieszenie, które często jest ignorowane
Jeśli zasoby statyczne (CSS, JS, fonty, obrazy) nie mają ustawionych nagłówków cache, przeglądarka użytkownika przy każdym wejściu pobiera całość od zera. Dla powracających użytkowników to marnowanie potencjału, a dla Core Web Vitals – zbędne dociążenie sieci.
Krok 1: sprawdź nagłówki dla statycznych plików
W DevTools, w zakładce „Network”, wybierz dowolny obraz, plik CSS lub JS.
W „Headers” poszukaj:
cache-control z max-age większym niż 0,
opcjonalnie expires z datą w przyszłości.
Jeśli widzisz no-cache, no-store albo bardzo niski max-age, to sygnał, że konfiguracja jest słaba.
Krok 2: ustaw długie cache dla zasobów wersjonowanych
Większość plików CSS/JS WordPressa i wtyczek ma dopięty parametr wersji (np. style.css?ver=6.4.1). To pozwala bezpiecznie stosować długie czasy życia cache.
W panelu hostingu lub w konfiguracji serwera (NGINX/Apache) ustaw:
długi max-age (np. od 1 miesiąca w górę) dla .css, .js, .jpg, .png, .webp, .svg, .woff2 itp.,
immutable przy zasobach wersjonowanych, jeśli serwer na to pozwala.
Jeśli nie masz dostępu do serwera, użyj wtyczki cache, która potrafi ustawić nagłówki przeglądarki.
Krok 3: pilnuj wersjonowania i bustingu cache
Długi cache wymaga konsekwentnego zmieniania wersji plików, gdy coś aktualizujesz. Inaczej użytkownikom potrafi zostać stara wersja CSS/JS.
Unikaj ręcznego usuwania parametrów ?ver= z plików CSS/JS, jeśli nie masz w zamian systemu bustingu (np. nazwy plików z hashami).
Jeżeli budujesz własne skrypty/arkusze, zadbaj, by przy każdej zmianie zmieniał się:
parametr wersji, albo
nazwa pliku (np. app.1234.css → app.5678.css).
Co sprawdzić: po konfiguracji nagłówków jeszcze raz przeanalizuj zasoby w DevTools, a w PageSpeed spójrz na sekcję „Wykorzystaj pamięć podręczną przeglądarki” oraz wpływ na LCP przy ponownych odwiedzinach.
Typowe błędy w konfiguracji cache, które psują Core Web Vitals
Na koniec tej sekcji warto zebrać powtarzające się błędy, które szczególnie mocno uderzają w CWV:
Cache włączony tylko dla zalogowanych administratorów – w panelu wtyczki zaznaczone „cache dla zalogowanych”, a dla gości nic się nie dzieje. Efekt: testy robione na zalogowanym koncie pokazują bajeczny TTFB, ale realni użytkownicy dostają „goły” WordPress.
Stałe czyszczenie cache przez inne wtyczki – np. wtyczka bezpieczeństwa skanuje pliki i odpala hooki, które z kolei czyszczą cache. Serwer nie ma kiedy go zapełnić, więc większość wejść idzie „na żywo”.
Cache dla stron dynamicznych – koszyk, checkout, panel użytkownika lądują w cache i odwiedzający widzą cudze dane albo nie mogą przejść procesu zakupu. W odpowiedzi admin „na szybko” wyłącza cache wszędzie.
Brak spójności z CDN – CDN ustawia swoje nagłówki cache, serwer swoje, wtyczka cache dorzuca jeszcze coś od siebie. W rezultacie przy każdym odświeżeniu inne warstwy podają różne wersje plików lub HTML.
Co sprawdzić: przetestuj stronę w trybie gościa (bez logowania), najlepiej w innym browserze lub w trybie prywatnym. Zwróć uwagę na:
stałość TTFB przy kolejnych wejściach,
komunikaty w nagłówkach i konsoli (np. błędy 304/412, problemy z CDN),
poprawność działania newralgicznych stron (koszyk, logowanie, formularze z danymi).
Błąd 5 – Nieoptymalne obrazy i media (formaty, rozmiary, lazy load)
Dlaczego obrazy potrafią „zjeść” LCP
Najcięższym elementem większości stron WordPress są obrazy: hero, banery, zdjęcia produktów, galerie. Gdy pierwszy widoczny obraz jest za duży, w złym formacie lub wczytywany bez sensownego lazy load, LCP od razu cierpi. Dodatkowo źle dobrane wymiary powodują skoki układu (CLS), a nieprzemyślane wtyczki do optymalizacji obrazów generują nadmiar plików i obciążają serwer.
Krok po kroku: porządek w obrazach dla LCP
Krok 1: zidentyfikuj kluczowe obrazy LCP
W PageSpeed, w szczegółach raportu, sprawdź, który element odpowiada za LCP na:
stronie głównej,
typowej stronie produktowej/ofertowej,
kluczowym landing page.
Zwróć uwagę, czy LCP to:
hero image (duże zdjęcie na górze),
slider,
blok tła sekcji (background-image).
Krok 2: dopasuj rozmiary i proporcje
Dla każdego typu kluczowego obrazu ustal docelową szerokość (np. hero dla desktopu ~1920 px, dla mobilnego ~800–1080 px).
Użyj funkcji WordPressa add_image_size() lub ustawień motywu/buildera, aby generować konkretny rozmiar pod hero/produkt, zamiast ładować oryginał 4000 px.
Na frontcie wykorzystaj srcset i sizes, tak aby przeglądarka mogła dobrać odpowiedni rozmiar do ekranu. Większość nowoczesnych motywów/builderów obsługuje to automatycznie – trzeba tylko wybrać poprawny „image size” w ustawieniach sekcji.
Krok 3: formatuj obrazy z głową (WebP/AVIF, ale nie wszędzie)
Formaty nowej generacji potrafią mocno odciążyć LCP, ale trzeba je wdrażać świadomie.
Krok 1: ustaw automatyczną kompresję i konwersję do WebP (lub AVIF) przy uploadzie – zrób to we wtyczce, która:
nie generuje po 10 wariantów każdego pliku bez kontroli,
pozwala ograniczyć liczbę rozmiarów i maksymalny wymiar (np. 2560 px szerokości).
Krok 2: zostaw JPEG/PNG jako fallback tam, gdzie WebP może być problematyczne (stare maile, PDF-y osadzające obrazy, bardzo specyficzne przeglądarki biznesowe).
Krok 3: testowo porównaj wagę przykładowej strony produktowej przed i po wdrożeniu WebP – różnica powinna być widoczna już w „Network” w DevTools.
Unikaj konwersji grafik wektorowych (logo, proste ikony) do WebP, jeśli masz oryginał w SVG – lepiej podać czysty SVG niż bitmapę udającą wektor.
Krok 4: konfiguruj lazy load z myślą o LCP
Domyślne lazy load WordPressa potrafi być zbyt agresywne i „opóźnić” też obraz LCP. Trzeba jasno określić, które obrazy mają ładować się od razu, a które później.
Dla kluczowego obrazu LCP (np. hero, główne zdjęcie produktu):
usuń atrybut loading="lazy", jeśli jest dodawany automatycznie,
dodaj fetchpriority="high" oraz decoding="async" tam, gdzie to ma sens.
Dla pozostałych obrazów „niżej” na stronie zostaw loading="lazy", ewentualnie użyj wtyczki, która pozwala:
wykluczyć kilka pierwszych obrazów nad linią załamania,
ustawić „threshold” (preload nieco przed pojawieniem się w viewport).
Na stronach z wieloma miniaturami (blog, listing produktów) dołóż placeholdery (np. tło w kolorze zbliżonym do zdjęcia), żeby zminimalizować skakanie layoutu przy doładowywaniu miniaturek.
Krok 5: porządek w bibliotece mediów i wtyczkach do obrazów
Bałagan w mediach mści się przy backupach, migracjach i indeksowaniu CWV. Jedna wtyczka do optymalizacji zwykle wystarczy, reszta generuje konflikty i dubluje rozmiary.
Przejrzyj listę wtyczek:
zostaw jedną odpowiedzialną za optymalizację (kompresja, WebP, ewentualny CDN obrazów),
wyłącz i odinstaluj resztę, wcześniej sprawdzając, czy nie zostawia po sobie dziesiątek dodatkowych folderów.
W ustawieniach mediów ogranicz liczbę generowanych rozmiarów:
wyłącz te, których nie używa motyw lub builder,
ustaw maksymalną szerokość/wysokość uploadowanych obrazów – oryginały z aparatu nie muszą lądować w pełnej rozdzielczości.
Przy okazji większego porządkowania zrób eksport listy załączników (np. przez WP-CLI) i usuń pliki, które nie są już nigdzie używane.
Co sprawdzić: w PageSpeed zweryfikuj sekcję „Serve images in next-gen formats” i „Properly size images”, a w DevTools porównaj wagę i liczbę żądań obrazów przed i po wprowadzeniu zmian. Dla kilku newralgicznych podstron przetestuj zmiany również w słabszej sieci (np. symulacja 3G), obserwując realne czasy wczytywania kluczowych zdjęć.
Przy większych bibliotekach z dziesiątkami tysięcy zdjęć zrób porządkowanie etapami: krok 1 – wyłącz zbędne rozmiary i nieużywane wtyczki, krok 2 – wygeneruj miniatury od nowa (np. poprzez wp media regenerate), krok 3 – posprzątaj stare, osierocone pliki. Po każdej większej operacji przetestuj kilka kluczowych podstron, czy nie brakuje obrazów i czy linki prowadzą do aktualnych, zoptymalizowanych wersji.
W projektach e‑commerce pomocne bywa osobne potraktowanie zdjęć produktowych i lifestyle’owych: pierwsze trzymane w umiarkowanej rozdzielczości na białym tle, drugie mocniej kompresowane i często serwowane z CDN. Taki podział pozwala skrócić LCP na listingach i jednocześnie nie psuć jakości kluczowych ujęć w galerii produktu. Kluczem jest spójna strategia: wiesz, które obrazy są krytyczne dla konwersji, a które są jedynie „ozdobnikami” i mogą być bardziej agresywnie kompresowane.
Co sprawdzić: czy obraz LCP nie jest objęty lazy load, czy ma odpowiedni rozmiar i format, a w PageSpeed znikają ostrzeżenia o nieprawidłowych rozmiarach oraz przestarzałych formatach. Dodatkowo porównaj w zakładce „Network”, ile czasu zajmuje pobranie pierwszego dużego obrazu przed i po optymalizacji – to prosta kontrola, czy wprowadzone zmiany faktycznie przełożyły się na szybszy LCP.
Jeśli przepracujesz kolejno hosting, motyw i builder, wtyczki, cache oraz obrazy, WordPress zaczyna zachowywać się przewidywalnie: Core Web Vitals stabilizują się, a każda kolejna zmiana ma mierzalny efekt. Łatwiej wtedy rozwijać serwis, bo zamiast gaszenia pożarów – krok po kroku usprawniasz konkretne elementy, świadomie testujesz wyniki i utrzymujesz serwis w stanie, w którym nowe treści czy funkcje nie rozwalają wydajności przy każdej aktualizacji.
Błąd 6 – Zbyt ciężki i chaotyczny JavaScript (blokujący interakcję i psujący INP)
Jak JS zabija INP i FID w WordPressie
Coraz więcej motywów i wtyczek do WordPressa dokłada swoje skrypty: slidery, pop-upy, chaty, analityka, trackery, efekty „parallax”, animacje na scroll. Każdy z nich coś robi przy ładowaniu strony albo przy każdym ruchu użytkownika. Efekt:
długi czas blokowania głównego wątku przeglądarki (Total Blocking Time),
opóźniona reakcja na kliknięcie przycisku (słaby INP),
„zamrożone” formularze, menu, filtry w sklepie przy słabszych urządzeniach.
Typowy scenariusz: na stronie działa 10 skryptów śledzących, 3 różne slidery, live chat i kilka integracji marketing automation. Wszystko startuje od razu przy wczytaniu strony, a użytkownik po kliknięciu „Dodaj do koszyka” czeka ułamki sekund, aż przeglądarka „przegryzie” wszystkie zdarzenia i event listenery. Google to widzi – INP rośnie.
Krok po kroku: porządki w JavaScript
Krok 1: prześwietl, co faktycznie się ładuje
W DevTools (zakładka „Network” > filter „JS”) sprawdź liczbę i wagę plików JS na:
stronie głównej,
typowej podstronie bloga,
stronie produktowej lub landing page.
W zakładce „Performance” lub „Performance insights” zobacz, co zajmuje najwięcej czasu na głównym wątku (long tasks, eventy). Skup się na skryptach o największym czasie wykonywania.
Sprawdź źródło skryptów: czy pochodzą z motywu, wtyczek, zewnętrznych usług (cdn, tag manager, pixel itp.).
Krok 2: odetnij nieużywane skrypty na poziomie WordPressa
Zanim wejdziesz w zaawansowane „optimizery”, usuń to, czego naprawdę nie potrzebujesz.
„delay JS” – wtyczka cache/optimizera może opóźnić start do pierwszej interakcji użytkownika (scroll, klik).
Krytyczny JS odpowiedzialny za:
menu mobilne,
podstawową obsługę koszyka (dodanie produktu),
kluczowe formularze,
ładuj możliwie wcześnie, ale tak, aby:
nie był zminifikowany do jednej wielkiej „kuli” z innymi skryptami,
nie był wpychany jako inline do HTML, jeśli jest ciężki.
Typowy błąd: wszystko wrzucone w jedną paczkę JS i ustawione na „defer”, przez co mały skrypt do menu czeka, aż załaduje się i zparsuje cały pakiet analityki, sliderów i pop-upów.
Krok 5: minimalizacja i łączenie, ale z umiarem
Minifikacja JS jest pomocna, łączenie – nie zawsze. Przy HTTP/2 i HTTP/3 wiele małych plików nie jest takim problemem, jak duży, monolityczny plik.
nie łącz zewnętrznych skryptów z lokalnymi – utrudnia to cache po stronie przeglądarki i kontrolę błędów.
Po włączeniu łączenia przetestuj:
panel logowania,
koszyk i proces zamówienia,
formularze kontaktowe.
Jeśli coś nie działa – wyklucz dane skrypty z łączenia.
Co sprawdzić: w PageSpeed obserwuj wskaźniki INP i TBT, a w DevTools zakładkę „Performance” – czy zmniejszyła się liczba „long tasks” oraz łączny czas blokowania. Równolegle na realnym urządzeniu (telefon, zwykły laptop) klikaj szybko w menu, koszyk, filtry: przeglądarka powinna reagować natychmiast, bez przycięć.
Źródło: Pexels | Autor: Song Kaiyue
Błąd 7 – Źle zoptymalizowane CSS i krytyczne style (FOUC, layout shift i wolny render)
Jak CSS potrafi opóźnić FCP i LCP
WordPressowe motywy i buildery tworzą zwykle dziesiątki plików CSS: globalne style motywu, style buildera, style wtyczek, dodatkowe „custom CSS” z panelu i jeszcze style wklejone inline. Gdy każdy z tych plików jest:
duży (setki kilobajtów),
ładowany w <head> jako blokujący render,
częściowo nieużywany na konkretnej stronie,
przeglądarka opóźnia render strony do momentu pobrania i przetworzenia CSS. Pojawiają się migotania stylów (FOUC), skoki układu (CLS), a LCP przesuwa się w czasie.
Krok po kroku: uproszczenie i podział CSS
Krok 1: sprawdź, ile CSS faktycznie się ładuje
W DevTools (Network > filter „CSS”) podejrzyj:
liczbę plików,
wagę każdego z nich,
czas pobierania (szczególnie zewnętrzne CDN-y).
W narzędziu Coverage (DevTools > More tools > Coverage) sprawdź, jaki procent danego pliku CSS jest używany na konkretnej podstronie – często mniej niż połowa.
Krok 2: wyłącz zbędne style z konkretnych wtyczek
Podobnie jak przy JS, wiele wtyczek ładuje swoje style wszędzie, choć używane są raz na kilka podstron.
Przy użyciu Asset CleanUp / Perfmatters:
wyłącz CSS:
formularza kontaktowego na stronach, gdzie formularza nie ma,
lightboxów i sliderów na zwykłych wpisach blogowych,
WooCommerce (lub jego modułów) na stronach firmowych typu „O nas” czy „Kontakt”, jeśli motyw nie wymaga ich globalnie.
zadbaj, aby podstawowe style motywu działały poprawnie po wyłączeniu – przetestuj kilka typów stron.
Krok 3: minifikacja i rozsądne łączenie CSS
Dużi gracze często stosują strategię: jeden plik z krytycznymi stylami + kilka mniejszych paczek dla poszczególnych sekcji funkcjonalnych.
W wtyczce optymalizującej:
włącz minifikację CSS,
połącz drobne pliki w większe paczki, ale:
unikaj tworzenia jednego ogromnego pliku dla całego serwisu,
rozważ osobne pliki dla:
strony głównej / landingu,
blog/wpisy,
sklep (WooCommerce).
Jeśli builder generuje per-stronowe style inline, wyłącz opcje, które dokładają dodatkowe pliki CSS dla każdego bloku, jeśli nie są niezbędne.
Krok 4: critical CSS i „above the fold”
Dobrze wdrożone critical CSS mocno przyspiesza FCP/LCP: przeglądarka najpierw dostaje zestaw podstawowych stylów dla widocznej części ekranu, reszta ładuje się asynchronicznie.
Użyj:
wbudowanej opcji critical CSS w wtyczkach typu WP Rocket, LiteSpeed Cache itp., lub
zewnętrznych narzędzi generujących krytyczne style per adres URL.
Skonfiguruj:
wstrzyknięcie critical CSS inline w <head>,
asynchroniczne ładowanie pozostałych arkuszy (np. z atrybutem media="print" i przebiciem na all po załadowaniu).
Po wdrożeniu przejdź przez:
kilka typów urządzeń (desktop, tablet, telefon),
różne przeglądarki,
kilka szablonów stron (główna, produkt, wpis).
Sprawdź, czy nie migają style (nagłówek bez stylu, potem z) i czy nie pojawiają się „gołe” elementy przez ułamek sekundy.
Krok 5: uporządkowanie fontów i ich stylów
Częścią problemu CSS są fonty: różne odmiany (light, regular, bold, italic) i wielkości, ładowane dla samej zasady. To wpływa na FOUT/FOIT i CLS.
W konfiguracji motywu/buildera:
ogranicz liczbę fontów do 1–2 rodzin (np. nagłówki + tekst),
dla każdej rodziny zostaw 2–3 odmiany (np. 400, 600, 700), a resztę wyłącz.
Ładując Google Fonts:
użyj parametru display=swap lub lepiej „optional”,
przenieś fonty lokalnie (opcje w większości lepszych motywów / wtyczek performance), aby ograniczyć zależność od zewnętrznego CDN.
Zadbaj o:
preload najważniejszego fontu (nagłówki/tekst nad linią załamania) przez <link rel="preload" as="font">,
poprawnie zdefiniowane font-family i font-weight, żeby uniknąć „przeskakiwania” grubości po dograniu fontu.
Co sprawdzić: w PageSpeed kontroluj „Remove unused CSS”, „Eliminate render-blocking resources” oraz ostrzeżenia dotyczące fontów. Wizualnie – czy pierwsze malowanie strony (nagłówka, hero) pojawia się szybko i stabilnie, bez „błysków” stylów i skoków układu.
Błąd 8 – Zbyt ciężkie i źle wpięte zewnętrzne skrypty (analityka, tag manager, chaty)
Dlaczego integracje marketingowe psują Core Web Vitals
Narzędzia analityczne i marketingowe są potrzebne, ale mogą zdusić wydajność, jeśli każde z nich:
ładuje się synchronicznie w <head>,
generuje kolejne skrypty i iframe’y (reklamy, heatmapy, trackery),
odpala zaawansowane funkcje na starcie, zanim użytkownik w ogóle przewinie stronę.
Krok po kroku: jak okiełznać zewnętrzne skrypty
Krok 1: inwentaryzacja wszystkich integracji
Najpierw zobacz, co faktycznie jest podpięte. W Source/Network w DevTools wyszukaj domeny typu google-analytics.com, googletagmanager.com, facebook.net, narzędzia heatmap, live chaty, popupy, piksele reklamowe. Zrób prostą listę: które skrypty są kluczowe dla biznesu (np. GA4, konwersje Google Ads), a które działają „od święta” albo ktoś je kiedyś testował i tak już zostały.
Krok 2: przenieś jak najwięcej do Tag Managera
Jeśli na stronie jest kilka osobnych snippetów (GA, piksel FB, LinkedIn, Hotjar), scentralizuj je w Google Tag Managerze. Zostaje jeden główny skrypt GTM, a całą resztą zarządzasz w interfejsie. Przy okazji możesz w GTM:
opóźnić odpalanie niektórych tagów (np. heatmapy) do czasu interakcji użytkownika,
ładować tagi tylko na wybranych podstronach, a nie na całym serwisie,
użyć reguł, które blokują zbędne trackery dla zalogowanych administratorów.
Krok 3: opóźnienie ładowania i „consent mode”
Narzędzia privacy/RODO i lepsze wtyczki cache mają funkcje typu „delay JS execution” albo „load on user interaction”. Skonfiguruj je tak, aby:
analityka podstawowa (np. GA4) startowała po wyrażeniu zgody w banerze cookies,
cięższe narzędzia (session replay, heatmapy, chat) uruchamiały się dopiero po pierwszym scrollu, kliknięciu lub kilku sekundach obecności na stronie,
skrypty były wstrzymane całkowicie, jeśli użytkownik odrzuci kategorie marketingowe/analityczne.
Unikaj błędu: pełne załadowanie GTM + wszystkich tagów przed pokazaniem banera – przeglądarka wykona skrypty, zanim użytkownik w ogóle ma szansę na decyzję.
Krok 4: optymalizacja chatów i widgetów
Chaty, „pomocnicy” i widżety opinii to częsty zabójca INP. Zamiast ładować cały chat od razu:
ładuj tylko lekki „launcher” (ikonka bąbelka) przy starcie,
pełny skrypt chatu uruchamiaj dopiero po kliknięciu w ikonkę lub po kilku sekundach obecności na stronie,
jeśli narzędzie na to pozwala – użyj trybu „light” lub wersji bez zbędnych integracji.
Przetestuj też, ile widgetów jest faktycznie potrzebnych: przycisk chat + popup + sticky banner z promocją to już trzy oddzielne skrypty, które mogą blokować wątki przeglądarki.
Co sprawdzić: w PageSpeed zwróć uwagę na „Third-party code” i „Reduce JavaScript execution time”. W DevTools w zakładce „Performance” zobacz, czy po wdrożeniu opóźnień i consent mode spadła liczba długich zadań powiązanych z domenami zewnętrznymi. Na realnym urządzeniu zweryfikuj, czy baner cookies, chat i inne widgety nie „szarpią” przewijania i klików w pierwszych sekundach wizyty.
Jeśli krok po kroku uporządkujesz hosting, motyw, wtyczki, cache, media oraz skrypty i style, Core Web Vitals przestają być loterią. Zostaje przewidywalny proces: diagnoza, jedna zmiana, test, kolejna zmiana. Taki rytm jest mniej efektowny niż „magiczna” wtyczka do optymalizacji, ale w praktyce właśnie on robi różnicę między przeciętnym WordPressem a szybkim, stabilnym serwisem, który dobrze konwertuje i nie boi się kolejnych aktualizacji algorytmów.
Źródła informacji
Web Vitals. Google – Oficjalne definicje i progi Core Web Vitals (LCP, CLS, INP)
Interaction to Next Paint (INP). Google – Szczegółowe omówienie metryki INP i różnic względem FID
WebPageTest Documentation. Catchpoint Systems – Opis testów, TTFB, waterfall i analizy wydajności zasobów
GTmetrix Documentation. GT.net – Instrukcje użycia GTmetrix, interpretacja metryk i waterfall
WordPress Hosting Handbook. WordPress.org – Zalecenia dot. hostingu, TTFB, cache i konfiguracji serwera dla WordPressa
Web Performance Optimization Guide. Mozilla Developer Network – Ogólne zasady optymalizacji zasobów, JS, CSS, obrazów i wpływu na UX
