173 - Przydatne narzędzia: Wtyczka Query Monitor

Cześć, z tej strony Maciej Kuchnik. Witam Cię w podcaście Rób WordPressa. Jeśli korzystasz z WordPressa, to na pewno znajdziesz tu coś dla siebie. Cześć, witam Cię w 173 odcinku podcastu Rób WordPressa. W dzisiejszym odcinku zajmiemy się wtyczką, która pomogła mi ostatnio rozwiązać kilka problemów na stronie, która dosyć wolno działała. W zasadzie to nie sama strona, a panel administracyjny. I ta wtyczka to Query Monitor. Zanim przejdziemy do tematu podcastu, to chwila dla partnera mojego podcastu, czyli marki Cyberfolks. Cyberfolks dostarcza domen i hosting pod wasze WordPressy.

Jeśli jesteście zainteresowani zakupem hostingu pod WordPressa, to z kodem podcast pisanym przez C możecie uzyskać 20% rabat na usługę hostingu WordPress. Oprócz hostingu zapraszam Was również na bloga CyberForce i na webinary, które są organizowane co jakiś czas, bo jest to doskonałe źródło wiedzy nie tylko o WordPressie, ale o różnych rzeczach związanych z biznesem w internecie, ze sprzedażą, z e-commercem, także na pewno znajdziecie coś dla siebie. A teraz przejdźmy do tematu odcinka, czyli do wtyczki Query Monitor. Jeśli robisz WordPressy już od jakiegoś czasu, to bardzo możliwe, że kiedyś korzystałeś z takiego narzędzia przeglądarkowego jak narzędzia deweloperskie, popularne DevTools.

I to jest taki, można powiedzieć, pakiet narzędzi, dzięki którym możesz zbadać pewne rzeczy na swojej stronie, posprawdzać jakieś rzeczy związane choćby z CSS, JavaScript, sprawdzić kwestie wydajności, ciastka jakie zapisuje dana strona. No ale to wszystko co widzisz w DevToolsach no to odnosi się raczej do frontendu strony i do tej części przeglądarkowej. Oczywiście no możesz podejrzeć jakieś tam połączenia, które lecą do serwera, parametry, nagłówki i tak dalej. Natomiast nie ma tam za bardzo informacji o tym, co się dzieje na serwerze. I jeśli miałbym tak w dwóch zdaniach powiedzieć, czym jest wtyczka Query Monitor, no to wtyczka Query Monitor to takie DevToolsy, które możemy zainstalować w swoim WordPressie, z tą różnicą, że pokazują nam sporo informacji związanych z backendem naszej strony, czyli z wszystkim tym, co dzieje się po stronie serwera.

I tutaj tej wtyczki możemy używać na dwa sposoby. Jeden sposób taki powiedzmy najprostszy, najszybszy, no to kwestia zainstalowania wtyczki i podglądu tych wszystkich parametrów, tych rzeczy składowych, które są uruchamiane podczas wykonywania kodu. Czyli podczas odwiedzania na przykład jakiejś konkretnej podstrony. We wstępie wspominałem, że pomogła mi ta wtyczka rozwiązać problem w WP Adminie. Ten problem objawiał się tym, że panel administracyjny strony działał bardzo, bardzo wolno. No i dzięki tej wtyczce mogłem namierzyć przyczynę, ale zanim do tego przejdę to Jeszcze oprócz tego, że możemy tą wtyczkę po prostu zainstalować i ona działa, pokazuje nam jakiś tam zestaw parametrów i różnych informacji na temat naszej strony, to możemy również wykorzystać ją w taki bardziej zaawansowany sposób, logować pewne rzeczy, mierzyć wydajność już jakichś małych fragmentów kodu.

Elementów składowych naszej strony. W zasadzie można powiedzieć, że na takie segmenty, które monitoruje ta wtyczka. Mamy oczywiście jakieś takie ogólne parametry, takie jak np. czas wygenerowania strony, czy pamięć, która została użyta. Wtedy mamy błędy w PHP, które gdzieś tam zostały wygenerowane, możemy sobie je przefiltrować po ważności, możemy wyświetlić albo wszystkie, albo ograniczyć się na przykład tylko do notice'ów czy do warningów, które zwykle nie mają znaczenia dla działania strony pod takim względem, że nie przerywają Jej działania nie powodują, że wyświetla nam się np. biały ekran. W kolejnej sekcji mamy rzeczy związane z zapytaniami do bazy danych.

Podczas wczytania strony, niezależnie czy jest to front czy jest to panel administracyjny, nasz WordPress wykonuje ileś tam różnych zapytań do bazy danych. I akurat w moim przypadku, o którym wspominałem na samym początku, Było tak, że za to wolne działanie panelu administracyjnego była odpowiedzialna w zasadzie jedna kwerenda do bazy danych, jedno zapytanie do bazy danych, które w skrajnych momentach potrafiło się wykonywać nawet około 30-35 sekund. I było to związane raz z rozmiarem bazy danych, a dwa z tym, że zapytania oparte o wiele pól postmeta Są bardzo nieefektywne jeśli chodzi o wydajność bazy danych, ale to myślę jest temat na inny odcinek podcastu.

Jeśli dodawalibyśmy sobie na przykład jakieś własne reguły, jeśli chodzi o URL, No to również może się to przydać do debugowania, gdyby coś nam działało nie tak jak trzeba. I są tutaj również wyświetlone wszystkie parametry tzw. Query Wars, czyli wszystkie parametry odpowiedzialne za to, co jest aktualnie wyświetlane pod danym adresem URL. Kolejna zakładka przyda nam się, jeśli chcemy rozwiązać jakiś problem związany z blokami Gutenberga, bo Jest to zakładka BLOCKS i tutaj mamy wylistowane wszystkie parametry związane z blokami, które są aktualnie wyświetlane. Zarówno same nazwy tych bloków, z których składa się dany widok, jak i wszelkie parametry, które są aktualnie załadowane w danym bloku, więc tutaj też może się to przydać przy debugowaniu.

Następnie mamy zakładkę związaną z językami. Tutaj, gdybyśmy mieli jakieś problemy z tłumaczeniem, no to znajdziemy też garść cennych informacji. I kolejna zakładka, która może być przydatna w momencie, w którym nasza strona działa powoli. Jeśli na przykład operujemy na jakichś zewnętrznych API, to tutaj, jeśli to wszystko działa na zasadzie funkcji wordpressowych, takich jak WP Remote Get bodajże, Albo Remote Post, no to również znajdziemy tutaj informacje na temat takich zapytań gdzieś tam na zewnątrz, czyli sytuacja, w której WordPress łączy się np. do jakiejś zewnętrznej usługi i pobiera dane, czy wysyła jakieś dane do zewnętrznej usługi, no to również tutaj zobaczymy szczegóły, W kolejnej zakładce mamy informację o tym, czy jakieś transienty zostały użyte.

Które funkcje zwracają true, a które false w danym kontekście. I tak jak mówiłem, mi akurat przydała się ta wtyczka w momencie, w którym miałem do znalezienia problem taki wydajnościowy, no bo panel WordPressa działał po prostu tragicznie źle. Ładowanie po 30-40 sekund można powiedzieć było standardem. Tam akurat w moim przypadku odpowiedzialna za to była Baza danych, w zasadzie nie tyle baza danych, co takie bardzo, bardzo nieoptymalne zapytanie, które wynikało z tego, że było to zapytanie wygenerowane przez klasę WP Query z wieloma parametrami dotyczącymi custom fieldów i niestety w takim połączeniu tych wielu warunków dało to po prostu finalnie zapytanie, które jest bardzo, bardzo nieefektywne.