La era de Single Page Applications (SPAs) ha madurado
A principios de 2014, el ecosistema web experimentó una transformación gigantesca hacia el Client-Side Rendering (CSR). El navegador se encargaba de compilar y descargar megabytes completos de bibliotecas de Javascript de golpe en la primera visita (el empaquetado del webpack), dejando los servidores como simples tuberías de objetos JSON. Las "Páginas Únicas" (SPAs) eran maravillas tecnológicas por la fluidez tras la carga.
Llega la era del Server-Side y componentes
A pesar del salto, la primera barrera temporal era alta y el SEO de estos proyectos se veía siempre fuertemente dañado. Para mitigar, tecnologías meta framework como Next.js implementaron SSR o SSG, pero seguía siendo engorroso porque requería en general procesos repetitivos de hidratación (reconstruir el JS interactivo). Con la llegada de los React Server Components, el paradigma se parte en dos mitades limpias: componentes mudos estáticos procesados nativamente desde la máquina del servidor, y el puñado exclusivo de componentes con estados dinámicos bajados por la red al navegador del usuario final.
Resultados Impactantes
¿El resultado? Tu código envía "literalmente 0 Kilobytes de JavaScript" embebido para ese componente estático como un render de cabecera visual o barras laterales que nunca requerían interacción de clic real. Esta micro segmentación causa un milagro de optimización en cascada, disparando todos los KPIs en Lighthouse Scorecards (incluyendo grandes respiros para las métricas LCP de Core Web Vitals imprescindibles para SEO).
Ejecución y Manos a la Obra
La migración hacia Server Components pide repensar visualmente la composición (Componer sobre todo). Pasamos de un estado mental de "todo es del lado de mi máquina" a pensar en el "árbol de peticiones". Si un cliente domina la asincronía en React.JS con componentes servidor y sus directrices `use client`, el código que antes requería 5 bibliotecas redundantes ahora se solventa con un solo `fetch()` directo a la Base de Datos.