Strona, którą przejęliśmy
Porównywarka ubezpieczeń trafiła do nas na WordPressie z ponad 30 aktywnymi wtyczkami, bazą danych 705 MB i Largest Contentful Paint na poziomie 7.7 sekundy. Nic z tego nie jest egzotyczne. To wzorzec nadmiaru wtyczek, jedna wtyczka instalowana na problem, aż stos załamuje się pod własnym ciężarem, i dokładnie to wciąż produkują szybkie oraz wspomagane AI wdrożenia. Oto teardown tego, co naprawdę było zepsute, i co to naprawiło.
Nadmiar wtyczek rzadko zapowiada się sam. Żadna pojedyncza wtyczka nie jest złoczyńcą. Strona działa, wolno, dopóki ktoś jej nie zmierzy i nie odkryje, że koszt jest skumulowany: każda wtyczka dokłada zapytania, skrypty, style, obowiązek aktualizacji i kawałek powierzchni ataku, a trzydzieści razem zamienia prostą stronę treściową w coś, co maluje się prawie osiem sekund.
Największym sprawcą był licznik odsłon
Największym pojedynczym problemem nie był ciężki page builder ani obrazek. Był nim licznik odsłon. Strona zliczała wyświetlenia artykułów, zwiększając wartość w wp_postmeta przy każdym wczytaniu, synchronicznie, w obrębie żądania. wp_postmeta to ogólna tabela klucz-wartość, którą WordPress czyta nieustannie; nie jest zbudowana pod częsty zapis przy każdej wizycie. Pozostawiony tak, ten jeden mechanizm rozdął wp_postmeta do 322 MB z bazy 705 MB.
Szkoda to nie tylko dysk. Rozdęta, gorąca wp_postmeta spowalnia dużą część normalnych zapytań WordPressa, bo tak wiele systemu z niej czyta. Więc funkcja, o której nikt nie myślał, liczba odsłon, po cichu opodatkowywała każdą stronę. Usunięcie synchronicznego zapisu i poprawne zliczanie odsłon przywróciło tej tabeli rozsądny rozmiar i zdjęło obciążenie z każdego żądania.
Nadmiar to także historia o bezpieczeństwie
Liczba wtyczek kosztowała nie tylko szybkość. Poszerzyła powierzchnię ataku w przewidywalny sposób:
- Otwarty endpoint
xmlrpc.php, klasyczny wektor brute-force i amplifikacji. - Błędy PHP wyświetlane na produkcji, ujawniające ścieżki serwera (information disclosure).
- Wtyczki ze znanymi podatnościami, bo porzucone lub nieaktualizowane wtyczki przestają być łatane.
Dlatego cięcie liczby wtyczek to środek bezpieczeństwa, nie tylko wydajności. Każda usunięta wtyczka to kod, którego nie musisz już ufać, pilnować i aktualizować. To ta sama logika, która stoi za porządnym audytem bezpieczeństwa WordPress: mniej powierzchni, mniej dróg wejścia.
Co to naprawdę naprawiło
Naprawa była nieefektowna i skuteczna:
- Audyt każdej wtyczki względem tego, co faktycznie robi, potem usunięcie nakładek i porzuconych, i zastąpienie drobnych zadań wtyczek kilkoma liniami kodu motywu.
- Przepisanie licznika odsłon, tak by nie zapisywał do
wp_postmetaprzy każdym żądaniu, co pozwoliło bazie się skurczyć. - Przeniesienie ponad 1.5 GB statycznych PDF-ów z serwera aplikacji na storage obiektowy Cloudflare R2, żeby VPS nie serwował dużych plików, którymi nie powinien się zajmować.
- Dodanie cache obiektowego Redis, by powtarzane zapytania trafiały do pamięci zamiast do bazy, odciążając VPS z 3 vCPU.
- Zamknięcie
xmlrpc.php, wyłączenie wyświetlania błędów na produkcji i doprowadzenie pozostałych wtyczek do załatanych wersji.
Nic z tego nie jest sprytne. To dyscyplina nałożona na stos, który jej nie miał, i to właśnie jest większość realnej pracy nad Core Web Vitals, gdy spojrzeć poza wynik laboratoryjny.
Czemu wdrożenia wspomagane AI wciąż to odtwarzają
Nadmiar wtyczek istniał przed AI. Ale asystenci AI pogłębiają go w konkretny sposób: gdy odpowiedzią na każdy wymóg jest “zainstaluj do tego wtyczkę”, dług gromadzi się szybciej, bo zasugerowanie wtyczki to dla asystenta droga najmniejszego oporu, tak samo jak dla człowieka w pośpiechu. Kończysz z tym samym 30-wtyczkowym stosem, tylko złożonym w jedno popołudnie. Dlatego ten teardown mieści się w naszej szerszej naprawie stron zrobionych przez AI: czy nadmiar wziął się od człowieka, czy od promptu, sprzątanie jest identyczne, audytuj, usuń, zastąp celowanym kodem i zmierz.
Słownik
- wp_postmeta - rdzenna tabela WordPressa przechowująca metadane klucz-wartość dla wpisów; czytana bardzo często, więc jej rozdęcie spowalnia całą stronę.
- Cache obiektowy (Redis) - magazyn w pamięci, który trzyma wyniki powtarzanych zapytań do bazy, by nie uderzały do bazy za każdym razem.
- Storage obiektowy (Cloudflare R2) - magazyn na pliki statyczne jak PDF-y i obrazy, serwowane niezależnie od serwera aplikacji.
- LCP (Largest Contentful Paint) - czas do wyrenderowania największego widocznego elementu; podstawowa miara odczuwanej szybkości.
Wniosek
Jeśli Twoja strona WordPress przekroczyła kilkanaście czy dwadzieścia wtyczek, koszt prawie nigdy nie jest jednym oczywistym winowajcą. To akumulacja, plus jeden czy dwa ciche mechanizmy, licznik odsłon, niezindeksowany log, synchroniczne wywołanie API, robiące realną szkodę w tle. Naprawa to policzyć wtyczki, znaleźć mechanizm zapisujący przy każdym żądaniu i przenieść ciężki balast statyczny z serwera aplikacji. Strona na 7.7 sekundy nie jest stracona. To zwykle stos, którego nikt nie zaudytował, a to bardzo inny i dużo tańszy problem, niż wygląda.
