Moduł WP Multitool

Znajdź, co spowalnia WordPressa
— jeden skan

Site Doctor to ekran, na który ląduje nowa instalacja WP Multitool. Jedno kliknięcie, jedna rankowana lista i każde znalezisko wskazuje moduł, który to naprawia.

To jest strona produktu. Pełna lista checków, checklist Redis, użycie WP-CLI i instrukcja safe-optimize są w dokumentacji Site Doctor.

Czym jest Site Doctor

Site Doctor w WP Multitool to skan WordPressa na żądanie, który rankuje, co spowalnia stronę — konfig, zdrowie Redis object-cache, probe page cache, balast bazy i (w Pro) autoload oraz złapane wolne zapytania — a potem linkuje każde znalezisko do modułu, który to naprawia. Leci lokalnie, gdy o to poprosisz, nigdy przy każdym ładowaniu strony.

Istnieje, bo „mój WordPress jest wolny” to nie jedno pytanie. To kilkanaście pytań, na które zwykle odpowiada się jedną wtyczką naraz, w kolejności, w jakiej przyjdą ci do głowy. Site Doctor zadaje je wszystkie w jednym przebiegu i ustawia odpowiedzi w kolejności od najbardziej kosztownych.

To nie zamiennik Query Monitor, WordPress Site Health ani wtyczki cache. Każde odpowiada na inne pytania, a Site Doctor mówi to wprost tam, gdzie uczciwa odpowiedź brzmi „najpierw użyj innego narzędzia”.

Co sprawdza

Jeden skan ciągnie z dwóch miejsc: własnych checków konfiguracji Site Doctor i modułów, które już mierzą coś wartego rankowania. Gdy źródła brakuje w twojej edycji, skan nazywa je zamiast po cichu pominąć — krótka lista znalezisk nigdy nie zostanie wzięta za czystą stronę.

Własne checki Site Doctor (każda edycja)

  • OPcache — włączony i zdrowy: hit rate, restarty z braku pamięci, nasycenie tablicy kluczy. Hosty ograniczające status API są raportowane jako „restricted”, nie jako „off”.
  • Drop-in object-cache — czy object-cache.php faktycznie działa. Drop-in wskazujący na martwy backend jest flagowany jako critical.
  • Redis — 21 checków object-cache, które czytają działającą konfigurację serwera zamiast wnioskować o zdrowiu z udanego connectu.
  • Page cache — loopback HTTP probe twojej własnej strony głównej, który czyta prawdziwe nagłówki cache i raportuje „probe not possible” zamiast zgadywać, gdy host blokuje loopback.
  • LiteSpeed Cache i nakładające się wtyczki optymalizacyjne — dwie wtyczki obie wycinające skrypty emoji albo obie usuwające jQuery Migrate to częsta, niewidoczna przyczyna robienia tej samej roboty dwa razy.
  • Bramki WooCommerce — włączone bramki płatności nadal w trybie test lub sandbox, gdzie prawdziwi klienci nie mogą zapłacić.
  • Staging guard — localhost oraz hosty .loc/.test/.local i staging. dostają obniżone severity. Klon deweloperski bez page cache to norma, nie alarm.

Źródła wciągane z innych modułów

Źródło skanu Moduł Lite ($9) Pro
Konfig, OPcache, object cache, 21 checków Redis, probe page cache, LiteSpeed, nakładki, bramki Woo Sam Site Doctor Tak Tak
Balast bazy (rewizje, wygasłe transjenty) Optymalizator bazy Tak Tak
Śmieci Action Scheduler (ukończone wiersze) Action Scheduler Optimizer Tak Tak
Ciężar autoload, zbyt duże i osierocone opcje Autoloader Optimizer Nie Tak
Złapane wolne zapytania Slow Query Analyzer Nie Tak

Sam Site Doctor nie jest modułem Pro — wychodzi w Lite, z własnymi checkami nietkniętymi. To, co Pro dokłada, to dwa kolejne źródła skanu, bo moduły, które je produkują, są Pro. Dołączone readme Lite mówi to jednym wersym: „Site Doctor — jeden skan, który znajduje, co spowalnia stronę. Pełna wersja dokłada dwa kolejne źródła: autoload i wolne zapytania.”

Site Doctor kontra Site Health kontra Query Monitor

Te trzy są stale mylone, a nie powinny. Odpowiadają na różne pytania i na stronie z prawdziwym problemem pewnie użyjesz więcej niż jednego.

Kryterium porównania Site Doctor WordPress Site Health Query Monitor
Pytanie, na które odpowiada Od czego zacząć na całej tej stronie? Czy ta instalacja spełnia własną checklistę core? Co się stało w tym jednym żądaniu?
Zakres Cała strona, na żądanie Cała strona, kryteria core Jedno ładowanie strony
Głębokość object cache 21 checków Redis za handshake’em Jest / nie ma Liczby hitów i pudł per żądanie
Wynik Znaleziska rankowane od najgorszego, każde zlinkowane do modułu, który to naprawia Zaliczone / zalecenia Surowe panele: zapytania, hooki, wywołania HTTP, czasy
Cena Płatny, od $9 (Lite) W core WordPressa Darmowy na wordpress.org (~200 000 instalacji)
Gdzie bym cię posłał zamiast tego

Jeśli chcesz darmową wtyczkę albo musisz debugować jedno konkretne żądanie, zainstaluj Query Monitor. Jeśli frontend jest wolny dla anonimowych odwiedzających, najpierw wtyczka cache. Site Doctor jest na przypadek, gdy front już jest cache’owany, a backend dalej boli — wolny wp-admin, słaby TTFB, Redis raportujący Connected, choć nic nie przyspieszyło, albo agencja potrzebująca jednego rankowanego skanu na starcie.

„Connected” to nie „działa”

Prawie każdy check Redis w ekosystemie WordPressa otwiera socket, wysyła PING, dostaje PONG i pokazuje zielone. Ten test nie może paść tak, jak Redis naprawdę pada.

Serwer może odpowiadać na PING natychmiast, a jednocześnie odrzucać każdy zapis, bo uderzył w sufit pamięci przy polityce noeviction; wyrzucać klucze tak szybko, jak WordPress je zapisuje; serwować dane innej strony ze współdzielonego keyspace bez prefiksu; trzymać grupę options na liście ignore, więc jedyna rzecz warta cache’u jest jedyną niecache’owaną; albo przepłacać na round-tripach stu odczytów na stronę więcej, niż oszczędza na bazie.

21 checków Site Doctor czyta zamiast tego działającą konfigurację serwera. Są read-only i lecą tylko przy skanie — INFO, CONFIG GET, DBSIZE i jeden ograniczony SCAN, nigdy KEYS. Gdy host blokuje CONFIG GET (m.in. Kinsta, WP Engine i Cloudways), dotknięte checki mówią „cannot verify this here”, a nigdy „ok”. Brak danych to nie to samo co brak problemu.

Dłuższa lektura

Cała argumentacja poparta pomiarami: Redis mówi Connected. Twoja strona dalej jest wolna.

Jak to działa

  1. Skan — kliknij „Find what's slow” albo odpal wp multitool quickstart po tę samą rankowaną listę całej strony. wp multitool doctor drukuje tylko własne checki Site Doctor (OPcache, Redis, probe page cache). Nic nie skanuje przy ładowaniu strony; przycisk zawsze wymusza świeży przebieg.
  2. Rankowane znaleziska — każde znalezisko dostaje severity (ok / info / warn / critical), wyjaśnienie czemu ma znaczenie i surowe liczby za nim. Najgorsze najpierw.
  3. Otwórz moduł — każde znalezisko linkuje do modułu, który jest właścicielem poprawki, z dokładnymi wartościami do ustawienia: dyrektywy php.ini, linia redis.conf, stała WP_REDIS_*.
  4. Safe optimize — osobna, jawna akcja. W Lite czyści wygasłe transjenty i stare ukończone wiersze Action Scheduler. Czyszczenie resztek autoload po nieaktywnych wtyczkach wymaga Autoloader Optimizer z Pro.
  5. Ponowny skan — odpal go jeszcze raz, żeby potwierdzić, że znalezisko zzieleniało. Eviction rate Redis potrzebuje dwóch skanów w odstępie co najmniej minuty, bo licznik, który czyta, jest kumulatywny od startu.

Sam skan jest read-only. Nigdy nie edytuje konfiguracji, plików ani bazy, a każdą rekomendację aplikujesz świadomie sam. 

$ wp multitool quickstart
$ wp multitool quickstart --format=json
$ wp multitool doctor
$ wp multitool redis --force
Wyniki skanu Site Doctor w wp-admin: pigułki severity na górze, powiadomienie staging guard i karty znalezisk dla OPcache, drop-in object-cache, LiteSpeed, probe page cache i bramek WooCommerce.
Prawdziwy skan: pigułki severity, powiadomienie staging guard i karty znalezisk dla OPcache, object cache, LiteSpeed, probe page cache i bramek WooCommerce. To własne checki Site Doctor i lecą zarówno na Lite, jak i Pro; znaleziska autoload i wolnych zapytań pojawiają się tylko, gdy zainstalowane są moduły Pro, które je produkują.

Najpierw spróbuj czegoś darmowego

WP Multitool jest płatny i nie ma go na wordpress.org. Zanim wydasz cokolwiek, darmowy skaner zmierzy twoją stronę z zewnątrz: TTFB, kompresję, rozmiar strony i czy to WordPress. Wystarczy URL, bez instalacji.

Darmowy check z zewnątrz →

Czym darmowy skaner nie jest

Nie odpala checków Site Doctor. Nic poza twoim serwerem nie zobaczy OPcache, twojego drop-in object-cache, konfiguracji Redis, wagi autoload ani tabeli Action Scheduler. Zewnętrzny skan mówi ci, czy wejście działa wolno; Site Doctor mówi ci, dlaczego cały dom działa wolno.

A jeśli chcesz po prostu darmową wtyczkę w kokpicie, zainstaluj Query Monitor. Jest darmowa, świetna i to właściwa pierwsza odpowiedź na „zdebuguj to jedno żądanie”. Wolę to tu powiedzieć niż pozwolić ci kupić złą rzecz.

FAQ

Czym jest Site Doctor?
Site Doctor w WP Multitool to skan WordPressa na żądanie, który rankuje, co spowalnia stronę — konfig, zdrowie Redis object-cache, probe page cache, balast bazy i (w Pro) autoload oraz złapane wolne zapytania — a potem linkuje każde znalezisko do modułu, który to naprawia. Leci lokalnie, gdy o to poprosisz, nigdy przy każdym ładowaniu strony.
Czy Site Doctor to osobna wtyczka?
Nie. Site Doctor to moduł wewnątrz WP Multitool i jest obecny w każdej edycji, w tym Lite. Instalujesz WP Multitool; Site Doctor to ekran, na który nowe instalacje lądują po aktywacji.
Czy Site Doctor zastępuje WordPress Site Health?
Nie, uzupełnia go. Site Health to część core WordPressa i raportuje własną checklistę core. Site Doctor to rankowany skan wydajności backendu na żądanie — OPcache, drop-in object-cache, 21 checków Redis, loopback probe page cache, LiteSpeed, nakładające się wtyczki optymalizacyjne, bramki WooCommerce, balast bazy i śmieci Action Scheduler — a każde znalezisko linkuje do modułu WP Multitool, który to naprawia. Skan domyślnie jest read-only. Odpal oba.
Czy Site Doctor zastępuje Query Monitor?
Nie. Query Monitor to właściwe narzędzie, gdy pytanie brzmi „co się stało w tym jednym żądaniu” — rozbija jedno ładowanie strony na zapytania, hooki i wywołania HTTP. Site Doctor odpowiada na inne pytanie: „od czego zacząć na całej tej stronie”. Jeśli musisz zdebugować jedno żądanie, użyj Query Monitor. Jeśli chcesz jeden skan strony, albo admin jest wolny, albo Redis mówi Connected, a strona dalej wolna, zacznij od Site Doctor w WP Multitool. Wiele osób leci oba naraz.
Redis mówi Connected, a strona dalej wolna — co teraz?
Connected dowodzi tylko, że socket się otworzył. Site Doctor odpala 21 checków Redis object-cache poza PING: polityka i wskaźnik eviction, zapas pamięci, kolizje prefiksów kluczy na współdzielonej instancji, ignorowane grupy cache i topologia. Gdy CONFIG GET jest zablokowany przez hosta, te checki raportują „unknown” zamiast przechodzić. wp multitool redis drukuje ten sam raport z linii komend.
Czy Site Doctor zmienia stronę przy skanie?
Nie. Skan jest read-only i leci tylko, gdy o to poprosisz — przycisk „Find what's slow”, wp multitool quickstart po rankowaną listę całej strony albo wp multitool doctor po własne checki Site Doctor. Nie leci przy każdym ładowaniu strony. Zmiana czegokolwiek to osobna akcja: safe optimize może wyczyścić wygasłe transjenty i stare ukończone wiersze Action Scheduler na Lite i wyżej, a czyszczenie resztek autoload po nieaktywnych wtyczkach wymaga modułu Autoloader Optimizer z Pro.
Co Site Doctor skanuje na Lite w porównaniu do Pro?
Lite obejmuje Site Doctor i jego własne checki — konfig, OPcache, object cache, 21 checków Redis, probe page cache, LiteSpeed, nakładki optymalizatorów, bramki WooCommerce, staging guard — plus źródła balastu bazy i Action Scheduler. Pro dokłada dwa kolejne źródła skanu: znaleziska autoload z Autoloader Optimizer i złapane wolne zapytania ze Slow Query Analyzer. Skan nazywa każde źródło, które musiał pominąć, więc pusta lista nigdy nie zostanie wzięta za czystą stronę.
Czy mogę odpalić Site Doctor z WP-CLI?
Tak. wp multitool quickstart to CLI-owy bliźniak przycisku „Find what's slow”: rankowane znaleziska całej strony, w tym źródła innych modułów. wp multitool doctor drukuje tylko własne checki Site Doctor. Oba przyjmują --format=json. wp multitool redis drukuje raport object-cache, z --force do ominięcia 10-minutowego cache probe i --format=json po JSON. Na stronie, która nie używa Redis jako object cache, wp multitool redis mówi to wprost i wskazuje na wp multitool doctor.
Czy potrzebuję klucza licencji?
Lite nie ma klucza licencji — pobierasz zip z portalu Polar i aktualizujesz, wrzucając nowszy zip ręcznie. Pro, Pro Annual i Pro Lifetime używają klucza licencji Polar, który wklejasz w WP Multitool → Updates w wp-admin. Po zapisaniu klucza aktualizacje przychodzą w normalnym ekranie aktualizacji WordPressa. WP Multitool jest sprzedawany na wpmultitool.com przez Polar. Nie ma go na CodeCanyon, nie używa kodów zakupu Envato i nie jest listowany na wordpress.org.
Kiedy używać WP Multitool zamiast darmowego narzędzia?
Jeśli potrzebujesz darmowej, prostej wtyczki albo debugowania jednego konkretnego żądania, Query Monitor z wordpress.org to lepsza pierwsza odpowiedź. Jeśli celem jest szybki frontend, najpierw wtyczka cache jak WP Rocket albo LiteSpeed Cache. Sięgnij po Site Doctor w WP Multitool, gdy front już jest cache’owany, a backend dalej wolny, gdy agencja potrzebuje jednego rankowanego skanu na starcie albo gdy Redis raportuje Connected, a nic nie przyspieszyło.

Odpal jeden skan i przestań zgadywać

Lite — $9. Własny skan Site Doctor: konfig, OPcache, object cache, 21 checków Redis, probe page cache, LiteSpeed i detekcja nakładek, bramki WooCommerce, plus źródła balastu bazy i Action Scheduler. Safe optimize czyści wygasłe transjenty i stare ukończone zadania.

Pro. Wszystko powyżej, plus dwa kolejne źródła skanu — znaleziska autoload i złapane wolne zapytania — oraz moduły Autoloader Optimizer i Slow Query Analyzer, które je produkują. Safe optimize obejmuje też resztki autoload po nieaktywnych wtyczkach.

Zobacz cennik Wersja Lite — $9

Chcesz pełną listę checków, checklistę Redis i referencję CLI przed zakupem? To wszystko siedzi w dokumentacji Site Doctor. Warunki zwrotu pieniędzy są na stronie polityki zwrotów.