¡Hola a todos! Como la inmensa mayoría de los que nos leéis sabéis, en SiloCreativo respiramos WordPress. Llevamos más de una década diseñando, desarrollando y comercializando plantillas y temas para el CMS más utilizado de internet. Lo conocemos al milímetro, es nuestra herramienta de cabecera y, para casi cualquier proyecto de clientes que entra por la puerta, es nuestra primera opción. ¡Es nuestra casa!
Sin embargo, a lo largo de este último año, nos encontramos en una encrucijada técnica. Empezamos a desarrollar Normatia, un SaaS propio orientado a digitalizar, conectar y consultar mediante IA toda la normativa de arquitectura en España.
Cuando nos sentamos frente a la pizarra en blanco para plantear el Stack tecnológico, tuvimos que tomar una decisión que, emocionalmente, fue difícil: hemos decidido dejar WordPress a un lado para el núcleo de este producto y apostar ciegamente por Astro. Hoy queremos reflexionar con vosotros sobre esta decisión. Os contamos por qué, a veces, hay que salir de la zona de confort y elegir la herramienta adecuada para el problema adecuado. ¡Vamos con ello!
El problema del renderizado dinámico en un SaaS masivo
Empecemos por el principio. WordPress es una auténtica maravilla gestionando contenido dinámico. Su ecosistema de Plugins y su capacidad para levantar un Backend en minutos no tiene rival. Pero su arquitectura subyacente basada en PHP y peticiones constantes a la base de datos tiene un coste inherente de rendimiento.
Para un blog corporativo, un portfolio o incluso un ecommerce estándar, este problema de latencia se soluciona fácilmente. Instalas un buen plugin de caché, configuras un CDN, optimizas las imágenes y listo, tienes una web volando. Pero Normatia no es un blog al uso. Normatia es una inmensa base de datos documental interconectada. Estamos hablando de miles y miles de artículos legales, tablas complejas, anexos técnicos y referencias cruzadas que los usuarios (arquitectos e ingenieros) consultan constantemente y a gran velocidad mediante un buscador semántico.
Dicho esto, procesar cada una de estas vistas de documentos en el servidor con PHP en tiempo real era un cuello de botella inasumible. Es como si en un restaurante de comida rápida, el cocinero tuviera que salir a plantar los tomates al huerto cada vez que un cliente pide una hamburguesa con ensalada. Necesitábamos algo radicalmente diferente, algo que nos permitiera servir información pesada a la velocidad de la luz.
Entendiendo el paradigma: Sitios Estáticos vs. Sitios Dinámicos
En nuestra búsqueda de la velocidad absoluta, volvimos la vista hacia los generadores de sitios estáticos. La premisa es simple: si el contenido de una ley (como el Código Técnico de la Edificación) no cambia todos los días, ¿por qué vamos a gastar recursos del servidor en renderizarlo cada vez que alguien lo lee?
Ahí es donde la filosofía del SSG (Static Site Generation) cobra todo el sentido del mundo. Queríamos pre-construir todas las páginas legales durante el proceso de Deploy. Así, cuando el servidor terminara su trabajo, lo único que quedaría en la carpeta pública serían miles de archivos de HTML puro y duro.
El resultado de esta arquitectura es evidente: cuando el usuario hace clic en un artículo de la normativa, la página carga de forma literalmente instantánea. No hay consultas a MySQL, no hay procesamiento de Loops en PHP, no hay comprobaciones de base de datos. El servidor simplemente le entrega al navegador un archivo HTML que ya estaba preparado de antemano. Las métricas de WPO (Web Performance Optimization) y de SEO que conseguimos con esta estrategia son simplemente brutales, logrando un 100/100 en Google PageSpeed.
Manos a la obra: Astro y su Arquitectura de Islas
Dentro del ecosistema de Frameworks modernos de Frontend (Next.js, Nuxt, Gatsby), Astro se ha ganado nuestro corazón de desarrolladores. ¿El motivo? Comparte una filosofía que en SiloCreativo siempre hemos defendido: menos JavaScript inútil y más HTML puro.
Astro nació con una premisa fantástica: extraer por defecto todo el JavaScript del cliente. Si creas un componente en React o Vue y lo metes en Astro, este lo renderiza como HTML estático y le quita el peso interactivo. Pero, ¿qué pasa si necesitas interactividad real? Aquí viene la magia.
Astro utiliza un concepto revolucionario llamado «Island Architecture» (Arquitectura de Islas). Esto significa que toda la web es un océano de HTML estático y rápido, pero puedes definir pequeñas «islas» interactivas donde sí se ejecuta JavaScript.
En nuestro caso, el texto de la ley, el Header y el Footer son puro HTML sin coste de carga. Pero nuestro buscador inteligente y nuestro asistente de chat por IA son «Islas» de React. Solo cargamos JavaScript exactamente donde el usuario lo necesita de forma crítica, manteniendo el Layout general ligero como una pluma. Es lo mejor de ambos mundos: la velocidad de la web de los 90 con la interactividad de las aplicaciones modernas de 2026.
La Experiencia de Desarrollador (DX)
Aprender un nuevo Framework siempre da un poco de vértigo, pero la curva de aprendizaje de Astro ha sido un paseo muy agradable. Para los que venimos de crear tutoriales de código y pelear con jerarquías de plantillas en PHP, la forma de estructurar componentes en Astro es un soplo de aire fresco.
El sistema de Routing basado en archivos (donde la estructura de carpetas define tus URLs automáticamente) elimina la necesidad de configurar enrutadores complejos. Además, el soporte nativo para Markdown y MDX ha sido vital para nosotros. Gran parte de los anexos y documentaciones de la normativa las gestionamos directamente en archivos MDX, lo que nos permite escribir texto formateado pero inyectando componentes interactivos de UI (como calculadoras técnicas) directamente en medio de los párrafos.
¿Significa esto que abandonamos WordPress?
¡Para nada, ni muchísimo menos! WordPress sigue siendo el rey indiscutible para webs de contenido, revistas digitales, tiendas online con WooCommerce y páginas corporativas. Su capacidad para empoderar al cliente final para que gestione su propia web sigue sin tener rival en la industria.
Pero trabajar con Astro nos permite separar las responsabilidades. Por ello, para construir el «motor» interno de la aplicación web, el SaaS en sí mismo, hemos aprendido que separar el Frontend hiper-optimizado (Astro) de nuestro Backend (la base de datos y la IA) nos da una flexibilidad y una escalabilidad que un CMS monolítico tradicional no nos puede ofrecer.
Y vosotros, ¿habéis dado el salto a probar Frameworks modernos como Astro, Next o Svelte, o seguís resolviendo absolutamente todos vuestros desarrollos web bajo el paraguas de WordPress? ¡Os leemos en los comentarios, que seguro que hay un debate súper interesante! 😉
