Desde el lanzamiento inicial de Astro 1.0, los desarrolladores han tenido que elegir entre generar salida estática (SSG) o de servidor (SSR). Los sitios web estáticos ofrecen un rendimiento increíble construyendo tus páginas con anticipación. Los servidores aprovechan su poder dinámico para generar HTML bajo demanda, único para cada solicitud.
Hasta ahora, esta había sido una decisión de todo o nada—¿es esto completamente estático o debería desplegar un servidor?
Astro 2.0 desbloquea lo mejor de ambos mundos con renderizado híbrido. Elige entre el rendimiento de las páginas estáticas o la flexibilidad total del renderizado del servidor para cada página de tu sitio web.
En esta publicación, revisaremos cómo funciona el renderizado híbrido explorando solo algunas de las nuevas características y mejoras de rendimiento posibles en Astro 2.0.
¿Cómo funciona el proceso de build de Astro?
El proceso de build de Astro ocurre en múltiples etapas, comenzando con un bundle de JavaScript del lado del servidor generado por Vite. Para simplificar un poco, la salida de este bundle incluye:
- JavaScript del lado del servidor usado para renderizar HTML
- Un client manifest que usa análisis estático para recolectar todos los componentes necesarios para la interactividad del lado del cliente
- CSS y otros assets para el cliente
Luego, Astro usa el client manifest para iniciar un segundo proceso de build que agrupa JavaScript optimizado del lado del cliente.
Si tu output configurado es static, Astro ejecutará el JavaScript del lado del servidor y escribirá la salida a archivos .html. El JavaScript del lado del servidor luego se descarta.
Si tu output configurado es server, Astro pasa el JavaScript del lado del servidor a un adaptador para procesamiento adicional.
Los adaptadores aseguran que tu JavaScript del lado del servidor sea compatible con el runtime de JavaScript de un proveedor de hosting en particular. Ten en cuenta que en este caso, la salida final no es un conjunto de archivos .html, sino el código JavaScript necesario para renderizar HTML.
Lamentablemente, esta configuración era bastante rígida y no permitía mezclar rutas estáticas y dinámicas en el mismo proyecto. Lo que realmente necesitábamos era un proceso que habilitara ambos patrones en paralelo.
¿Cómo funciona el renderizado híbrido?
En Astro 2.0, hemos renovado el pipeline de astro build para manejar el renderizado híbrido.
Durante el proceso inicial de bundling, un nuevo paso de análisis estático determina qué páginas deben ser pre-renderizadas.
Esto nos permite dividir tus rutas en chunks separados, dependiendo de cuándo deben ser renderizadas.
Al igual que el proceso static original, el chunk pre-renderizado se ejecuta y la salida se escribe a archivos .html. El chunk luego se descarta.
Al igual que el proceso server original, el chunk del servidor se pasa a un adaptador para procesamiento adicional. En última instancia se desplegará como una función Serverless o Edge, dependiendo de tu adaptador.
¿Por qué usar análisis estático?
El análisis estático es una técnica usada para analizar tu código fuente sin ejecutarlo realmente. Astro depende de este enfoque en muchos lugares, pero es especialmente crítico durante el proceso de build. Por razones de rendimiento, Astro debe poder categorizar tus páginas sin ejecutar su código fuente. Para proyectos más pequeños, la ejecución podría no ser un problema, pero a escala se convierte rápidamente en un cuello de botella.
El renderizado híbrido fue diseñado específicamente teniendo en mente el análisis estático, aunque consideramos APIs alternativas.
El proceso de build de Astro es capaz de verificar la presencia de una declaración export const prerender = true para determinar qué páginas deben ser pre-renderizadas.
Para hacer esto de forma eficiente, dependemos de la maravillosa librería es-module-lexer, que también es usada internamente en Node.
---// This route should be generated at build time!export const prerender = true
const text = await fetch("https://example.com/").then((res) => res.text())---
<article set:html={text} />Casos de uso para renderizado híbrido
El renderizado híbrido desbloquea un conjunto completamente nuevo de casos de uso posibles, pero queríamos destacar algunos que nos emocionan particularmente.
Caso de uso: mejorar el rendimiento de renderizado de páginas populares
Considera un sitio e-commerce pequeño/mediano construido con Astro, con miles de productos y variaciones posibles diferentes. Si usaras generación de sitios estáticos, estarías atascado reconstruyendo tu sitio web cada vez que uno de estos productos cambiara o se agotara.
Este tipo de proyecto requiere renderizado del lado del servidor, lo que permitiría que tus páginas de productos se generen frescas en cada solicitud. Pero ahora tenemos un nuevo problema: tu página principal ya no es estática. El rendimiento de carga sigue siendo crítico para impulsar las ventas, y tu página principal no tiene ningún contenido dinámico que realmente requiera que se reconstruya fresca en cada solicitud.
El renderizado híbrido resuelve nuestro problema de rendimiento renderizando la página principal a HTML estático con anticipación, mientras mantiene el resto de tu sitio web renderizándose bajo demanda.
Caso de uso: agregar una API a tu sitio estático existente
A medida que tu sitio web estático crece, puedes encontrar la necesidad de alojar una API pública. Históricamente, agregar una API a un sitio estático ha requerido configuración específica del host, pero en Astro 2.0, podemos agregar endpoints de servidor (rutas de API) sin sacrificar el rendimiento de nuestras páginas estáticas.
De hecho, los endpoints de servidor pueden ser agregados automáticamente por el hook injectRoute de nuestra Integrations API. ¡Estamos emocionados de fomentar un poderoso ecosistema de integraciones de terceros con estas nuevas primitivas!
Caso de uso: mejorar el rendimiento de build de sitios grandes
La generación estática puede ser difícil de escalar a miles de páginas, ya que cada página debe ser renderizada durante el proceso de build. El renderizado del lado del servidor difiere el renderizado de páginas hasta el momento de la solicitud, eliminando un posible cuello de botella de tu proceso de build.
Cuando hay cientos de rutas generadas por getStaticPaths, el renderizado del lado del servidor puede llevar a mejoras significativas de rendimiento. En nuestras pruebas internas, vimos los tiempos de build mejorar hasta en un 30% al cambiar rutas dinámicas a renderizado del lado del servidor.
Empezando con renderizado híbrido
¡El renderizado híbrido está disponible hoy en Astro 2.0! Puedes dirigirte a nuestra guía de renderizado del lado del servidor para aprender más sobre las características SSR de Astro. Los adaptadores oficiales de Astro también han sido actualizados para soportar el renderizado híbrido, así que asegúrate de instalar la última versión de tu adaptador.
Para celebrar el lanzamiento, nuestros amigos de SST acaban de lanzar astro-sst, su adaptador oficial de AWS para Astro. Revisa su video de anuncio y walkthrough para aprender más y empezar con AWS + SST.
¡Agradecemos tus comentarios! Recopilamos una entrada maravillosa durante el Prerender API RFC y te invitamos a proponer ideas futuras usando nuestro nuevo roadmap público o comunidad de Discord.