El renderizado en servidor se gana su sitio cuando importa la velocidad del primer pintado, la visibilidad para los rastreadores o los dispositivos poco potentes, porque el usuario recibe HTML con sentido antes de que se ejecute nada de JavaScript. Una app renderizada en cliente está bien detrás de un login donde los buscadores dan igual y las sesiones son largas. El coste real del renderizado en servidor es la hidratación, una segunda ejecución en el cliente, más un runtime de servidor, caché y obtención de datos de los que ahora eres responsable.
Por qué lo preguntan los entrevistadores
El entrevistador quiere saber si sabes justificar la arquitectura con resultados de usuario en vez de con los valores por defecto de un tutorial de framework. Escuchan la hidratación, porque es la parte que la gente olvida, y el hecho de que el renderizado en servidor añade superficie operativa. Decir que el renderizado en servidor siempre es mejor es una respuesta más débil que nombrar el caso concreto donde una app de cliente sin más es la opción correcta y más barata.
Cómo estructurar tu respuesta
- Nombra los resultados de usuario que mejora el renderizado en servidor.
- Nombra el caso donde el renderizado en cliente es la mejor compensación.
- Explica la hidratación y por qué no es gratis.
- Menciona el renderizado estático o cacheado como término medio.
Ejemplo de respuesta
Se reduce a quién está esperando y a si un rastreador necesita leer la página. Para cualquier cosa de cara al público, páginas de marketing, listados de producto, contenido, el renderizado en servidor es casi obligatorio, porque el usuario ve contenido real en la primera respuesta en vez de una ruedita mientras un bundle se descarga y se analiza en un Android de gama media. Para una herramienta interna o un panel autenticado pesado, me vale una app renderizada en cliente; nadie la está indexando y la sesión dura una hora, así que la carga inicial se amortiza. Lo que quiero que la gente entienda es la hidratación. Renderizar en servidor no significa menos JavaScript por defecto; los mismos componentes suelen ejecutarse otra vez en el cliente para enganchar manejadores, así que puedes entregar HTML rápido y aun así tener una página que ignora los clics durante dos segundos. Por eso importan los Server Components y el streaming, porque recortan cuánto tiene que hidratarse. Donde los datos cambian poco, prefiero renderizar en tiempo de build o cachear el HTML en el edge y saltarme el trabajo de servidor por completo.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Qué causa un desajuste de hidratación y cómo lo depuras?
- ¿Cómo cambia el streaming con Suspense la carga percibida?
- ¿Cuándo elegirías en su lugar generación estática con revalidación?
Más preguntas para Desarrollador full stack
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas