// Exemplu rapid de fetch pe WPGraphQL pentru a popula o pagină de produs în Next.js
export async function getStaticProps() {
const res = await fetch('https://backend-ul-tau-wp.com/graphql', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
query: `
query GetWooProducts {
products(first: 12) {
nodes {
id
name
slug
image {
sourceUrl
}
... on SimpleProduct {
price
}
}
}
}
`
})
});
const { data } = await res.json();
return {
props: {
products: data?.products?.nodes || []
},
revalidate: 60 // ISR la fiecare minut ca să nu omorâm baza de date
};
}Am tot văzut hype-ul ăsta masiv cu „headless WordPress” pe Next.js și cum toată lumea promite performanțe de Core Web Vitals perfecte. Am trecut prin tranziția asta anul trecut cu un magazin destul de măricel, cam 40.000 de produse active și în jur de 85.000 de vizitatori unici pe lună.
Spoiler alert: nu e totul lapte și miere, iar decizia asta ar trebui să fie pur financiară, nu bazată pe ce e la modă pe Twitter sau Reddit.
Când începe să scârțâie monolith-ul PHP?
WordPress-ul clasic e genial până la un punct. Cât timp ai pagini care pot fi complet cash-uite prin Cloudflare sau LiteSpeed, totul zboară. Problema apare când traficul ăla devine foarte dinamic.
La proiectul menționat, aveam campanii de Black Friday unde trimiteam mii de oameni simultan pe pagini de produs. În momentul în care 200-300 de useri adăugau în coș în aceeași secundă, baza de date se bloca. De ce? Pentru că WooCommerce rula toate sesiunile, query-urile de stoc și AJAX-urile de coș prin aceeași mașinărie greoaie de PHP. Am încercat să aruncăm cu servere mai mari (ajunsesem să plătim 180$ pe lună pe un VPS optimizat), dar tot aveam spikes de TTFB de peste 2 secunde la checkout.
De ce am trecut pe Next.js și care a fost prețul real
Am decis să decuplăm frontend-ul. Am lăsat WordPress strict ca backend (WP REST API + WPGraphQL) administrat de pe un server ieftin, iar frontend-ul l-am scris în Next.js, găzduit pe Vercel.
Rezultatul imediat? Viteza de navigare a fost brutală. Paginile se încarcă instant datorită Static Site Generation (SSG) și Incremental Static Regeneration (ISR). Am salvat cam 30% la rata de bounce pe mobil, ceea ce s-a tradus direct în conversii mai bune.
Dar acum vine trade-off-ul sincer, despre care agențiile de marketing nu-ți spun nimic:
- Plugin-urile nu mai funcționează direct. Ai un plugin de transport care afișează punctele de livrare pe hartă în checkout? Sau un plugin de discount-uri dinamice? În headless, ele nu mai există pe frontend. Trebuie să le rescrii manual în React și să le legi prin API-uri personalizate.
- Costul de dezvoltare. Ce făceam înainte în 2 ore pe o temă PHP (de exemplu, adăugarea unui câmp custom în pagina de produs), în Next.js ne lua o zi întreagă de muncă, pentru că trebuia să expunem câmpul în GraphQL, să-l preluăm în frontend, să-i facem tipizare și să-l stilizăm.
- Găsirea oamenilor. Să găsești un programator care știe și WP la nivel de backend/baze de date și React/Next.js la nivel avansat e extrem de greu și scump în România.
Breakpoint-ul real: Când merită efortul?
După experiența asta, am tras o linie clară.
Sub 50.000 de vizite pe lună: Rămâi pe o temă clasică de PHP (cum e WoodMart sau o temă custom minimalistă) bine optimizată, cu Redis, un plugin de cache serios și un CDN bun. Nu are absolut niciun sens economic să te complici cu Next.js. Costurile de mentenanță vor depăși profitul generat de acele câteva milisecunde câștigate.
Peste 100.000 de vizite pe lună SAU când ai campanii masive de marketing: Aici Next.js începe să-și scoată banii. Când ai nevoie ca landing page-urile să nu pice indiferent de câți influenceri trimit trafic simultan, decuplarea e sfântă. Backend-ul tău de WordPress va respira ușurat pentru că va procesa doar request-urile de checkout și stoc, nu și randarea de HTML.
Fiecare arhitectură are locul ei. Voi ați avut tentative de headless cu WooCommerce? Unde v-ați blocat cel mai des?