WordPress sin cabeza: ¿Qué es y lo necesita?

En Servebolt, somos grandes defensores de WordPress y su ecosistema. También lo usamos para nuestros propios sitios porque realmente consideramos que es el mejor sistema de administración de contenido, como lo muestran las estadísticas año tras año. Es de código abierto, versátil y, en pocas palabras, es increíblemente fácil ver por qué funciona con más del 40% de todos los sitios web en Internet.

Con lo grande que es el ecosistema y la comunidad de desarrolladores que rodea a WordPress, no sorprende que las personas usen WordPress de diferentes maneras. Uno de esos enfoques es usar WordPress como un CMS sin cabeza, en resumen, denominado WordPress sin cabeza, que está creciendo en popularidad.

En esta guía, desglosaremos todo lo que necesita saber sobre WordPress sin cabeza, sus ventajas, desventajas y más a partir de la experiencia de primera mano de nuestro equipo.

¿Qué es WordPress sin cabeza?

Para comprender WordPress sin cabeza, debe saber qué es WordPress monolítico. Monolithic , o WordPress en su forma tradicional, es WordPress como lo conoces. Es un sistema de administración de contenido que puede usar para administrar todo el contenido de su sitio.

Generalmente, WordPress tiene el backend (el sistema de administración de contenido) y la capa de presentación, que le permite diseñar su sitio web. Sin embargo, los sitios de WordPress sin cabeza son aquellos que simplemente confían en WordPress como un sistema de administración de contenido y usan una pila de interfaz diferente para mostrar el contenido.

Esto permite una mayor flexibilidad en términos de desarrollo. Esencialmente, con la ayuda de la API REST, puede usar WordPress para su funcionalidad de administración de contenido mientras lo combina con una interfaz creada por separado en un marco como Vue.js o React (solo por nombrar algunos, hay una amplia gama de otros frameworks y herramientas frontend disponibles).

WordPress se considera una arquitectura CMS acoplada porque todas las herramientas de edición front-end y la funcionalidad de administración (edición) de contenido de back-end están acopladas. Esto permite que los equipos de desarrolladores, editores, redactores publicitarios y más administren tanto la capa de presentación como el contenido. A diferencia de los sitios web de WordPress sin cabeza que siguen una arquitectura desacoplada en la que la capa de presentación y el contenido están, como sugiere el nombre, desacoplados.

Integración REST, GraphQL y Flat-File

Una configuración de CMS sin cabeza utiliza API y CDN para representar contenido. Y por el momento, hay tres opciones disponibles: la API REST, la integración de Flat-File y GraphQL.

WordPress usa la API REST para permitirle conectar la interfaz al CMS. Una API REST es simplemente una interfaz de programación de aplicaciones que sigue las restricciones de la arquitectura REST y proporciona una interfaz uniforme que permite a los servidores y clientes transferir datos entre sí. REST permite que los desarrolladores expongan y usen datos específicos, si el punto final de REST no tiene los datos disponibles directamente, necesitará un desarrollo adicional.

Otra alternativa es GraphQL (QL es la abreviatura de Query Language). GraphQL facilita la consulta de API con campos y relaciones específicos, tal como lo haría con una base de datos. Esta es una mejora significativa, y hay un complemento que hace que una API de GraphQL esté disponible en WordPress . Esto puede significar que no se necesita un desarrollo adicional para explotar el contenido del CMS, ya que GraphQL ya tiene acceso a él, la parte más compleja es realizar las consultas correctas y eficientes para obtenerlo.

La otra opción es la integración de archivos planos. La integración de archivos planos le permite exportar los datos que normalmente se proporcionan a través de REST o GraphQL como un archivo .JSON, lo que permite que el servidor los almacene en caché y no sea necesario generarlos en cada solicitud, lo que lo hace mucho más rápido. El uso de este método generará automáticamente un nuevo conjunto de archivos .JSON con cada cambio en la base de datos. Esta es normalmente una implementación a medida y no solo un complemento. Por lo tanto, se necesita un desarrollador para configurarlo.

Las ventajas y desventajas de WordPress sin cabeza

Ahora que sabe qué es WordPress sin cabeza y en qué se diferencia de una configuración de WordPress convencional , estas son las ventajas y desventajas que debe conocer antes de tomar una decisión.

Desarrollo flexible, Si bien sigue usando WordPress como su sistema de administración de contenido, desacoplar WordPress les brinda a sus desarrolladores la flexibilidad de construir con las tecnologías frontend de su elección, es decir, marcos como Next.js. A nivel superficial, esto significa mucha más libertad para construir.

En la superficie, esto es genial. Pero también significa que termina reinventando la rueda para la funcionalidad básica, como mapas de sitio y enlaces permanentes, lo que garantiza que las vistas previas en vivo de las publicaciones y el contenido de la página funcionen.

Y pierde la mayor parte del flujo de trabajo editorial por el que se conoce a WordPress. La configuración de nuevas páginas a menudo se vuelve mucho más complicada y requiere que los desarrolladores estén en espera para depurar cuando las cosas simplemente no funcionan .

Creación de aplicaciones móviles con un backend de WordPress

Un caso de uso que se pasa por alto con frecuencia es que cuando desacopla WordPress, usándolo únicamente para el backend, puede crear aplicaciones móviles.

Las aplicaciones son complejas, mucho más que la creación de sitios web desde cero (es decir, con o sin WordPress), por lo que si termina siguiendo esta ruta, mientras que el contenido estará basado en API, gran parte del resto dependerá de las funciones nativas del dispositivo. con la ayuda de marcos como React Native. Aquí hay una excelente comparación de diferentes formas de crear aplicaciones móviles de Scott Bollinger de AppPresser. Uno de los cuales es, como habrás adivinado, AppPresser, que es una gran implementación de esto para aquellos que quieren comenzar de inmediato. Está, por supuesto, impulsado por WordPress, utilizando complementos de WordPress, temas y la API REST para potenciar las aplicaciones móviles iOS y Android nativas/híbridas.

Comenzar con una solución como esta le ahorrará semanas, si no meses, de tiempo de desarrollo y, en última instancia, se basa en los años de experiencia interna de su equipo trabajando en proyectos de clientes durante años y probando la plataforma en producción para refinarla.

Mejor rendimiento, con compensaciones.

Hay tres formas principales en que se puede desarrollar sin cabeza

1. Lado del cliente : todo se construye en el navegador usando javascript con el contenido cargado desde el servidor al acceder a él. Por ejemplo, usar React como motor obtiene los datos a través de, por ejemplo, la API REST. Cuando se cambia la página, hay una solicitud de más datos a la API y se crea una nueva página en el cliente. Se utiliza con mayor frecuencia en aplicaciones de una sola página (SPA)
2. Publicado estático : todo ya está construido y exportado como HTML, CSS y JS en el servidor. Debido a que solo sirve archivos estáticos, no genera dinámicamente la página, esto se puede almacenar en un servidor o CDN de muy baja potencia. Este método es ultrarrápido. Esto a menudo se hace con algo como Next.js. Cuando se cambia la página, se descarga una nueva página HTML del servidor y se muestra. Se usa con mayor frecuencia en sitios que no cambian con frecuencia, como sitios de folletos o documentación.
3. Páginas isomorfas : la primera página web a la que se accede es Server Side Rendered (SSR) como HTML, pero todas las demás páginas posteriores se generan en el lado del cliente si el cliente puede hacerlo. Si el cliente no puede generar la página, la solicitará al servidor. Se usa con mayor frecuencia en aplicaciones web progresivas (PWA), sitios muy dinámicos o aquellos que tienen que funcionar con navegadores web más antiguos. A menudo se utiliza un marco como Svelte.kit para esto.

Los métodos n.° 1 y n.° 3 podrían usar archivos de datos planos para generar el HTML, haciéndolos comparables con un sitio publicado estático, pero usar REST o GraphQL los ralentizará un poco, ya que es posible que tenga que generar el contenido JSON con cada solicitud.

Si se necesitan cosas como contenido generado por el usuario (formularios o comentarios), estas tres formas de trabajar se vuelven mucho más complejas que el WordPress estándar.

Tomemos un formulario de contacto como ejemplo, el formulario debe construirse para que funcione en el lado del cliente y pueda enviar su información a través de Javascript/AJAX al servidor, donde luego se verifica, se desinfecta y se inserta en el contacto. sistema de gestión de plugins de formularios. Debido a que esta es una forma totalmente diferente de trabajar, no puede confiar en el creador del complemento del formulario de contacto para proporcionar esto o aquello, como los botes de miel y otra protección contra el correo no deseado, seguirán funcionando. Es posible que necesite un desarrollador para crear un punto final REST y hacer que todo funcione según sea necesario. Mucho más complejo.

Los comentarios son, en teoría, mucho más fáciles porque los puntos finales REST ya existen, pero aun así, será necesario que un desarrollador haga posible recuperar los comentarios aprobados y presentarlos en un diseño encadenado, cargar nuevos comentarios en el proceso de aprobación. y, por supuesto, lidiar con el spam.

Cuando se desarrolla de manera autónoma, hay más que hacer para lograr los mismos objetivos que vienen de fábrica con WordPress o que son posibles con algunos complementos.

¿ La percepción de Hay mucha información errónea en torno a la seguridad de WordPress sin cabeza. Ejecutar una configuración de sitio estático con un CDN es una buena medida preventiva contra los ataques DDoS. Pero, en última instancia, cualquier servidor puede ser víctima de un ataque DDoS si no implementa los sistemas necesarios (es decir, Cloudflare, etc.). Las configuraciones desacopladas de WordPress funcionan con WordPress instalado en un dominio o subdominio separado, con la interfaz en el dominio estándar.

Por ejemplo, si tuviéramos que usar este sitio web, continuaríamos usando servebolt.com como nuestro sitio de acceso público mientras configuramos Y, por ejemplo, usar una interfaz Next.js como ejemplo significaría que tiene la opción de usar SSR (representación del lado del servidor), donde la página HTML se genera con cada solicitud, o SSG (generación estática), donde la página HTML se genera en el momento de la compilación. La generación estática permite que el HTML se reutilice para cada solicitud, lo que permite que una CDN lo almacene en caché.

En cualquier caso, la capa de presentación aún se comunica y solicita contenido de la capa de contenido que ejecuta WordPress. Esto significa que el área en la que aloja la capa de administración de contenido para su configuración de WordPress sin cabeza aún estaría ejecutando WordPress.

En resumen, la respuesta a si la seguridad es mejor en los sitios web de WordPress sin cabeza frente a los sitios que se ejecutan en la configuración convencional es que puede serlo. En pocas palabras, porque es una configuración menos común. Lo que queremos decir con esto es que la verdadera razón por la que algunos intentan pintar la percepción de que hay problemas de seguridad con los sitios que ejecutan WordPress es que muchos sitios ejecutan WordPress, y las cosas son completamente flexibles, por lo que, por supuesto, puede crear o instalar algo que no es confiable, lo mismo es cierto si construyes con headless y prácticamente cualquier otra pila.

Cuando trabaja con un proveedor de alojamiento de WordPress que brinda competencia en seguridad, escalabilidad y rendimiento de la forma en que lo hacemos en Servebolt , aún es muy posible mantener sus sitios seguros sin sacrificar todo lo que puede hacer con WordPress: tener que soportar un desarrollo costoso. costos de reconstruir desde cero.

Más desventajas que probablemente encuentres con headless

Los costos de WordPress sin cabeza

Ya hemos tocado esto brevemente, pero en resumen, WordPress sin cabeza puede ser bastante costoso. No solo en términos de costo de desarrollo, sino quizás lo más importante, el tiempo.

Su equipo pierde la capacidad de moverse rápido e iterar sin tener que apoyarse en ingenieros internos (o en una agencia).

Para los equipos de ritmo rápido que no ven sus sitios como estáticos, esta es una compensación que no vale la pena. Hemos visto de primera mano cómo las empresas de 8 cifras, que claramente tienen los recursos para administrar internamente WordPress sin cabeza, toman la decisión de pasar a una configuración sin cabeza y, en última instancia, retroceder porque lo que no podían permitirse era el pérdida de tiempo, flexibilidad para moverse rápidamente y, en última instancia, dar a más de un puñado de personas en su equipo el control para trabajar en su sitio.

Los buenos desarrolladores que saben lo que hacen pueden ser difíciles de encontrar

WordPress sin cabeza sigue siendo una configuración relativamente nueva. Entonces, aunque encontrar desarrolladores de JavaScript familiarizados con JavaScript (y marcos como React, Vue, Svelte, Gatsby) no es particularmente difícil, y tal vez incluso más fácil que encontrar grandes desarrolladores de WordPress en este momento, aquellos que realmente están familiarizados con la integración de la capa frontend con WordPress de una manera convencional que se adhiere a todas las mejores prácticas tiende a ser más difícil de conseguir.

No siempre más rápido que el almacenamiento en caché perimetral de página completa

Hay caminos más fáciles, y posiblemente mejores, para un sitio web más rápido.

La mayoría de las empresas que consideran la arquitectura sin cabeza deberían arreglar su alojamiento primero antes de tomar una decisión significativamente más complicada. No solo es mucho más fácil hacerlo, sino que también verá rápidamente mejoras significativas sin una gran inversión inicial. Sin invertir en reconstruir su sitio y sacrificar todos los beneficios de su instalación de WordPress en su estado actual.

¿Cuándo debería evitar WordPress sin cabeza?

Como regla general, WordPress sin cabeza no es adecuado para la mayoría de las empresas que construyen con WordPress. En resumen, aquellos que:

• Desea evitar mantener dos capas separadas (la capa de contenido y presentación).
• No quiero renunciar al flujo de trabajo editorial y de gestión de contenido por el que se conoce a WordPress.
• Permita que su equipo tenga control y flexibilidad para trabajar sin tener que depender constantemente de sus desarrolladores.
• Quiere ahorrar recursos (tiempo y dinero).
• No tenga desarrolladores experimentados disponibles para tomar las decisiones correctas sobre cómo se hace el sistema.
• ¿Está buscando contratar trabajadores temporales o hacer que una agencia desarrolle su sitio con la vista puesta en desarrollos futuros posteriores?

¿Para quién es bueno WordPress sin cabeza?

WordPress sin cabeza puede ser una buena opción para tu equipo si:

• Su equipo de desarrollo es experto en la construcción con marcos de JavaScript, y encontrar un desarrollador de WordPress no es una opción (por la razón que sea). Pero también quiere seguir usando WordPress como sistema de gestión de contenidos, WordPress headless puede ser una buena opción.
• Su equipo desea lograr cosas específicas, como la continuidad entre el diseño de una plataforma SaaS que ya está construida, lo que haría más laborioso reconstruirlos y mantenerlos en WordPress. En este caso, separar la capa de contenido y la de presentación puede ser una buena opción.
• Estás decidido a no construir dentro de los límites de los temas de WordPress y no confías específicamente en ninguna funcionalidad adicional que ofrecen los complementos.
• Como empleador, desea capacitar continuamente a su personal técnico con las últimas habilidades y sabe que, al brindarles este conocimiento, es más probable que permanezcan con usted por más tiempo.
• Su objetivo es realizar optimizaciones de grado n en todas las partes de la pila.

Ejemplos de sitios web creados con Headless WordPress

línea de salud

TechCrunch

frontidad

Backlinko

Rudis

Informe posterior a la acción: evaluación de Headless como solución

Algunos quieren explorar sin cabeza porque es la cosa nueva y brillante con la que pocos otros están trabajando. No porque sea verdaderamente la mejor solución a un problema específico que de otro modo no sería posible. Como subproducto, la mayoría de los sitios que adoptan el enfoque sin cabeza caen en la categoría de ingeniería excesiva sin la necesidad.

No hace falta decir que también hay implementaciones emocionantes de WordPress sin cabeza y escenarios en los que puede ser una gran elección. Aquellas en las que la elección es lo que permite a los equipos crear sitios web increíbles que impulsan el resultado que buscan lograr.

¿Todavía te preguntas si WordPress sin cabeza se alinea con lo que tu equipo está buscando? No dude en reservar una llamada con nosotros y estaremos encantados de hablar sobre los problemas que está experimentando y estamos considerando implementar WordPress sin cabeza para resolverlos.

O, si esta guía ya respondió a todas sus preguntas y está listo para probar el enfoque de Servebolt:

¿Está interesado en el alojamiento administrado que es empíricamente más rápido? Pruebe nuestro enfoque para el alojamiento de WordPress :

• Escalabilidad: en las pruebas de carga de trabajo de usuarios reales, Servebolt entregó tiempos de respuesta promedio de 65 ms, tiempos de respuesta 4,9 veces más rápidos que el segundo mejor.
• Los tiempos de carga globales más rápidos: los tiempos de carga de página promedio de 1,26 segundos nos colocan en la parte superior de la lista de resultados globales de WebPageTest.
• La velocidad informática más rápida: los servidores Servebolt brindan velocidades de base de datos nunca antes vistas, procesando 2,44 veces más consultas por segundo que el promedio y ejecutando PHP 2,6 veces más rápido que el segundo mejor.
• Seguridad y tiempo de actividad perfectos: con un tiempo de actividad del 100 % en todos los monitores y una calificación A+ en nuestra implementación de SSL, puede estar seguro de que su sitio está en línea y seguro.