¿Tu sitio web necesita publicación instantánea?

Antes de elegir cómo publicar un sitio web, hazte una pregunta práctica: ¿una actualización debe quedar visible para el público en segundos o puede tardar unos minutos? La respuesta cambia la arquitectura.

Una sala de redacción puede necesitar que una corrección se vea de inmediato. Una tienda puede necesitar que cada solicitud use los datos vigentes de inventario y precios. Un sitio de servicios, un portafolio o un sitio empresarial relativamente estable puede aceptar una breve demora si separar, en tiempo de compilación, la edición de la entrega responde a sus necesidades de actualización y flujo de trabajo. La decisión correcta parte de la frecuencia de actualización necesaria, no de una herramienta favorita.

El editor y el sitio público cumplen funciones distintas. El editor le da al propietario un solo lugar para modificar el contenido. El sitio público entrega las páginas que leen los visitantes.

En yesid.dev, la aplicación actual lee módulos de contenido generados para las páginas públicas en vez de pedirle contenido al CMS durante cada visita incluida en la muestra. En trazas recientes de producción del 10 de julio de 2026, la página de inicio, Servicios, Blog, un artículo publicado y la página del proyecto yesid.dev devolvieron un código 200. Todas las solicitudes observadas se mantuvieron en yesid.dev, sin solicitudes a Directus ni a un host cms.*. Esto es evidencia de cinco trazas, no una afirmación sobre todas las rutas ni sobre cada visita futura.

Depender menos del CMS en el sitio público tiene un valor práctico. Las páginas ya publicadas están diseñadas para seguir disponibles si el editor no lo está, porque no necesitan una respuesta nueva del CMS para cada lector. Esa expectativa se desprende de la arquitectura; no se ha demostrado mediante un simulacro independiente de interrupción del servicio. El sitio completo todavía puede fallar. Siguen existiendo dependencias de hosting, código, red y recursos.

Para el propietario sigue habiendo un solo editor. La separación se aplica a la forma en que el contenido publicado se genera y se entrega.

Este es el único aparte técnico: la ruta de producción es Directus -> exportación durante la compilación -> módulos generados -> SvelteKit/Vercel. El CMS entrega el contenido publicado al proceso de compilación, la compilación prepara los archivos públicos y solo un despliegue completado reemplaza la versión anterior.

La actualización de contenido en producción ya está habilitada. El 11 de julio de 2026, una compilación de producción registró mode=live, leyó https://cms.yesid.dev con una política de fallo cerrado, exportó cinco artículos publicados y cinco cuerpos de contenido, y generó los 22 módulos de contenido.

En la ruta de exportación en vivo, el contenido actualizado no se vuelve público hasta que un nuevo despliegue está listo. Para el registro del 11 de julio, la compilación de producción comenzó a las 06:17:57.482 UTC y el despliegue terminó a las 06:19:26.603 UTC: 89.121 segundos desde el inicio de la compilación hasta el despliegue completado.

Esa es una sola observación, no un SLA ni una promesa de que ese sea el rango habitual. Sí demuestra que este cambio específico del CMS llegó al sitio público: al terminar, las cinco URL nuevas previstas devolvieron un código 200, cada una tenía una URL canónica hacia sí misma y todas aparecieron en el sitemap; las tres URL de artículos retirados devolvieron un código 404 y desaparecieron del sitemap. Este artículo seguía deliberadamente como borrador durante ese registro; también devolvió un código 404 y no aparecía en el sitemap. Una compilación candidata anterior rechazó un enlace a esta página en borrador y no fue promovida, así que el despliegue anterior siguió activo hasta que terminó la compilación corregida.

Esta arquitectura encaja mal cuando las actualizaciones deben publicarse en segundos. Eso incluye la publicación al ritmo de una sala de redacción, el inventario o los precios que deban reflejar los datos vigentes al atender cada solicitud, las aplicaciones con contenido personalizado, los tableros en vivo y cualquier flujo de trabajo que no pueda tolerar una compilación antes de que el contenido se vuelva público.

Puede funcionar para sitios de servicios, portafolios, documentación y otras páginas relativamente estables donde unos minutos sean aceptables. Incluso entonces, que sea una buena opción depende de las necesidades de vista previa, las aprobaciones editoriales, las integraciones y cuánto trabajo operativo esté dispuesto a asumir el propietario o el desarrollador. La entrega estática no es una recomendación universal.

Si ese equilibrio funciona para tu sitio, mira cómo el servicio de Sitios web y e-commerce aborda los proyectos web.

Este es el capítulo 6 de una saga de seis capítulos. Capítulos 1 a 3: quién soy. Capítulos 4 a 6: lo que construyo. Anterior: De 50 $ a 0 $: una VM Oracle Always Free.