Jedna źle dobrana wtyczka potrafi obciążyć WordPressa bardziej niż kilkadziesiąt prostych dodatków. Sama liczba aktywnych modułów niewiele więc mówi. Liczy się to, ile kodu wykonują przy każdym żądaniu, jakie zapytania wysyłają do bazy danych, gdzie ładują CSS i JavaScript oraz jakie procesy uruchamiają w tle.
Problemy zwykle narastają stopniowo. Najpierw pojawia się formularz, potem baner cookies, system statystyk, slider, czat, backup, zabezpieczenia, optymalizacja zdjęć i kilka rozszerzeń WooCommerce. Każdy element osobno wydaje się potrzebny, ale po kilku miesiącach strona zaczyna wolniej odpowiadać, panel administracyjny zacina się przy edycji produktów, a koszyk ładuje zasoby, które nie mają żadnego związku z zakupem.
Rozwiązaniem nie jest losowe usunięcie pięciu wtyczek. Najpierw trzeba ustalić, co faktycznie spowalnia witrynę, a dopiero później zdecydować, czy dany moduł usunąć, zastąpić, przeprogramować czy ograniczyć do wybranych podstron.
Co wtyczki robią podczas ładowania strony
Wtyczka WordPress nie działa jak odizolowany przełącznik. Może podłączać się do wielu mechanizmów systemu, wykonywać kod PHP, pobierać ustawienia z bazy, dodawać własne tabele, uruchamiać zadania WP-Cron oraz dołączać pliki widoczne w przeglądarce użytkownika.
Najczęstsze źródła spadku wydajności to:
- zapytania do bazy danych wykonywane przy każdym wyświetleniu strony;
- pliki CSS i JavaScript ładowane w całym serwisie, mimo że są potrzebne tylko w jednym miejscu;
- połączenia z zewnętrznymi usługami, takimi jak mapy, czaty, systemy opinii, piksele reklamowe i narzędzia marketingowe;
- procesy działające w tle: backupy, skanowanie plików, importy, synchronizacje i generowanie miniatur;
- konflikty między modułami zmieniającymi te same skrypty, cache lub reguły przekierowań;
- rozbudowane funkcje panelu administracyjnego, które analizują treść przy każdym zapisie wpisu albo produktu.
Najbardziej kosztowne bywają wtyczki wpływające bezpośrednio na frontend: kreatory stron, slidery, galerie, formularze, pop-upy, filtry produktów, konfiguratory, czaty i dodatki WooCommerce. Nie oznacza to, że każda z nich jest źle napisana. Problem zaczyna się wtedy, gdy moduł ładuje kilkaset kilobajtów skryptów na podstronie, na której jego funkcja w ogóle nie występuje.
Typowy przykład to formularz kontaktowy używany wyłącznie na stronie „Kontakt”. Część wtyczek dołącza jednak swoje style, obsługę walidacji i dodatkowe biblioteki również na stronie głównej, blogu, regulaminie oraz kartach produktów. Użytkownik pobiera zasoby, z których nigdy nie skorzysta.
W WooCommerce dochodzi kolejny problem: rozszerzenia często ingerują w koszyk, konto klienta, płatności, stany magazynowe i sesje. Źle zoptymalizowany filtr produktów może generować wiele kosztownych zapytań, a moduł dynamicznych cen przeliczać reguły przy każdym odświeżeniu. Na małym katalogu będzie to niewidoczne. Przy kilku tysiącach produktów i większym ruchu serwer zacznie regularnie dobijać do limitów CPU lub procesów PHP.
Osobną kategorią są wtyczki „wszystko w jednym”. Pakiet obejmujący statystyki, formularze, udostępnianie, galerię i ochronę logowania bywa wygodny, ale używanie jednej funkcji nie zawsze oznacza, że pozostałe mechanizmy są całkowicie bezczynne. Trzeba sprawdzić, czy nie powstają dodatkowe wpisy w bazie, zadania cykliczne albo pliki ładowane globalnie.
Nie należy też automatycznie zakładać, że mała wtyczka jest lekka. Moduł zajmujący kilkaset kilobajtów na dysku może uruchamiać źle zbudowane zapytanie przy każdej odsłonie. Z kolei większa wtyczka może działać sprawnie, jeśli ładuje kod warunkowo i korzysta z cache.
Jak znaleźć moduł, który naprawdę obciąża WordPressa
Audyt trzeba rozpocząć od punktu odniesienia. Pomiar wykonany tylko dla strony głównej zwykle nie wystarcza, szczególnie w sklepie lub serwisie z kontami użytkowników.
Osobno należy sprawdzić:
- stronę główną;
- typowy wpis lub podstronę;
- najważniejszy landing page;
- kartę produktu;
- kategorię z filtrami;
- koszyk i checkout;
- panel administracyjny podczas edycji treści.
Do diagnozy przydaje się Query Monitor, który pokazuje czas generowania strony, zapytania do bazy, błędy PHP, wywołania HTTP oraz elementy powiązane z konkretnymi wtyczkami. Nie należy jednak uruchamiać go na stałe na stronie produkcyjnej. To narzędzie diagnostyczne, które samo zwiększa zużycie zasobów i może ujawniać techniczne informacje osobom z dostępem do panelu.
Frontend warto sprawdzić w PageSpeed Insights, Lighthouse, GTmetrix albo WebPageTest. Sam wynik punktowy nie powinien decydować o usunięciu wtyczki. Ważniejsze są konkretne dane:
- liczba i rozmiar ładowanych zasobów;
- skrypty blokujące renderowanie;
- długie zadania JavaScript;
- czas odpowiedzi serwera;
- połączenia z zewnętrznymi domenami;
- zmiany wskaźników LCP, INP i CLS po dezaktywacji modułu.
Najskuteczniejszy test jest prosty:
- Utwórz aktualną kopię zapasową i środowisko stagingowe.
- Zmierz tę samą podstronę kilka razy, najlepiej w podobnych warunkach.
- Zapisz czas odpowiedzi, liczbę zapytań i rozmiar przesyłanych danych.
- Wyłącz jedną podejrzaną wtyczkę.
- Wyczyść cache strony, serwera, CDN i przeglądarki.
- Powtórz pomiar.
- Sprawdź działanie formularzy, koszyka, płatności, logowania i wysyłki e-maili.
Wyłączanie kilku modułów naraz daje szybszy test, ale kiepską diagnozę. Gdy wynik się poprawi, nadal nie wiadomo, która wtyczka była winna ani czy problem wynikał z konfliktu między dwoma dodatkami.
Trzeba też odróżnić wolny backend od ciężkiego frontendu. Jeżeli rośnie TTFB, czyli czas oczekiwania na pierwszą odpowiedź serwera, należy sprawdzić kod PHP, bazę danych, procesy w tle, cache obiektowy i parametry hostingu. Jeżeli serwer odpowiada szybko, lecz strona długo staje się interaktywna, problem częściej leży w JavaScripcie, fontach, reklamach, mapach i zewnętrznych tagach.
Wyniki testu zalogowanego administratora mogą być mylące. Administrator często ogląda stronę bez pełnego cache, z dodatkowym paskiem narzędzi, skryptami edytora i aktywnym modułem diagnostycznym. Dlatego pomiary należy wykonywać także w trybie prywatnym, jako niezalogowany użytkownik.
Sygnałem do dokładniejszej kontroli jest sytuacja, w której po aktywacji wtyczki:
- wyraźnie rośnie liczba zapytań do bazy;
- pojawiają się nowe zasoby na każdej podstronie;
- edycja produktów zaczyna trwać kilka sekund dłużej;
- występują błędy JavaScript albo problemy z checkoutem;
- serwer regularnie osiąga limit pamięci lub procesów PHP;
- WP-Cron zawiera dużą liczbę zaległych zadań;
- baza szybko rośnie przez logi, sesje albo dane tymczasowe.
Jednorazowy test nie daje gwarancji. Wynik może zależeć od obciążenia hostingu, rozgrzania cache, ruchu botów lub odpowiedzi zewnętrznego API. Dlatego decyzję o usunięciu ważnego modułu warto oprzeć na kilku pomiarach, a nie na jednej próbie wykonanej w przypadkowym momencie.
Usunąć, zastąpić czy ograniczyć działanie
Najpierw należy usuwać elementy, które nie mają znaczenia biznesowego. To najbezpieczniejsza część optymalizacji i zazwyczaj daje lepszy efekt niż agresywne zmiany w checkoutcie czy systemie płatności.
Pierwszy priorytet: wtyczki nieużywane i porzucone.
Nieaktywna wtyczka zwykle nie wykonuje kodu na froncie, ale jej pliki nadal znajdują się na serwerze. Jeżeli zawiera podatność, może stanowić zagrożenie nawet wtedy, gdy została wyłączona. Modułów trzymanych „na później” lepiej nie magazynować w instalacji produkcyjnej.
Drugi priorytet: dublujące się funkcje.
Dwa systemy cache, dwa optymalizatory obrazów, kilka wtyczek przekierowań albo równoległe narzędzia do minifikacji potrafią wzajemnie nadpisywać ustawienia. Efektem są błędy skryptów, nieaktualne wersje stron i trudne do odtworzenia problemy po aktualizacji.
Trzeci priorytet: zasoby ładowane bez potrzeby.
Narzędzia takie jak Perfmatters czy Asset CleanUp pozwalają wyłączać wybrane pliki CSS i JavaScript na określonych typach stron. Sprawdza się to przy formularzach, mapach, galeriach, sliderach oraz dodatkach WooCommerce.
Ta metoda wymaga jednak ostrożności. Wyłączenie skryptu na karcie produktu może zepsuć wybór wariantu, dodawanie do koszyka lub aktualizację ceny. Po każdej zmianie trzeba przetestować stronę na komputerze i telefonie, najlepiej również w kilku przeglądarkach.
Proste funkcje czasem można zastąpić krótkim kodem, ale nie należy robić tego za wszelką cenę. Dodanie kodu analitycznego, niewielkiego przekierowania lub modyfikacji interfejsu nie musi wymagać rozbudowanej wtyczki. Kod powinien jednak trafić do motywu potomnego, własnej miniwtyczki albo kontrolowanego systemu snippetów, a nie bezpośrednio do plików aktywnego motywu. Aktualizacja motywu może usunąć ręcznie naniesione zmiany, a błąd składni zablokować stronę.
Ciężkiego modułu biznesowego nie należy wyłączać wyłącznie dlatego, że pogarsza wynik testu. Wtyczka płatności, rezerwacji, faktur, członkostwa lub wielojęzyczności może być kosztowna obliczeniowo, ale niezbędna. W takim przypadku kolejność działań jest inna:
- ograniczenie skryptów do właściwych podstron;
- poprawa konfiguracji cache;
- przeniesienie ciężkich zadań poza godziny największego ruchu;
- konfiguracja prawdziwego crona serwerowego zamiast polegania wyłącznie na WP-Cron;
- optymalizacja bazy danych;
- zwiększenie zasobów hostingu;
- dopiero na końcu wymiana wtyczki.
Migracja na „lżejszą alternatywę” również ma koszt. Trzeba przenieść dane, odwzorować ustawienia, sprawdzić integracje i przetestować aktualizacje. W sklepie internetowym taka zmiana może wpłynąć na zamówienia, wiadomości transakcyjne, podatki, faktury lub statusy płatności. Oszczędność kilkuset milisekund nie uzasadnia ryzyka utraty sprzedaży.
Szczególnej ostrożności wymagają:
- bramki płatnicze;
- systemy subskrypcji;
- integracje księgowe i fakturowe;
- moduły rezerwacji;
- wtyczki wielojęzyczne;
- przekierowania SEO;
- zabezpieczenia logowania;
- cache obiektowy;
- integracje magazynowe i kurierskie.
Przed dezaktywacją takiego modułu trzeba wykonać backup, test na stagingu oraz listę procesów zależnych od wtyczki. Sam poprawny wygląd strony nie wystarcza. Należy sprawdzić zakup od wejścia na kartę produktu do otrzymania wiadomości potwierdzającej, a także zwroty, płatności odrzucone, logowanie klienta i zadania wykonywane w tle.
FAQ
Czy duża liczba wtyczek zawsze spowalnia WordPressa?
Nie. Ważniejsze są jakość kodu, zakres działania oraz sposób ładowania zasobów. Trzy ciężkie moduły mogą obciążać stronę bardziej niż trzydzieści prostych wtyczek.
Czy wyłączone wtyczki wpływają na szybkość strony?
Zwykle nie wykonują kodu na froncie, ale mogą pozostawiać zadania, dane i pliki. Nieaktualne moduły stanowią również ryzyko bezpieczeństwa, dlatego niepotrzebne wtyczki lepiej usunąć.
Czy wtyczka cache naprawi problem z ciężkimi dodatkami?
Tylko częściowo. Cache może skrócić generowanie stron, ale nie usunie zbędnego JavaScriptu, połączeń z zewnętrznymi usługami ani problemów w panelu administracyjnym.
Czy warto zastępować wtyczki własnym kodem?
Tak, gdy funkcja jest prosta, dobrze opisana i łatwa do przetestowania. Płatności, rezerwacje, bezpieczeństwo i fakturowanie lepiej pozostawić sprawdzonym modułom, ponieważ koszt błędu jest znacznie większy niż potencjalny zysk wydajnościowy.
Jak często wykonywać audyt wtyczek?
Na stronie firmowej rozsądnym minimum jest kontrola raz na kwartał oraz po większej aktualizacji motywu lub WordPressa. W sklepie audyt należy wykonać również po wdrożeniu nowych płatności, filtrów, integracji magazynowych albo zmianie checkoutu.
Od której wtyczki zacząć testy?
Od modułu, który ładuje zasoby na całej stronie, mimo że jego funkcja występuje tylko w jednym miejscu. Często będzie to formularz, slider, mapa, czat lub dodatek WooCommerce działający także poza sklepem.
Pierwsze działanie powinno być proste: otwórz jedną kluczową podstronę w Query Monitorze i narzędziu do analizy sieci, a następnie sprawdź, które wtyczki dołączają zasoby mimo braku swojej funkcji na ekranie. Usunięcie takiego globalnego ładowania jest zwykle bezpieczniejsze niż wyłączanie modułu płatności czy przebudowa całego systemu cache, a przy tym szybko pokazuje, czy problem rzeczywiście leży we wtyczkach.
