Sätteri en Astro 6.4: el procesador Rust que acelera tus builds de Markdown (y lo que pierdes al cambiarte)

Sí, Sätteri —el procesador de Markdown/MDX escrito en Rust que llegó con Astro 6.4— reduce los tiempos de build de verdad: el sitio de documentación de Astro y el de Cloudflare recortaron más de un minuto cada uno al cambiarse. Pero la letra pequeña que casi ningún resumen menciona es que Sätteri no ejecuta plugins de remark ni de rehype. Y la noticia más importante de la versión no es la velocidad: es la nueva API markdown.processor, que termina con el monopolio de una década que unified tenía sobre cómo Astro renderiza Markdown.

Lo escribimos desde un sitio de producción que vive exactamente en medio de este trade-off. mintec.co corre sobre Astro 6.4 con Markdoc para sus colecciones de contenido: más de 750 archivos bilingües, páginas de servicio y un pipeline que publica artículos nuevos cada mañana. El tiempo de build no es una abstracción para nosotros; es un costo de CI diario. Por eso, cuando Astro 6.4 salió el 28 de mayo de 2026 con Sätteri, hicimos la evaluación completa en lugar de subirnos al titular del benchmark.

Qué trajo Astro 6.4 (y qué quedó en el titular)

La versión trajo tres cosas, y solo una se llevó los titulares:

1. La nueva API markdown.processor — ahora puedes cambiar el pipeline de Markdown completo con una opción de configuración. El default sigue siendo unified(), así que los proyectos existentes no se rompen, pero tus plugins de remark/rehype se configuran ahora directamente en el procesador, no a nivel superior.
2. Sätteri (@astrojs/markdown-satteri) — un pipeline de Markdown y MDX escrito en Rust, mucho más rápido que el default de unified, que implementa de forma nativa muchas funciones de Markdown (como las directivas) que antes requerían plugins.
3. Helpers cf() para Cloudflare — para el advanced routing experimental de Astro 6.3: bindings de sesión KV, el binding ASSETS y locals.cfContext con una sola llamada.

Las deprecaciones son la parte que los equipos se pierden: markdown.remarkPlugins, markdown.rehypePlugins, markdown.remarkRehype, markdown.gfm y markdown.smartypants siguen funcionando pero están deprecadas, y el equipo de Astro confirmó que se eliminarán en Astro 8.0. Con el ritmo de releases actual, eso da de 12 a 18 meses. Suena cómodo, pero la migración es trivial hoy y solo se complica a medida que tu config acumula personalización.

Los números que importan

Los benchmarks en un solo lugar, porque esta es una historia de números:

Nuestro número es el que podemos defender en una conversación con un cliente: un build completo de producción de mintec.co —756 archivos de contenido en dos idiomas más las páginas de servicio, renderizados con Markdoc— tarda 252 segundos en CI. Está por encima del umbral donde Sätteri empieza a importar, y aun así el cambio no nos ayudaría, porque Markdoc no pasa por el pipeline de unified. Esa tensión es exactamente por qué existe el framework de decisión de abajo.

La heurística que circula en la comunidad (el análisis del trade-off de Sätteri en Byteiota) es práctica: si tu build supera regularmente los 80 segundos y tu pipeline de Markdown es casi vanilla, el cambio es directo. Por debajo de ese umbral, el ahorro absoluto es real pero rara vez justifica tocar el pipeline.

La tabla del trade-off: unified() vs Sätteri

Esa última fila es la que hay que vigilar. Las notas de la versión dicen explícitamente que esperan que Sätteri sea el procesador por defecto en una versión mayor futura. Si hoy usas Astro, no estás decidiendo si Sätteri importa — estás decidiendo cuándo será tu default.

Por qué la API importa más que la velocidad

Aquí va la opinión que nos dejó evaluarlo para un sitio real: la API markdown.processor es el cambio más importante de Astro 6.4, y los equipos que solo ven el benchmark de Rust se están perdiendo el punto.

Unified (remark/rehype y compañía) ha sido el estándar de facto para procesar Markdown en JavaScript durante una década: potente —miles de plugins—, pero también un monopolio con costo real, porque procesa cada archivo a través de capas de transformaciones de AST en JavaScript, justo donde los builds con mucho contenido gastan su tiempo. Las implementaciones nativas de Sätteri (GFM, directivas, primitivas de resaltado de sintaxis) atacan ese costo a nivel de arquitectura, no de optimización.

Pero la API es lo que hace posible la competencia. Antes de 6.4 el pipeline no era reemplazable: podías ajustar unified, pero no sustituirlo. Ahora sí. Es el momento en que el ecosistema deja de ser un punto único de falla, y la razón por la que existe el camino de portabilidad: Sätteri acepta plugins MDAST/HAST, así que los autores pueden apuntar al pipeline de Rust sin esperar a que Astro cambie nada.

La consecuencia práctica para los equipos: la migración de configuración (envolver los plugins en unified({...})) es trabajo obligatorio que conviene hacer ya; el cambio a Sätteri es trabajo opcional que conviene diferir hasta que tu lista de plugins tenga equivalentes.

Qué significa esto para un sitio con Markdoc como el nuestro

Aquí la cobertura genérica deja de servir: la configuración más común en nuestro rincón del ecosistema —Markdoc para colecciones de contenido— queda fuera de la historia de Sätteri por completo.

Markdoc tiene su propio renderizador. No pasa por la API markdown.processor, así que Sätteri no puede acelerarlo y el trade-off de plugins no aplica. El tiempo de build de nuestro sitio está dominado por renderizar más de 750 archivos de contenido con Markdoc y por el bundling, no por el pipeline de Markdown de unified. Cambiarnos a Sätteri hoy no cambiaría nada — una conclusión honesta que casi ningún artículo sobre la versión menciona.

Eso no significa que la versión nos sea irrelevante: el calendario de deprecación sí lo es. Cuando Astro 8.0 elimine las opciones de markdown de nivel superior, todos los proyectos —con Markdoc o sin él— tendrán que estar en el modelo de configuración nuevo. Y como ya usamos una estrategia de contenido multifuente, tenemos más pipelines que un sitio típico, lo que convierte la elección de procesador en una decisión recurrente.

Nuestro framework de evaluación, que aplicaríamos igual en un sitio de cliente:

La heurística de los 80 segundos se sostiene en nuestra experiencia: por debajo, la ganancia de Sätteri es un nice-to-have; por encima, sobre todo con pipelines vanilla, es una mejora de infraestructura genuina.

Qué estamos haciendo, y qué recomendamos hacer

Pasos concretos, en orden, para que esto no se convierta en un ticket que espera hasta Astro 8.0:

1. Corre npx @astrojs/upgrade — sube a 6.4.x (o más reciente) y deja que la herramienta haga la parte mecánica.
2. Envuelve tus plugins: mueve remarkPlugins/rehypePlugins a markdown: { processor: unified({ ... }) }. Es la única parte que se romperá en Astro 8.0 — hazla antes de que se rompa.
3. Audita tu lista de plugins: cuenta lo que usas de verdad. La mayoría de los sitios que auditamos usan 2-4 plugins de remark/rehype, y casi todos (GFM, directivas, smartypants) ya tienen equivalentes nativos en Sätteri.
4. Mide tu build real: corre tu build de producción con cronómetro antes y después de cualquier cambio. El número de marketing es "más de un minuto en sitios de docs"; el que importa es el tuyo.
5. Solo entonces decide sobre Sätteri — y si cambias, compara el output renderizado contra unified para edge cases antes de mergear. El parsing GFM es compatible con el spec, pero los casos límite pueden producir diferencias menores.

Nosotros mantenemos mintec.co en unified por ahora, con la migración de configuración hecha, y reevaluaremos cuando el ecosistema de plugins alcance — la misma conclusión a la que llegamos a los seis meses de nuestra experiencia en producción con Astro + Cloudflare: adopta la dirección de la plataforma temprano, adopta la dirección del ecosistema tarde.

Astro 6.4 hizo algo poco común: lanzó una ganancia de rendimiento real y un cambio arquitectónico en la misma versión. La ganancia es Sätteri. El cambio arquitectónico —un pipeline de Markdown intercambiable— es lo que seguirá importando en 2027.

Si estás evaluando Astro para un sitio con mucho contenido o multilingüe, llevamos más de un año corriendo este stack en producción. Documentamos las lecciones de migrar desde WordPress, los benchmarks reales contra Next.js y lo que cambió con Astro 7.