export async function getProduct(slug: string) {
const res = await fetch(process.env.WP_GRAPHQL_URL!,
body: JSON.stringify({
query: `query ProductBySlug($slug: ID!) {
product(id: $slug, idType: SLUG) {
id
name
... on SimpleProduct { price rawPrice: price(format: RAW) stockQuantity }
}
}`,
variables: { slug }
}),
headers: { 'Content-Type': 'application/json' },
next: { tags: [`product-${slug}`], revalidate: 3600 }
});
const { data } = await res.json();
return data?.product;
}Am migrat două magazine mari pe arhitectură decuplată (Next.js + WPGraphQL) și pe al treilea l-am ținut cu dinții pe temă clasică PHP. Dacă te gândești la headless doar ca să scoți 100 în PageSpeed, s-ar putea să-ți arunci bugetul pe geam fără motiv.
Discuția asta nu e despre tehnologii moderne vs vechi, ci despre cash flow și mentenanță pe termen lung.
Cifrele reci: unde crapă WooCommerce clasic
WooCommerce pe PHP monolit devine lent din două cauze clare: interogările grele pe tabela wp_postmeta și sesiunile dinamice de cart care ocolesc Full Page Caching (Varnish/Nginx FastCGI). Cât timp ai trafic liniar, Redis Object Cache și un Varnish bine reglat țin magazinul în picioare fără stres.
Problema apare la promoții agresive. La un magazin de fashion cu care am lucrat, aveam 12.000 de utilizatori simultani în prima oră de Black Friday. Pe PHP clasic, fiecare adăugare în coș și fiecare filtrare după mărime/culoare lovea direct în PHP-FPM și MySQL. Rezultatul? CPU 100% pe un server dedicat de 64 GB RAM, timpi de răspuns de 4-5 secunde pe pagina de checkout și comenzi pierdute.
Pe Next.js, catalogul întreg stă pe Edge (Vercel sau Cloudflare Pages), generat static (ISR). La 12k useri simultani pe catalog, serverul de WordPress nici măcar n-a știut că e Black Friday. A văzut zero request-uri pentru browsing.
Prețul ascuns: de ce o să înjuri decizia
Sună idilic, dar realitatea te lovește când clientul vine și cere plugin-uri:
- Plugin-urile de marketing mor instant. Ai instalat un plugin de bundles, un slider ciudat sau un calculator de livrare? În PHP clasic dai click pe „Activate” și funcționează. În headless, plugin-ul doar scrie date în baza de date; trebuie să expui acele date în GraphQL și să rescrii manual interfața în React.
- Checkout-ul rămâne o problemă. 90% din implementările headless trimit utilizatorul tot pe checkout-ul clasic de WooCommerce (pe un subdomeniu gen
checkout.site.ro) ca să nu rescrie integrarea cu procesatorii locali (Netopia, PayU, Stripe). Utilizatorul simte saltul, chiar dacă maschezi sesiunea prin cookies cross-domain. - Costul de dev se triplează. În loc de un developer mid de WordPress care știe PHP și puțin SCSS, ai nevoie de un om bun pe Next.js (App Router, state management, cache tags) plus cineva care înțelege arhitectura internă WooCommerce.
Breakpoint-ul real: când merită mutarea?
După ce am tras linia pe bugete, am găsit o regulă simplă care funcționează aproape mereu:
- Sub 1.500 de comenzi pe lună / catalog sub 5.000 de produse: Rămâi pe PHP. Pune o temă ultra-ușoară (sau una custom scrisă curat), Redis, Cloudflare APO și PHP 8.2+. Costă infim, se repară rapid și orice freelancer poate interveni dacă pățești ceva.
- Peste 5.000 de comenzi pe lună / campanii recurente de tip flash-sale: Next.js își scoate banii în câteva luni. Aici contează fiecare 100ms la conversie, iar faptul că traficul de browsing e complet izolat de baza de date îți garantează că magazinul nu pică fix când vin banii.
Nu folosi Next.js cu WordPress ca să te joci cu un tech stack nou pe banii clientului. Îl folosești doar când costul serverelor și downtime-ul din campanii dor mai tare decât salariul a doi devi de frontend.
Voi la ce număr de request-uri simultane ați simțit că PHP-ul nu mai face față pe WooCommerce?