Dominar las tres estrategias de renderizado no es suficiente si no sabes cuándo aplicar cada una. La verdadera habilidad está en comprender qué métrica de negocio quieres optimizar —velocidad, SEO, interactividad o costos— y combinar técnicas cuando el proyecto lo exige.
¿Dónde y cuándo se genera el HTML en cada estrategia?
Cada modelo de renderizado resuelve el ciclo de obtener datos y generar HTML de forma distinta [01:07]:
- Server side rendering (SSR): el fetch ocurre en el servidor por cada request. Se consulta la base de datos en cada visita, aunque se puede mitigar con estrategias de caché para no golpear la base de datos directamente cada vez.
- Static site generation (SSG): el fetch también se ejecuta en el servidor, pero una sola vez durante el comando de build. Se generan archivos estáticos que se sirven sin procesamiento adicional.
- Client side rendering (CSR): el navegador es quien se encarga de toda la renderización. El HTML llega vacío y se completa con JavaScript en el dispositivo del usuario.
Esto impacta directamente en la frescura de los datos. En SSR los datos siempre están actualizados porque se consultan por visita. En CSR también, porque se piden al momento. En SSG solo se actualizan cada vez que se lanza un nuevo build [03:05].
¿Por qué el SEO depende de la estrategia de renderizado?
El SEO —la optimización para motores de búsqueda— se ve perjudicado con CSR [02:40]. Los crawlers de Google o Bing analizan el código fuente igual que un view source. Si el HTML llega vacío, no hay contenido que indexar. Con SSR o SSG el HTML se recibe completo, lo que permite una indexación correcta.
¿Cuánto cuesta cada estrategia en infraestructura?
El costo operativo varía considerablemente [04:33]:
- SSR: costo alto. Se necesita un servidor con RAM y CPU suficientes para generar HTML dinámicamente en cada petición.
- SSG: costo mínimo. Solo se consume servidor en el momento del build; después se sirven archivos planos.
- CSR: costo prácticamente nulo en servidor, porque todo el trabajo de renderizar la UI se delega al navegador del usuario.
¿Qué preguntas hacerse para decidir la estrategia correcta?
Existe un patrón mental sencillo para tomar la decisión [06:02]:
- ¿Necesitas aparecer en motores de búsqueda? Si la respuesta es sí, descarta CSR puro.
- ¿Los datos cambian frecuentemente? Si sí, elige SSR. Si no cambian de forma constante, SSG es suficiente.
- ¿La aplicación es altamente interactiva? Dashboards, formularios y gráficas encajan mejor con CSR. Si no requiere interactividad, SSG puede funcionar.
Algunos ejemplos prácticos [05:10]:
- E-commerce y noticias: SSR, porque los datos cambian constantemente y necesitan indexación.
- Blogs, landing pages y documentación: SSG, contenido que se actualiza con poca frecuencia.
- Dashboards internos y apps bancarias: CSR, aplicaciones que no necesitan estar indexadas ni requieren render ultra rápido.
¿Qué son las arquitecturas híbridas de renderizado?
En el mundo real no te casas con una sola estrategia [07:20]. Un mismo proyecto puede combinar técnicas distintas por ruta o incluso dentro de la misma ruta.
Imagina un e-commerce:
- La landing page principal es estática para maximizar velocidad.
- El blog también se mantiene SSG.
- La sección de productos usa SSR porque necesita alinearse con el inventario en tiempo real.
- El carrito de compras y el dashboard de administración funcionan con CSR, ya que no requieren indexación.
¿Puede una misma ruta usar dos técnicas a la vez?
Sí. Un ejemplo avanzado: la página de productos puede hacer el render inicial con SSR o SSG, pero una vez que el usuario interactúa —agrega al carrito, deja un comentario, califica con estrellas— esa parte se maneja con JavaScript interactivo del lado del cliente [08:30]. No se recarga la página completa; se mantiene la experiencia fluida.
Para lograr estas estrategias híbridas, los frameworks como Next.js, Angular o Vue son fundamentales [09:15]. Permiten definir por ruta qué técnica aplicar, e incluso mezclarlas de forma automática. Hacer esto con JavaScript puro es posible, pero equivale a reinventar la rueda. La ventaja del framework es crear valor rápido y ofrecer mejores experiencias de usuario sin configurar manualmente cada detalle del renderizado.
¿Ya decidiste qué estrategia usarías en tu próximo proyecto? Comparte tu caso en los comentarios.
