Monitoring wydajności WordPress enterprise: APM, alerty i Core Web Vitals

Monitoring wydajności WordPressa klasy enterprise odpowiada na trzy pytania: czego doświadczają prawdziwi użytkownicy, czy kolejne wdrożenie coś pogorszyło i która warstwa stosu za to odpowiada. Każde pytanie wymaga innego narzędzia. Na pierwsze odpowiadają dane terenowe od prawdziwych użytkowników (RUM), na drugie testy syntetyczne w pipeline wdrożeniowym, a na trzecie narzędzia po stronie serwera (Query Monitor, agent APM, trace OpenTelemetry, slow query log MySQL, statystyki Redis).

Wolny koszyk albo rosnący Interaction to Next Paint (INP) w serwisie na jednym rynku kosztuje przychody i widoczność w wyszukiwarce na długo przed tym, zanim ktoś zgłosi problem. Nowoczesne instalacje WordPressa są rozproszone między CDN, workery PHP, bazę danych, object cache, a czasem osobny front, więc pytanie “czy serwer żyje” od lat niewiele mówi. Ten przewodnik opisuje stos monitoringu dla takiej architektury, a każdy próg i każde ustawienie pochodzi z dokumentacji dostawcy albo standardu podlinkowanej w tekście.

#RUM czy testy syntetyczne w monitoringu WordPressa

Pełny obraz wymaga dwóch perspektyw. Nie konkurują ze sobą: każda widzi coś, czego druga nie zobaczy.

#Real user monitoring (RUM)

RUM rejestruje doświadczenie każdego odwiedzającego, na jego urządzeniu i w jego sieci.

• Fragmentacja urządzeń: jak strona działa na nowym iPhonie w porównaniu ze średniopółkowym Androidem na przeciążonym łączu komórkowym.
• Śledzenie interaktywności: każda interakcja, która składa się na INP, żeby znaleźć konkretne elementy interfejsu, które użytkownicy odczuwają jako wolne.
• Wydajność Edge: rzeczywiste opóźnienie między odwiedzającym a najbliższą lokalizacją CDN, w podziale na kraje.

Średnia z całego serwisu ukrywa większość tego, co ważne. Dziel dane RUM według klasy urządzenia, typu połączenia, kraju, szablonu (wpis, archiwum, produkt, koszyk) oraz pierwszej i kolejnej wizyty. Raportuj 75. percentyl, bo na nim Google ocenia Core Web Vitals. Artykuł web.dev o Web Vitals formułuje regułę pomiaru tak:

“75. percentyl wczytań strony, w podziale na urządzenia mobilne i komputery”

Źródło: Web Vitals, web.dev (tłumaczenie własne)

#Monitorowanie syntetyczne i testy uptime

Testy syntetyczne wczytują strony skryptowanymi przeglądarkami w kontrolowanych warunkach.

• Integracja CI/CD: przebieg Lighthouse przy każdym pushu, którym deweloper zmienia kod motywu albo wtyczek.
• Testy uptime i ścieżek: skryptowane przejścia ścieżek, które przynoszą przychód (“dodaj do koszyka”, “wyślij formularz kontaktowy”), z regionów, w których sprzedajesz, w stałym rytmie.

Testy syntetyczne nie widzą prawdziwych użytkowników, więc nigdy nie zastąpią RUM. Ich zaletą są stałe warunki testu. Jeśli wynik syntetyczny się pogorszył, przyczyną jest kod albo infrastruktura, a nie to, kto danego dnia odwiedził stronę.

#Jak zbierać Core Web Vitals biblioteką web-vitals

Na start nie potrzebujesz ciężkiego skryptu zewnętrznego dostawcy. Biblioteka web-vitals od Google opisuje się jako malutka, modułowa biblioteka (około 3K po kompresji brotli) i mierzy każdą metrykę tak samo, jak raportują ją narzędzia Google. Odczytuje API wydajności przeglądarki na stronie i przekazuje każdy wynik do callbacku; potem navigator.sendBeacon wysyła wartość do Twojego kolektora, a README biblioteki zaznacza, że ta metoda działa nawet podczas zamykania strony.

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToTelemetry(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname
  });

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/telemetry/vitals', body);
  } else {
    fetch('/api/telemetry/vitals', { body, method: 'POST', keepalive: true });
  }
}

onCLS(sendToTelemetry);
onINP(sendToTelemetry);
onLCP(sendToTelemetry);

Fragment wysyła tylko pathname, bez query stringa. Ta decyzja ma znaczenie dla prywatności, o czym niżej.

Wersja attribution tej samej biblioteki zamienia złą liczbę w zadanie, które ktoś może wziąć. Dla LCP podaje selektor elementu LCP (target), adres obrazu, jeśli to obraz, czas do pierwszego bajtu, opóźnienie i czas ładowania zasobu oraz opóźnienie renderowania elementu. Dla INP podaje element, z którym użytkownik wszedł w interakcję, opóźnienie wejścia, czas przetwarzania i opóźnienie prezentacji, a także longAnimationFrameEntries, czyli wpisy Long Animation Frame nakładające się na interakcję w przeglądarkach, które obsługują to API. “INP jest zły na stronach produktu” zamienia się w “selektor wariantów spędza większość czasu w jednym skrypcie”.

#Czy PageSpeed Insights i Search Console wystarczą do monitoringu

Search Console i PageSpeed Insights pokazują dane terenowe z Chrome UX Report (CrUX). Dokumentacja CrUX API opisuje te dane jako 28-dniową średnią kroczącą zagregowanych metryk, aktualizowaną codziennie około 04:00 UTC. Regresja wdrożona dziś rano przesuwa tę średnią powoli, więc dowiadujesz się o niej po dniach albo tygodniach.

Drugim ograniczeniem jest pokrycie. Według metodologii CrUX strona lub origin musi być publicznie dostępna do odkrycia i wystarczająco popularna, żeby trafić do zbioru, a dane przekazują tylko użytkownicy Chrome, którzy się na to zgodzili, na komputerach i Androidzie. Chrome na iOS, aplikacje z Android WebView i inne przeglądarki oparte na Chromium, takie jak Edge, danych nie przekazują. Portal B2B za logowaniem, serwis na rynek z małym ruchem albo publiczność głównie na iPhone’ach mogą mieć niewiele danych CrUX albo nie mieć ich wcale.

CrUX pozostaje właściwym punktem odniesienia dla SEO, bo z tego zbioru Google raportuje Core Web Vitals. Do reakcji w dniu wdrożenia potrzebny jest własny strumień RUM bez okna uśredniania.

#Jak prowadzić monitoring RUM zgodnie z RODO

Każdy beacon RUM to żądanie z przeglądarki odwiedzającego do Twojego kolektora. Jeśli razem z metryką trafia tam adres IP, identyfikator sesji albo pełny adres URL z parametrami (na przykład e-mail w linku z newslettera), przetwarzasz dane osobowe w rozumieniu RODO, a nadzór sprawuje UODO. Zapis i odczyt informacji na urządzeniu użytkownika (cookies, localStorage) reguluje art. 399 ustawy z 12 lipca 2024 r. Prawo komunikacji elektronicznej. Wymaga on uprzedniej informacji i zgody, z wyjątkiem zapisu potrzebnego do przekazania komunikatu albo do świadczenia usługi, której użytkownik wyraźnie zażądał.

Utrzymuj beacon w minimalnej formie:

• Zbieraj metrykę, nie osobę: nazwa metryki, wartość, typ szablonu, kraj, klasa urządzenia. Do policzenia 75. percentyla LCP adres IP nie jest potrzebny.
• Wycinaj query string przed wysyłką i zostawiaj samą ścieżkę.
• Nie zakładaj cookie tylko po to, żeby łączyć wizyty. Stracisz podział na nowe i powracające sesje, ale telemetria przestanie zależeć od zgody na zapis na urządzeniu.
• Skonfiguruj kolektor tak, żeby nie zapisywał adresów IP albo skracał je przy odbiorze.
• Jeśli dostawca przechowuje dane w USA, sprawdź, czy oferuje region danych w UE, i czy podpisana jest umowa powierzenia przetwarzania.
• Opisz telemetrię w polityce prywatności i w rejestrze czynności przetwarzania.

To nie jest porada prawna. Granicę w konkretnym wdrożeniu powinien potwierdzić inspektor ochrony danych.

#Jak blokować wolne wdrożenia za pomocą Lighthouse CI

Lighthouse CI uruchamia Lighthouse w Twoim pipeline na adresach preview albo stagingu i porównuje wyniki z asercjami, które definiujesz. Domyślnie lhci collect uruchamia Lighthouse trzy razy na każdy adres (numberOfRuns), co wygładza pojedyncze zaszumione przebiegi. Każda asercja ma poziom: warn wypisuje wynik bez przerywania, a error kończy polecenie kodem różnym od zera, i właśnie to zatrzymuje build.

Preset lighthouse:recommended to rozsądny punkt wyjścia. Według dokumentacji Lighthouse CI sprawdza, czy każdy audyt poza wydajnością dostał maksymalny wynik, i ostrzega, gdy wartości metryk spadną poniżej wyniku 90. Audyty, które nie pasują do projektu, wyłączasz pojedynczo. Dodaj jawne limity dla tego, na co zespół ma bezpośredni wpływ, na przykład łącznej wagi JavaScriptu i CSS na szablonach, które zarabiają.

Lighthouse działa w warunkach laboratoryjnych, więc jego liczby nie będą zgodne z CrUX. Używaj go do porównania jednego buildu z poprzednim w tych samych warunkach, a nie do przewidywania wartości terenowych.

#Testy regresji wizualnej w Playwright

Wydajność to także stabilność. Aktualizacja wtyczki, która nagle przesuwa layout na telefonach, szkodzi jednocześnie CLS i konwersji.

Playwright ma do tego wbudowaną asercję toHaveScreenshot. Przy pierwszym uruchomieniu generuje zrzuty referencyjne, kolejne przebiegi porównują się z nimi. Po zamierzonej zmianie wyglądu wersję bazową odświeżasz poleceniem npx playwright test --update-snapshots. Opcja maxDiffPixels określa, ile pikseli może się różnić, zanim test się nie powiedzie. Dokumentacja Playwright ostrzega też, że renderowanie zależy od systemu operacyjnego, wersji przeglądarki, ustawień i sprzętu, więc wersje bazowe generuj w tym samym środowisku, w którym działają testy, zwykle w kontenerze CI, a nie na laptopie dewelopera.

Praktyczna konfiguracja jest skromna: zrzuty szablonów, które zarabiają (strona główna, kategoria, produkt, koszyk, checkout), w trzech szerokościach ekranu. Drobne różnice w granicach tolerancji przechodzą, większe czekają na decyzję człowieka w pull requeście.

#Jak używać Query Monitor i Kondycji witryny do diagnozy WordPressa

Query Monitor autorstwa Johna Blackbourna to standardowa wtyczka diagnostyczna dla pojedynczego żądania. Dla każdego wczytania strony wypisuje zapytania do bazy i oznacza wolne, zduplikowane lub błędne, pokazuje błędy PHP wraz z odpowiedzialnym komponentem i stosem wywołań oraz listuje żądania HTTP API z kodem odpowiedzi, odpowiedzialnym komponentem i czasem trwania. Obejmuje też hooki i akcje, hierarchię szablonów, kolejkowane skrypty i style oraz aktualizacje transientów. Domyślnie wynik widzą tylko administratorzy na pojedynczej witrynie i superadministratorzy w Multisite; cookie uwierzytelniające może rozszerzyć dostęp na innych użytkowników.

Używamy Query Monitor na stagingu do diagnozy, a nie jako stałego monitoringu produkcji: wyjaśnia jedno żądanie w głąb, a agent APM agreguje wszystkie.

Kondycja witryny (Narzędzia, Kondycja witryny) dokłada darmową warstwę wczesnego ostrzegania. Zakładka Stan grupuje wyniki na problemy krytyczne, zalecane usprawnienia i zaliczone testy. Od WordPressa 6.6 Kondycja witryny zgłasza problem krytyczny, gdy łączny rozmiar opcji ładowanych automatycznie przekracza 800 KB, co opisuje notatka deweloperska WordPressa 6.6 o opcjach autoload. To samo wydanie domyślnie przestaje automatycznie ładować pojedyncze opcje większe niż 150 000 bajtów, co jest osobnym limitem sterowanym filtrem wp_max_autoloaded_option_size. Rozdęte dane autoload wczytują się przy każdym żądaniu, więc ten test warto przeczytać po każdym audycie wtyczek.

#Monitoring APM WordPressa z agentem PHP New Relic

Agent APM zapisuje każde żądanie na produkcji i pokazuje, gdzie poszedł czas. Obsługa WordPressa w agencie PHP New Relic to dobry przykład instrumentacji, która rozumie WordPressa:

• newrelic.framework.wordpress.hooks jest domyślnie włączone od wersji agenta 5.3; ustawienie false wyłącza metryki specyficzne dla WordPressa.
• Metryki hooków pokazują czas spędzony w każdym hooku WordPressa, mierzony od apply_filters, apply_filters_ref_array, do_action i do_action_ref_array.
• Metryki wtyczek i motywów pokazują czas spędzony w każdej wtyczce i motywie, co odpowiada na pytanie “która wtyczka spowolniła tę stronę” bez zgadywania.
• Od wersji agenta 10.16 newrelic.framework.wordpress.hooks.options określa, ile się zapisuje. W trybie threshold agent rejestruje tylko hooki wolniejsze niż newrelic.framework.wordpress.hooks.threshold, domyślnie 1 ms. To ogranicza narzut i ilość danych w serwisach z dużym ruchem.

Datadog, Tideways i Blackfire pokrywają podobny zakres własnymi agentami. Wybór zależy zwykle od tego, czego używa już reszta organizacji, bo jedno narzędzie dla wszystkich usług wygrywa z lepszym narzędziem, do którego nikt inny nie zagląda.

#Jak śledzić WordPressa za pomocą OpenTelemetry PHP

OpenTelemetry to opcja niezależna od dostawcy: te same trace mogą trafiać do Grafana Tempo, Jaegera albo komercyjnego backendu. Dokumentacja automatycznej instrumentacji PHP wymaga PHP 8.0 lub nowszego i rozszerzenia instalowanego poleceniem pecl install opentelemetry. Konfiguracja odbywa się przez zmienne środowiskowe:

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_SERVICE_NAME=wordpress-shop
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318

Dla WordPressa istnieje osobny pakiet, open-telemetry/opentelemetry-auto-wordpress, instalowany poleceniem composer require open-telemetry/opentelemetry-auto-wordpress. Rdzeń WordPressa nie używa Composera, więc README pakietu pokazuje, jak załadować autoloader Composera przed startem WordPressa, na przykład przez php_value auto_prepend_file /var/www/vendor/autoload.php w Apache. Instrumentację można z powrotem wyłączyć zmienną OTEL_PHP_DISABLED_INSTRUMENTATIONS=wordpress.

Do jednorazowego profilowania z terminala polecenie wp profile z WP-CLI nie potrzebuje żadnej wtyczki. Instalujesz je przez wp package install wp-cli/profile-command, a potem wp profile stage mierzy etapy bootstrap, main query i template, wp profile hook akcje i filtry, a wp profile queries zapytania do bazy. Działa na serwerach, na których nie wolno Ci instalować wtyczek. Xdebug daje najbardziej szczegółowy profil ze wszystkich, ale przez narzut zostaje na maszynach lokalnych.

#Jakie metryki bazy danych i object cache monitorować

Slow query log MySQL jest domyślnie wyłączony. Zapisuje zapytania, które trwają dłużej niż long_query_time sekund i sprawdzają co najmniej min_examined_row_limit wierszy. Domyślna wartość long_query_time to 10 sekund, zdecydowanie za dużo dla żądania WWW; minimum to 0, a wartość przyjmuje rozdzielczość mikrosekundową. Każdy wpis zawiera Query_time, Lock_time, Rows_sent i Rows_examined. Duża różnica między wierszami sprawdzonymi a wysłanymi to klasyczny objaw brakującego indeksu, typowo na wp_postmeta za filtrami produktów. log_queries_not_using_indexes dopisuje do logu zapytania bez indeksu, a log_throttle_queries_not_using_indexes ogranicza tempo ich zapisu. mysqldumpslow podsumowuje plik logu. Jak naprawić to, co znajdzie log, opisujemy w przewodniku po optymalizacji bazy danych WordPress.

Dla object cache w Redis surowe liczniki daje polecenie INFO:

• keyspace_hits i keyspace_misses: udane i nieudane wyszukania kluczy. Hit rate to trafienia podzielone przez sumę trafień i chybień.
• evicted_keys: klucze usunięte przez limit maxmemory. Rosnąca liczba oznacza, że cache jest za mały na zbiór roboczy.
• mem_fragmentation_ratio: stosunek used_memory_rss do used_memory.

Nie istnieje uniwersalnie “dobry” hit rate, bo zależy od tego, jaka część serwisu da się cachować. Zapisz własny punkt odniesienia po czystym wdrożeniu i alarmuj przy trwałym spadku: zwykle oznacza on, że nowa wtyczka omija cache, zmieniła się konfiguracja albo ruch przesunął się na strony bez cache.

#Jak monitorować headless WordPress

Gdy WordPress pełni tylko rolę API z treścią, a front działa w Astro lub Next.js, są dwa systemy do obserwowania. Po stronie backendu: czas odpowiedzi i odsetek błędów 5xx endpointów REST API lub WPGraphQL. Po stronie frontu: czas buildu, czas regeneracji stron i koszt hydratacji w przeglądarce.

Obie warstwy łączy rozproszony trace. Rekomendacja W3C Trace Context definiuje nagłówki traceparent i tracestate, które niosą identyfikator trace od frontu do API WordPressa, a OpenTelemetry obsługuje je przy propagacji kontekstu. Jedno żądanie widać wtedy na całej drodze: CDN, front, API WordPressa, MySQL i Redis. Bez tego każdy zespół widzi tylko swój odcinek, a każde wolne żądanie wygląda na winę sąsiedniej warstwy.

#Wykrywanie anomalii w wydajności strony

Stałe progi w rodzaju “alarm, gdy LCP przekroczy 2,5 s” albo odpalają za późno, albo dają fałszywe alarmy w szczytach ruchu. Dynamiczne punkty odniesienia uczą się, co jest normalne dla danej godziny i dnia tygodnia, i zgłaszają odchylenia, zanim padnie twardy próg. Większość platform APM i observability to oferuje; samo ustawienie ma mniejsze znaczenie niż kontekst obok niego.

Anomalia przydaje się dopiero wtedy, gdy widać, co zmieniło się obok niej. Nanoś wdrożenia, aktualizacje wtyczek i starty kampanii na tę samą oś czasu co metryki: Grafana robi to przez adnotacje, New Relic przez znaczniki wdrożeń. Skok TTFB tuż obok aktualizacji wtyczki kończy dochodzenie, zanim się zacznie.

#Jak ustawić budżet wydajności Core Web Vitals i alerty

Budżet to zestaw górnych granic, których przekroczenie ma z góry ustalony skutek. Progi “dobre” według Google dla 75. percentyla to minimum: LCP do 2,5 s, INP do 200 ms, CLS do 0,1, zgodnie z web.dev. Zespoły enterprise zwykle ustawiają ostrzejsze cele dla projektu i dokładają limity wysyłanego JavaScriptu i CSS, sprawdzane w bramce Lighthouse CI.

Budżet bez właściciela się rozmywa. Wskaż jedną osobę, która co tydzień przegląda trend, decyduje, czy próg nadal ma sens, i może zatrzymać wdrożenie. Kieruj też alerty według wagi: niedziałający koszyk budzi dyżurnego, powolny wzrost TTFB trafia na kanał zespołu, a drobne odchylenia czekają na cotygodniowy raport. Jeśli każdy alert kogoś budzi, po miesiącu nikt ich nie czyta.

#Jak szybkość strony wpływa na konwersję

Przydatne pytanie dla zarządu nie brzmi “ile milisekund”, tylko “ile kosztuje nas wolniejsza strona”. Odpowiedz na nie własnymi danymi zamiast procentem wziętym z cudzego case study. Wysyłaj wartości RUM do tego samego magazynu analitycznego co zdarzenia konwersji, pogrupuj sesje według przedziału LCP lub INP i porównaj konwersję w każdej grupie. Wynik dotyczy Twojej publiczności i Twojego koszyka, i właśnie tę wersję zaakceptuje dyrektor finansowy, gdy poprosisz o sprint wydajnościowy.

#Co obejmuje wdrożenie monitoringu WordPressa

W WPPoland praca przy monitoringu obejmuje trzy rzeczy.

1. Projekt monitoringu full-stack: RUM, testy syntetyczne i APM albo trace OpenTelemetry połączone w jeden widok, żeby jeden incydent był widoczny od przeglądarki aż po zapytanie SQL.
2. Zapobieganie regresjom: bramki Lighthouse CI i Playwright, które zatrzymują wolne lub zepsute szablony, zanim trafią na produkcję.
3. Raporty, na podstawie których da się działać: metryki przełożone na decyzje, które musi podjąć zarząd, z właścicielem każdego budżetu.

Narzędzia i wdrożenie wyceniamy indywidualnie, bo koszt zależy od liczby serwisów, wolumenu ruchu i wybranego dostawcy.

#Od czego zacząć monitoring wydajności WordPressa

Zacznij od małych kroków i w kolejności. Najpierw dane terenowe od prawdziwych użytkowników z biblioteki web-vitals, bo pokazują, czego odwiedzający naprawdę doświadczają, oraz Query Monitor na stagingu. Potem Lighthouse CI i testy Playwright w pipeline oraz syntetyczne testy ścieżek z regionów, w których sprzedajesz. Dalej APM albo trace OpenTelemetry i slow query log na endpointach, które wskazały dwie pierwsze warstwy. Każda warstwa odpowiada na pytanie postawione przez poprzednią, a alert bez właściciela to szum.

Gdy monitoring pokaże, gdzie ucieka czas, przychodzi pora na poprawki. Nasz przewodnik po kompleksowej optymalizacji WordPressa obejmuje serwer, cache i front, a przewodnik po optymalizacji INP wchodzi głębiej w metrykę interaktywności. Szerszy przegląd tematu daje przewodnik po wydajności WordPressa i Core Web Vitals. Jeśli chcesz, żebyśmy przejrzeli Twoją stronę, zobacz nasze usługi optymalizacji szybkości WordPress.