Saltar al contenido
Infraestructura

Adiós CMS: rehicimos host.it con Astro y el marketing ahora funciona solo

Team Host.it 9 min de lectura

Infrastruttura

Il marketing corre da solo

Da CMS a sito statico con Astro

Durante años nuestro sitio fue lo que recomendábamos a los clientes: un CMS, una base de datos, PHP y un panel de administración. Funcionó. Pero cada modificación de un aterrizaje pasaba por un ticket, cada plugin era una dependencia a actualizar y cada componente dinámico aumentaba la superficie a proteger.

El nuevo host.it es otra cosa: HTML estático, generado con Astro, servido por nuestro CDN y publicado por un pipeline en el que el equipo de marketing trabaja sin esperar a un desarrollador. Aquí hablamos de arquitectura, de los motivos de las elecciones y también de sus límites, porque no es la respuesta adecuada para todos los proyectos.

Por qué dejamos el CMS

WordPress, Joomla y otros CMS han hecho que la Web sea accesible para millones de personas y siguen siendo herramientas adecuadas para muchos proyectos. Pero nuestro sitio institucional tenía necesidades diferentes: la mayoría de las páginas cambian cuando el marketing lo decide, no con cada solicitud HTTP.

  • El 90% del sitio no era dinámico. El servidor no necesitaba regenerar las páginas de productos, las listas de precios y el contenido institucional en cada visita.
  • La superficie de ataque no era proporcionada. El tiempo de ejecución de PHP, la base de datos, el panel administrativo y los complementos requieren actualizaciones y comprobaciones continuas, incluso cuando el sitio solo necesita mostrar contenido.
  • El cuello de botella era organizativo. Para editar una página, se necesitaban habilidades en redacción, gráficos, desarrollo y lanzamiento.

Lo que hace Astro, en términos técnicos

Astro es un marco moderno diseñado para sitios orientados a contenido. Durante la compilación, transforme componentes, datos y páginas en archivos HTML listos para implementar. Cuando un visitante abre host.it, el servidor no tiene que consultar una base de datos ni ejecutar PHP para redactar la respuesta.

JavaScript cero por defecto

Astro envía HTML y CSS al navegador. JavaScript sólo se añade a los componentes que necesitan ser verdaderamente interactivos: el visitante no descarga una aplicación completa para leer una página.

Arquitectura isleña

Un formulario, un configurador o un widget pueden convertirse en una isla interactiva, cargada cuando sea necesario. El resto de la página sigue siendo HTML estático. Esto reduce el código que se ejecuta en el navegador y facilita el control del rendimiento y el comportamiento.

Componentes y contenidos validados durante la fase de construcción.

Las páginas y los componentes se verifican antes de publicar. Si falta un dato necesario, un enlace no respeta el esquema o el proyecto no se compila, el proceso se detiene: el cliente no descubre el error en producción.

El resultado: archivos estáticos listos para CDN

El resultado final es una carpeta de archivos HTML, CSS, JavaScript y de imagen. No es necesario iniciar ningún proceso de solicitud y no se necesita una sesión de usuario para mostrar una página. El tiempo de respuesta depende principalmente de la red y la ubicación del nodo CDN, no de qué tan bien funciona una aplicación en cada visita.

Seguridad por diseño, no seguridad por eslogan

Decir que un sitio es "no vulnerable" sería técnicamente incorrecto: los repositorios, los canales de CI/CD, las cuentas, las dependencias, el DNS y el CDN siguen siendo componentes que deben protegerse. La ventaja concreta es otra: en el sitio público desaparecen clases enteras de vulnerabilidades de aplicación típicas de una pila dinámica.

  • No hay PHP en ejecución. No hay un tiempo de ejecución público a través del cual ejecutar código del lado del servidor o cargar un webshell.
  • No hay base de datos para componer las páginas. No hay consultas expuestas a la navegación y por lo tanto no hay inyección SQL en el contenido estático.
  • Sin panel administrativo público. No hay una página de inicio de sesión de CMS para fuerza bruta o relleno de credenciales.
  • Sin cadena de complementos en el perímetro público. El visitante no interactúa con las extensiones del lado del servidor para mantenerse y actualizarse continuamente.
  • Contenido publicado de forma controlada. Para modificar el sitio, debe pasar por el proceso de creación e implementación, que está protegido y rastreado.

CDN y funcionalidad “siempre en línea”

El nuevo sitio es distribuido por nuestro CDN: las páginas son replicadas y atendidas por nodos periféricos cercanos a los usuarios. Esto reduce la latencia y la carga en la infraestructura de origen.

Sin embargo, hay un beneficio que va más allá de la velocidad. Con la funcionalidad “siempre en línea”, la CDN puede continuar brindando la copia estática del sitio incluso si no se puede acceder temporalmente al servidor de origen. Una falla de mantenimiento o de fuente no debería resultar automáticamente en un sitio fuera de línea.

En esta arquitectura el origen es esencial para publicar una nueva versión, pero no para generar todas las páginas solicitadas. El contenido ya distribuido permanece disponible en la red CDN.

El canal de IA: superpoderes para el marketing

El cambio más importante no se da sólo en la infraestructura. Anteriormente, para publicar una nueva página de producto, se necesitaban intervenciones de redacción, gráficos, desarrollo frontend, revisión e implementación por separado. Hoy en día, el equipo de marketing puede gestionar todo el ciclo con un canal asistido por IA.

  • Contenidos. Redacción y revisión de textos con estructura, SEO, tono de voz y traducciones gestionadas en un mismo flujo.
  • Gráficos. Portadas y recursos visuales producidos en los formatos requeridos por el sistema de diseño.
  • Diseño. Las páginas están compuestas con componentes ya aprobados: la IA utiliza el sistema de diseño, no lo omite.
  • Pruebas automatizadas. Las compilaciones, validaciones y comprobaciones funcionales se realizan antes de la publicación.
  • Puesta en escena y producción separadas. Cada cambio se genera y verifica primero en la puesta en escena y luego se promueve a producción.

Qué se necesita para hacerlo bien y cuándo no hacerlo

Cambiar a un sitio estático no es gratis y no es la respuesta universal. Para obtener un resultado confiable, necesita un sistema de diseño sólido, un proceso de CI/CD con entornos separados, pruebas automáticas y una estrategia precisa para las partes verdaderamente dinámicas.

  • Formularios e integraciones. Deben confiarse a puntos finales o servicios dedicados, con la misma atención a la seguridad que cualquier aplicación.
  • Herramientas interactivas y de búsqueda. Pueden vivir como islas, sin convertir todo el sitio en una aplicación JavaScript.
  • Áreas restringidas y datos en tiempo real. Requiere un backend o un servicio de aplicación independiente.

Para aplicaciones con contenido personalizado por usuario, comercio electrónico con precios y disponibilidad en tiempo real o portales con amplias áreas reservadas, un CMS o una aplicación dinámica puede seguir siendo la opción correcta. De hecho, seguimos alojando y protegiendo miles de ellos: el objetivo no es eliminar la dinámica, sino utilizarla sólo donde cree valor.

Más rápido, más resistente, más autónomo

El nuevo host.it es más rápido, pero sobre todo es más difícil de comprometer, más resistente y más fácil de actualizar. El rendimiento, la seguridad y la autonomía de marketing provienen de la misma elección: crear una vez, probar e implementar en todas partes.

Si crea sitios para clientes y quiere saber si este modelo tiene sentido para su cartera, hablemos. Para organizar lanzamientos controlados puedes conocer más sobre nuestro servicio de puesta en escena y desarrollo.

Destacado · Host.it

Datacenters y cloud en Italia

Turín, Pisa y servicios redundantes para continuidad y soberanía de los datos.

Del blog

Sicurezza

Patch a caldo, sito acceso

CVE kernel senza riavvii a raffica

WordPress

WordPress 7.0 e l’AI

Cosa cambia per le web agency

Del archivo

Infraestructura

Rendimiento web y SEO con Giorgio Taverniti

Seguridad

PHP 7.3: ¿qué versión de PHP usar?