WooCommerce 11.1 i plan WordPress 7.1.1 – co zmieniają

Wydajność zaczyna się od architektury

Masz dwie drogi do szybszego sklepu. Możesz dołożyć kolejną wtyczkę do pamięci podręcznej albo zdjąć z serwera pracę, której w ogóle nie musi wykonywać. Początek września 2026 roku dobrze pokazuje, dlaczego druga droga coraz częściej daje lepszy i bardziej przewidywalny efekt.

WooCommerce 11.1 trafił do stabilnego kanału 3 września. WordPress 7.1.1 był w tym samym czasie dopiero porządkowany jako wydanie poprawkowe po dużej wersji 7.1. To różne etapy cyklu wydawniczego, ale wspólny wniosek jest jeden: szybkość sklepu zależy nie tylko od liczby wtyczek, lecz przede wszystkim od bazy danych, pamięci podręcznej i przebiegu każdego żądania.

Dwa projekty i dwa różne etapy prac

WordPress 7.1 został wydany 19 sierpnia. Plan wersji 7.1.1 ogłoszono 2 września i ograniczono go do błędów oraz regresji z cyklu 7.1. Spotkania poświęcone selekcji zgłoszeń odbyły się 3 i 4 września, pierwszą wersję kandydującą zaplanowano na 10 września, a wydanie stabilne na 17 września. Na dzień publikacji tego artykułu nie ma więc nowej paczki WordPress 7.1.1 do instalacji.

WooCommerce przeszedł już pełną drogę wydawniczą: zamrożenie funkcji 10 sierpnia, wersje beta 17 i 24 sierpnia oraz pierwszą wersję kandydującą 31 sierpnia. Problemy z mini-koszykiem wymusiły drugą wersję kandydującą 2 września i przesunięcie premiery o jeden dzień. Stabilne wydanie obejmuje 561 zmian przygotowanych przez 77 osób, zachowuje zgodność wsteczną i wymaga aktualizacji bazy danych.

Najważniejsze funkcje WooCommerce 11.1

Galerie dla wariacji produktów zostały przeniesione do rdzenia WooCommerce. Funkcja nie jest już eksperymentalna, a migracja w wydaniu 11.1 włącza ją również w sklepach, w których wcześniej była wyłączona. Dla części witryn oznacza to możliwość rezygnacji z dodatkowej wtyczki, ale dopiero po sprawdzeniu galerii wszystkich typów produktów i zgodności motywu na środowisku testowym.

Druga nowość odpowiada na potrzeby handlu w Unii Europejskiej. Funkcja odstąpienia od zamówienia jest domyślnie wyłączona. Po jej aktywacji klient otrzymuje formularz na swoim koncie, prośba zostaje zapisana jako notatka przy zamówieniu, a obsługa sklepu dostaje wiadomość. Nie jest to automat anulujący zamówienie i zwracający pieniądze, tylko uporządkowany kanał zgłoszenia.

Szybsze API bez zbędnej rejestracji bloków

Najważniejsza zmiana wydajnościowa nie dodaje kolejnej warstwy pamięci podręcznej. WooCommerce przestaje wykonywać pracę, która w wielu żądaniach była zbędna. Do wersji 11.0 typy bloków i wzorce rejestrowano niemal przy każdym żądaniu, nawet jeśli odpowiedź w ogóle nie zawierała bloków.

W wersji 11.0 wzorce zaczęły być rejestrowane przez ścieżkę pliku i wczytywane dopiero wtedy, gdy potrzebował ich edytor. Dawało to od 5 do 8 milisekund oszczędności. WooCommerce 11.1 idzie dalej: mechanizm kontekstu rejestracji bloków całkowicie pomija tę czynność dla zadań cyklicznych, żądań asynchronicznych i interfejsów programistycznych, które nie renderują bloków.

W pomiarach zespołu odpowiedzi Store API i REST API były szybsze o 13–18 milisekund, czyli o 30–42 procent. Front sklepu, panel administracyjny i edytor mają działać bez zmiany. Opisy produktów zawierające bloki są obsługiwane na żądanie także w interfejsach API, wariacjach i powiadomieniach wychodzących.

Wyjątkiem są rozszerzenia, które samodzielnie renderują bloki w żądaniach API. WooCommerce udostępnia dla nich filtr pozwalający przywrócić rejestrację. Ponieważ działa on bardzo wcześnie podczas uruchamiania wtyczek, decyzja musi opierać się na informacjach dostępnych już na tym etapie żądania.

Bezpieczniejsza finalizacja zamówienia i zwroty

WooCommerce 11.1 rozwija także obsługę zwrotów. Interfejs REST pozwala obliczyć wartości zwrotu oraz przygotować jego podgląd bez księgowania operacji. Dzięki temu integracja może najpierw sprawdzić wynik, zanim wprowadzi nieodwracalną zmianę w zamówieniu.

Finalizacja zamówienia przez Store API otrzymała kontrolę oczekiwanej sumy. Jeżeli kwota przesłana przez przeglądarkę nie zgadza się z obliczeniem serwera, żądanie zostaje odrzucone odpowiedzią o konflikcie. Mechanizm ogranicza ryzyko złożenia zamówienia na podstawie nieaktualnej zawartości koszyka lub zmienionych warunków cenowych.

Import produktów z pliku lepiej zachowuje kategorie i pozostałe przypisania klasyfikacyjne przy ponownym wgraniu, potrafi usunąć obrazy, gdy plik wejściowy wyraźnie to wskazuje, i respektuje walutę sklepu. W tle rozwijane są również eksperymentalne filmy w galerii oraz scalanie zasobów edytora bloków, które po włączeniu ogranicza liczbę jego plików o ponad 90 procent.

Co rzeczywiście wniósł WordPress 7.1

WordPress 7.1 jest dużym wydaniem obejmującym ponad 310 zgłoszeń w rdzeniu, około 600 zmian z kolejnych wersji Gutenberga i 20 nowych punktów rozszerzeń. Wprowadza między innymi responsywne style oraz stany interaktywne bez ręcznego dopisywania arkuszy stylów, konfigurowalne punkty przełamania w ustawieniach motywu i rozbudowany edytor mediów.

Zmiany obejmują także nieskończone przewijanie biblioteki, stały pasek administracyjny w edytorze, formatowane notatki ze wzmiankami, playlisty, karty, gradienty tła i nowe interfejsy dla ikon oraz możliwości systemu. Edytor bloków działa obowiązkowo w ramce dla bloków zgodnych z trzecią wersją interfejsu bloków.

Nie wszystkie czerwcowe zapowiedzi weszły do wydania. Ukrycie klasycznego bloku cofnięto po dyskusji, React 19 przesunięto poza wersję 7.1, a współpraca w czasie rzeczywistym i widżet wspomnień również nie trafiły do finału. Wersja 7.1.1 ma porządkować błędy tego cyklu, a nie dodawać kolejne funkcje.

Ładowanie spekulacyjne bez ryzyka dla sklepu

Ładowanie spekulacyjne pozwala przeglądarce wcześniej pobrać albo przygotować kolejną stronę po wskazaniu odnośnika, jeszcze przed kliknięciem. Roadmapa WordPressa zapowiadała automatyczne przejście z trybu zachowawczego na umiarkowany po wykryciu pamięci podręcznej obiektów i stron. Taka automatyka nie znalazła się jednak w kodzie wersji 7.1.

Domyślna konfiguracja pozostaje zachowawcza. Tryb umiarkowany na komputerach może rozpocząć pobieranie lub wstępne renderowanie już po około 200 milisekundach wskazywania odnośnika. Jeżeli strona nie jest serwowana z pamięci podręcznej, każde takie przygotowanie oznacza pełne żądanie do PHP i bazy danych.

W sklepie koszyk, finalizacja zamówienia i konto klienta i tak omijają pamięć podręczną stron. Dlatego umiarkowane ładowanie spekulacyjne ma sens przede wszystkim dla treści i kategorii skutecznie obsługiwanych na brzegu sieci. Ścieżki transakcyjne, API oraz akcje zmieniające liczniki powinny pozostać wykluczone.

Baza danych jako główne wąskie gardło

Większy serwer daje więcej zasobów, lecz nie naprawia nieefektywnego sposobu ich użycia. W rozbudowanych sklepach regularnie powtarza się problem tabeli metadanych wpisów bez odpowiednich indeksów złożonych. Zapytanie trwające 20 milisekund przy małej bazie może z czasem urosnąć do 2 sekund.

Produkt z 30 wariacjami może wygenerować od 400 do 600 wierszy metadanych. Katalog obejmujący 15 tysięcy produktów oznacza więc od 6 do 10 milionów wierszy. Filtrowanie jednocześnie po rozmiarze, kolorze i cenie wymaga wtedy wielu połączeń tabel, przetwarzania wartości tekstowych i tworzenia tabel tymczasowych.

Drugim obciążeniem są opcje ładowane automatycznie przy każdym żądaniu. Gdy ich łączny rozmiar przekracza 1 megabajt, każda odsłona przenosi ten sam balast przez proces PHP. Trzecim problemem są zadania Action Schedulera i WordPressa uruchamiane podczas żądania strony, które mogą opóźnić odpowiedź właśnie w chwili zakupu.

HPOS, pamięć podręczna i zadania cykliczne

HPOS przenosi zamówienia z ogólnych tabel wpisów i metadanych do dedykowanych tabel WooCommerce z typowanymi kolumnami i indeksami. Sklepy z ponad 10 tysiącami zamówień mogą dzięki temu uzyskać kilka razy szybsze listy zamówień, mniejsze obciążenie bazy oraz większą przepustowość finalizacji zakupów.

Migracja powinna przebiegać kontrolowanie, w trybie zgodności i za pomocą narzędzia wiersza poleceń WooCommerce. Przed przełączeniem trzeba sprawdzić, czy rozszerzenia nie pobierają zamówień bezpośrednio przez metadane wpisów albo zapytania kierowane do starego typu zamówienia. Dopiero pozytywna weryfikacja danych pozwala bezpiecznie zakończyć przejście.

Po uporządkowaniu bazy pomaga obiektowa pamięć podręczna Redis z rozszerzeniem Relay, które przechowuje często używane dane również w pamięci procesu PHP. Wyszukiwanie oparte na wolnych porównaniach tekstowych można przenieść do wyspecjalizowanego silnika, a zadania cykliczne uruchamiać z harmonogramu systemowego zamiast podczas wizyty klienta.

Osobna baza i osobna pamięć podręczna mają sens dopiero po takim uporządkowaniu, gdy sklep nadal obsługuje od 50 do 100 jednoczesnych użytkowników, setki zamówień dziennie, bazę o rozmiarze od 20 do 50 gigabajtów i zapytania trwające od pół do dwóch sekund. Wcześniej większy zwrot zwykle dają indeksy, HPOS i ograniczenie danych ładowanych automatycznie.

Aktualizacje bezpieczeństwa i zależności

Wydajność nie może przesłonić bezpieczeństwa. WooCommerce 11.0.1 z 10 sierpnia był wydaniem zabezpieczającym bez migracji bazy. Poprawiał między innymi oczyszczanie danych wejściowych, kontrolę uprawnień, obsługę sesji gości, sprawdzanie tokenów Store API i uprawnienia przy operacjach na obrazach oraz motywach.

W marcu poprawiono krytyczną lukę w Store API obejmującą wersje od 5.4 do 10.5.2. Złośliwe żądania grupowe mogły po interakcji użytkownika doprowadzić do utworzenia konta administratora. W sierpniu osobnej aktualizacji wymagała bramka Stripe w wersjach od 9.7.0 do 10.8.4, ponieważ błąd mógł spowodować niedostępność sklepu.

Sam skok WooCommerce do 11.1 nie zastępuje więc audytu pozostałych rozszerzeń. Przed wdrożeniem trzeba sprawdzić wersję bramki płatniczej, kopie zapasowe, mechanizmy sesji, integracje API i zgodność dodatków z aktualizacją bazy danych.

Plan działania dla małego i dużego sklepu

W małym sklepie z niewielkim katalogiem i kilkudziesięcioma zamówieniami dziennie rozsądnym krokiem jest aktualizacja do WooCommerce 11.1 na środowisku testowym, a następnie na produkcji. Wbudowany zysk 13–18 milisekund dla API nie wymaga dodatkowej konfiguracji. Trzeba jednak sprawdzić, czy któreś rozszerzenie nie renderuje bloków w niestandardowych żądaniach.

W dużym sklepie z historią powyżej 10 tysięcy zamówień i filtrami opartymi na metadanych kolejność jest ważniejsza niż kolejna wtyczka. Najpierw sprawdź:

• indeksy używane przez zapytania do metadanych produktów,
• łączny rozmiar opcji ładowanych automatycznie,
• stan migracji i zgodności z HPOS,
• sposób uruchamiania Action Schedulera oraz zadań cyklicznych,
• wolne zapytania na koszyku i podczas finalizacji zamówienia,
• wykluczenia pamięci podręcznej i ładowania spekulacyjnego.

Dopiero po tych kontrolach warto oceniać Redis, zewnętrzną wyszukiwarkę, osobny serwer bazy albo zmianę czułości ładowania spekulacyjnego. Każda z tych warstw rozwiązuje inny problem i nie zastępuje pomiaru rzeczywistego wąskiego gardła.

Najpierw usuń pracę, potem dodawaj zasoby

WooCommerce 11.1 pokazuje właściwy kierunek optymalizacji: nie przyspiesza zbędnej pracy, tylko przestaje ją wykonywać. Pominięcie rejestracji bloków w żądaniach, które niczego nie renderują, skraca odpowiedzi API bez dokładania kolejnego mechanizmu pamięci podręcznej.

WordPress 7.1 pozostaje zachowawczy w ładowaniu spekulacyjnym, ponieważ agresywniejsze ustawienie bez wydajnego źródła mogłoby zwiększyć obciążenie. Planowana wersja 7.1.1 porządkuje błędy po dużym wydaniu, ale na dzień 6 września nie jest jeszcze wersją stabilną.

Największą poprawę uzyskają sklepy, które potraktują nowe numery wersji jako impuls do uporządkowania fundamentów. Aktualizacja może zdjąć część pracy z API, lecz nie naprawi wielomilionowej tabeli bez odpowiednich indeksów, nadmiernego automatycznego ładowania opcji ani zadań cyklicznych uruchamianych podczas zakupu.