// Exemplu rapid de fetch pentru produse via WP-GraphQL
// E mult mai rapid decât REST API-ul clasic în WooCommerce
const GET_PRODUCTS = `
query GetProducts($first: Int) {
products(first: $first) {
nodes {
id
name
slug
... on SimpleProduct {
price
regularPrice
}
}
}
}
`;
export async function getStaticProps() {
const res = await fetch(process.env.WORDPRESS_API_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ query: GET_PRODUCTS, variables: { first: 12 } }),
});
const { data } = await res.json();
return {
props: {
products: data.products.nodes,
},
revalidate: 60, // Incremental Static Regeneration
};
}Am observat că în ultima vreme a devenit un fel de modă să arunci cu Next.js în orice proiect de WordPress. Toți clienții vor „viteză de rachetă”, iar devii vor să scape de coșmarul numit wp_enqueue_script. Dar după ce am livrat trei magazine WooCommerce pe stack-ul ăsta (unul cu peste 12.000 de produse), pot să spun cu mâna pe inimă: e un cuțit cu două tăișuri care taie foarte adânc în bugetul de mentenanță.
Când PHP-ul începe să gâfâie
Am avut cazul unui client cu un magazin de nișă pe piese auto. Pe o temă clasică de PHP, totul era ok până când băga 2000 de euro în campanii de Facebook Ads și îi intrau 400-500 de useri simultan. Chiar și cu Redis și WP Rocket, serverul (un VPS decent de 40 euro) începea să dea 504. PHP-ul e secvențial prin natura lui și, oricât l-ai optimiza, la un moment dat ajungi la limitările procesorului dacă ai prea multe apeluri la DB pe fiecare pagină.
Pragul real unde am simțit că PHP-ul devine o problemă e undeva pe la 150-200 de utilizatori concurenți pe un server standard. Dacă ai un magazin mic, cu 10 comenzi pe zi, să faci Headless e pur masochism. Rămâi pe o temă ușoară (ca Hello Elementor sau GeneratePress, dar scrisă curat) și economisești luni de muncă.
Coșmarul integrărilor în Headless
Chestia pe care nu ți-o spune nimeni în tutorialele de pe YouTube e că în momentul în care ai scos frontend-ul din WordPress, ai omorât 90% din ecosistemul de plugin-uri. Vrei un plugin de cupoane deștepte? Trebuie să-i scrii tu integrarea în Next.js. Vrei un checkout custom de la un procesator de plăți local? Mult noroc să mapezi toate câmpurile prin WP-GraphQL sau REST API.
La proiectul de care ziceam, am economisit vreo 30% la timpul de încărcare (LCP-ul a scăzut de la 2.4s la 0.8s), dar am triplat timpul de dezvoltare pentru chestii banale. De exemplu, filtrarea produselor după atribute. În PHP e un widget; în Next.js e un întreg sistem de management de stare, rute dinamice și query-uri complexe care trebuie să fie rapide.
Trade-off-ul sincer: Performanță vs. Agilitate
Merge brici pentru SEO și UX. Userul dă click și pagina e acolo instant, fără acel „white flash” specific PHP-ului. Dar e groaznic pentru marketing. Oamenii de marketing vor să schimbe bannere, să bage trackere de TikTok, să modifice layout-ul paginii de mulțumire. Într-un setup Headless, cam orice modificare de genul ăsta trece prin tine, developerul, pentru că nu mai au „Customizer” sau page buildere care să funcționeze direct pe frontend-ul tău de React.
Am calculat la un moment dat: costul total de ownership (TCO) pentru un magazin Headless e cu cel puțin 60% mai mare în primii doi ani. Plătești mai mult pe dev, plătești hosting separat (Vercel/Netlify + VPS-ul de WordPress), și plătești timpul pierdut când se schimbă ceva în API-ul de WooCommerce la un update major.
Concluzia mea
Recomand WordPress Headless doar dacă te încadrezi în una din situațiile astea:
- Ai un trafic constant de peste 500 de useri simultan și vrei să scalezi orizontal frontend-ul pe un CDN.
- Ai deja o aplicație mobilă și vrei să folosești același backend de e-commerce pentru tot.
- Design-ul e atât de complex încât te-ai lupta mai mult cu template-urile de PHP decât să scrii componente de React de la zero.
În rest, pentru magazinul mediu din România, o temă PHP bine optimizată, cu un server Nginx configurat corect și caching la nivel de obiecte, bate orice soluție Headless la capitolul ROI.
Voi ați avut curajul să treceți un client mare pe Headless sau ați rămas la „vechiul” PHP?