No existe una arquitectura más rápida para todo
Una respuesta en caché cerca del visitante puede ser rápida sin importar cómo se generó originalmente el HTML. Una página renderizada en el servidor con consultas eficientes puede superar a una página estática que envía JavaScript en exceso. El TTFB, la frescura del contenido y la capacidad de respuesta son propiedades distintas.
Esta comparación es un marco de decisión, no un benchmark de sistemas de clientes. La versión del framework, el entorno de ejecución, el adaptador de hosting, la configuración de caché, la geografía y el acceso a los datos influyen en los resultados.
Compara el trabajo que hace cada enfoque
| Enfoque | Cuándo se genera el HTML | Buen uso inicial | Qué revisar con cuidado |
|---|---|---|---|
| SSR | Durante una solicitud, según la caché | Páginas autenticadas o específicas de cada solicitud | Trabajo en el origen, tiempos de espera y límites de la caché privada |
| SSG | Antes de la visita, normalmente durante una compilación | Páginas editoriales y de documentación estables | Duración de la compilación y retraso en la publicación |
| ISR | Salida generada que se reutiliza y se actualiza | Contenido público con una antigüedad acotada | Invalidación, fallos de regeneración y primera visita sin caché |
Usa SSR cuando la solicitud cambia la respuesta
Las páginas de cuenta y las vistas que dependen de permisos suelen necesitar decisiones en el momento de la solicitud. Mantén la autenticación y la autorización en el servidor e impide la caché compartida de respuestas privadas. El streaming, la caché de datos y un diseño cuidadoso de las consultas pueden reducir la espera, pero no eliminan la necesidad de medir.
SSR no implica un costo de infraestructura determinado ni un tamaño de clúster obligatorio. La carga, el trabajo de cada respuesta y la estrategia de escalado determinan esos requisitos.
Usa SSG cuando la publicación puede ocurrir antes de las visitas
El HTML generado de antemano se puede servir con un hosting estático normal o una CDN. Es un buen punto de partida para contenido que cambia de forma previsible. Comprueba cuánto tarda una compilación realista y cómo ven los editores los borradores antes de publicar.
No todos los sistemas estáticos regeneran cada página en cada edición; el comportamiento de la compilación incremental depende de la herramienta. Prueba el procesamiento de imágenes, la obtención de contenido y el tiempo de despliegue, además del renderizado de las páginas.
Usa ISR cuando una antigüedad acotada sea aceptable
ISR combina la salida generada con la regeneración. En el Pages Router de Next.js, un intervalo de revalidación permite que una solicitud posterior dispare la actualización una vez transcurrido el intervalo; no es un temporizador que garantice contenido fresco en un segundo exacto. La salida en caché puede seguir visible mientras se regenera.
Valida el comportamiento de las primeras visitas, las regeneraciones fallidas y la invalidación bajo demanda en tu plataforma de hosting real. Los nombres de las APIs y su soporte varían según el router y la versión del framework. No des por hecho que un entorno edge admite las mismas funciones de regeneración que un despliegue en Node.js.
Las descripciones públicas de productos suelen tolerar cierta antigüedad, pero el precio, el inventario y la decisión de pago definitivos deben comprobarse en el flujo de la transacción. Nunca permitas que una página antigua en caché sea la única fuente de verdad para una compra.
Haz una comparación que puedas reproducir
- Usa el mismo contenido, las mismas imágenes y un comportamiento de interacción equivalente en todas las implementaciones.
- Registra la versión del framework, el entorno de ejecución, la región del servidor, la CDN, la región de la base de datos y la política de caché.
- Prueba por separado las solicitudes en frío y en caliente, incluidas la regeneración y la caída del origen.
- Mide desde varias ubicaciones y con cargas concurrentes realistas; registra el número de muestras y la distribución de la latencia.
- Compara el LCP, los bytes transferidos y las trazas de interacción, además del TTFB.
- Prueba la publicación, la despublicación, los cambios de permisos y la reversión con el equipo que mantendrá el sitio.
Preguntas frecuentes
¿Se pueden combinar estrategias?
Sí. Un blog, un catálogo de productos y un panel privado pueden tener necesidades de renderizado y de caché distintas. Define esos límites de forma explícita y mantén el número de modos operativos lo bastante reducido para que tu equipo pueda probarlos.
¿Qué estrategia de renderizado es mejor para el blog de una empresa?
El HTML público generado de antemano o en caché suele ser un buen punto de partida cuando el contenido cambia de forma previsible. La elección correcta también depende de la vista previa, el retraso de publicación, las integraciones y el mantenimiento. Mide la página completa, incluidas las imágenes y el trabajo de interacción, no solo el primer byte de la respuesta.
¿Un intervalo de revalidación de ISR garantiza una actualización inmediata?
No. El comportamiento depende del framework y del despliegue. En el modelo del Pages Router de Next.js descrito arriba, una solicitud posterior puede disparar la regeneración tras el intervalo, mientras que una respuesta generada antes puede seguir disponible. Prueba las actualizaciones fallidas, las primeras visitas sin caché y la invalidación bajo demanda.
¿Las páginas de cuenta privadas pueden usar la misma caché compartida que un artículo público?
Las respuestas privadas o que dependen de permisos necesitan límites deliberados y no deben filtrarse a través de una caché pública compartida. Establece la autorización antes de devolver información protegida. Las páginas editoriales públicas y las páginas de cuenta autenticadas pueden usar políticas de renderizado y de caché distintas.
Fuentes y lecturas recomendadas
- Next.js: Incremental Static Regeneration, Pages Router
- Next.js: renderizado del lado del servidor, Pages Router
- Google: Web Vitals
Sigue explorando
Compara WordPress headless y tradicional y luego usa el flujo de medición del rendimiento.
Leave a Reply