const GET_PRODUCTS = `
query GetProducts($first: Int) {
products(first: $first) {
nodes {
id
name
slug
... on SimpleProduct {
price
}
}
}
}
`;
// Fetch-ul e rapid, dar pierzi tot ecosistemul de hook-uri din WooCommerce PHP.Văd tot mai mulți clienți care cer „Headless WordPress” doar pentru că au auzit ei că e rapid. Și văd mulți developeri care sar cu capul înainte pentru că vor să scrie React în loc de PHP vechi. Am avut anul trecut un proiect cu un magazin online care avea vreo 12.000 de SKU-uri și am decis să mergem pe Next.js. După șase luni de mentenanță, mi-am dat seama că ambele variante au niște bube pe care nimeni nu le discută sincer la început.
Când tema de PHP devine o frână reală
WP-ul clasic e greoi prin definiție. Când ai un magazin cu 10k+ vizitatori unici pe zi, baza de date începe să gâfâie din cauza interogărilor complexe de WooCommerce. Dacă mai pui și un page builder gen Elementor sau Divi, ești terminat la capitolul Core Web Vitals. Am pățit la un client să avem Time to First Byte (TTFB) de peste 2 secunde doar pentru că tema încărca 40 de scripturi aiurea.
În punctul ăla, dacă ai buget, headless chiar te salvează. Am reușit să scădem timpul de încărcare cu vreo 60% trecând pe Next.js. Userul simte navigarea instantanee, iar conversia crește pentru că paginile de produs nu mai stau să se „gândească” la fiecare click. Dar, și e un mare DAR aici, costurile de server au crescut pentru că acum plăteam și un VPS pentru WP (ca API) și deployment-ul pe Vercel.
Coșmarul integrărilor: de ce headless e greu
Cel mai mare trade-off pe care l-am simțit a fost pierderea ecosistemului. Vrei un plugin de cupoane speciale? În PHP dai click pe Install. În Headless, trebuie să verifici dacă pluginul are puncte terminale în REST API sau WPGraphQL. De cele mai multe ori nu are, deci stai și scrii tu rute custom.
Am pierdut vreo 3 zile doar ca să fac integrarea cu un procesator de plăți local care nu avea SDK de JS, ci doar un plugin de WP care făcea redirect-uri bazate pe hook-uri de PHP. E frustrant. Dacă proiectul nu are un buget de mentenanță de cel puțin 1.500 - 2.000 euro pe lună, nu te atinge de headless. O să rămâi blocat în bug-uri de sincronizare între coșul de cumpărături din React și sesiunea de PHP din spate.
Breakpoint-ul real de trafic
Din experiența mea de până acum, am tras o linie destul de clară. Dacă magazinul are sub 5.000 de vizitatori pe zi, rămâi pe o temă de PHP curată (cum e Hello Elementor sau ceva custom pe Blocks). E mult mai ieftin de întreținut și poți obține scoruri de 90+ în Lighthouse cu un cache bine configurat și un CDN bun.
Investiția în Next.js cu WPGraphQL merită doar când treci de pragul de 15.000 - 20.000 de vizitatori pe zi sau când ai campanii masive de tip Black Friday. Atunci, faptul că frontend-ul e decuplat și servit static (ISR) îți salvează baza de date de la colaps total. Am economisit cam 30% la resursele de procesare ale bazei de date după ce am mutat tot ce înseamnă „read” în pagini statice generate la build time.
E mai mult o decizie de business decât una tehnică. Vrei viteză brută și scalabilitate cu prețul unei dezvoltări de 3 ori mai scumpe? Sau vrei flexibilitate și viteză de implementare pe un stack clasic?
Voi ați avut clienți care au insistat pe headless și apoi s-au plâns că nu mai pot folosi plugin-urile lor preferate de marketing?