Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
El renderizado en servidor construye el HTML de una página en el servidor, para cada petición, y lo envía al navegador ya completo. El usuario ve contenido real en cuanto llega, antes de que se ejecute nada de JavaScript. Luego la página se hidrata: el JavaScript se acopla y el marcado estático se convierte en una aplicación viva e interactiva.
Es la contraparte del renderizado en cliente, donde el navegador recibe una cáscara casi vacía y lo ensambla todo él mismo. El SSR gana en dos frentes que importan: el primer pintado significativo es más rápido, y los buscadores y las vistas previas de enlaces ven contenido completo en lugar de una página en blanco. El coste es trabajo de servidor en cada petición y el paso de hidratación, que puede sentirse lento si una página envía demasiado JavaScript. El SSR también se distingue de la generación estática, donde las páginas se construyen una vez por adelantado. El SSR reconstruye por petición, que es lo que quieres para contenido que cambia por usuario o por minuto. Un panel con sesión iniciada que te saluda por tu nombre y muestra tus últimos pedidos se renderiza en el servidor para que los datos sean correctos en el instante en que carga la página.
Frameworks como Next.js, Nuxt y Remix convirtieron el SSR en algo habitual al permitir que un único código renderice en el servidor y funcione en el navegador sin un backend aparte para las vistas.
La mayor parte del trabajo web que entregamos se apoya en decisiones de renderizado tomadas de forma deliberada, ruta a ruta. Una página de marketing que tiene que posicionar se renderiza en servidor o se genera de forma estática. Una herramienta interna muy interactiva puede renderizarse en el cliente, donde el SEO es irrelevante. Decidimos según para qué sirve la página, no según un valor por defecto del framework que alguien dejó puesto. Ese criterio es el núcleo de cómo abordamos el desarrollo web.
La hidratación es donde los proyectos de SSR fallan en silencio, así que la vigilamos de cerca. Desajustes entre la salida del servidor y la del cliente, bundles enormes que retrasan la interactividad, cambios de diseño que perjudican los Core Web Vitals. Nuestro QA de rendimiento y SEO se ejecuta sobre la salida renderizada, no sobre la máquina local de un desarrollador, porque eso es lo que reciben los usuarios y los rastreadores reales.
¿Necesitas páginas que carguen rápido y posicionen? Elijamos la estrategia de renderizado adecuada para cada una.
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Convertir una marca en un negocio que funciona.
Medio millón de personas. Una app. Cero caos.















