¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Fernando Jiménez 30/01/2025 Cargando comentarios…
En la creación de aplicaciones web modernas, la velocidad, la experiencia del usuario y el SEO son aspectos clave que no podemos ignorar. Para tener en cuenta estos tres aspectos, combinar SSR (Server-Side Rendering) con tecnologías como Vite y React es una excelente estrategia. En este post te guiaré a través de los conceptos y cómo puedes empezar a crear sitios con esta potente combinación.
SSR es una técnica donde el HTML de una aplicación React se genera en el servidor en lugar de hacerlo en el navegador. Esto significa que, cuando una persona solicita una página, el servidor envía el HTML completamente renderizado a su browser, lo que permite una carga inicial más rápida y un mejor SEO, ya que los motores de búsqueda pueden indexar la página más fácilmente.
La diferencia entre SSR Streaming y SSR Non-Streaming (o simplemente SSR tradicional) radica en cómo se maneja la entrega del contenido HTML generado en el servidor al navegador del cliente. Este dato será necesario para comprender cómo funciona SSR y poder decidir qué opción utilizar a la hora de crear nuestro proyecto con Vite. Veamos sus diferencias:
En el SSR Non-Streaming, el proceso funciona de la siguiente manera:
Ventajas:
Desventajas:
En el SSR Streaming, el proceso se maneja de manera diferente:
Ventajas:
Desventajas:
Tiempo de entrega: con SSR Streaming, el contenido se empieza a entregar al cliente tan pronto como está disponible, mientras que en SSR Non-Streaming, todo el contenido se entrega de una vez, lo que puede demorar más en aparecer en la pantalla.
Percepción de velocidad: SSR Streaming puede mejorar la percepción de velocidad de la página, ya que el usuario ve algo en la pantalla antes, incluso si la página completa aún no ha sido cargada. Con SSR Non-Streaming, los usuarios experimentan un retraso hasta que toda la página está lista.
Complejidad: SSR Non-Streaming es más sencillo de implementar y de mantener, mientras que SSR Streaming puede requerir un manejo más cuidadoso del flujo de datos y la renderización en el servidor.
Necesitaremos crear un nuevo proyecto, para ello utilizaremos la línea de comandos y el siguiente comando:
npm create vite@latest paradigma-react-ssr-app
Seleccionaremos las opciones: Others > create-vite-extra > ssr-react > Streaming o Non-Streaming > TypeScript.
Una vez generado nuestro proyecto, tenemos que tener en consideración los siguientes ficheros, ya que son componentes clave en la arquitectura de una aplicación React que utiliza Server-Side Rendering. Cada uno cumple una función específica en el proceso de renderización y entrega de la aplicación al usuario final. A continuación veremos las diferencias de cada uno de ellos para proyectos non-streaming y streaming.
El fichero server.js en aplicaciones SSR, tanto en la variante non-streaming como en la streaming, desempeña un papel crucial en la generación y entrega del HTML al cliente, aunque la forma en que lo hace varía entre los dos enfoques.
En SSR Non-Streaming, el fichero server.js sigue un flujo relativamente simple: el HTML se genera por completo en una sola respuesta y se envía. Adecuado para aplicaciones donde la renderización de la página completa no causa demoras perceptibles.
En SSR con streaming, el fichero server.js maneja la renderización y envío de HTML de manera más avanzada. Generando y enviando el HTML en fragmentos a medida que está disponible, lo que permite al navegador comenzar a renderizar partes de la página antes de que todo el contenido esté listo. Esto mejora la experiencia del usuario en aplicaciones más grandes o complejas.
Su función principal tanto en la variante non-streaming como en la de streaming es "hidratar" la aplicación, es decir, tomar el HTML pre-renderizado por el servidor y convertirlo en una aplicación React completamente interactiva en el navegador del cliente.
La “hidratación” es un proceso fundamental en aplicaciones web que utilizan SSR. Se refiere a la fase en la que el navegador toma el HTML estático pre-renderizado enviado por el servidor y lo "reactiva" para convertirlo en una interfaz de usuario interactiva. Durante la hidratación, React adjunta los event listeners y sincroniza el estado de la aplicación con el contenido del DOM, esencialmente tomando control de la estructura HTML existente.
Este proceso permite que la aplicación web funcione de manera dinámica en el cliente, transformando el contenido generado en el servidor en una experiencia de usuario completa y reactiva. En ambos casos, el objetivo final es garantizar que la aplicación React sea completamente funcional y pueda manejar la interacción del usuario de manera eficiente a partir del HTML generado en el servidor.
Este archivo es responsable de la lógica de renderización en el lado del servidor. Es llamado por el servidor (generalmente a través de server.js) para renderizar la aplicación React a una cadena de HTML, permitiendo que la página esté lista para ser enviada al cliente.
En aplicaciones SSR Non-Streaming, entry-server.tsx genera el HTML completo de una sola vez con la función renderToString, mientras que en SSR con streaming utiliza técnicas como renderToPipeableStream para enviar el HTML en fragmentos, permitiendo una carga progresiva. Además, este archivo puede gestionar la lógica para pre-cargar datos y manejar el estado inicial de la aplicación.
El fichero App.tsx es un componente fundamental en una aplicación React, ya que actúa como el punto de entrada principal para la lógica y el diseño de la aplicación. Este archivo suele contener la estructura principal de la interfaz de usuario y es donde se integran los diferentes componentes y funcionalidades de la aplicación.
En resumen:
Con toda esta información, ahora tienes una comprensión clara de los roles y funciones que desempeñan los ficheros anteriormente mencionados en nuestra aplicación React con SSR.
En un entorno de Server-Side Rendering (SSR) con React y Vite, el proceso de compilación es un poco más complejo que en una aplicación React tradicional. Aquí se requiere generar dos builds diferentes: uno para el cliente (frontend) y otro para el servidor (backend). Estos dos builds trabajan en conjunto para renderizar la aplicación en el servidor y luego enviar el HTML renderizado al cliente.
El build del cliente genera los assets que serán cargados por el navegador. Esto incluye el JavaScript y CSS necesarios para la "hidratación" de la aplicación React en el lado del cliente, es decir, para hacer la aplicación interactiva después de que el HTML inicial ha sido servido por el servidor.
Por defecto en un proyecto de SSR con React y Vite, el comando que ejecutaremos para generar dicho Build será el siguiente:
npm run build:client
o
vite build --ssrManifest --outDir dist/client
El build del servidor produce un bundle optimizado que se ejecutará en el entorno de Node.js. Este código se utiliza para generar el HTML de la aplicación en el servidor, el cual luego es enviado al cliente. Este HTML pre-renderizado es lo que permite que la aplicación sea servida rápidamente, mejorando la performance inicial y la optimización para motores de búsqueda (SEO).
npm run build:server
o
vite build --ssrManifest --outDir dist/client
React Router es una popular librería de enrutamiento para aplicaciones React que permite gestionar la navegación entre diferentes vistas o "páginas" de la aplicación. En el contexto de una aplicación Server-Side Rendering (SSR), React Router se adapta para funcionar tanto en el lado del servidor como en el lado del cliente, lo que permite una navegación fluida y optimizada.
En una aplicación SSR, la lógica de enrutamiento se debe manejar tanto en el cliente como en el servidor. Esto implica que React Router se configura para trabajar en ambos entornos:
Renderización en el servidor: cuando llega una solicitud al servidor, React Router analiza la URL solicitada y determina qué componentes React deben renderizarse en HTML. Este HTML pre-renderizado se envía al cliente.
“Hidratación” en el cliente: una vez que el HTML llega al cliente, React Router toma el control de la navegación. Esto permite que la navegación entre diferentes rutas ocurra sin recargar la página, manteniendo la experiencia de una aplicación de una sola página (SPA).
A continuación mostraremos un esquema básico de cómo configurar React Router en una aplicación SSR Non-streaming.
Instalación de dependencias
En tu proyecto, ejecuta el siguiente comando para instalar las dependencias necesarias de React Router:
npm install react-router-dom react-router-dom@6 react-router-dom@6 react-router@6
Configuración básica del proyecto
Una vez que hayas instalado las dependencias, puedes configurar React Router en tu aplicación. Como se mencionó antes, usarás BrowserRouter en el cliente y StaticRouter en el servidor. Antes de utilizar estos elementos de React Router, vamos a definir el fichero que configura las rutas dentro de nuestra aplicación:
// router/index.tsx
import { Routes, Route } from 'react-router-dom';
import { Contact, Home } from '../views';
export const Router = () => {
return (
<Routes>
<Route path="/" element={<Home />} />
<Route path="/contact" element={<Contact />} />
</Routes>
);
};
Como podemos ver en el ejemplo anterior, estamos definiendo dos rutas: la principal (/) y la ruta de contacto (/contact). Cada una de ellas hace referencia a una vista definida dentro de nuestro proyecto.
// views/Home.tsx
import {Link} from "react-router-dom";
export const Home = (): JSX.Element => {
return (
<>
<nav>
<Link to="/">Home</Link>
<Link to="/contact">Contact</Link>
</nav>
<main>
<h6>Home</h6>
...
</main>
</>
);
};
// views/Contact.tsx
import {Link} from "react-router-dom";
export const Contact = (): JSX.Element => {
return (
<>
<nav>
<Link to="/">Home</Link>
<Link to="/contact">Contact</Link>
</nav>
<main>
<h6>Contact</h6>
...
</main>
</>
);
};
Con las rutas definidas y las vistas para cada ruta creadas, solo nos falta configurarlas dentro de nuestra aplicación SSR. Para ello, deberás integrarlo en el punto de entrada tanto del cliente como del servidor, añadiendo la siguiente configuración:
Cliente (entry-client.tsx)
import React from 'react'
import ReactDOM from 'react-dom/client'
import { BrowserRouter } from 'react-router-dom'
import { Router } from './router'
ReactDOM.hydrateRoot(
document.getElementById('root') as HTMLElement,
<React.StrictMode>
<BrowserRouter>
<Router />
</BrowserRouter>
</React.StrictMode>
)
Servidor (entry-server.tsx)
import React from 'react'
import ReactDOMServer from 'react-dom/server'
import { StaticRouter } from 'react-router-dom/server';
import { Router } from './router'
interface IRenderProps {
path: string;
}
export function render({path}: IRenderProps) {
const html = ReactDOMServer.renderToString(
<React.StrictMode>
<StaticRouter location={path}>
<Router />
</StaticRouter>
</React.StrictMode>
)
return { html }
}
Con estas dependencias y configuraciones, tu aplicación SSR con React Router estará lista para manejar la navegación de manera eficiente en ambos entornos: cliente y servidor. Esto te permitirá aprovechar las ventajas del SSR, como un mejor SEO y tiempos de carga iniciales más rápidos, mientras mantienes una experiencia de usuario fluida con navegación entre rutas.
El uso de Server-Side Rendering (SSR) con React, Vite y React Router mejora significativamente la experiencia del usuario al ofrecer tiempos de carga iniciales rápidos y una navegación fluida. React facilita la construcción de interfaces dinámicas, Vite acelera el desarrollo y optimización de la aplicación, y React Router gestiona las rutas de manera efectiva tanto en el cliente como en el servidor.
Juntas, estas tecnologías crean una solución eficiente y escalable que mejora el rendimiento y la indexación en motores de búsqueda, proporcionando una experiencia de usuario superior y una base sólida para aplicaciones web modernas.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.