{"componentChunkName":"component---src-templates-blog-post-blog-post-js","path":"/metodos-de-renderizado/","result":{"data":{"site":{"siteMetadata":{"title":"girgetto.it","siteUrl":"https://girgetto.it","author":{"name":"Girgetto"}}},"markdownRemark":{"id":"59e596a5-eb08-5936-9cf4-6018d73d3d8d","excerpt":"Los frameworks modernos de frontend ofrecen varias estrategias para entregar contenido al navegador. Elegir la correcta puede afectar drásticamente el…","html":"

Los frameworks modernos de frontend ofrecen varias estrategias para entregar contenido al navegador. Elegir la correcta puede afectar drásticamente el rendimiento, el SEO y la experiencia del usuario. Este artículo cubre los cuatro métodos de renderizado más importantes — CSR, SSR, SSG e Hidratación — con un diagrama para cada uno.

\n
\n

Client-Side Rendering (CSR)

\n

En CSR el navegador descarga una carcasa HTML mínima y un bundle de JavaScript. El JS se ejecuta en el navegador, obtiene los datos y construye la página completa en el cliente.

\n

Frameworks: React (CRA / Vite SPA), Vue (Vite SPA), Angular

\n
\nsequenceDiagram\n participant B as 🌐 Navegador\n participant S as 🖥️ Servidor\n\n B->>S: GET /index.html\n S-->>B: HTML vacío ⟨div id=\"root\"⟩⟨/div⟩\n B->>S: GET /bundle.js\n S-->>B: bundle.js (~500 KB)\n Note over B: El JS se ejecuta — construye el DOM\n B->>S: fetch('/api/datos')\n S-->>B: Datos JSON\n Note over B: UI completamente renderizada ✅\n
\n

Cómo funciona el CSR paso a paso

\n
    \n
  1. El navegador solicita la página → el servidor devuelve un archivo HTML casi vacío
    2. \n
  2. El navegador descarga el bundle de JavaScript
    3. \n
  3. El JS se ejecuta en el navegador y construye el DOM
    4. \n
  4. Se obtienen datos de las APIs y se renderiza la interfaz
    5. \n
\n
\n

⚠️ La página está completamente en blanco hasta que el bundle de JS se ha descargado y ejecutado. Esto perjudica tanto el rendimiento percibido como los crawlers de SEO que no ejecutan JS.

\n
\n

Ventajas y desventajas

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
✅ Ventajas❌ Desventajas
Interacciones ricas, tipo aplicaciónCarga inicial lenta (pantalla en blanco)
Baja carga en el servidorSEO deficiente por defecto
Despliegue sencillo (hosting estático)Bundles de JS grandes
Navegación rápida tras la primera cargaRequiere JS habilitado
\n
\n

Ideal para: Dashboards, paneles de administración, apps detrás de un login, herramientas en tiempo real.

\n
\n
\n

Server-Side Rendering (SSR)

\n

Con SSR el servidor genera el HTML completo en cada solicitud. El navegador recibe una página completa y legible de inmediato. Después el JavaScript se ejecuta para hacer la página interactiva.

\n

Frameworks: Next.js (getServerSideProps), Nuxt.js, SvelteKit, Remix

\n
\nsequenceDiagram\n participant B as 🌐 Navegador\n participant S as 🖥️ Servidor\n participant D as 🗄️ Base de datos / API\n\n B->>S: GET /pagina\n S->>D: Consulta de datos\n D-->>S: Respuesta con datos\n Note over S: Renderiza el HTML completo en el servidor\n S-->>B: Página HTML completa ✅\n Note over B: Contenido visible de inmediato (FCP rápido)\n B->>S: GET /bundle.js\n S-->>B: Bundle JS\n Note over B: Hidratación — la página se vuelve interactiva ✅\n
\n

Cómo funciona el SSR paso a paso

\n
    \n
  1. El navegador envía una solicitud para una página
    2. \n
  2. El servidor obtiene datos de la base de datos o API
    3. \n
  3. El servidor renderiza el HTML completo y lo envía al navegador
    4. \n
  4. El navegador muestra el HTML de inmediato (First Contentful Paint rápido)
    5. \n
  5. El navegador descarga el JS e hidrata la página para agregar interactividad
    6. \n
\n
\n

⚠️ Todo este ciclo se ejecuta en cada solicitud. El servidor debe estar disponible, ser rápido y escalar horizontalmente.

\n
\n

Ventajas y desventajas

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
✅ Ventajas❌ Desventajas
Excelente SEOMayor carga en el servidor por solicitud
Pintura inicial rápida (contenido visible)Infraestructura más compleja
Datos dinámicos y siempre frescosRetrasos de arranque en frío (serverless)
Funciona sin JSMás lento que servir archivos estáticos
\n
\n

Ideal para: Páginas de productos en e-commerce, artículos de noticias, páginas que necesitan datos frescos en cada visita.

\n
\n
\n

Static Site Generation (SSG)

\n

SSG pre-renderiza todas las páginas en tiempo de compilación. El resultado es un conjunto de archivos HTML estáticos desplegados en una CDN. No se necesita servidor en tiempo de solicitud.

\n

Frameworks: Next.js (getStaticProps), Gatsby, Astro, Hugo, Eleventy

\n
\nflowchart TD\n subgraph Build[\"🔨 Tiempo de Compilación — se ejecuta una vez\"]\n C[\"📁 Contenido\\nMD / JSON / CMS\"] --> BT[\"⚙️ Herramienta de Build\\nNext.js / Gatsby\"]\n BT --> H[\"📄 Archivos HTML Estáticos\"]\n H --> D[\"🚀 Despliegue a CDN\\nVercel / Netlify / S3\"]\n end\n\n subgraph Runtime[\"🌍 Tiempo de Solicitud — instantáneo\"]\n Browser[\"🌐 Navegador\"] -->|\"GET /pagina\"| Edge[\"☁️ Nodo CDN Edge\\ncaché global\"]\n Edge -->|\"HTML pre-construido ⚡\"| Browser\n end\n\n D --> Edge\n
\n

Cómo funciona el SSG paso a paso

\n
    \n
  1. En tiempo de compilación, el framework obtiene todos los datos y renderiza cada página a HTML
    2. \n
  2. Los archivos HTML se suben a una CDN
    3. \n
  3. En tiempo de solicitud, el navegador obtiene el HTML pre-construido del nodo CDN más cercano — sin ejecución en el servidor
    4. \n
\n
\n

⚠️ Los datos pueden quedar desactualizados entre compilaciones. Se requiere un nuevo despliegue para cambios de contenido, a menos que se use ISR (Incremental Static Regeneration).

\n
\n

Ventajas y desventajas

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
✅ Ventajas❌ Desventajas
Extremadamente rápido (archivos desde CDN)Los datos pueden quedar desactualizados
Excelente SEOSe requiere recompilar para cambios de contenido
Altamente escalable (sin servidor)Tiempos de build largos en sitios grandes
Muy seguroNo apto para páginas personalizadas por usuario
\n
\n

Ideal para: Blogs, sitios de documentación, páginas de marketing, portfolios.

\n
\n
\n

Hidratación

\n

La hidratación es el proceso que hace interactiva una página renderizada en el servidor o generada estáticamente. El navegador recibe el HTML completo (pintura rápida), luego se carga el JS y se \"conecta\" al DOM existente — adjuntando event listeners y estado sin volver a renderizar.

\n
\nflowchart TD\n A[\"① HTML del Servidor\\n📄 HTML completo enviado\\nVisible ✅\\nNo Interactivo ❌\"]\n B[\"② Bundle JS Cargando\\n⬇️ Descargando...\\nVisible ✅\\nNo Interactivo ❌\"]\n C[\"③ Hidratando\\n💧 Adjuntando eventos\\nVisible ✅\\nParcial ⚠️\"]\n D[\"④ Interactivo\\n✅ El framework controla el DOM\\nVisible ✅\\nInteractivo ✅\"]\n\n A -->|El navegador recibe| B\n B -->|JS se ejecuta| C\n C -->|Completo| D\n\n style A fill:#f1f5f9,stroke:#94a3b8,color:#334155\n style B fill:#dbeafe,stroke:#3b82f6,color:#1e40af\n style C fill:#fef9c3,stroke:#eab308,color:#713f12\n style D fill:#dcfce7,stroke:#22c55e,color:#166534\n
\n

El problema de la Hidratación

\n

La hidratación introduce el concepto de Time To Interactive (TTI): la página parece lista pero no es clicable hasta que el JS termina de hidratarse. En redes lentas o bundles de JS grandes, esta brecha frustra a los usuarios.

\n\n FCP ─────────────────────────────────► TTI\n(página visible) (página usable)\n │◄─── JS descarga + hidrata ────►│\n \n

Soluciones modernas

\n\n
\n

Comparación de todos los métodos

\n
\nquadrantChart\n title Velocidad vs SEO — Dónde se sitúa cada método\n x-axis \"Carga inicial lenta\" --> \"Carga inicial rápida\"\n y-axis \"SEO deficiente\" --> \"SEO excelente\"\n quadrant-1 Ideal\n quadrant-2 Bueno para contenido\n quadrant-3 Uso limitado\n quadrant-4 Orientado a apps\n CSR: [0.40, 0.15]\n SSR: [0.58, 0.88]\n SSG: [0.92, 0.92]\n Hybrid SSR+SSG: [0.75, 0.88]\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CSRSSRSSGHíbrido (SSR+SSG)
Velocidad de carga inicial🔴 Lenta🟡 Media🟢 Rápida🟢 Rápida
SEO🔴 Deficiente🟢 Excelente🟢 Excelente🟢 Excelente
Frescura de datos🟢 Tiempo real🟢 Por solicitud🔴 Tiempo de build🟡 Configurable
Coste de servidor🟢 Bajo🔴 Alto🟢 Ninguno🟡 Medio
Escalabilidad🟡 Media🔴 Más difícil🟢 Excelente🟢 Buena
Interactividad🟢 Rica🟡 Tras hidratación🟡 Tras hidratación🟡 Tras hidratación
Complejidad🟢 Simple🟡 Media🟢 Simple🔴 Compleja
\n
\n

Cuándo usar cada método

\n

Usa CSR cuando:

\n\n

Usa SSR cuando:

\n\n

Usa SSG cuando:

\n\n

Usa Híbrido (SSG + SSR + ISR) cuando:

\n\n
\n
\n

El consenso moderno: La mayoría de las apps en producción se benefician de un enfoque híbrido. Frameworks como Next.js, Nuxt.js y SvelteKit permiten elegir la estrategia de renderizado por página, de forma que puedes generar estáticamente tus páginas de marketing mientras renderizas en servidor tus listados de productos y en cliente tu dashboard.

\n
","fields":{"slug":"/metodos-de-renderizado/"},"wordCount":{"words":931},"frontmatter":{"title":"Métodos de Renderizado: CSR, SSR, SSG e Hidratación","isoDate":"2026-03-19","isoUpdated":null,"description":"Un análisis profundo de las principales estrategias de renderizado en frontend — Client-Side Rendering, Server-Side Rendering, Static Site Generation e Hidratación — con diagramas para cada una.","lang":"es","img":"https://i.postimg.cc/T3kBzrqr/rendering-methods.webp"},"tableOfContents":""},"translations":{"nodes":[{"fields":{"slug":"/en/rendering-methods/"},"frontmatter":{"lang":"en"}}]},"previous":{"fields":{"slug":"/password-seguridad/"},"frontmatter":{"title":"Seguridad de Contraseñas - Cómo se hackean y cómo protegerte"}},"next":{"fields":{"slug":"/es6-javascript/"},"frontmatter":{"title":"Guía esencial de ES6: Las features que transformaron JavaScript"}}},"pageContext":{"id":"59e596a5-eb08-5936-9cf4-6018d73d3d8d","previousPostId":"2f83cf33-e6f1-54bc-94d5-753ee0723f8a","nextPostId":"e65a2fd1-5a4e-520c-81aa-1d1c693a4c8d","baseSlug":"/rendering-methods/","locale":"es"}},"staticQueryHashes":["4035521183"],"slicesMap":{}}