Co zrobić, gdy WooCommerce zwalnia? Przewodnik decyzyjny

Dlaczego WooCommerce zwalnia przy większej skali sklepu

Zanim wybierzesz drogę wyjścia, warto zrozumieć, skąd bierze się problem.

Pierwszy siedzi w backendzie. WooCommerce trzyma atrybuty produktów w wp_postmeta — tabeli klucz-wartość, w której każdy atrybut to osobny wiersz. Przy kilkunastu tysiącach produktów z wariantami zapytania filtrów i wyszukiwarki zaczynają mielić miliony wierszy. Do tego dochodzi spuchnięta tabela wp_options ładowana z autoloadem przy każdym żądaniu, koszyk odpytujący admin-ajax.php (cart fragments) przy każdej odsłonie oraz narzut dziesiątek wtyczek, które dokładają swoje hooki do każdego requestu.

Drugi siedzi we froncie. Ciężki motyw z kreatora stron, nieoptymalizowane obrazy, kilkanaście skryptów third-party. Skutkiem jest czerwony PageSpeed.

Dlatego pierwszym krokiem jest by dokonać pomiaru przed decyzją. Wysoki TTFB przy lekkim froncie wskazuje na bazę i hosting, a szybki TTFB przy wolnym LCP, wskazuje na motyw i zasoby. Query Monitor pokaże, które zapytania i wtyczki zjadają czas. Ta diagnoza wprost mapuje się na trzy drogi poniżej: problemy frontendu rozwiązuje scenariusz A albo B, problemy backendu już rozwiązuje scenariusz C.

Scenariusz A: kiedy klasyczny WordPress + WooCommerce powinien zostać

Zacznijmy od najważniejszego, bo tu najczęściej popełnia się błąd w drugą stronę, czyli przestrzelenie formy nad treścią. Zaawansowany, customowy stack dla małego sklepu to wyrzucanie pieniędzy w błoto.

Zostań na klasycznym Woo, jeśli:

• Skala jest mała lub średnia, czyli powiedzmy poniżej kilkunastu tysięcy produktów i bez ekstremalnych pików ruchu.

• Budżet na rozwój jest ograniczony i nie masz dedykowanego zespołu programistów na etacie.

• Sklep opiera się na dziesiątkach gotowych, specyficznych wtyczek do Woo, które obsługują nietypowe subskrypcje, systemy lojalnościowe, kalkulatory wysyłki, integracje z lokalnymi kurierami. Przepisanie tego wszystkiego na customowy kod byłoby ekstremalnie drogie i ryzykowne.

Podsumowując, jeśli sklep działa, a jedynym realnym ograniczeniem jest prędkość, w pierwszej kolejności zainwestuj w porządny, dedykowany hosting (Kinsta, WP Engine) i lekki, czysty motyw zamiast obładowanego kreatora stron. Optymalizacja obrazów, cache i CDN potrafią odzyskać większość utraconej wydajności bez wchodzenia w nową architekturę. Nowy stack to inwestycja, która musi się zwrócić, a przy tej skali tak raczej nie będzie.

Scenariusz B: Headless WooCommerce z Next.js — zostawiamy bazę, zmieniamy frontend

To rozwiązanie pomostowe, idealne dla dużych, już istniejących sklepów, które nie mogą sobie pozwolić na migrację całej bazy, ale duszą się przez bardzo wolny frontend.

Zostawiasz panel WordPressa oraz bazę produktów i zamówień jako backend, ale całkowicie wyrzucasz motyw WP. Cały frontend sklepu piszesz od nowa i to najczęściej w Next.js, łącząc go z Woo przez WPGraphQL albo REST API. Klient nadal zarządza sklepem tam, gdzie zawsze, a użytkownik dostaje błyskawiczny, nowoczesny interfejs.

Kiedy to ma sens

• Masz ogromną bazę danych i integracje z ERP oraz systemami magazynowymi zapięte pod WordPress. Migracja tego byłaby koszmarem obarczonym ryzykiem błędów w danych finansowych.

• Zespół zna i lubi panel WooCommerce, i nie chce się z niego przesiadać.

• Potrzebujesz ekstremalnej prędkości (Core Web Vitals na zielono) oraz unikalnego UX, którego Elementor czy Divi nie są w stanie wygenerować.

Dlaczego Next.js, a nie Astro? Sklep to dynamiczny organizm, a Next.js z mechanizmem ISR (inkrementalna regeneracja statyczna) i rewalidacją na żądanie radzi sobie świetnie z tym, co w e-commerce zmienia się bez przerwy, czyli stany magazynowe, ceny, koszyk i personalizacja użytkownika. Strony produktów generujesz statycznie dla maksymalnej prędkości, a stan magazynowy odświeżasz punktowo, gdy się zmieni:

// app/produkt/[slug]/page.tsx — statyczna strona produktu, świeży stan magazynowy
// WPGraphQL to jeden endpoint /graphql przyjmujący zapytania przez POST
const PRODUCT_QUERY = `
  query Product($slug: ID!) {
    product(id: $slug, idType: SLUG) {
      name
      ... on SimpleProduct {
        price
        stockStatus
      }
    }
  }
`
 
async function getProduct(slug: string) {
  const res = await fetch(process.env.WPGRAPHQL_ENDPOINT!, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query: PRODUCT_QUERY, variables: { slug } }),
    // rewaliduj co 60 s albo na żądanie przez webhook z Woo (revalidateTag)
    next: { revalidate: 60, tags: [`product-${slug}`] },
  })
  const { data } = await res.json()
  return data.product
}

Koszyk, checkout i panel klienta żyją po stronie klienta i w Server Actions — dokładnie tam, gdzie architektura Reacta jest najmocniejsza. Astro w tej roli musiałoby przełączyć się w tryb, w którym traci swoje główne atuty (o czym za chwilę osobno).

Uczciwie o największym koszcie tej architektury: checkout i płatności. Wtyczki bramek płatności renderują się w motywie WordPressa, którego w headless już nie ma — przepływ płatności trzeba zbudować od nowa po stronie Next.js. Częstym i rozsądnym kompromisem jest hybryda: headless katalog dla prędkości i SEO, a sam checkout pozostawiony na klasycznym WP. Brzmi mniej efektownie, ale jako pierwszy etap migracji minimalizuje ryzyko tam, gdzie błędy kosztują najwięcej.

Scenariusz C, czyli całkowita zmiana stacku. Migracja na Shopify albo Medusa

To opcja najbardziej radykalna, gdy WordPress już tylko przeszkadza, a backend i frontend Woo jest źródłem problemów.

Kierunek 1: Shopify (SaaS)

Najlepsze rozwiązanie, kiedy chcesz stabilności e-commerce klasy enterprise i nie chcesz w ogóle myśleć o serwerach, bazach danych i łatach bezpieczeństwa.

Wybieraj, gdy budżet udźwignie prowizje i abonament Shopify, a Ty chcesz skupić się na marketingu i sprzedaży zamiast na łataniu kodu. Zamieniasz problemy techniczne na przewidywalny koszt miesięczny. Warto wiedzieć, że Shopify da się też postawić w wariancie Headless z frontendem w Next.js albo na dedykowanym frameworku Hydrogen (w sytuacji gdy potrzebujesz pełnej kontroli nad wyglądem przy zachowaniu stabilnego backendu Shopify).

Kierunek 2: Medusa (nowoczesny open source na Node.js)

Medusa to w uproszczeniu „nowoczesny, javascriptowy odpowiednik WooCommerce", ale zbudowany od podstaw jako headless. Stworzony do zaawansowanych, unikalnych projektów. Obecna wersja (Medusa 2) ma modularną, rozdzieloną architekturę commerce modules, panel admina w React, oficjalny starter dla Next.js oraz API REST i GraphQL.

Wybieraj wtedy, kiedy potrzebujesz pełnej kontroli nad kodem i danymi, budujesz zaawansowany marketplace, system B2B albo sklep multi-region, a WordPress wydaje Ci się technologicznie przestarzały. Medusa natywnie obsługuje konta firmowe, cenniki, złożone promocje i wielu sprzedawców, czyli rzeczy, które w Woo realizuje się nakładaniem wtyczek na architekturę nie do tego projektowaną.

Pamiętaj, że Medusa wymaga zespołu z Node.js i TypeScriptem oraz zaplecza DevOps do utrzymania własnej infrastruktury (albo skorzystania z Medusa Cloud). To nie jest platforma no-code, tylko framework dla zespołów inżynierskich, które świadomie wybierają kontrolę i długoterminowe posiadanie kodu.

Przy obu kierunkach doliczaj koszt, którego nie widać w demo: migrację danych i SEO. Historia zamówień, konta klientów i subskrypcje muszą przejść bez błędów, a zmiana silnika prawie zawsze oznacza zmianę struktury URL-i — bez kompletnej mapy przekierowań 301 sklep zapłaci za migrację utraconym ruchem organicznym. Jak przeprowadzić takie wdrożenie bez strat w widoczności, opisałem w planie uruchomienia strony.

Dlaczego Astro NIE jest dobrym wyborem dla zaawansowanego e-commerce

Astro jest genialne do stron opartych na treści, czyli blogów, portfolio, landingów, dokumentacji, a jego przewaga bierze się z tego, że domyślnie serwuje zero JavaScriptu. To dokładnie ta cecha, która staje się problemem w e-commerce.

Sklep internetowy jest z definicji dynamiczny, ze względu na ciągłe zmiany stanów magazynowych, filtrowanie produktów na żywo, dynamiczne ceny i promocje, waluty, koszyk, panel klienta. Każdy z tych elementów wymaga interaktywności po stronie przeglądarki. W Astro dodajesz ją przez architekturę wysp (Islands Architecture), czyli punktowo, komponent po komponencie. Świetnie sprawdza się to przy kilku interaktywnych fragmentach na stronie z treścią, ale przy dużym, w pełni dynamicznym sklepie kończy się to „zaśmieceniem" strony dziesiątkami wysp z Reacta czy Vue. W tym momencie tracisz główną zaletę Astro (minimalny JS), a zyskujesz architekturę trudniejszą w utrzymaniu niż spójna aplikacja od początku pomyślana jako interaktywna.

Podsumowując w zaawansowanym e-commerce królują frameworki z mocnym, hybrydowym wsparciem dla SSR i renderowania po stronie klienta, czyli przede wszystkim Next.js. Astro zostaw do tego, w czym jest bezkonkurencyjne: do warstwy treściowej, bloga i landingów wokół sklepu.

WooCommerce, Headless, Shopify czy Medusa: matryca decyzyjna

Ostateczną decyzję trzeba dopasować do skali, budżetu i zespołu. W skrócie: