Elegir la estrategia de renderizado correcta puede marcar la diferencia entre un sitio rápido y eficiente o uno costoso y lento. El static site generator (SSG) es una técnica que construye el HTML una sola vez, lo sirve como archivo estático y solo se actualiza cuando el desarrollador lo decide. Entender sus ventajas, limitaciones y casos de uso es fundamental para cualquier arquitecto frontend.
¿Cómo funciona el flujo de un static site generator?
A diferencia de server side rendering, donde cada request del usuario genera dinámicamente el HTML, en SSG el desarrollador ejecuta un script de construcción que consulta las APIs o la base de datos y pregenera los archivos HTML [01:47]. Una vez generados, estos archivos se despliegan en un CDN (content delivery network), un servidor especializado en distribuir contenido estático [02:10].
El usuario consulta directamente esos archivos ya construidos. No hay proceso dinámico, no hay consultas a bases de datos en cada visita. Es como publicar un libro: una vez lanzado, el contenido no cambia hasta que el autor decide crear una nueva edición [00:32].
¿Qué sucede en la práctica al correr el build?
Dentro del proyecto de ejemplo, el código de SSG no expone un servidor de Node como lo haría server side rendering. En su lugar, es un script que se ejecuta con el comando npm run build [03:52]. Al correrlo:
- Se lee la base de datos.
- Se construye la página web.
- Se genera una carpeta llamada dist (distribution) con el
index.html ya listo [04:30].
Ese archivo estático se puede servir con npm run serve, que en el ejemplo lo despliega en el puerto 3001 [05:32]. El contenido ya está renderizado, listo para mostrarse sin ningún procesamiento adicional.
¿Se puede distinguir un sitio SSG de uno con server side rendering?
Al inspeccionar el view source de ambos, el resultado luce prácticamente igual [05:54]. La diferencia real está en cómo se generó: uno de forma dinámica en cada petición y el otro de forma estática antes del despliegue. La pista más visible es la velocidad de carga: un sitio SSG carga de forma casi instantánea, mientras que un sitio con server side rendering puede mostrar un pequeño loading por la consulta a la base de datos [06:28].
¿Cuál es la gran ventaja y la principal desventaja del SSG?
La ventaja es clara: rendimiento superior. No hay consultas dinámicas, no hay procesamiento en el servidor por cada visita, el archivo ya existe y se entrega directamente [07:04].
La desventaja es igual de evidente: la información queda desactualizada. Si se agregan nuevos productos a la API, el sitio SSG no los mostrará hasta que se ejecute un nuevo npm run build [07:22]. En el ejemplo, al crear productos nuevos, el sitio con server side rendering los muestra de inmediato, pero el sitio estático requiere una reconstrucción explícita [07:48].
¿Cuándo conviene usar static site generator y cuándo no?
La decisión depende de la periodicidad con la que cambian los datos [08:44].
- No conviene para un timeline de una red social como Facebook, donde se publican posts y fotos cada segundos. Generar un build personalizado para cada usuario sería extremadamente costoso [08:56].
- Sí conviene para blogs, donde un artículo se publica y rara vez se modifica. No necesita consultar la base de datos en cada visita [09:42].
- Funciona muy bien en landing pages: páginas de venta, call to action, suscripciones. Su contenido cambia poco y los ajustes se hacen en ventanas de tiempo planificadas [10:48].
Para portales de noticias con alta frecuencia de publicación, como el New York Times, estar disparando múltiples builds por cada autor se vuelve complejo, así que ahí también conviene optar por server side rendering [10:24].
¿Cómo se automatizan las actualizaciones en un sitio estático?
En ingeniería se usan disparadores (triggers) [10:04]. Si hay un cambio en la base de datos, un proceso automático genera el build y ejecuta un nuevo despliegue. El autor no necesita correr npm run build manualmente. Si nadie hace cambios, el sitio permanece pregenerado y la carga es instantánea.
Con SSG y server side rendering cubiertos, el siguiente paso es entender client side rendering, la tercera técnica que complementa el panorama de estrategias de renderizado. ¿Con cuál de estas estrategias trabajas actualmente? Comparte tu experiencia.
