Ostatnio pisałem o tym jak sprawić, żeby Twój WooCommerce był szybki.
Ale zanim za to się zabierzemy, to warto wiedzieć jak obiektywnie taką szybkość ocenić.
Spis treści
Rozwiń spis treści
Jak definiuje szybki sklep?
Sklep, który jest szybki w każdej sytuacji, a nie tylko, gdy serwuje nam html z cache.
- Szybki sklep to taki, w którym zalogowany użytkownik przegląda tak samo szybko jak przed zalogowaniem
- W szybkim sklepie sprawnie poruszamy się po backendzie edytując produkty czy przeglądając zamówienia
- Bez problemu dodamy do koszyka kolejne produkty czy skorzystamy z wyszukiwarki
- No i przede wszystkim szybko wygenerujemy stronę zamówienia
Wszystkie te operacje wymagają dynamicznej pracy strony i nie da się ich zamaskować wtyczką typu Litespeed Cache czy WP Rocket.
Szybki sklep według mnie spełnia wszystkie te warunki, a nie taki, który ma wysokie oceny w typowych testach jak Google Page Speed Insights, które nie biorą pod uwagę (same z siebie) scenariuszy dynamicznych.
Jeden z moich ulubionych case’ów zapisałem już jakiś czas temu.
Złe wyniki Core Web Vitals w praktyce
Jak widzicie można w suchych testach łapać prawie maksimum punktów, a w rzeczywistości kompletnie zawalać wszystkie prawdziwe metryki.
Tak - Core Web Vitals to są metryki, na które należy patrzeć, bo są zbierane przy sesjach Twoich użytkowników. Tutaj fatalna implementacja na tanim serwerze miała być zamaskowana Nitropaackiem.
Podałbym tu nawet link, bo aż się prosiło o wypunktowanie, ale niestety sklep już nie funkcjonuje.
Jeśli chcemy lepiej odwzorować prawdziwe sytuacje, które pozwolą nam ocenić realne scenariusze na sklepie, to przydadzą nam się:
Dynamiczne testy k6 pod WooCommerce
Testy k6 to nowoczesne narzędzie typu open-source do testów wydajnościowych, które pozwala na dokładne sprawdzanie, jak aplikacje i systemy radzą sobie pod obciążeniem. Dzięki prostej składni opartej na JavaScript, k6 umożliwia symulację realistycznych scenariuszy użytkowania.
Narzędzie to może być uruchamiane lokalnie na urządzeniu, co pozwala na szybkie i wygodne testy nawet z poziomu terminala czy VS Code. Alternatywnie, k6 może być używane w chmurze, np. w połączeniu z Grafana Cloud, co daje możliwość monitorowania i analizowania wyników w czasie rzeczywistym za pomocą zaawansowanych wizualizacji i tabel.
Chmura pozwala nam także przeprowadzić bardziej wymagające testy, które wykonane z naszego komputera mogą być na przykład obciążone błędem przez maksymalne wykorzystanie naszego łącza internetowego.
Przykład testu k6
import http from "k6/http";
import { sleep } from "k6";
// Konfiguracja testu
export const options = {
stages: [
{ duration: "60s", target: 20 },
// Przez 60 sekund test będzie symulował 20 użytkowników równocześnie
],
};
export default function () {
const url = "https://example.com"; // Zastąp przykładowy URL swoim adresem
const response = http.get(url);
// Możesz dodać opcjonalne logowanie lub sprawdzanie odpowiedzi
if (response.status !== 200) {
console.error(`Request failed with status ${response.status}`);
}
sleep(1); // Odczekaj 1 sekundę pomiędzy żądaniami
}
Test uruchamiamy na naszej maszynie komendą w terminalu:
k6 run test.js
lub z chmury
k6 cloud test.js
Jak przebiegnie ten test?
Nasz adres example.com będzie odpytytwany przez 20 równoległych użytkowników przez 60s.
Czy da nam to odpowiedź na dynamiczną pracę serwera?
Tylko pod warunkiem, że:
- zamiast example.com użyjemy adresu dynamicznego np. example.com/?s=some%20product - co np. zasymuluje nam wyszukanie frazy “some product”
- nie używamy żadnej wtyczki do cache, ani nasz hosting nie robi tego za nas na poziomie serwera
Jeśli jednak nie chcemy się ograniczać do jednego adresu, możemy skorzystać z trochę bardziej zaawansowanego testu, który w trochę lepszy sposób zasymuluję typowe zachowania użytkowników na sklepie.
Dynamiczny test k6 pod WooCommerce
Pod tym linkiem znajdziesz przykładowy test pod WooCommerce.
W komentarzach lub opisie repozytorium znajdziesz instrukcje jak go uzupełnić danymi ze swojej domeny.
Poniżej postaram się omówić najważniejsze fragmenty.
// Stała lista URLi kategorii i produktów
// tu wpisz ścieżki do kategorii swoich produktów
const categories = [
"/product-category/phone/",
"/product-category/pc/",
"/product-category/laptop/",
];
// tu wpisz ścieżki do swoich produktów
const products = [
"/product/iphone-16/",
"/product/macbook-13/",
"/product/ipad/",
];
// tu wpisz ID swoich produktów bez wariantów, które będzie dodawać do koszyka,
// znajdziesz to w zakładce produkty po najechaniu na produkt
const productIds = [113, 120, 194, 129, 191];
Uzupełniamy ten fragment danymi z naszego sklepu. Dodajemy kolejno ścieżki kategorii, produktów oraz id produktów, które w teście będziemy dodawać do koszyka.
distribution: {
"amazon:de:frankfurt":
{ loadZone: "amazon:de:frankfurt", percent: 100 },
// Strefa Frankfurt
},
Darmowe konto Grafany umożliwia nam wykonanie całkiem dużej liczby testów. Wybieramy Frankfurt lub inną lokalizację, która jest najbliżej Twojego serwera.
scenario_cart_and_checkout: {
executor: 'constant-vus',
vus: 20, // 20 użytkowników
duration: '180s',
// Maksymalny czas scenariusza
exec: 'checkout',
gracefulStop: '30s',
// Dodajemy 30 sekund na zakończenie testu
},
Tutaj definiujemy scenariusze oraz ilość wirtualnych użytkowników, którzy wezmą udział w teście.
W tym przykładzie to 20 wirtualnych osób oraz 3 minutowy test. Do tego dodajemy 30s, żeby część dłuższych iteracji miała okazję dojść do końca.
Dalej mamy 3 funkcje, które będą imitować nam zachowanie użytkownika na sklepie:
viewCategoryAndProduct()
Gdzie funkcja losowo odpytuje stronę kategorii, a później produktu. Sprawdzamy czy odpowiedzi serwera mają status 200 - czyli prawidłowy.
addToCart()
Gdzie dodajemy losowy produkt do koszyka i go wyświetlamy. Korzystamy z funkcji Woo i wywołania adresu z dodatkiem parametru add-to-cart.
checkout()
To funkcja całości naszego scenariuszu. W obrębie funkcji najpierw robimy wywołanie stron ze sklepu, później dodanie do koszyka, a na samym końcu generujemy checkout.
Tutaj warto zaznaczyć, że jeden VU - Virtual User ma zachowaną ciągłość sesji, dlatego sprawdzenie ostatniej 200 na checkoucie jest dla nas kluczowe. Jeśli spróbowalibyśmy wywołać checkout w WooCommerce z pustym koszykiem, to zamiast 200 otrzymamy przekierowanie 301 na pusty koszyk z komunikatem błędu.
Sprawdzenie statusu w tym miejscu weryfikuje nam poprawność całego procesu.
W obrębie wszystkich funkcji są losowe momenty, gdy nasz test robi sobie przerwę np.
sleep(Math.random() * 15);
Z mojego punktu widzenia lepszy jest taki test na większej liczbie userów, niż strzelanie w sklep raz za razem i rozpoczynanie nowych sesji.
Na starcie testu nie mam też efektu nałożenia się wszystkich użytkowników na siebie dokładnie w tym samym czasie, tylko w lekko losowy sposób rozpoczynamy wykonanie scenariusza.
Uzupełniony test puszczamy np. komendą:
k6 run cart_and_checkout.js
Po przeprowadzonym teście otrzymamy podobny do tego wynik.
Przykładowe wyniki testu k6
Jak interpretować wyniki k6?
Test checks
Na samej górze mamy sprawdzenie warunków naszego testu, czyli głównie statusów. Sprawdzamy przede wszystkim czy nasz sklep zwracał prawidłowe odpowiedzi. Jeśli nie mamy 100% - szukamy, gdzie pojawiały się błędy - tu zdecydowanie najprościej to wychwycić z konsoli Grafana cloud.
Http_req_waiting
Ta metryka pokażę Wam ile serwer, a co za tym idzie sklep potrzebował czasu, aby zwrócić odpowiedź. To absolutnie kluczowa metryka dla core web vitals. Nawet jeśli mamy lekki front, a serwer będzie potrzebował dużo czasu na odpowiedź, to ciężko nam będzie zmieścić się w zaleceniach LCP.
Celujemy w czasy poniżej 800ms dla p90/p95, czyli 0.8 sekundy.
Co oznacza p90 i p95?
p90 (percentyl 90%) i p95 (percentyl 95%) wskazują, jaki czas odpowiedzi osiąga 90% lub 95% wszystkich żądań.
Najprostsze wyjaśnienie:
- p90: 90% żądań było szybszych lub równych temu czasowi, a tylko 10% było wolniejszych.
- p95: 95% żądań było szybszych lub równych temu czasowi, a tylko 5% było wolniejszych.
Przykład z wyników powyżej:
- p90=213.48ms: 90% żądań otrzymało odpowiedź w czasie 217ms lub krótszym.
- p95=231.18ms: 95% żądań otrzymało odpowiedź w czasie 237ms lub krótszym.
p95 to popularna miara w branży IT, bo daje wgląd w “najgorsze” doświadczenia użytkowników.
Ilość zapytań
Http_reqs to suma wszystkich zapytań wykonanych w teście. Jeśli podzielimy ją przez długość trwania testu, to otrzymamy średnią ilość zapytań jaką nasz sklep przetwarza w ciągu 1s.
Tutaj to 506/210s - czyli 2.41s na sekundę.
Podsumowanie
Stworzyłem arkusz, który pozwoli nam ocenić czy taki ruch będzie zbliżony skalą dla naszego sklepu. Możesz go zobaczyć tutaj i skopiować, aby wprowadzić swoje dane.
Jeśli jesteś w stanie w testach osiągnąć 10 razy większy ruch niż w estymacji z arkusza, a przy tym zachować dobry czas odpowiedzi, to super. Twój sklep jest szybki. Oczywiście zawsze możesz pracować na tym, aby czasy z poziomu 800ms zbliżyć do 200 czy 300ms, ale masz już świetny punkt wyjścia.
Jeśli nie, to prawdopodobnie Twój sklep wymaga pracy nad doborem wtyczek, pracy z kodem lub zmiany serwera na taki, który ma lepszą konfigurację i więcej zasobów.
Przydatne linki
Grafana Cloud - załóż darmowe konto
Jak sprawić by WooCommerce był szybki
Przykładowy test k6 dla WooCommerce
Jeśli potrzebujesz bardziej skomplikowanego sklepu lub konsultacji dotyczącej konfiguracji WooCommerce - napisz do mnie.
Jeśli masz uwagi dotyczące samego testu lub metodologii, którą tutaj przyjąłem - zostaw komentarz poniżej (wymaga logowania kontem GitHub).
