Next.js estático, SSR o ISR: cómo elegir por ruta
No clasifiques todo el proyecto con una sola etiqueta: decide cada ruta según frescura, personalización, caché, privacidad y coste de fallo.
Clasifica los requisitos de cada URL
Un catálogo público y una cuenta bancaria no comparten el mismo contrato. Para cada ruta anota cuánto puede envejecer el contenido, si dos visitantes pueden recibir el mismo HTML, si utiliza cookies o permisos y qué debe ocurrir cuando el origen falla. Esa tabla decide la estrategia con más precisión que llamar a todo el repositorio “dinámico”.
La documentación de renderizado de Next.js explica los mecanismos. El equipo todavía debe traducir frescura y privacidad del producto en una elección explícita.
Genera estático cuando el resultado es compartible
Marketing, documentación, políticas y colecciones editoriales suelen funcionar bien como archivos generados. Se sirven desde caché, no dependen de un proceso por visita y mantienen disponibilidad durante una caída del backend. La publicación produce un artefacto identificable que puede probarse antes de recibir tráfico.
Evita crear en build todas las combinaciones imaginables de filtros. Publica URLs con demanda real, responde 404 para valores inválidos y usa canonical coherente. Miles de páginas casi vacías perjudican al lector y complican rastreo, despliegue e invalidación.
Revalida si aceptas una ventana de antigüedad
ISR o una caché con revalidación encaja cuando el contenido cambia pero no en cada solicitud. Define el intervalo desde la necesidad: “los cambios editoriales aparecen en cinco minutos”, no “usaremos 300 segundos porque parece razonable”. Para correcciones urgentes, añade invalidación por evento y reintentos.
Observa aciertos, fallos y regeneraciones. Si la actualización falla, decide si conservas la versión anterior o muestras error. La página antigua puede ser una buena degradación para un artículo, pero una mala decisión para disponibilidad de entradas.
Renderiza en servidor solo con verdad de solicitud
SSR es apropiado para permisos, datos privados, inventario muy cambiante o contenido dependiente de la petición. Marca las respuestas privadas para que nunca entren en una caché compartida. Reduce llamadas encadenadas, establece timeouts y decide qué paneles opcionales pueden omitirse si una dependencia tarda.
El coste no es solo cómputo. Cada render puede abrir conexiones y ampliar la superficie de incidente. Si una ruta entrega el mismo contenido a todos, introducir un servidor en cada visita exige una justificación medible.
Comprueba la salida desplegada
Prueba una visita sin caché, un hit, una invalidación, un origen caído, una sesión autenticada y una URL inexistente. Inspecciona el HTML que recibe un crawler. Mide TTFB, LCP, ratio de caché, errores del servidor y fallos de regeneración.
La arquitectura habitual es híbrida: páginas públicas estáticas, datos compartidos revalidados, cuentas privadas en servidor e interacción en cliente. Elegir por ruta ofrece mejor rendimiento y recuperación que imponer un modo único por comodidad.
Preguntas frecuentes
¿Todo un proyecto Next.js debe usar el mismo modo?
No. Una web puede combinar páginas estáticas, contenido revalidado y rutas privadas renderizadas en cada solicitud.
¿SSR mejora siempre el posicionamiento?
No. Una página estática accesible puede ser igual de rastreable y suele reducir latencia, coste y puntos de fallo.
¿Cuándo conviene ISR?
Cuando muchos lectores comparten la página y el producto permite mostrar durante un intervalo corto una versión anterior.