Renderizado del lado del cliente (CSR): definición

¿Qué es el renderizado del lado del cliente (CSR)?

El renderizado del lado del cliente (CSR) significa que el navegador construye el HTML de la página con JavaScript en lugar de recibirlo terminado desde el servidor. El servidor envía un pequeño HTML base y un paquete de JavaScript; el script obtiene datos, normalmente de una API, y crea el contenido en el DOM. MDN lo define como lo opuesto al renderizado del lado del servidor y señala que ambos pueden combinarse en una misma aplicación.

Cómo funciona el renderizado del lado del cliente

1. El navegador solicita una URL y recibe un documento HTML mínimo, a menudo solo un contenedor vacío y etiquetas script.
2. Descarga, analiza y ejecuta el paquete de JavaScript.
3. La app pide sus datos a una API.
4. La app construye el DOM y el usuario ve el contenido.
5. La navegación posterior se queda en el navegador: la app cambia de vista y solo pide datos, no páginas completas. Así funciona una aplicación de una sola página (SPA).

Ejemplo

Un panel hecho con React carga un archivo HTML de unos cientos de bytes. El visitante ve una página en blanco o un indicador de carga hasta que se descarga el paquete, responde la API y se dibujan los gráficos. Después, cambiar de pestaña es instantáneo, porque solo viaja JSON por la red.

Ventajas

• Navegación rápida dentro de la app. Tras la primera carga, las vistas cambian sin recargar la página.
• Gran interactividad. Paneles, editores y herramientas encajan en una app que vive en el navegador.
• Alojamiento sencillo. La base y el paquete son archivos estáticos que cualquier CDN sirve; solo la API necesita servidores.

Inconvenientes

• Primer contenido más lento. No aparece nada útil hasta que se ejecuta JavaScript. web.dev señala que la cantidad de JavaScript tiende a crecer con la app, lo que puede perjudicar el INP, y que el CSR es difícil de mantener rápido en móviles.
• El SEO exige cuidado. Google procesa las páginas con JavaScript en tres fases: rastreo, renderizado e indexación. Las páginas esperan en una cola de renderizado, "unos segundos, pero puede tardar más" (en palabras de Google Search Central). Google añade que el renderizado en servidor o el prerenderizado siguen siendo buena idea, porque no todos los bots ejecutan JavaScript.
• Depende del dispositivo. Analizar y ejecutar un paquete grande lleva más tiempo en un móvil lento que en el portátil de un desarrollador.

Errores habituales

• Enviar un único paquete enorme. Divide el código por ruta y carga bajo demanda lo que la primera pantalla no necesita.
• Pedir datos en cascada. Un componente que espera a que cargue su padre antes de pedir sus datos añade un viaje completo por nivel.
• Poner noindex en el HTML base y quitarlo con JavaScript. Google puede saltarse el renderizado al ver noindex, así que esa eliminación quizá nunca se ejecute.
• Probar solo en equipos rápidos. Comprueba con CPU y red limitadas, o en móviles de gama media reales.
• No dar HTML con contenido a las páginas clave. Las páginas de marketing y contenido suelen funcionar mejor con generación estática o renderizado en servidor, y la app renderizada en cliente detrás del inicio de sesión.

CSR, SSR y SSG comparados

La elección es cuándo se produce el HTML. El renderizado puede ocurrir en el navegador (CSR), en el servidor en cada petición (SSR) o en la compilación (SSG). Frameworks como Next.js los mezclan por página, y la hidratación hace después interactivo el HTML generado en servidor. Una página pública que debe aparecer en buscadores encaja mal con un CSR puro; una herramienta con sesión suele encajar bien.

Cómo probar y monitorizar una app CSR

Importan tanto los datos de laboratorio como los de campo, porque el trabajo lo hace el navegador. La monitorización de velocidad de página de LoadFocus ejecuta auditorías Lighthouse y comprobaciones de Core Web Vitals programadas desde 25 regiones en la nube y avisa cuando una página se ralentiza; el verificador de Core Web Vitals da una medición puntual, y la guía sobre monitorizar Core Web Vitals con alertas e informes explica la configuración. La API que hay detrás es otro asunto: una prueba de carga con JMeter o k6 ejercita sus endpoints, no el renderizado del navegador.

Preguntas frecuentes: renderizado del lado del cliente

¿Cuál es la diferencia entre CSR y SSR?

Con CSR el navegador construye el HTML con JavaScript. Con SSR el servidor envía un HTML ya construido para esa petición. SSR suele mostrar contenido antes; CSR hace más rápida la navegación posterior dentro de la app.

¿El renderizado del lado del cliente es malo para el SEO?

No necesariamente. Google puede renderizar JavaScript, pero las páginas esperan en una cola de renderizado y no todos los bots ejecutan scripts. Para páginas que deben posicionar, el renderizado en servidor o el prerenderizado es más seguro.

¿Qué frameworks usan renderizado del lado del cliente?

React, Angular y Vue crean por defecto aplicaciones de una sola página que se renderizan en el navegador. Metaframeworks como Next.js y Nuxt añaden renderizado en servidor y generación estática.

¿El CSR perjudica los Core Web Vitals?

Puede. Un paquete grande retrasa el contenido principal y ocupa el hilo principal, lo que afecta a la carga y al INP. La división de código, la carga diferida y un paquete más pequeño reducen el riesgo.

¿Cuándo elegir renderizado del lado del cliente?

Para herramientas con sesión, paneles y apps muy interactivas donde las propias pantallas no necesitan visibilidad en buscadores. Para páginas de contenido público, valora el renderizado en servidor o la generación estática.