WordPress o Next.js: cuándo una plantilla deja de bastar

La mayoría de las páginas que responden a esta pregunta las escribe una empresa que vende una de las dos cosas. Así que primero la declaración: nosotros construimos aplicaciones Next.js, y para buena parte de los sitios que llegan aquí nuestra respuesta es que se queden en WordPress.

El punto de partida honesto

Un sitio de folleto, un blog, la web de una pyme, una publicación con editores. WordPress hace ese trabajo bien, barato, y con un mantenimiento que no exige un equipo de front. Moverlo a Next.js compra una página teóricamente más rápida y cuesta una experiencia de edición, un ecosistema de plugins y una factura de alojamiento que antes era irrelevante.

Si por su parte nadie va a hacerse cargo de una base de código JavaScript cuando nos vayamos, eso no es un detalle que rodear. Es la respuesta entera.

Qué está renunciando en realidad

Esta es la parte que se saltan las comparativas, así que aquí va en lista.

El editor. No el campo de texto, el conjunto. Vista previa, revisiones, publicación programada, gestión de medios, y el editor de bloques para el que su equipo tiene memoria muscular. Parte vuelve. Nada vuelve gratis.

Los formularios. Un formulario de contacto es un plugin en WordPress. En Next.js son cuatro decisiones: adónde envía, qué frena el spam, dónde se guarda el envío, y a quién se avisa.

El plugin de SEO. Yoast y sus parientes ponen metadatos, sitemaps, redirecciones y schema detrás de una interfaz que puede manejar alguien de marketing. En Next.js eso es código. Al final es mejor, porque la etiqueta equivocada pasa a ser imposible en vez de solo desaconsejada, pero el primer día es trabajo que alguien tiene que hacer.

Las redirecciones. Gestionadas en una pantalla de administración, o gestionadas en el código. Solo una de las dos la puede hacer su equipo de marketing un viernes a las cinco.

Dónde una plantilla deja de ser el contenedor correcto

Hay una frontera real y no es el tráfico, ni el número de páginas.

Está donde el front empieza a tener comportamiento de aplicación. Estado de sesión que cambia lo que muestra una página. Filtrado sobre miles de elementos que tiene que ser rápido y enlazable. Un sistema de diseño compartido con un producto que no es la web. Personalización. Un checkout que controla de verdad.

Una plantilla se puede empujar hasta todo eso. Lo hemos visto. El resultado son plantillas PHP con varios miles de líneas de jQuery encima, una capa de caché que hay que saltarse para la mitad de las rutas, y nadie dispuesto a tocar la cabecera.

Core Web Vitals, que no es el argumento que usted cree

Una plantilla de WordPress bien construida en un alojamiento decente gana a una aplicación Next.js mal construida. Hemos medido las dos cosas suficientes veces como para decirlo sin rodeos.

El framework no es la variable. Lo que decide el LCP es cuándo arranca la petición del elemento mayor, y un sitio Next.js se equivoca en eso con la misma facilidad que una plantilla. Lo que da Next.js es un techo más alto y herramientas para defenderlo en CI. El suelo no viene de regalo.

Si alguien le vende una reconstrucción prometiendo una puntuación verde, pregunte cuál es la puntuación ahora y qué está causando el número. Normalmente son tres imágenes y una tipografía.

WordPress headless, el camino intermedio

WordPress se queda como superficie de edición. Se renderiza con Next.js. Los editores conservan la herramienta que conocen, las URL siguen siendo suyas, y el front consigue la frontera que le faltaba.

Es una arquitectura legítima y a menudo el camino más barato. También es donde estos proyectos se tuercen, de una forma concreta: la vista previa. Si los editores no pueden ver un borrador tal como va a aparecer, dejan de confiar en el sistema en un mes, y todo se da por perdido por razones que no tienen nada que ver con el renderizado.

Cómo decidir sin una reescritura

Coja las dos o tres plantillas que llevan su tráfico y sus conversiones. No el sitio entero.

Si lo que las hace malas son imágenes, tipografías y un plugin haciendo algo tonto, eso es un problema de WordPress con una solución de WordPress, por una fracción del coste de reconstruir. Si lo que las hace malas es que la página tiene que ser una aplicación y es una plantilla, ya tiene su respuesta. Mueva esas rutas primero y deje el resto del sitio donde está.

Donde el front tenga que convertirse de verdad en una aplicación, eso es el desarrollo. Donde no, y la respuesta honesta sea que Next.js es la herramienta equivocada para el sitio que tiene, también hay una página sobre eso.

Una tienda en Shopify es otra conversación, y más corta. Ahí Shopify se queda en cualquier caso, así que lo que se decide en realidad es quién renderiza el escaparate.