La pregunta «Next.js o WordPress?» sol començar pel lloc equivocat.
Abans preguntaria:
què ha de fer la web i qui hi treballarà després?
Amb WordPress i amb Next.js es poden construir webs ràpides, lentes, fàcils de mantenir o impossibles de tocar.
Això no ho decideix la tecnologia tota sola.
I tampoc no són ben bé el mateix tipus d'eina.
WordPress és un sistema de gestió de continguts. Inclou base de dades, panell d'administració, editor visual, temes i un ecosistema enorme de plugins.
Next.js és un framework de React per construir aplicacions web. Dona control sobre la interfície, el renderitzat, les dades i la lògica, però no inclou per defecte cap CMS on el client entri a editar la seva web.
Aquesta diferència explica bona part de l'elecció.
Quan triaria WordPress
WordPress té molt de sentit quan l'edició del contingut és una part important del projecte.
Per exemple:
- l'equip publica articles o pàgines sovint;
- diverses persones han d'editar sense dependre de desenvolupament;
- la web és sobretot editorial;
- necessites funcionalitats estàndard que ja estan ben resoltes;
- l'equip ja treballa còmodament amb WordPress.
El seu editor de blocs permet modificar contingut i construir pàgines des del mateix panell.
Això no vol dir que una web WordPress hagi de fer servir una plantilla genèrica.
També s'hi pot desenvolupar un tema completament a mida.
L'avantatge és que la gestió del contingut ja forma part del sistema.
Quan triaria Next.js
Next.js comença a tenir més sentit quan la interfície o el funcionament de la web necessita força control.
Per exemple:
- una direcció visual molt específica;
- interaccions que són una part important de l'experiència;
- dades que vénen de diverses fonts;
- integracions amb eines externes;
- àrees privades;
- lògica pròpia;
- una web que comença a comportar-se més com una aplicació.
També permet decidir amb força precisió com es genera i s'entrega cada pàgina.
Però això no vol dir que Next.js sigui automàticament ràpid, tingui millor SEO o sigui més fàcil de mantenir.
Es pot construir malament amb qualsevol tecnologia.
I si el client necessita editar contingut?
Fer servir Next.js no vol dir renunciar a un panell.
El pots connectar a un CMS.
El contingut pot viure a Sanity, Strapi, WordPress, Shopify o un altre sistema, mentre Next.js s'encarrega de mostrar-lo.
Així l'equip pot editar productes, articles, projectes, serveis o qualsevol contingut que hàgim preparat perquè el gestioni.
El que normalment continuarà necessitant desenvolupament són els canvis en:
- components;
- plantilles;
- lògica;
- integracions;
- comportament de l'aplicació.
L'autonomia no depèn només del framework.
Depèn de com s'hagi dissenyat el sistema.
Headless: WordPress i Next.js poden treballar junts
Triar-ne un no sempre vol dir descartar l'altre.
WordPress es pot fer servir només per gestionar el contingut i lliurar aquestes dades a través de la seva API.
Next.js pot fer servir aquestes dades per construir el frontend.
És el que se sol anomenar una arquitectura headless.
Pot tenir sentit quan un equip vol conservar una experiència d'edició coneguda però necessita un frontend molt personalitzat.
També hi afegeix complexitat.
Ara tens dos sistemes per connectar, desplegar i mantenir.
Per això no faria servir una arquitectura headless només perquè sigui tècnicament interessant.
Ha de resoldre un problema real.
El manteniment existeix en tots dos
Aquesta és una diferència que de vegades s'explica massa malament.
A WordPress has de mantenir:
- el mateix WordPress;
- plugins;
- tema;
- servidor;
- la compatibilitat entre totes aquestes peces.
A Next.js també hi ha manteniment:
- framework;
- React;
- dependències;
- integracions;
- entorn d'execució;
- plataforma on es desplega.
Una web Next.js estàtica o amb molt poca lògica de servidor pot tenir menys peces actives en producció que una instal·lació WordPress complexa.
Però això no vol dir que quedi congelada per sempre.
La pregunta no és:
«quin no necessita manteniment?»
Tots dos en necessiten.
La pregunta és quines peces acceptem mantenir i qui se n'encarregarà.
El rendiment i el SEO no decideixen l'elecció per si sols
Pots aconseguir molt bon rendiment amb WordPress.
També pots fer una web Next.js innecessàriament pesada.
I amb el SEO passa el mateix.
WordPress pot generar correctament:
- metadata;
- sitemap;
- canonicals;
- dades estructurades;
- pàgines indexables.
Next.js també.
En cap dels dos no apareix una estratègia SEO pel fet d'instal·lar la tecnologia.
L'arquitectura, el contingut i la implementació continuen havent d'estar ben plantejats.
Comparació ràpida
| WordPress | Next.js | |
|---|---|---|
| Gestió de contingut | Inclosa | Cal afegir-la si es necessita |
| Disseny a mida | Sí | Sí |
| Funcionalitat estàndard | Gran ecosistema de plugins | Integracions o desenvolupament |
| Lògica pròpia | Possible amb desenvolupament | Molt flexible per a aplicacions a mida |
| Manteniment | Core, plugins, tema, servidor | Framework, dependències, integracions, runtime |
| Rendiment | Depèn de la implementació i el hosting | Depèn de la implementació i l'arquitectura |
| SEO tècnic | Es pot fer molt bé | Es pot fer molt bé |
La taula no té cap guanyador.
Aquesta és la idea.
Les preguntes que decidirien per mi
Abans de triar preguntaria:
- Qui editarà la web després?
- Amb quina freqüència?
- Les funcionalitats que necessitem són força estàndard?
- L'experiència visual necessita molt desenvolupament propi?
- Hi ha dades o eines externes per integrar?
- Estem construint una web o comença a semblar una aplicació?
- Qui la mantindrà d'aquí a dos anys?
Un cop respost això, la tecnologia sol ser força més fàcil de decidir.
El que fem servir nosaltres
A Roke treballem principalment amb Next.js perquè sol encaixar amb els projectes que fem: disseny a mida, arquitectures pròpies, integracions i força control sobre la implementació.
Això no vol dir que Next.js sigui la resposta correcta per a totes les webs.
Si una empresa necessita sobretot publicar molt contingut amb autonomia i WordPress resol bé el problema, fer servir Next.js només perquè nosaltres el preferim seria començar la decisió al revés.
La tecnologia hauria de sortir dels requisits.
Si necessites sobretot una web que representi bé la teva empresa, pots veure com plantegem una Web de marca.
I si el que estàs construint té lògica, processos interns o funcionalitats pròpies, probablement parlem de Software a mida.
Escrivim sobre decisions que apareixen en projectes reals: com estructurar una web, com captar demanda i quan la tecnologia pot simplificar un negoci.