Entrevista de Frontend: ¿Cómo elegir entre CSR, SSR, SSG e ISR?

Enunciado y escenarios aplicables

Una plataforma de comercio en Next.js 16 tiene cuatro familias de páginas:

• /guides/[slug]: 20.000 guías públicas, editadas semanalmente, cuyo cuerpo de texto debe ser descubierto de manera confiable por los motores de búsqueda;
• /products/[id]: un millón de páginas públicas de productos cuyas descripciones e imágenes pueden tener hasta cinco minutos de desactualización, mientras que el precio y el inventario deben confirmarse en vivo antes del checkout;
• /search?q=: resultados que varían según la consulta, los filtros y el estado actual del catálogo; la primera vista debe poder compartirse, pero no es necesario indexar cada combinación de consulta;
• /account/orders: páginas privadas que varían según el usuario autenticado y no deben ingresar ni a una caché compartida ni a un índice de búsqueda.

El equipo desea reducir el renderizado en el origen sin sacrificar la visibilidad en las páginas públicas ni la capacidad de respuesta en las interactivas. El candidato debe elegir una estrategia principal de renderizado para cada familia de rutas y luego indicar qué regiones pueden combinarse con una estrategia diferente. La respuesta debe definir un límite de frescura, el desencadenante de invalidación, la salida ante fallos y la prueba en producción.

Una guía pública de entrevistas de frontend de 2026 enumera explícitamente la elección de una estrategia de renderizado para una página determinada y la decisión entre ISR y SSR. Un banco de preguntas de frontend independiente incluye una comparación dedicada de CSR, SSR, SSG e ISR. Muchos resultados de búsqueda se quedan en una tabla de pros y contras de cuatro filas. Pocos combinan invalidación, verificación en vivo de campos críticos, una CDN externa y la semántica de fallos. Esta pregunta añade esa capa de decisión de producción.

Lo que evalúa el entrevistador

Primero, ¿define el candidato los requisitos de la página antes de elegir un acrónimo? La ubicación del renderizado no es el objetivo. La indexabilidad pública, el contenido inicial, la frescura, la personalización, el tráfico, la cantidad de páginas, el costo de interacción y el comportamiento ante fallos son los datos de entrada. “SSR es bueno para el SEO” no permite decidir sobre una página de pedidos o un catálogo de un millón de páginas.

Segundo, ¿comprenden dónde impone el costo cada estrategia?

Tercero, ¿pueden identificar un enfoque híbrido? Una página de producto puede usar ISR para una descripción indexable, consultar en el cliente las opciones actuales de entrega y revalidar el precio y el inventario en el servicio de checkout. Elegir ISR no hace que todos los campos sean seguros para servirse desactualizados. Elegir SSR no elimina el JavaScript del cliente ni la hidratación.

Cuarto, ¿pueden convertir la elección en un contrato comprobable? Una respuesta sólida detalla cuán desactualizado puede llegar a estar el contenido, quién lo invalida, qué muestra un fallo de regeneración, si las claves de caché incluyen usuario o región y cuánto JavaScript descarga un navegador real. Aporta métricas de compilación, tiempo de ejecución, caché y corrección de negocio.

Preguntas para clarificar antes de responder

• ¿Es la página pública y está destinada a ser indexada? Es preferible que el cuerpo del texto público, el título, el canonical y el estado estén presentes en la respuesta inicial. Los pedidos privados necesitan autenticación, nada de almacenamiento en caché compartido y una política explícita de noindex.
• ¿Qué tan rápido es el "tiempo real"? Una descripción puede tener cinco minutos de antigüedad, mientras que el precio y el inventario afectan un compromiso de pago. Esos campos no pueden heredar el mismo SLA de caché.
• ¿Qué dimensiones modifican el contenido? El locale, la región, la moneda, la autenticación y el grupo de experimento pueden alterar una clave de caché. Una dimensión faltante puede servir datos incorrectos o privados; demasiadas dimensiones destruyen la tasa de aciertos (hit rate).
• ¿Cuál es la cantidad de páginas y la distribución de actualizaciones? Compilar un millón de URLs en cada despliegue no es viable. Si el 95% son páginas de cola larga (long-tail), precompila las rutas populares y genera el resto en el primer acceso.
• ¿Son confiables los eventos de publicación? ¿Puede el CMS o el catálogo emitir un ID de entidad? Si los eventos pueden perderse, añade expiración basada en tiempo, reconciliación o invalidación manual como compensación.
• ¿Cómo está desplegado el almacenamiento en caché? Un solo proceso, múltiples contenedores, una plataforma administrada y una CDN externa propagan la invalidación de manera distinta. Purgar la caché del servidor Next.js puede dejar intacta otra copia en la CDN.
• En caso de fallo, ¿es más seguro el contenido antiguo que el incorrecto? Servir la última guía exitosa suele ser razonable. El precio, el inventario y el estado del pedido deben ser confirmados por un servicio autoritativo.
• ¿Cuáles son los criterios de éxito? Defina la completitud del contenido indexable, TTFB/LCP/INP, hit rate, retraso de regeneración, antigüedad del contenido, QPS de renderizado en origen, duración de la compilación, tasa de errores y tasa de conflictos en el checkout.

Estructura de respuesta en 30 segundos

“Divido las rutas según si son públicas, la variación por solicitud, la frescura y la cantidad de páginas. Las guías son principalmente SSG y se invalidan por ruta tras la publicación. El detalle del producto utiliza ISR para un cuerpo indexable y de bajo costo, con eventos de catálogo más un fallback por tiempo de cinco minutos; el precio y el inventario se refrescan en el cliente y se confirman nuevamente en el checkout. La búsqueda es SSR por consulta, sin compartir respuestas que contengan dimensiones del usuario. Los pedidos privados utilizan una estructura base (shell) autenticada en el servidor y actualizaciones de datos mediante CSR. Verifico el comportamiento de la caché en una compilación de producción y monitoreo la antigüedad del contenido, el hit rate, TTFB, LCP, tamaño de JavaScript, fallos de regeneración y conflictos de negocio, sin confiar ciegamente en un solo puntaje de Lighthouse.”

Análisis detallado paso a paso

Paso 1: Utilizar una matriz de decisión para seleccionar la estrategia principal por ruta

Pase cada familia de páginas por la misma matriz en lugar de comenzar por las APIs del framework:

“SSG más invalidación por publicación” utiliza regeneración incremental en tiempo de ejecución, aunque su modelo principal de contenido sigue siendo una página estática prerenderizada. Es más económico que aplicar SSR para cada solicitud a 20.000 guías y más específico que recompilar todo el sitio por un error tipográfico. Todas las guías pueden compilarse inicialmente; si el conjunto crece, precompile las rutas populares y genere el resto en la primera solicitud.

ISR se adapta a los detalles de producto porque el cuerpo es público, se consulta con frecuencia y tolera una breve desactualización. Una configuración de revalidación de cinco minutos no constituye un máximo estricto de cinco minutos en todas las condiciones. La primera solicitud después del intervalo aún puede recibir HTML desactualizado mientras se inicia la regeneración en segundo plano. Una página con poco tráfico puede activarse más tarde, y una regeneración fallida extiende la vida útil de la versión anterior. Si la publicación debe aparecer de inmediato, invalide por ID de producto tras confirmarse la escritura y mantenga la ventana de tiempo solo como compensación.

El espacio de consultas de búsqueda es demasiado grande para precompilarlo. SSR puede incluir contenido coherente con la consulta y un estado real en la primera respuesta. Las claves de caché deben incluir todos los parámetros públicos que modifiquen los resultados. Las respuestas que involucren autenticación o precios personalizados deben ser privadas o no almacenarse en caché. El cliente toma el control de los filtros, la paginación y la entrada tras la primera vista.

La página de pedidos no obtiene beneficio alguno de un HTML público indexable. El servidor puede establecer un shell autenticado, mientras que CSR carga la lista y el estado en vivo desde una API de usuario. Esa respuesta no debe ingresar en una caché compartida. CSR es una decisión de renderizado; la autenticación y la autorización siguen perteneciendo al servidor.

Paso 2: Expresar ISR como un contrato de frescura e invalidación

La ruta del producto necesita dos contratos:

Cacheable body: name, description, images, category
  Event invalidation: after product:{id} updates successfully
  Time fallback: 300 seconds
  Failure semantics: serve the last successful version and alert

Critical live fields: price, inventory, delivery eligibility
  Page display: refresh from the authority and show update time
  Checkout submission: recompute on the server and confirm changes

La guía de ISR de Next.js indica que la primera solicitud tras el intervalo puede recibir contenido desactualizado mientras la regeneración se ejecuta en segundo plano. Las solicitudes posteriores reciben la nueva versión tras completarse exitosamente. Si la regeneración lanza un error, la última versión exitosa permanece en caché y otra solicitud reintentará el proceso. Monitoree la antigüedad del contenido; un valor de configuración no es prueba de que se cumpla el SLA del negocio.

En Next.js 16, revalidateTag(tag, "max") utiliza stale-while-revalidate y se adapta a artículos, catálogos o cuerpos de productos que admiten una breve demora. Cuando un usuario debe leer inmediatamente su propia escritura, updateTag en una Server Action proporciona semántica de tipo read-your-writes. No son botones intercambiables de “limpiar caché”. El origen del evento, la desactualización permitida y el punto de llamada determinan qué operación es la adecuada.

Trace también la cadena de propagación. El navegador, la CDN, la caché de rutas de Next.js, la caché de datos y el servicio upstream pueden tener cada uno un TTL. La guía oficial de CDN advierte que la invalidación por ruta o etiqueta en Next.js no purga automáticamente una copia almacenada por separado en la CDN. Si se añade una CDN externa, purgue también las variantes coincidentes de HTML y datos, o configure su TTL para que satisfaga el mismo contrato de frescura. El autoalojamiento (self-hosting) con múltiples instancias también necesita una caché compartida o un estado sincronizado de etiquetas para que ninguna instancia quede desactualizada.

Paso 3: Gestionar el SEO, la interacción y los límites de fallos por separado

Google puede ejecutar JavaScript e indexar HTML renderizado, pero el renderizado entra en una cola y otros bots podrían no ejecutar JavaScript. Las guías públicas y los cuerpos de productos deben incluir texto visible, título, canonical, datos estructurados y el estado correcto en el HTML inicial. No devuelva un shell 200 vacío permitiendo que el cliente convierta un producto faltante en “no encontrado”. El servidor o la ruta de generación estática deben producir el 404 real.

El prerenderizado no hace automáticamente que una página sea rápida o interactiva. Una página SSR/SSG/ISR con demasiados componentes de cliente sigue asumiendo el costo de descarga, análisis sintáctico e hidratación de JavaScript. Un CSR bien dividido con datos cercanos puede rendir bien en la navegación autenticada. Mida TTFB, LCP, INP, tareas largas (long tasks), JavaScript descargado y ejecutado, y el tiempo transcurrido desde que es visible hasta que es interactivo.

Clasifique el comportamiento ante fallos según el riesgo de los datos:

• Falla la regeneración de la guía o del cuerpo del producto: sirva la última versión exitosa, exponga su hora de actualización y active alertas sobre su antigüedad.
• Se agota el tiempo de espera del servicio upstream de búsqueda: muestre un fallo con opción a reintento o una caché corta explícitamente permitida, no un resultado vacío inventado.
• Falla la API de precios o inventario: no confirme un valor antiguo; exija un reintento antes del checkout.
• Falla la API de pedidos: conserve la UI ya cargada y ofrezca reintentar; nunca recurra a datos entre distintos usuarios mediante una caché compartida.
• Los eventos de invalidación sufren retrasos: reconcilie las versiones de las entidades, detecte las páginas desfasadas respecto a la autoridad y emita invalidaciones de compensación.

Paso 4: Verificar con una compilación de producción y métricas de negocio

El modo de desarrollo no puede demostrar el comportamiento de la generación estática y de ISR. Realice una compilación de producción y ejecute el servidor de producción antes de verificar las cuatro familias de rutas. Cubra al menos estas pruebas:

1. Inspeccione la salida de la compilación y confirme que cada ruta sea estática, bajo demanda o dinámica según lo previsto, en lugar de convertirse accidentalmente en SSR por una lectura no almacenada en caché.
2. Solicite un producto repetidamente para comprobar los aciertos (hits); luego actualícelo y registre los tiempos del evento, la invalidación y el primer HTML nuevo.
3. Provoque un fallo en la dependencia de regeneración, demuestre que el último cuerpo exitoso se mantiene y que el error queda registrado, y luego recupere el servicio.
4. Solicite diferentes locales, regiones, monedas y estados de autenticación para comprobar claves completas y el aislamiento de respuestas privadas.
5. Obtenga el HTML inicial directamente para verificar el cuerpo, los metadatos, el canonical y el 404, y luego utilice un navegador real para la hidratación.
6. Modele una CDN externa y múltiples instancias; compruebe que la invalidación llegue a cada capa e instancia.
7. Con la distribución real de páginas, mida el tiempo de compilación, el QPS de renderizado en origen, el hit rate, TTFB, LCP, INP y el costo de JS.
8. Compare los valores mostrados con la autoridad de checkout y vigile los conflictos de precio/inventario, para que la optimización no altere la corrección transaccional.

Migre ruta por ruta. Observe el tráfico y la corrección actuales de SSR, y luego mueva las guías de bajo riesgo a entrega estática. Ejecute primero el ISR de productos en modo sombra (shadow mode) registrando lo que devolvería la caché. Sírvalo solo después de que la invalidación demuestre ser confiable. Mantenga una opción de reversión por ruta hacia la estrategia anterior, activada por límites de corrección o de antigüedad del contenido.

Ejemplo de respuesta de alta calidad

“No elegiría un solo acrónimo para toda la aplicación. Las guías son públicas, uniformes y se editan con poca frecuencia, por lo que compilo HTML estático e invalido la ruta tras una publicación exitosa en el CMS. El texto inicial se mantiene indexable y casi todas las solicitudes aprovechan la caché estática. Hay un millón de URLs de productos, así que precompilo los productos de alta demanda y genero el resto en el primer acceso. El cuerpo del producto utiliza ISR, invalidado por ID de producto, con 300 segundos únicamente como compensación por pérdida de eventos. La primera solicitud tras la expiración aún puede recibir contenido antiguo e iniciar la generación en segundo plano, por lo que monitoreo la brecha entre la hora de actualización de la entidad y la hora de generación de la caché en lugar de prometer que 300 signifique un máximo estricto.”

“El precio, el inventario y la elegibilidad de entrega no heredan la ventana de desactualización del cuerpo. El navegador los refresca desde la autoridad, y el checkout los recalcula en el servidor y solicita confirmación si el precio cambió. La búsqueda tiene demasiadas combinaciones y varía según la consulta, por lo que su primera vista es SSR y el cliente asume los filtros posteriores. Las respuestas que contienen autenticación o condiciones personalizadas nunca ingresan a una caché compartida. Los pedidos utilizan un shell autenticado y datos mediante CSR, con autorización de usuario del lado del servidor y noindex.”

“Verifico los modos de ruta reales con una compilación de producción, y luego pruebo aciertos, invalidación por eventos, el fallback de 300 segundos, fallos de regeneración y recuperación. Una CDN externa debe purgarse junto con Next.js, y múltiples instancias requieren invalidación sincronizada. Inspecciono el HTML público inicial para comprobar el cuerpo, canonical y estado, y luego mido TTFB, LCP, INP y costo de JavaScript en un navegador real. Finalmente, comparo los precios mostrados con los de checkout. Obtener buen rendimiento a costa de degradar la corrección transaccional sigue siendo un fallo.”

Errores comunes y mejoras

• Elegir una sola estrategia para toda la aplicación → Las páginas públicas, de búsqueda y privadas tienen requisitos diferentes → Decidir por ruta y, a veces, por región de datos.
• Tratar SSR como una garantía de SEO → Los metadatos, el estado, el canonical y los enlaces rastreables aún pueden ser incorrectos → Inspeccionar el HTML inicial y la salida del crawler.
• Afirmar que CSR es completamente invisible para los motores de búsqueda → Google puede renderizar JavaScript, aunque con colas de procesamiento y diferencias de capacidad frente a otros bots → Prerenderizar el contenido público clave y describir la limitación con precisión.
• Tratar revalidate=300 como un SLA estricto de cinco minutos → El bajo tráfico, el trabajo en segundo plano y los fallos prolongan la desactualización → Combinar invalidación por eventos, monitoreo de antigüedad y un fallback temporal.
• Asignar a toda la página una única regla de frescura → La descripción tolera desactualización; el precio y el inventario no pueden prometerse a partir de ella → Dividir los datos por riesgo y revalidar en el límite transaccional.
• Purgar únicamente Next.js → Una CDN externa u otra instancia pueden conservar una copia → Mapear cada nivel de caché y probar la propagación.
• Asumir que prerenderizado equivale a rápido → El exceso de JavaScript, la hidratación y los servicios upstream lentos siguen perjudicando → Medir red, hilo principal, Web Vitals y métricas del servidor.
• Probar ISR únicamente en desarrollo → El comportamiento en desarrollo no representa el almacenamiento en caché de producción → Utilizar una compilación y un servidor de producción para pruebas de aciertos, invalidación y fallos.
• Usar páginas desactualizadas para ocultar cualquier error → Búsquedas vacías, precios desactualizados o pedidos entre usuarios provocan decisiones erróneas o filtraciones → Definir stale-if-error según el riesgo de los datos.

Preguntas de seguimiento

¿Puede mantenerse ISR si los cambios en los productos deben ser visibles globalmente en menos de diez segundos?

Sí, pero diez segundos deben convertirse en un SLO de invalidación de extremo a extremo. Tras confirmarse la transacción en el catálogo, emita de forma confiable un evento versionado, sincronice la invalidación de etiquetas en todas las instancias de Next.js, purgue la CDN externa y sondee la nueva versión desde múltiples regiones. La revalidación temporal es una compensación, no una garantía de diez segundos. Si la cadena de purga no puede cumplir el objetivo, lea ese campo dinámicamente o utilice una ruta de caché más corta cuyo límite pueda demostrarse.

¿Por qué puede ser un problema generar estáticamente un millón de productos?

Acopla el tiempo de compilación, los artefactos y el riesgo del despliegue a la cantidad de páginas, a pesar de que muchas páginas de cola larga tal vez nunca se lean. Precompile los productos de alto tráfico y genere el resto en la primera solicitud. Limite la concurrencia de regeneración, evite que un evento de alta concurrencia provoque una tormenta de regeneraciones y preserve un comportamiento confiable de 404 para productos inexistentes.

¿Se puede almacenar en caché de CDN una respuesta de SSR?

La capacidad de compartir la respuesta depende de si esta es idéntica en todas las dimensiones de la clave de caché, no del nombre SSR. Una respuesta de búsqueda pública con una clave completa y una breve desactualización permitida puede almacenarse en caché con cautela. Una respuesta que involucre cookies, permisos de usuario, precios personalizados o pertenencia a un experimento debe ser privada o no almacenarse en caché. Pruebe Vary, la construcción de claves y el aislamiento entre usuarios tras cerrar sesión.

¿Invalidan RSC, streaming SSR y PPR el modelo de cuatro estrategias?

Permiten combinar el trabajo estático y dinámico de forma más precisa dentro de una misma ruta, pero no eliminan las variables de decisión. Todavía se debe definir dónde se ejecuta el trabajo, qué contiene el HTML inicial, cuánto tiempo se almacenan los datos en caché, cuánto JavaScript recibe el cliente y cómo falla una región dinámica. En una entrevista, establezca la entrega y frescura de CSR/SSR/SSG/ISR y luego explique cómo RSC, el streaming o el prerenderizado parcial mejoran una región específica.

¿Cómo se previene una tormenta de invalidaciones?

Agrupe eventos repetidos por entidad, descarte versiones obsoletas, limite la concurrencia de regeneración, agregue fluctuación aleatoria (jitter) y permita un solo generador por clave de caché. Monitoree la profundidad de la cola, la duración de la generación, los fallos y la antigüedad del contenido. Si la acumulación de trabajo pendiente crece, preserve lecturas dinámicas y autoritativas para precio e inventario mientras el cuerpo del producto continúa sirviendo su última versión exitosa.