Planteamiento y contexto
La página contiene navegación, contenido del artículo, recomendaciones, comentarios y acciones personalizadas. El artículo debe ser visible rápidamente; un módulo lento no debe bloquear los primeros bytes ni tumbar toda la página cuando un servicio falle. Diseña un SSR por streaming con Suspense y explica cómo el servidor envía el shell, cómo se completan los límites, cómo se degradan los fallos y cómo se recupera el cliente después de que se carguen los scripts.
React documenta que el streaming puede enviar primero el shell y los fallbacks, y luego reemplazarlos a medida que los límites se completan. La entrevista evalúa si puedes transformar ese mecanismo en un comportamiento controlado de tiempos de espera, errores, caché y monitoreo.
Qué evalúa el entrevistador
Cubre el shell estable frente a los límites asíncronos, la desduplicación de solicitudes, los tiempos de espera de los límites, los errores del servidor, los reintentos del cliente, las variantes de caché, la cancelación, la accesibilidad y Core Web Vitals. Especifica qué contenido debe ser sincrónico y cuál puede retrasarse.
Preguntas de aclaración para hacer
- ¿Es el objetivo de la primera pantalla TTFB, LCP o tiempo de interacción, y cuál es el presupuesto de cada uno?
- ¿Qué nivel de disponibilidad y privacidad se aplica al artículo, recomendaciones, comentarios y personalización?
- ¿La página se almacena en caché en una CDN y qué variantes de usuario, región o experimento existen?
- Ante el fallo de un módulo lento, ¿debe la interfaz de usuario mostrar un estado vacío, datos obsoletos o reintentar?
- ¿Qué rutas principales deben funcionar si falla el JavaScript del cliente?
Una respuesta en 30 segundos
“Envía un shell que no dependa de datos lentos, luego divide las recomendaciones, los comentarios y la personalización en límites de Suspense con presupuestos explícitos. Cada límite tiene un tiempo de espera en el servidor, errores observables y un fallback aceptable, de modo que un fallo se mantenga local. El cliente asume reintentos acotados y la interacción después de la hidratación. Almacena en caché solo fragmentos públicos seguros y monitorea TTFB, LCP, INP, errores y latencia de límites”.
Análisis detallado paso a paso
Paso 1: Particionar el shell y los límites
Completa el enrutamiento, el título, la estructura del artículo y la semántica principal de forma sincrónica. Coloca las recomendaciones, los comentarios y la personalización en límites separados. Un límite debe representar un área comprensible para el usuario, no una colección arbitraria de dependencias remotas.
shell: navigation + heading + article outline
boundary A: recommendations, budget 300 ms
boundary B: comments, budget 500 ms
boundary C: personalized actions, private and uncachedMantén los encabezados, las dimensiones y la semántica en cada fallback para evitar cambios de diseño (layout shift). No fragmentes la página hasta el punto de que los usuarios no puedan entender qué se está cargando.
Paso 2: Construir el streaming y la cancelación
Utiliza la API de renderizado del lado del servidor por streaming del framework para que el shell entre primero en la respuesta y los límites le sigan a medida que se resuelven los datos. Asigna un plazo límite a la solicitud; tras el tiempo de espera, cancela la llamada remota y emite un fallback aceptable. El cliente no debe esperar por una tarea del servidor que ya ha sido cancelada.
Registra los eventos de inicio, finalización, tiempo de espera y error de cada límite. Cuando el cliente se desconecte, cancela las peticiones no finalizadas para que las páginas abandonadas no consuman capacidad de la base de datos o de recomendaciones.
Paso 3: Manejar errores de servidor y cliente
Un error dentro de un límite del servidor debe resolverse mostrando el fallback de ese límite, preservando al mismo tiempo el shell y los elementos hermanos ya completados. Adjunta un identificador de límite estable y un ID de rastreo de solicitud para los operadores, mientras que el texto de cara al usuario solo indica que la sección no está disponible temporalmente.
Una vez que se cargue el código del cliente, permite reintentos acotados y basados en retroceso exponencial (backoff) para los límites aptos. Los reintentos necesitan un límite de intentos, condiciones de idempotencia y cancelación. Si los scripts del cliente fallan, el texto del artículo, los enlaces y los formularios principales deben seguir siendo utilizables.
Paso 4: Definir los límites de caché
Almacena en caché el contenido público del artículo y los módulos no vinculados a usuarios con claves para ruta, idioma, región y versión del contenido. Los límites personalizados no deben entrar en una caché HTML pública; los experimentos deben ser explícitos en la clave o aislarse en el edge.
Un acierto de caché (cache hit) no debe ocultar datos de origen obsoletos. Registra el tiempo de generación, la caducidad y la versión de cada fragmento, y utiliza una política de frescura coherente. Ten precaución al almacenar en caché el flujo concatenado final; los fragmentos seguros suelen ser un mejor límite.
Paso 5: Preservar la accesibilidad y la estabilidad del diseño
Mantén los mismos encabezados semánticos, puntos de referencia y restricciones de dimensión tanto en el fallback como en el contenido final. El reemplazo no debe mover el foco del teclado a un nodo invisible. Las regiones dinámicas necesitan un anuncio de estado apropiado sin tener que leer repetidamente toda la página.
Reserva las dimensiones de imágenes y medios y mantén estable la geometría del esqueleto (skeleton); monitorea el CLS. Mantén el contenido clave del artículo dentro de un límite visible temprano y no coloques el elemento de LCP detrás de una solicitud de cola larga no controlada.
Paso 6: Agregar controles de lanzamiento y observabilidad
Las pruebas previas al lanzamiento cubren dependencias lentas, respuestas 500, desconexiones, fallos de scripts del cliente, contaminación de caché y cancelación. En producción, mide TTFB, LCP, INP, p50/p95 de límites, tasa de tiempos de espera agotados, tasa de fallbacks y éxito de reintentos por ruta, límite y dependencia.
Durante un despliegue canary, observa el shell y los límites críticos antes de habilitar la personalización de alto riesgo. Si los errores o la latencia de cola cruzan un umbral, revierte la composición de límites o el fallback estático en lugar de ampliar el tráfico.
Un ejemplo de respuesta sólida
Definiría presupuestos de primera pantalla y niveles de disponibilidad, luego dividiría el shell del artículo, las recomendaciones, los comentarios y la personalización en límites de Suspense independientes. Cada límite recibe un tiempo de espera, un fallback, una ruta de cancelación y un ID de rastreo; los fallos se mantienen locales. Los fragmentos públicos utilizan dimensiones de caché seguras, mientras que la personalización nunca entra en una caché compartida. Probaría desconexiones y fallos de script, y monitorearía LCP, INP, CLS, p95 de límites y tasa de fallbacks.
Errores comunes
- Envolver toda la página en un solo límite → la dependencia más lenta bloquea todo → dividir por regiones comprensibles para el usuario.
- No dar dimensiones fijas a un fallback → el reemplazo genera CLS → reservar espacio y preservar la semántica.
- Colocar HTML personalizado en una caché pública → los datos del usuario pueden filtrarse → aislar fragmentos privados e incluir dimensiones de clave seguras.
- Reintentar indefinidamente tras un tiempo de espera del servidor agotado → se amplifica la presión sobre la dependencia → utilizar presupuestos, retroceso exponencial, límites y cancelación.
- Probar solo el caso de éxito → las desconexiones o fallos de scripts inutilizan la página → probar errores, cancelación y degradación sin scripts.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Tener más límites es siempre mejor?
No. Los límites deben asignarse a regiones de usuario y dominios de fallo independientes. Límites excesivamente finos añaden ruido de fallbacks, coste de monitorización y variantes de caché; límites demasiado amplios agrandan el dominio de bloqueo.
Pregunta de seguimiento 2: ¿Cómo evitas que un solo error detenga el stream?
Mantén la recuperación dentro de las rutas de servidor y cliente del límite, preserva el shell ya enviado y proporciona un fallback estable para cada límite. Prueba los fallos después de que parte de la respuesta ya haya sido enviada.
Pregunta de seguimiento 3: ¿Qué métricas demuestran que el diseño funciona?
Haz un seguimiento conjunto de TTFB, LCP, INP, CLS, p95 de límites, tasa de tiempos de espera agotados, tasa de fallbacks y éxito de reintentos. El tiempo de respuesta promedio por sí solo oculta la latencia de cola y los fallos locales.
Pregunta de seguimiento 4: ¿Cómo previenes fugas de caché en datos de experimentos o de usuario?
Incluye dimensiones de seguridad de usuario, experimento, región, idioma y versión de contenido en la clave. Los fragmentos cuya seguridad no se pueda probar quedan fuera de las cachés públicas, y las pruebas de reproducción cruzada entre usuarios verifican el aislamiento.