Rapidez por defecto

La velocidad aquí no se ajusta por proyecto, es una propiedad de la arquitectura. El site público son archivos estáticos simples servidos desde el disco, sin renderizado por petición, con caché agresiva y payloads pequeños por construcción. Esta página resume de dónde viene la velocidad y qué perillas controlas tú.

Sin renderizado por petición

Tus visitantes reciben archivos estáticos publicados directamente desde el disco. La aplicación de autoría nunca renderiza páginas públicas a demanda, en producción está enlazada a una dirección loopback privada, así que los visitantes simplemente no pueden alcanzarla.

Caché que viene con la configuración de fábrica

La configuración de servidor de ejemplo establece vidas de caché para que tu despliegue sea rápido por defecto:

• Páginas HTML, una caché corta de 5 minutos con must-revalidate, así que el contenido recién construido llega a los lectores a los minutos de un build.
• Fuentes, archivos con hash de contenido, cacheados por un año y marcados immutable.
• Otros assets estáticos (CSS, JS, imágenes, iconos), cacheados por un día.
• El service worker, explícitamente no cacheado, así que una copia obsoleta nunca puede bloquear actualizaciones.
• Assets del dashboard de administración, cacheados por un día.

La compresión (zstd y gzip) está habilitada del lado del servidor en la configuración de fábrica.

Páginas pequeñas, generadas con inteligencia

La etapa de build hace en tiempo de publicación el trabajo que otros sistemas pagan en tiempo de ejecución:

• El HTML se minifica por defecto. El espacio en blanco colapsa en cada página construida (hay un toggle en settings si necesitas salida sin minificar para depurar).
• Las imágenes lazy-load automáticamente. Cada imagen sin hint de carga recibe loading="lazy" durante el build.
• Las imágenes llegan con derivados responsivos. Cuando subes una imagen, se generan copias escaladas a 320, 640 y 1280 px tanto en el formato original (JPEG o PNG) como en WebP, y las plantillas reciben atributos srcset listos para usar, así que los visitantes solo descargan el tamaño que necesitan.

Velocidad también al momento de autoría

• Builds incrementales por defecto: los archivos sin cambios se saltan por hashing de contenido, así que los rebuilds del día a día son rápidos; un rebuild completo sigue disponible para esos días en que lo quieres.
• La base de datos nunca bloquea al admin. SQLite corre en modo WAL, las lecturas concurrentes no bloquean las escrituras, afinado con una caché considerable para la carga de trabajo esperada de una sesión de admin activa más builds periódicos.
• Los builds permanecen acotados, y una salida obsoleta vale más que una salida rota: un build tiene un tope de volumen de escritura y de tiempo (cinco minutos), y un build que colapsa (caída en el conteo de páginas, pico de enlaces, timeout) no se promueve, el site bueno anterior sigue sirviendo.

Lo que no te hace lento

No hay JavaScript en tiempo de ejecución en la salida pública, nada que fetchear, nada que ejecutar, nada que diferir, y ningún beacon que cargar. Las páginas de contenido son solo markup con optimizaciones horneadas en tiempo de build.