export async function getStaticProps({ params }: { params: { slug: string } }) {
const res = await fetch(`https://api.magazin-wp.ro/wp-json/wc/v3/products?slug=${params.slug}`, {
headers: {
Authorization: `Basic ${Buffer.from(`${process.env.WC_KEY}:${process.env.WC_SECRET}`).toString('base64')}`,
},
});
const [product] = await res.json();
if (!product) return { notFound: true };
return {
props: { product },
revalidate: 60, // ISR: se regenerează la max 60s la trafic
};
}Am migrat primul WooCommerce pe arhitectură headless prin 2021, orbit de promisiunea unui Lighthouse 100 curat. De atunci am trecut prin încă patru proiecte similare și am dat rollback la unul, direct înapoi pe temă clasică de PHP. Dacă te bate gândul să separi frontend-ul de WordPress, hai să disecăm pragul real unde mutarea asta aduce bani, nu doar frustrări.
Iluzia vitezei și costul ascuns
Toată lumea laudă headless pentru viteză, dar realitatea e că 90% din magazinele online nu au o problemă de frontend, ci de server și interogări proaste în MySQL.
Am avut un magazin de piese auto cu 45.000 de SKU-uri și în jur de 8.000 de comenzi pe lună. Proprietarul voia Next.js pentru că „se mișcă greu”. Am pus Redis pentru object cache, am configurat Varnish corect în fața unui Nginx bine tunat și am curățat vreo 12 plugin-uri inutile. TTFB-ul a scăzut de la 1.4s la 120ms pe paginile de categorie, cu tema PHP existentă. Costul? Două zile de lucru, nu trei luni de rescris tot UI-ul în React.
Când treci pe headless, nu scapi de WordPress; doar îl transformi într-o bază de date cu REST API sau GraphQL. Iar WP REST API este, din păcate, destul de lent dacă nu îi pui un strat serios de caching pe endpoint-uri.
Breakpoint-ul real: când are sens Next.js?
Nu iei decizia asta pe baza numărului de produse, ci pe baza tipului de trafic și a cerințelor de business. Din testele mele, trecerea la Next.js devine justificată în trei scenarii clare:
- Spike-uri violente de trafic (campanii TV, Black Friday masiv): Dacă ai 3.000 - 5.000 de utilizatori simultani care intră în 10 minute, PHP-FPM va crăpa sau va cere servere scumpe. Next.js cu Incremental Static Regeneration (ISR) servește paginile direct din CDN/Edge ca fișiere statice. Baza ta de date nici măcar nu simte vizitele, procesând doar sesiunile de checkout.
- Omnichannel real: Ai nevoie de același backend de produse pentru site, aplicație mobilă în React Native și un ecran interactiv dintr-un magazin fizic. Aici WP pe post de CMS headless strălucește.
- Flow-uri complexe de configurare: Dacă vinzi produse personalizate (ex: configurator 3D, calculatoare complexe de preț) unde interfața e mai mult aplicație web decât catalog clasic de produse.
Unde te lovești cu capul de prag
Trade-off-ul este masiv pe partea operațională. În secunda în care ai scos tema de PHP, pierzi compatibilitatea nativă cu 95% din plugin-urile de marketing.
Vrei ca echipa de marketing să schimbe bannere sau să facă A/B testing? Trebuie să construiești tu componente flexibile. Vrei preview la ciorne înainte de publicare? Ai de implementat preview mode în Next.js cu token-uri de autentificare. Formularele de contact, integrarea cu procesatorul de plăți (Netopia, Stripe) și calculul dinamic de transport pentru curieri locali (Fan Courier, Sameday) trebuie rescrise manual ca microservicii sau API routes.
De asemenea, mentenanța se dublează: ai o infrastructură Node.js (pe Vercel sau VPS propriu) plus instanța de WordPress cu PHP și MySQL care trebuie ținută la zi și securizată.
Monolitul PHP câștigă detașat până la 100k vizite/lună dacă investești 10% din bugetul de dezvoltare într-un hosting serios și optimizare de cache. Headless merită doar când arhitectura monolitică devine o barieră tehnică de nesuportat pentru scalare.
Voi ați făcut pasul spre headless pe proiecte mari de e-commerce sau ați rămas pe stack-ul clasic?