Sprawdzanie wydajności WordPressa to jeden z najskuteczniejszych sposobów na poprawę widoczności w Google, zwiększenie współczynnika konwersji i obniżenie kosztów reklamy. Wolno ładująca się strona zniechęca użytkowników, generuje wysokie współczynniki odrzuceń i psuje wizerunek marki. Z kolei szybki WordPress to lepsze pozycje w wyszukiwarkach, większa sprzedaż i większa satysfakcja odwiedzających. W tym poradniku krok po kroku przejdziesz przez proces sprawdzania wydajności, interpretacji wyników oraz wdrażania zmian – tak, aby mierzyć realne efekty optymalizacji.
Dlaczego wydajność WordPressa jest tak ważna
Wydajność strony internetowej to nie tylko subiektywne wrażenie szybkości. To zestaw mierzalnych parametrów, które bezpośrednio wpływają na użyteczność, pozycjonowanie i sprzedaż. Badania wielokrotnie pokazały, że każde dodatkowe 0,5–1 sekundy ładowania strony może obniżyć współczynnik konwersji nawet o kilkanaście procent. Użytkownik, który czeka zbyt długo, porzuca witrynę i wybiera konkurencję.
Google wprost przyznaje, że szybkość ładowania jest czynnikiem rankingowym zarówno na urządzeniach mobilnych, jak i desktopowych. Oznacza to, że wolny WordPress ma utrudnioną drogę do wysokich pozycji w wynikach wyszukiwania. Co więcej, wysoka wydajność redukuje obciążenie serwera i koszty infrastruktury – przy dobrze zoptymalizowanym kodzie i zasobach jedna maszyna obsłuży znacznie więcej użytkowników bez spadku jakości.
Warto podkreślić, że wydajność to nie tylko szybkość pierwszego wrażenia. Liczy się także stabilność, płynność przewijania, szybkość reakcji na działania użytkownika czy sposób ładowania elementów interaktywnych. Nowoczesne narzędzia, takie jak PageSpeed Insights, skupiają się na tzw. Core Web Vitals, czyli zestawie kluczowych wskaźników odzwierciedlających realne doświadczenia osób korzystających ze strony. Zrozumienie ich znaczenia to fundament skutecznego mierzenia wydajności WordPressa.
Dla właścicieli sklepów internetowych na WooCommerce szybkość jest szczególnie istotna. Klient, który doświadcza opóźnień przy dodawaniu produktów do koszyka czy przechodzeniu do kasy, częściej rezygnuje z zakupu. Wydajność bezpośrednio przekłada się tu na przychody. Podobnie w przypadku serwisów contentowych – im szybciej ładuje się treść, tym dłużej użytkownik zostaje w serwisie, czyta więcej artykułów i częściej wraca.
Decydując się na regularne badanie wydajności, zyskujesz także możliwość oceny wpływu wtyczek, motywów i aktualizacji na działanie strony. Każda dodatkowa funkcja może zwiększać obciążenie, a bez twardych danych trudno ocenić, czy jest to akceptowalny kompromis. Systematyczne testy pomagają świadomie rozwijać witrynę, zamiast reagować dopiero wtedy, gdy strona zaczyna wyraźnie zwalniać.
Kluczowe wskaźniki i narzędzia do testowania WordPressa
Aby rzetelnie sprawdzić wydajność WordPressa, trzeba zrozumieć podstawowe wskaźniki oraz nauczyć się korzystać z narzędzi, które je mierzą. Dane z jednego testu to tylko moment w czasie; dopiero regularne pomiary i ich porównywanie pokazują realny trend. Poniżej znajdziesz najważniejsze metryki oraz przegląd narzędzi przydatnych w codziennej pracy.
Najczęściej używane wskaźniki w kontekście WordPressa to:
- Time To First Byte (TTFB) – czas, jaki upływa od wysłania żądania do momentu, gdy przeglądarka otrzyma pierwszy bajt odpowiedzi z serwera. Ocenia głównie wydajność serwera, konfigurację PHP i bazy danych.
- Largest Contentful Paint (LCP) – moment pojawienia się na ekranie największego istotnego elementu treści (np. dużego zdjęcia lub bloku tekstu). Bezpośrednio odzwierciedla szybkość wyświetlenia tego, po co użytkownik przyszedł na stronę.
- First Input Delay (FID) lub nowszy wskaźnik Interaction to Next Paint (INP) – mierzą opóźnienie między pierwszą interakcją użytkownika (kliknięcie, dotknięcie) a reakcją strony. Wysokie wartości świadczą o nadmiernym obciążeniu JavaScriptem.
- Cumulative Layout Shift (CLS) – ocenia stabilność układu. Wysoki CLS oznacza, że elementy „skaczą” podczas ładowania, co jest bardzo frustrujące i obniża komfort korzystania ze strony.
- Fully Loaded Time – całkowity czas załadowania wszystkich zasobów. Dobrze pokazuje, jak rozbudowany jest serwis i jak duże ma wymagania wobec przeglądarki.
Do mierzenia tych parametrów możesz wykorzystać kilka uzupełniających się narzędzi. Pierwszym z nich jest PageSpeed Insights od Google. Wystarczy wkleić adres strony, by otrzymać wynik dla wersji mobilnej i desktopowej, szczegółowe dane o Core Web Vitals oraz rekomendacje optymalizacyjne. Narzędzie pokazuje zarówno dane laboratoryjne (symulowane), jak i dane z rzeczywistych użytkowników, jeśli strona generuje odpowiedni ruch.
Kolejnym przydatnym rozwiązaniem jest GTmetrix. Łączy ono silnik Lighthouse z dodatkowymi wskaźnikami, umożliwia wybór lokalizacji serwera testowego i rodzaju przeglądarki. GTmetrix prezentuje także czytelne waterfall, czyli wykres pokazujący, które zasoby ładują się najdłużej i w jakiej kolejności. To niezwykle pomocne przy identyfikacji wolnych skryptów, zbyt dużych obrazów czy opóźnień w odpowiedzi serwera.
Innym popularnym narzędziem jest WebPageTest, oferujący bardzo szczegółowe raporty, testy z wielu lokalizacji i możliwość analizy zachowania strony przy różnych prędkościach łącza. Dla bardziej zaawansowanych użytkowników niezwykle cenne są także wbudowane narzędzia deweloperskie przeglądarki – zakładka Network w Chrome DevTools pozwala śledzić ładowanie poszczególnych plików, ich rozmiary i czasy odpowiedzi.
Nie można zapominać o narzędziach monitorujących zachowanie WordPressa po stronie serwera. Wtyczki takie jak Query Monitor pomagają identyfikować wolne zapytania do bazy danych, nadmiarowe żądania czy konflikty między wtyczkami. Dzięki nim można dotrzeć do problemów, których same testy front-endu nie pokażą. To szczególnie ważne przy bardziej rozbudowanych stronach, portalach i sklepach.
Najlepsze rezultaty przynosi połączenie kilku narzędzi. PageSpeed Insights dostarcza informacji o Core Web Vitals i zaleceniach Google, GTmetrix oferuje przejrzyste wykresy i szczegółowe dane o zasobach, WebPageTest pozwala symulować rzeczywiste warunki sieciowe, a Query Monitor diagnozuje „wnętrze” WordPressa. Razem tworzą kompleksowy zestaw do systematycznego badania wydajności.
Jak krok po kroku sprawdzić wydajność strony WordPress
Proces sprawdzania wydajności warto przeprowadzać według określonej procedury. Pozwala to na powtarzalność wyników i łatwe porównywanie efektów w czasie. Poniżej znajdziesz praktyczny schemat, który możesz wdrożyć dla każdej strony opartej na WordPressie, niezależnie od tego, czy jest to mały blog, czy rozbudowany sklep internetowy.
Na początek przygotuj środowisko do testów. Upewnij się, że nie wykonujesz w tym samym czasie dużych aktualizacji, importów produktów czy intensywnych prac administracyjnych. Jeśli korzystasz z cache na poziomie serwera lub wtyczki, zdecyduj, czy chcesz przetestować stronę z włączonym czy wyłączonym cache. Najczęściej testuje się konfigurację z cache, ponieważ odzwierciedla to realne warunki dla większości użytkowników.
Następnie wybierz reprezentatywne adresy URL do badania. Zazwyczaj są to: strona główna, przykładowy wpis blogowy, kluczowa podstrona ofertowa lub produktowa oraz – w przypadku sklepów – koszyk i strona zamówienia. Każda z tych podstron może mieć inny profil obciążenia, inną liczbę zasobów i skryptów, dlatego ich wyniki mogą się znacząco różnić. Pominięcie którejś z nich może ukryć poważne problemy.
Kiedy masz już listę adresów, wykonaj po kilka testów w każdym narzędziu. Jednorazowy pomiar potrafi być zafałszowany chwilowym przeciążeniem łącza lub serwera, dlatego warto uśredniać wyniki. Najpierw uruchom PageSpeed Insights i zapisz wyniki dla wersji mobilnej oraz desktopowej. Zwróć uwagę na wartości LCP, FID/INP i CLS oraz ogólną ocenę punktową. Nie skupiaj się wyłącznie na „końcowym” wyniku – znacznie ważniejsze są poszczególne wskaźniki i ich kolory (zielony, pomarańczowy, czerwony).
Kolejnym krokiem jest analiza w GTmetrix. Wybierz możliwie najbliższą lokalizację serwera testowego względem lokalizacji użytkowników docelowych. Przeprowadź test, a następnie przejdź do zakładki Waterfall. Tu zobaczysz, które zasoby ładują się najdłużej. Zwróć szczególną uwagę na duże obrazy, zewnętrzne skrypty (np. czat, piksel reklamowy, systemy analityczne) oraz powolne odpowiedzi serwera. Zanotuj sobie adresy najwolniejszych elementów i ich rozmiary.
Równolegle warto sprawdzić TTFB. Możesz to zrobić w GTmetrix lub w zakładce Network w przeglądarce. Jeśli TTFB utrzymuje się na wysokim poziomie (powyżej 600–800 ms) nawet przy prostych podstronach, może to świadczyć o słabej jakości hostingu, braku cache na poziomie serwera, niewydajnej konfiguracji PHP lub problemach z bazą danych. W takim przypadku sama optymalizacja front-endu nie wystarczy – konieczna będzie praca nad serwerem.
Kiedy masz już dane z zewnętrznych testów, przejdź do analizy wewnętrznej WordPressa. Zainstaluj wtyczkę Query Monitor (na czas testów, niekoniecznie na stałe) i sprawdź liczbę zapytań do bazy na wybranych podstronach oraz czas ich wykonywania. Jeśli widzisz dziesiątki wolnych zapytań, powtarzające się żądania lub wyjątkowo ciężkie funkcje, masz wskazówkę, że problem leży w motywie lub wtyczkach. Tego typu diagnoza pozwala podjąć decyzję o zmianie motywu, wymianie wtyczki na lżejszą albo modyfikacji niestandardowego kodu.
Ostatnim elementem procedury jest zebranie wyników w jednym miejscu. Możesz wykorzystać prosty arkusz kalkulacyjny, w którym zapiszesz datę testu, adres URL, wartości LCP, INP, CLS, TTFB, czas pełnego ładowania oraz najważniejsze wnioski. Dzięki temu po każdej większej zmianie – aktualizacji motywu, wprowadzeniu nowej wtyczki, zmianie hostingu – łatwo porównasz, czy działania przyniosły poprawę, czy pogorszenie wydajności.
Najczęstsze problemy wpływające na wyniki testów
Gdy zaczniesz regularnie badać wydajność WordPressa, szybko zauważysz, że pewne problemy powtarzają się na wielu stronach. Zrozumienie ich przyczyn i skutków ułatwia zarówno interpretację raportów, jak i planowanie poprawek. Wiele z nich wynika ze specyfiki ekosystemu WordPressa – łatwości instalowania motywów i wtyczek, które nie zawsze są zoptymalizowane.
Jednym z najczęstszych powodów słabych wyników jest niewydajny hosting. Tani współdzielony serwer często ma ograniczone zasoby procesora i pamięci, a wiele stron konkuruje o te same parametry. Skutkuje to wysokim TTFB oraz niestabilnymi czasami odpowiedzi. Nawet dobrze zoptymalizowany WordPress nie będzie działał szybko, jeśli serwer jest regularnie przeciążony. Rozwiązaniem bywa zmiana planu hostingowego, przejście na serwer z LiteSpeed lub NGINX, a przy większych projektach – na rozwiązania typu VPS lub managed WordPress.
Kolejny problem to zbyt wiele wtyczek. Każda z nich dodaje własny kod PHP, JavaScript i CSS, niektóre generują dodatkowe zapytania do bazy, inne wczytują ciężkie biblioteki na każdej podstronie, nawet jeśli są potrzebne tylko w jednym miejscu. W efekcie rośnie liczba żądań HTTP i czas przetwarzania strony. Szczególnie kłopotliwe są wtyczki budujące rozbudowane page buildery, wizualne kreatory oraz moduły analityczne działające w tle.
Trzeci typowy problem to nieoptymalne obrazy. Zbyt duże grafiki, brak kompresji, brak skalowania do rozdzielczości wyświetlacza i brak nowoczesnych formatów (WebP, AVIF) znacząco obciążają łącze użytkownika. W raportach narzędzi testujących często widać rekomendacje typu „serve images in next-gen formats” czy „properly size images”. Zaniedbanie tej kwestii bardzo mocno obniża LCP i wydłuża czas pełnego załadowania.
Nie bez znaczenia jest też nadmiar zewnętrznych skryptów. Piksele reklamowe, systemy remarketingowe, chaty online, mapy, zewnętrzne formularze – wszystkie te elementy wymagają dodatkowych połączeń z innymi serwerami. Część z nich potrafi blokować renderowanie strony, szczególnie jeśli została wstawiona nieprawidłowo. Przy dużej liczbie takich skryptów trudno utrzymać dobre wyniki w Core Web Vitals, zwłaszcza na urządzeniach mobilnych z wolniejszym łączem.
Często bagatelizowanym źródłem problemów jest także nieprzemyślany motyw graficzny. Rozbudowane motywy wielofunkcyjne, oferujące dziesiątki gotowych szablonów, są wygodne, ale nierzadko bardzo ciężkie. Zawierają mnóstwo stylów i skryptów, które rzadko są w pełni wykorzystywane. Minimalistyczny, lekki motyw zaprojektowany pod konkretny cel (blog, sklep, portfolio) może zapewnić znacznie lepszą wydajność przy tym samym kontencie.
Do tego dochodzą kwestie konfiguracyjne: brak systemu cache, brak minifikacji i łączenia plików, brak lazy load dla obrazów czy niepotrzebne ładowanie fontów z wielu źródeł. Każdy z tych elementów osobno może wydawać się drobiazgiem, ale razem składają się na odczuwalne spowolnienie strony. Dlatego tak ważne jest, aby raporty narzędzi testujących traktować jako mapę do porządkowania kolejnych warstw projektu.
Jak optymalizować WordPress, aby poprawić wyniki testów
Po zdiagnozowaniu problemów przychodzi czas na realne działania. Optymalizacja WordPressa powinna być planowana etapami – od najprostszych kroków, które dają szybki efekt, po bardziej zaawansowane zmiany dotyczące serwera i architektury strony. W ten sposób możesz sprawdzać po każdym etapie, jaki wpływ miały konkretne modyfikacje na wyniki testów.
Jednym z pierwszych kroków jest wdrożenie skutecznego cache. Możesz skorzystać z wtyczek typu WP Rocket, W3 Total Cache, LiteSpeed Cache czy innych rekomendowanych przez dostawcę hostingu. Cache generuje statyczne wersje podstron, dzięki czemu serwer nie musi za każdym razem przeliczać wszystkiego od zera. To znacząco obniża TTFB i przyspiesza odpowiedź dla użytkowników. Warto skonfigurować cache tak, aby pracował razem z kompresją GZIP lub Brotli oraz odpowiednimi nagłówkami przeglądarki.
Kolejnym etapem jest optymalizacja obrazów. W praktyce oznacza to trzy rzeczy: kompresję (bez widocznej utraty jakości), dobór właściwych wymiarów oraz konwersję do nowoczesnych formatów. Wtyczki takie jak ShortPixel, Imagify czy EWWW Image Optimizer automatycznie przetwarzają grafiki podczas wgrywania. Dobrym rozwiązaniem jest też włączenie lazy load, czyli ładowania obrazów dopiero wtedy, gdy użytkownik się do nich zbliża podczas przewijania. To ogranicza początkową ilość danych, które musi pobrać przeglądarka.
Następnie warto uporządkować wtyczki. Przejrzyj listę zainstalowanych rozszerzeń i usuń te, których nie używasz lub które dublują funkcje. Poszukaj lżejszych alternatyw dla najbardziej rozbudowanych modułów, zwłaszcza jeśli dotyczą one page builderów czy elementów ozdobnych. Każda wtyczka mniej to potencjalnie krótszy czas ładowania, mniejsze ryzyko konfliktów i łatwiejsza diagnostyka problemów. Przy okazji aktualizuj wszystkie pozostałe rozszerzenia do najnowszych wersji – często zawierają one poprawki wydajnościowe.
Optymalizacja kodu front-endu obejmuje minifikację i łączenie plików CSS oraz JavaScript, a także ich odpowiednie umiejscowienie. Chodzi o to, aby jak najmniej skryptów blokowało renderowanie strony. Narzędzia takie jak autoptimize czy funkcje wbudowane w wtyczki cache potrafią zautomatyzować ten proces, ale wymagają testowania – niektóre konfiguracje mogą powodować konflikty z motywem. Po każdej większej zmianie uruchom ponownie testy i sprawdź, czy wyniki się poprawiły oraz czy strona działa poprawnie.
Jeżeli hosting jest wąskim gardłem, rozważ jego zmianę. Przeniesienie na serwer zoptymalizowany pod WordPress, z szybszym dyskiem SSD/NVMe, nowocześniejszą wersją PHP i serwerem HTTP/2 lub HTTP/3, przynosi często radykalną poprawę TTFB bez ingerencji w samą stronę. Warto też korzystać z wbudowanych mechanizmów cache na poziomie serwera, jeśli są dostępne – działają one z reguły wydajniej niż rozwiązania czysto wtyczkowe.
Przy większym ruchu ogromne znaczenie ma wykorzystanie CDN, czyli sieci dostarczania treści. CDN przechowuje kopie statycznych zasobów (obrazów, CSS, JS) w wielu lokalizacjach na świecie, dzięki czemu użytkownicy pobierają je z najbliższego im serwera. To skraca opóźnienia sieciowe, szczególnie dla odwiedzających spoza kraju, w którym znajduje się główny serwer. Popularne są tu rozwiązania takie jak Cloudflare, KeyCDN czy BunnyCDN.
Ostatnim, ale bardzo ważnym krokiem jest okresowy przegląd motywu. Jeśli korzystasz z ciężkiego szablonu, który sprawia problemy wydajnościowe, rozważ migrację na lżejszy motyw zoptymalizowany pod szybkość. Zmiana ta wymaga więcej pracy, ale bywa najbardziej skuteczna w długim okresie. Po przejściu na lepszy motyw i uporządkowaniu wtyczek często okazuje się, że wiele wcześniejszych „łatek” nie jest już potrzebnych.
Monitorowanie wydajności w czasie i dobre praktyki
Sprawdzenie wydajności WordPressa jednorazowo nie wystarczy. Każda aktualizacja motywu, dodanie nowej wtyczki, zmiana konfiguracji serwera czy wzrost ruchu mogą zmienić zachowanie strony. Dlatego istotne jest wdrożenie stałego monitoringu i zestawu dobrych praktyk, które minimalizują ryzyko nagłego pogorszenia wyników.
Dobrym podejściem jest ustalenie harmonogramu regularnych testów, np. raz w miesiącu lub po każdej większej zmianie na stronie. Możesz skorzystać z automatycznych monitorów, które cyklicznie uruchamiają testy i wysyłają powiadomienia o znaczących spadkach wydajności. Niektóre narzędzia oferują historię wyników, co pozwala łatwo dostrzec moment, w którym zaczęły się problemy. Dzięki temu szybciej połączysz je z konkretną aktualizacją lub wdrożeniem.
Warto również na bieżąco śledzić raporty w Google Search Console, szczególnie sekcję dotyczącą Core Web Vitals. Pokazuje ona dane z rzeczywistych urządzeń i realnych użytkowników, a nie tylko testów laboratoryjnych. Jeśli wielu użytkowników doświadcza problemów z LCP, INP czy CLS, otrzymasz wyraźny sygnał do działania. To bardziej wiarygodny obraz niż jednorazowy test, ponieważ uwzględnia różne przeglądarki, łącza i urządzenia.
Jedną z kluczowych dobrych praktyk jest wprowadzanie zmian najpierw na środowisku testowym (staging), a dopiero potem na produkcji. Dzięki temu możesz bez ryzyka sprawdzić wpływ nowych wtyczek, aktualizacji czy modyfikacji motywu na wydajność. Po każdej serii zmian porównaj wyniki testów sprzed i po wdrożeniu. Jeśli zauważysz pogorszenie, łatwo wycofasz ostatnie modyfikacje.
Drugą ważną zasadą jest ostrożność przy korzystaniu z gotowych szablonów stron i bloków w kreatorach. Wiele z nich zawiera zbędne efekty, animacje i skrypty, które obciążają przeglądarkę. Warto usuwać nieużywane sekcje, redukować liczbę fontów, ograniczać liczbę wstawek wideo czy zewnętrznych widgetów. Minimalizm w projektowaniu nie tylko poprawia wydajność, ale też często pozytywnie wpływa na przejrzystość i czytelność treści.
Nie zapominaj także o podstawowej higienie technicznej. Aktualizuj regularnie WordPressa, motyw i wtyczki, dbaj o bezpieczeństwo, wykonuj kopie zapasowe. Wiele aktualizacji zawiera usprawnienia wydajnościowe lub poprawki błędów, które pośrednio wpływają na szybkość działania strony. Zadbany system jest łatwiejszy w utrzymaniu i rzadziej sprawia niespodziewane problemy.
Na koniec zadbaj o prostą dokumentację. Zapisuj, jakie zmiany wprowadzasz, kiedy wykonujesz testy i jakie uzyskujesz wyniki. Dzięki temu po kilku miesiącach będziesz w stanie prześledzić historię optymalizacji i szybciej dojść do wniosku, co przynosi najlepsze efekty. Takie podejście pozwala traktować wydajność nie jako jednorazowy projekt, ale jako stały element zarządzania stroną WordPress.
FAQ – najczęstsze pytania o sprawdzanie wydajności WordPress
Jak często powinienem sprawdzać wydajność strony WordPress?
Optymalnym rozwiązaniem jest wykonywanie testów wydajności co najmniej raz w miesiącu oraz po każdej większej zmianie: aktualizacji motywu, instalacji nowej wtyczki, migracji na inny hosting czy dużym redesignie. Regularne pomiary pozwalają szybko wychwycić spadki szybkości, porównać wyniki w czasie i powiązać problemy z konkretnymi zmianami, zanim odczują je użytkownicy.
Czy wynik 100/100 w PageSpeed Insights jest konieczny?
Maksymalny wynik nie jest konieczny ani w praktyce często osiągalny przy realnych projektach komercyjnych. Ważniejsze jest utrzymanie kluczowych wskaźników (LCP, INP, CLS) w zielonej strefie oraz zapewnienie faktycznie szybkiego, stabilnego działania strony dla użytkowników. Dążenie za wszelką cenę do 100/100 może prowadzić do nadmiernych kompromisów funkcjonalnych i utrudnić rozwój serwisu.
Czy liczba wtyczek zawsze spowalnia WordPressa?
Nie sama liczba wtyczek, lecz ich jakość i sposób działania wpływają na wydajność. Kilkanaście lekkich, dobrze napisanych rozszerzeń może być mniej obciążające niż kilka rozbudowanych modułów z wieloma funkcjami. Problem pojawia się, gdy wtyczki dublują się funkcjonalnie, generują nadmiar zapytań do bazy lub ładują ciężkie skrypty na każdej podstronie. Dlatego ważniejsza jest selekcja niż ślepe liczenie.
Czy zmiana hostingu zawsze poprawi szybkość strony?
Zmiana hostingu może znacząco poprawić TTFB i stabilność, ale nie rozwiąże wszystkich problemów. Jeśli WordPress jest przeładowany ciężkim motywem, wieloma wtyczkami i nieoptymalnymi obrazami, nawet najlepszy serwer nie zapewni idealnych wyników. Najlepsze efekty daje połączenie dobrej jakości hostingu z optymalizacją na poziomie samej strony: cache, obrazy, skrypty, motyw i baza danych.
Jak sprawdzić, która wtyczka najbardziej spowalnia moją stronę?
Najprostsza metoda to testy porównawcze: wyłączasz podejrzaną wtyczkę, czyścisz cache i ponownie uruchamiasz testy PageSpeed lub GTmetrix dla tych samych adresów. Dodatkowo możesz użyć narzędzi takich jak Query Monitor, aby zobaczyć, które wtyczki generują najwięcej zapytań do bazy lub zużywają najwięcej czasu wykonania. Łącząc te dane, łatwiej zidentyfikujesz główne źródła spowolnień.
601 162 666
