WordPress o Astro: lo que cuesta elegir la plataforma

WordPress arma la página cuando el visitante la pide. Un generador de sitios estáticos arma cada página una vez, antes de que llegue alguien, y después entrega un archivo. La decisión cambió porque el segundo camino dejó de exigir que alguien escribiera HTML a mano para cada página.

Qué cambió en el cálculo

Hace veinte años un sistema de gestión de contenido se ganaba su lugar resolviendo un trabajo: convertir texto en páginas web. Hacer eso a mano para unos cientos de páginas era trabajo que nadie quería repetir, así que una base de datos y una pantalla de administración se pagaban solas.

Ese trabajo hoy lo hace una etapa de build. Un generador lee markdown, aplica una plantilla y escribe archivos HTML en una carpeta. La publicación ocurre en un pipeline, y el pipeline puede dispararlo un commit, un formulario o una tarea programada. El costo de producir HTML cayó a casi nada, y el costo de mantener una aplicación en pie no cayó con él.

Lo que no cambió es la razón de que un CMS exista. Algunos sitios producen de verdad una página distinta para cada visitante. Un área de suscriptores, un carrito con stock en vivo o un hilo de comentarios necesita código corriendo en el momento de la petición. Para esos casos, una carpeta estática es la forma equivocada.

WordPress también cambió. El editor de bloques facilitó la publicación, y las actualizaciones automáticas de versión menor (en inglés) quitaron una clase de mantenimiento del camino. Además, WordPress Playground (en inglés) corre WordPress al instante, en cualquier dispositivo y sin alojamiento. Esto no es una historia de antiguo contra nuevo.

Cómo entrega la página cada camino

Casi todo lo demás depende de cómo llega la página al visitante.

En WordPress, la petición del visitante llega a un servidor web que corre PHP. WordPress arranca, consulta la base de datos, ejecuta el tema y cada plugin activo, arma un documento HTML y lo devuelve. La página de requisitos es explícita al decir que WordPress necesita un servidor web con PHP y una base de datos detrás. Ese trabajo se repite en cada petición, salvo que una caché guarde la página terminada y la sirva en su lugar.

La caché es la respuesta estándar, y es una respuesta real. También es una pieza más para configurar, invalidar y mantener funcionando después de una actualización.

En un sitio estático, ese mismo HTML se escribió antes. La documentación del propio Astro afirma que, por defecto, sus páginas y rutas se pre-renderizan en el build como páginas estáticas. La petición del visitante se resuelve en un archivo, normalmente en el borde de una CDN cerca de él. Ningún proceso PHP arranca, ninguna base de datos se consulta y ningún código de plugin corre para producir ese documento.

La cuestión aquí es de dependencia, no solo de velocidad. En WordPress la experiencia del visitante depende de la salud de una aplicación en pie en ese instante. En un sitio estático depende de que el archivo exista y sea alcanzable.

Estático tampoco es la única opción dentro de un generador. Astro documenta renderizado bajo demanda mediante un adaptador de servidor, lo que devuelve el servidor a las rutas que lo necesitan. Elegir un generador no obliga al camino estático.

Seguridad leída como superficie de ataque

El propio manual de hardening de WordPress (en inglés) resume el asunto en una línea: la seguridad es reducción de riesgo, no eliminación de riesgo. Ese marco debería sobrevivir a cualquier comparación.

La superficie de WordPress es una lista de cosas alcanzables desde afuera. Una pantalla de login queda en la internet pública. Las credenciales de la base de datos quedan en el disco. Plugins y temas de autores distintos corren con los mismos privilegios que el núcleo. Las rutas de subida, la API REST y XML-RPC suman más entradas. El mismo manual (en inglés) dice que el alojamiento es responsable de la infraestructura y no de la aplicación que se instala. Después pide mantener los plugins actualizados y borrar los que no se usan.

Nada de esto es un defecto. Viene con mantener una aplicación. Un sistema que acepta entrada, la guarda y deja que administradores actúen sobre ella tiene que autenticar, autorizar y validar todo.

Un sitio estático tiene una lista mucho más corta. No hay login que alcanzar, no hay base de datos escuchando en el momento de la petición y no hay código de servidor ejecutándose en cada visita. Lo publicado es HTML, CSS, imágenes y tipografías. No existe contra qué autenticar a un desconocido, porque ningún desconocido puede hacer que el sitio trabaje.

Pero la superficie de ataque no desaparece. Cambia de lugar. Un sitio estático igual tiene cuenta de alojamiento, cuenta de dominio y repositorio. Un token de deploy expuesto o un portátil comprometido alcanza el sitio publicado tan directo como un plugin explotado alcanza un sitio WordPress. Proteger el pipeline de build pasa a ser el trabajo que antes era proteger el panel.

Lo que cuesta mantener cada camino en el tiempo

El precio varía por alojamiento y por región, así que conviene comparar por mecanismo en vez de por factura.

WordPress pide operar un sistema corriendo. Núcleo, temas y plugins se actualizan en calendarios propios, y cada actualización hay que probarla contra el resto de la pila. Se carga un alojamiento que corre PHP y base de datos, más backup, disponibilidad, versión de PHP, tamaño de la base y invalidación de caché. La recompensa es que sumar una capacidad suele ser una instalación, y el modelo de contenido se dobla a lo que se necesita.

Un sitio estático pide operar un build. Las dependencias se actualizan, y un build puede romperse, pero se rompe donde se ve antes que el visitante. El alojamiento puede ser una CDN sirviendo archivos, que es una forma más barata que una máquina corriendo una aplicación. El modelo de contenido queda fijado por el schema que se escribe, así que un campo nuevo es un cambio de código.

Los costos se invierten en un punto concreto. Un sitio con muchos editores, roles, historial de revisiones, publicación programada y comentarios dentro del sitio está pidiendo una aplicación. Reconstruir eso en un pipeline estático significa reconstruir un sistema de gestión de contenido, y la mayoría de los equipos lo hace peor que el que dejó.

Rendimiento contado en lo que el visitante descarga

Conviene empezar contando las peticiones de cada lado.

Una página WordPress suele entregar el documento, el CSS y el JavaScript del tema y los de la biblioteca de bloques. A eso se suma lo que cada plugin activo agrega en el front. Cada plugin que incluye assets suma peticiones, y cada plugin de optimización creado para bajarlos es un plugin más para mantener.

Una página estática entrega el documento, una hoja de estilo e imágenes. La documentación de islas de Astro describe el modelo directo: renderizar la mayor parte de la página como HTML estático. Sobre eso se suman islas pequeñas de JavaScript, solo donde hace falta interactividad o personalización.

Core Web Vitals convierte eso en una meta publicada. Google Search Central fija los límites así: Largest Contentful Paint hasta 2,5 segundos, Interaction to Next Paint hasta 200 milisegundos y Cumulative Layout Shift hasta 0,1. La guía de web.dev sobre las métricas es la fuente del percentil 75: cada límite se cumple cuando 75 por ciento de las cargas queda por debajo de él.

Aquí lo que importa es qué mueve cada métrica. El LCP mejora cuando el elemento más grande no espera trabajo de servidor. El INP mejora cuando el hilo principal no está ocupado hidratando un script grande. El CLS mejora cuando el espacio del layout se reserva antes de que llegue el contenido. El HTML estático arranca con menos que deshacer.

La investigación de percepción da otros números. Los límites de tiempo de respuesta de NN/g (en inglés) ponen 0,1 segundos como borde de lo instantáneo y 1 segundo como el límite que conserva el flujo de pensamiento. Diez segundos es el límite de la atención. Su artículo sobre tiempos de respuesta de sitios (en inglés) registra que la imagen grande dejó de ser la causa principal de la lentitud. Eso dialoga con la cuenta de peticiones de arriba. Los indicadores de progreso (en inglés) tratan qué mostrar cuando la espera es inevitable.

Los dos marcos divergen a propósito. NN/g mide lo que la persona siente, interacción por interacción, mientras que Core Web Vitals es dato de campo en el percentil 75. Una página puede pasar el LCP de 2,5 segundos y seguir por encima del límite de 1 segundo que conserva el flujo de pensamiento (Core Web Vitals, NN/g (en inglés)).

El contrapunto: un sitio WordPress bien cacheado y con tema liviano pasa las tres. Google mide las páginas, no el framework, y el dato de campo decide el resultado.

Cuándo WordPress sigue siendo la elección correcta

• Muchos editores que nunca deberían tocar código, con roles y permisos distintos por persona.
• Contenido que difiere por visitante o por sesión, como área de suscriptores, stock en vivo o carrito.
• Una capacidad que no se puede construir y para la que existe un plugin mantenido, como pagos, reservas o plataforma de cursos.
• Comentarios y comunidad dentro del sitio, en vez de en una plataforma social.
• Un equipo que ya conoce WordPress, donde volver a formarlo costaría más que alojar.
• Un alojamiento que se ocupa del servidor, para no tocar nunca la máquina.

Y no son pocos casos. WordPress es la respuesta correcta más veces de las que un texto de comparación suele admitir.

La pregunta que decide

Hay una sola pregunta: ¿la página cambia según el visitante en el momento de la petición?

Si la respuesta es no, el trabajo pertenece al build, y servir archivos quita una capa de código corriendo del camino del visitante. Si la respuesta es sí, hace falta una aplicación, y WordPress es una aplicación madura, con muchos plugins, temas y gente que sabe mantenerla.

Costo, velocidad y seguridad salen de esa respuesta.

La misma decisión de adoptar o construir aparece en el texto sobre Material Design, a menor escala.