Lección 02: Arquitectura de Renderizado
MOD 01- CSR (Client-Side Rendering): Delega la carga al navegador del usuario. Peligroso para el SEO si no se gestiona bien.
- SSR (Server-Side Rendering): El servidor entrega el HTML listo. Ideal para SEO, pero más costoso en infraestructura.
- Hidratación: El proceso de convertir HTML estático en una aplicación React interactiva.
- La elección de la arquitectura (Next.js, Nuxt) define tu techo de visibilidad orgánica.
El error más común en el desarrollo moderno es asumir que "si funciona en mi navegador, Google lo ve". Frameworks como React, Vue o Angular, por defecto, ejecutan todo el contenido en el cliente (tu navegador). Para un motor de búsqueda, esto a menudo se traduce en una página en blanco.
En esta lección de renderizado SEO, desglosaremos las tres arquitecturas principales y cómo afectan la capacidad de indexación de tu proyecto. No se trata solo de código; se trata de quién hace el trabajo pesado: ¿tu servidor o el dispositivo del usuario?
CSR vs SSR: El Dilema
Velocidad de Carga vs InteractividadEn Client-Side Rendering (CSR), el navegador recibe un HTML vacío y debe descargar y ejecutar todo el JS para pintar la web. Googlebot puede no esperar. En Server-Side Rendering (SSR), el servidor pre-renderiza el HTML, entregando contenido visible al instante.
- CSR: Bajo coste servidor, alto riesgo SEO.
- SSR: SEO perfecto, mayor carga servidor.
- TTFB: Crítico en SSR.
- FCP: Lento en CSR (Pantalla blanca).
CSR vs SSR: El Dilema del Ingeniero
La web tradicional enviaba HTML completo desde el servidor. Con la llegada de las Single Page Applications (SPA), movimos esa lógica al cliente. Esto mejoró la experiencia de usuario (transiciones suaves), pero rompió la visibilidad para los crawlers que no ejecutan JavaScript eficientemente.
Si usas CSR puro (ej: `create-react-app` estándar), tu código fuente se ve así: <div id="root"></div>. Eso es todo lo que ve Google en la primera pasada. Si el presupuesto de rastreo es bajo, Google no volverá para ejecutar el JS, y tu contenido nunca existirá en el índice.
Renderizado Dinámico e Hidratación
La solución moderna (utilizada por Next.js o Nuxt) es un híbrido. El servidor envía un HTML pre-renderizado (como en los viejos tiempos) para que Google y el usuario vean el contenido de inmediato. Luego, en segundo plano, React "hidrata" ese HTML, inyectando los listeners de eventos para hacerlo interactivo.
El Proceso de Hidratación
De Estático a InteractivoLa hidratación es la técnica donde el JavaScript del cliente "toma el control" del HTML estático generado por el servidor. Para el SEO, obtenemos lo mejor de los dos mundos: contenido indexable instantáneo y una experiencia de usuario fluida tras la carga inicial.
- HTML visible sin JS activado.
- Time to Interactive (TTI) optimizado.
- Google indexa el contenido inicial.
- Evita el "Layout Shift" masivo.
SSG: Static Site Generation
Para sitios que no cambian cada segundo (como este blog o una landing page), la mejor opción de ingeniería es SSG. Generamos todo el HTML en "tiempo de compilación" (Build Time). El servidor solo sirve archivos estáticos, lo que resulta en un TTFB (Time to First Byte) casi nulo y una seguridad inquebrantable. Es la arquitectura favorita de m8d para alto rendimiento.
Documentación Oficial
Fuentes técnicas para profundizar en renderizado.