WordPress 7.0 i WooCommerce 10.x wchodzą w fazę beta w połowie 2026 roku. Dla nas, którzy na co dzień budujemy sklepy B2B na WooCommerce, to najważniejsza zmiana od lat. Chodzi o jedno: headless WooCommerce przestaje być abstrakcją, a staje się realną opcją.
W tym artykule zbieram wszystko, co pojawi się wraz z nowymi wersjami — konkrety, liczby, wpływ na wydajność i co to oznacza dla sklepów B2B.
Stan na czerwiec 2026: WordPress 7.0 jest w fazie beta. WooCommerce 10.5-10.7 zostały już wydane. Poniższe informacje są aktualne na moment publikacji.
Czym właściwie jest headless WooCommerce?
W klasycznym WooCommerce WordPress odpowiada za wszystko — backend (panel admina, baza danych, zamówienia) i frontend (wygląd sklepu, koszyk, proces zamówienia).
W headless WooCommerce WordPress działa tylko jako backend i API. Frontend — strona sklepu, koszyk, konto klienta — działa w osobnej technologii (React, Vue, Next.js). Komunikacja między frontendem a backendem odbywa się przez REST API.
Zalety: dowolny frontend, lepsza wydajność (PageSpeed 95+), pełna kontrola nad UX. Wady: większa złożoność, trzeba utrzymywać dwa systemy.
Do tej pory headless WooCommerce był możliwy, ale bolesny. REST API był wolny, brakowało publicznych endpointów, a cachowanie wymagało pluginów. WordPress 7.0 i WooCommerce 10.x zmieniają to.
Co zmienia WordPress 7.0?
1. REST API nawet o 60-70% szybsze
Największa zmiana — zoptymalizowano sposób, w jaki REST API pobiera dane z bazy. Wcześniej, zwracając listę produktów przez API, WordPress robił osobne zapytanie SQL dla zdjęcia każdego produktu, osobne dla kategorii, osobne dla autora. Przy 24 produktach to było około 72 zapytań. WordPress 7.0 wprowadza leniwe ładowanie danych powiązanych — zamiast 72 zapytań robi 1-2.
Efekt dla sklepu: Strony kategorii, listy produktów i wyniki wyszukiwania ładują się 40-60% szybciej. Dotyczy to zarówno klasycznego sklepu, jak i headless. Oficjalny announcement WordPress 7.0 →
2. Publiczne endpointy menu
Od WordPress 6.8 (rozszerzone w 7.0) menu nawigacyjne są dostępne przez REST API bez logowania. Wcześniej, żeby pobrać menu sklepu przez API, trzeba było być zalogowanym użytkownikiem lub pisać własny endpoint. To była jedna z największych blokad dla headless.
Dla headless WooCommerce oznacza to: Menu kategorii, stron i linków są dostępne z poziomu API bez dodatkowej autoryzacji.
3. Content Types w Core
WordPress 7.0 wprowadza natywny system Content Types — definiowanie struktur danych wbudowane w Core, bez potrzeby custom post types i pluginów (ACF, MetaBox). Dla WooCommerce oznacza to prostsze definiowanie atrybutów produktów, certyfikatów, kart charakterystyki — bez dodatkowego kodu.
4. Lepsze filtrowanie pół API
Parametr _fields w REST API został rozszerzony i przyspieszony. Można teraz precyzyjnie określić, które pola ma zwrócić API — bez przeciążania odpowiedzi zbędnymi danymi. Dla headless sklepów, gdzie każde żądanie API to realny czas ładowania strony, to ma znaczenie.
A co konkretnie zmienia WooCommerce 10.x?
1. Caching REST API (WooCommerce 10.5) — 60-70% redukcji czasu odpowiedzi
WooCommerce 10.5 wprowadził eksperymentalny mechanizm cachowania dla endpointów REST API. Testy na sklepie z 20 000 produktów pokazały:
- Bez cache: 2-2,5 sekundy na odpowiedź
- Z cache: 0,6-0,8 sekundy
- Redukcja: 60-70%
Endpoints objęte cachowaniem automatycznie zwracają nagłówki Cache-Control, ETag i 304 Not Modified. Jeśli dane się nie zmieniły, klient dostaje pustą odpowiedź 304 — zero transferu danych. Ogłoszenie WooCommerce 10.5 →
2. HPOS orders — 51% mniej zapytań (WooCommerce 10.7)
WooCommerce 10.7 (wydany 14 kwietnia 2026) przyniósł największą optymalizację zapytań od lat. Endpoint /wc/v4/orders wcześniej robił 271 zapytań SQL na jedno żądanie. Po cache primingu: 132 zapytania. Redukcja o 51%.
Dla porównania — proces checkout bez cache: 204 zapytania, z cache: 115-127 zapytań.
Do tego dodano filtr woocommerce_pre_refresh_order_count_cache, który pozwala ominąć odświeżanie licznika zamówień w scenariuszach wysokiego ruchu. Release notes WooCommerce 10.7 →
3. Store API — Last-Modified caching
Endpoints Store API (używane przez koszyk i checkout w headless) dostały cache'owanie nagłówka Last-Modified na endpointach produktów. Jeśli dane się nie zmieniły, API pomija zapytanie do bazy i zwraca 304. Oszczędność: kilka-kilkanaście zapytań SQL na każde odświeżenie strony.
4. Order fulfillments API (Beta)
WooCommerce 10.7 wprowadza dedykowane API do realizacji zamówień (order fulfillments) — wersja beta. Dla headless sklepów oznacza to możliwość zarządzania procesem realizacji zamówień w pełni przez API, bez panelu admina.
Store API vs Klasyczne REST API — jaka jest różnica?
Jeśli dopiero zaczynasz z headless WooCommerce, musisz znać różnicę między dwoma API. Często są mylone, a mają zupełnie inne przeznaczenie.
Store API — endpoint pod /wp-json/wc/store/v1/. Zostało zaprojektowane specjalnie dla headless frontendów (React, Vue, Next.js). Zwraca gotowe do wyświetlenia dane koszyka, checkoutu i produktów — z uwzględnieniem kontekstu użytkownika, rabatów, podatków i dostępności. To API, którego powinieneś używać do budowy frontendu sklepu.
Klasyczne REST API — endpoint pod /wp-json/wc/v4/. Zwraca surowe dane z bazy: produkty, zamówienia, klientów, raporty. To API dla integracji i panelu admina — synchronizacja z ERP, import/export danych, panel zarządzania zamówieniami. Nie nadaje się do budowy frontendu, bo nie uwzględnia kontekstu koszyka ani logiki cenowej.
| Cecha | Store API | Klasyczne REST API |
|---|---|---|
| Endpoint | /wc/store/v1/ |
/wc/v4/ |
| Przeznaczenie | Frontend sklepu (koszyk, checkout, produkty) | Backend, integracje, panel admina |
| Koszyk | ✅ Wbudowany — tworzy i zarządza koszykiem | ❌ Brak — trzeba implementować samemu |
| Checkout | ✅ Gotowy proces zamówienia | ❌ Brak — trzeba składać zamówienie ręcznie |
| Rabaty i ceny | ✅ Automatycznie uwzględnia kontekst klienta | ⚠️ Zwraca surowe ceny — rabaty trzeba kalkulować osobno |
| Podatki | ✅ Automatycznie kalkulowane | ⚠️ Zwraca osobne pola — trzeba kalkulować samemu |
| Dostępność | ✅ Sprawdza stan magazynowy w kontekście koszyka | ⚠️ Zwraca tylko liczbę — bez kontekstu |
| Autoryzacja | 🔓 Publiczne (produkty) + sesja (koszyk) | 🔑 Consumer Key / OAuth |
| REST API Caching (WC 10.5) | ✅ Częściowo (Last-Modified na produktach) | ✅ Pełny cache przez RestApiCache trait |
| Zastosowanie | Next.js, React, Vue — frontend klienta | ERP, PIM, marketplace, panel administracyjny |
Więc jak to działa w praktyce? Gdy budujesz headless sklep WooCommerce, używasz obu API. Store API do koszyka, checkoutu i wyświetlania produktów klientowi. Klasyczne REST API do synchronizacji z ERP, importu eksportu danych i zarządzania zamówieniami z poziomu panelu. Dokumentacja Store API →
A kiedy GraphQL nadal ma sens?
GraphQL nie jest natywnie wspierane przez WooCommerce — nie ma oficjalnego endpointu GraphQL w Core. Ale to nie znaczy, że nie ma zastosowania. Są sytuacje, w których GraphQL wygrywa z REST mimo wszystkich usprawnień w WordPress 7.0 i WooCommerce 10.x:
- Agregacja danych z wielu źródeł — jeśli Twój frontend pobiera dane nie tylko z WooCommerce, ale też z CMS-a (blog, strony), systemu ERP, PIM czy marketplace — GraphQL pozwala połączyć to wszystko w jednym zapytaniu, bez multiple-hop REST waterfall.
- Aplikacje mobilne — na słabym łączu mobilnym GraphQL wygrywa, bo pobiera tylko te pola, które są potrzebne. REST zwraca cały obiekt, nawet jeśli potrzebujesz tylko nazwy i ceny.
- Złożone dashboardy i panele analityczne — gdy jeden widok wymaga danych z 5-10 różnych endpointów REST, GraphQL robi to w jednym żądaniu.
- PIM / Content-heavy sklepy — jeśli sklep ma rozbudowane atrybuty produktów, dokumentacje techniczne, karty charakterystyki, GraphQL pozwala zapytać dokładnie o to co potrzebujesz, bez przeciążania odpowiedzi.
W praktyce GraphQL w WooCommerce działa przez wtyczki WPGraphQL (najpopularniejsza, ~1200 gwiazdek na GitHub) lub QXGraphQL. WPGraphQL wspiera WooCommerce od wersji 6.x+ i umożliwia zapytania o produkty, zamówienia, koszyk i klientów. Nie wspiera jednak Store API — więc do checkoutu i koszyka nadal musisz używać REST.
Rekomendacja Genmo: Store API + REST dla standardowych headless sklepów WooCommerce. GraphQL tylko wtedy, gdy potrzebujesz agregacji danych z wielu źródeł w jednym zapytaniu. WordPress 7.0 nie zmienia tego — GraphQL to nie konkurencja dla REST, tylko narzędzie do konkretnych zastosowań.
Co to oznacza dla sklepu B2B?
W Genmo budujemy sklepy B2B, które często:
- Mają 10 000+ produktów
- Synchronizują się z ERP co 5 minut
- Integrują się z BaseLinker, marketplace
- Mają złożone cenniki i rabaty
- Obsługują setki zamówień dziennie
Każda z tych operacji to REST API. Szybsze API oznacza:
- Krótszy czas synchronizacji ERP — z 10 minut do 3-4 minut
- Szybsze strony kategorii — nawet przy 500 produktach na stronę
- Większa przepustowość — ten sam serwer obsłuży więcej żądań
- Niższe koszty serwera — mniej zapytań SQL = mniejsze obciążenie
Czy headless WooCommerce ma sens dla Twojego sklepu?
Headless WooCommerce ma sens, jeśli:
- Potrzebujesz bardzo szybkiego frontendu (PageSpeed 95+)
- Chcesz użyć konkretnego frameworka (React, Vue, Next.js)
- Masz złożoną logikę koszyka i zamówień która nie mieści się w standardowym WooCommerce
- Potrzebujesz tego samego backendu do obsługi sklepu, aplikacji mobilnej i kiosku
Nie ma sensu, jeśli:
- Masz prosty sklep z kilkudziesięcioma produktami
- Nie potrzebujesz ekstremalnej wydajności frontendu
- Nie masz zespołu który utrzyma dwa systemy (backend + frontend)
WordPress 7.0 i WooCommerce 10.x nie zmieniają tego rachunku zysków i strat — ale znacząco zmniejszają koszty (wolne API, brak publicznych endpointów), które wcześniej były głównymi argumentami przeciw headless.
Podsumowanie
| Zmiana | Wersja | Efekt |
|---|---|---|
| Leniwe ładowanie danych REST API | WP 7.0 | 40-60% szybsze strony kategorii |
| Publiczne endpointy menu | WP 6.8 / 7.0 | Headless bez pluginów |
| System Content Types | WP 7.0 | Bez ACF do atrybutów produktów |
| REST API Caching | WC 10.5 | 60-70% redukcji czasu odpowiedzi |
| HPOS cache priming | WC 10.7 | 271→132 zapytań na /wc/v4/orders |
| Last-Modified w Store API | WC 10.7 | Cache produktów bez zapytania SQL |
| Order fulfillments API | WC 10.7 | Pełne API realizacji zamówień |
Dla nas, jako Genmo, to oznacza jedno — headless WooCommerce przestaje być eksperymentem. Staje się realną opcją dla firm B2B, które potrzebują szybkiego, elastycznego sklepu z pełną kontrolą nad frontendem.
Jeśli myślisz o headless WooCommerce dla swojego sklepu — porozmawiajmy. Mamy doświadczenie zarówno w WooCommerce, jak i w budowaniu wydajnych frontendów.