Me hubiera gustado haber visto esta explicación hace mucho tiempo. En su momento me costó mucho trabajo comprender el SSR, es muy complicado de encontrar alguien que lo entienda y pueda explicarlo de una manera tan sencilla.
Entendiendo el rendimiento
Optimización Avanzada de Páginas Web con Técnicas Prácticas
Optimización de Sitios Web para Mejorar Conversión y Experiencia Usuario
Optimización del Rendimiento Web: Modelo RAIL de Google
Antes de optimizar...
Medición del Rendimiento Web con Chrome DevTools y Lighthouse
Métricas de Experiencia de Usuario: LCP, FID y CLS
Instalación y Configuración de Proyecto Web con Git y Webpack
Crítical Rendering Path
Entendiendo el Critical Rendering Path en Navegadores Web
Optimización de JavaScript para mejorar rendimiento web
Priorización de recursos CSS para mejorar rendimiento web
Optimización de Carga de Recursos con Preload, Prefetch y Preconnect
Optimización de Animaciones CSS para Mejorar el Renderizado
CSS
Optimización de Animaciones CSS para Mejorar Rendimiento
Optimización de CSS: Reducir Complejidad y Mejorar Rendimiento
WebFonts
Optimización de WebFonts para Mejorar el Rendimiento Web
Imágenes, Iconos y SVG
Optimización de Imágenes para Web: Formatos y Herramientas Efectivas
Optimización de Imágenes para Web: Uso de Tamaños y Formatos Adecuados
Comparación entre WebFonts y SVG: Ventajas y Desventajas
Lazy Loading de Imágenes: Técnicas y Estrategias Efectivas
Carga Adaptativa de Imágenes con Gatsby y Web API
Aplicaciones JavaScript
Optimización de JavaScript para Producción Web
Análisis y Optimización de Bundles con Webpack
Optimización de Bundles en Proyectos Web con Webpack
Code Splitting con Webpack: Optimización de Bundles en Proyectos Web
Lazy Loading de Videos con JavaScript y Modales
Event Propagation y Filtrado de Eventos en JavaScript
Integración de Librerías en Proyectos JavaScript
Optimización de Carga de Modales con Lazy Loading en Webpack
Renderizado en Cliente vs. Servidor: Diferencias y Funciones
Implementación de Server Side Rendering en NodeJS
Optimización de Sitios con Static Site Generation
Caché
Funcionamiento de Caché y Redes de Distribución de Contenido (CDN)
Configuración y despliegue de sitios web con Netlify y Github Actions
Automatización de despliegues con Github Actions y Cron en Netlify
Implementación de Caché con Service Workers en JavaScript
Performance Budget
Auditoría de Performance Web con Github Actions y Lighthouse
Creación de Pull Request y Auditorías con Github Actions
Monitoreo de Métricas en Sitios Web en Producción
Conclusiones
Optimización del Critical Render Path en Aplicaciones Web
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Renderizado en Cliente vs. Servidor: Diferencias y Funciones
28/38Recursos
¿Qué es el Cliente Side Rendering (CSR)?
El Cliente Site Rendering (CSR) es una técnica de renderizado web que se realiza en el navegador del usuario. Cuando una aplicación web utiliza CSR, todo el procesamiento para generar el contenido visible en la página ocurre directamente en el dispositivo del usuario. Esto implica que:
- El navegador descarga un archivo HTML base que al leerlo desencadena una serie de peticiones.
- A través de estas peticiones se descargan archivos adicionales como JavaScript, CSS e imágenes.
- El archivo JavaScript principal, una vez descargado y ejecutado, se ocupa de solicitar información a las APIs y convierte esos datos en HTML.
- Todo este proceso de renderización se ejecuta completamente en el browser.
Aunque este método es efectivo, tiene ciertas limitaciones, como el tiempo de espera hasta que todo el JavaScript esté ejecutado, lo que puede afectar la accesibilidad y el SEO.
¿Cómo se compara con Server Side Rendering (SSR)?
El Server Site Rendering (SSR) es otra técnica que aborda algunas de las limitaciones del CSR al trasladar el proceso de renderizado al servidor. A continuación, se describen las principales diferencias y el flujo de funcionamiento del SSR:
- El navegador cliente envía una solicitud HTTP al servidor.
- El servidor, antes de devolver el HTML al navegador, ejecuta el JavaScript.
- Este JavaScript se conecta a las APIs necesarias para obtener información y luego renderiza el HTML directamente en el servidor.
- El HTML pre-renderizado se incluye en la respuesta al navegador, lo cual acelera la visualización del contenido.
- Aunque también se envía un archivo JavaScript, su rol principal es añadir interactividad, como la ejecución de modals o animaciones.
Este método ofrece una carga inicial más rápida y es más amigable con SEO, ya que el contenido está más pronto disponible para los motores de búsqueda. Además, reduce la carga en los dispositivos del cliente, ya que el procesamiento se lleva a cabo en el servidor.
¿Cuál es el mejor enfoque para tu proyecto?
Elegir entre CSR y SSR depende de varios factores relacionados con tu proyecto específico:
-
Tipo de Contenido: Si necesitas que los motores de búsqueda indexen rápidamente tu contenido, SSR es probablemente la mejor opción. Además, SSR es efectivo para aplicaciones que requieren rápido tiempo de carga inicial.
-
Arquitectura del Proyecto: Si tu aplicación es simple y no requiere mucho procesamiento inicial, CSR puede ser suficiente. Además, es útil para aplicaciones que son altamente interactivas y donde el estado de la UI cambia con frecuencia.
-
Infraestructura del Servidor: Implementar SSR requiere más recursos de servidor, ya que este asume gran parte del procesamiento que antes hacía el cliente. Asegúrate de tener la capacidad para manejar este requerimiento adicional.
Ambos métodos tienen sus ventajas y desventajas, y pueden incluso combinarse según cada vista o componente dentro del mismo proyecto para maximizar la eficiencia y el rendimiento. Siempre es recomendable evaluar tus necesidades específicas y considerar realizar pruebas de rendimiento antes de decidir la mejor solución para tu aplicación web.
Aportes 6
Preguntas 0
Ordenar por:
🚚 Moviendo la carga de rendering hacia el servidor: Server Side Rendering
<h4>Ideas/conceptos claves</h4>Client Side Rendering es que toda la carga suceda en el navegador y en el cliente
<h4>Apuntes</h4>- Client-Side Rendering tiene la característica que
- No se mostrará nada hasta que el navegador haya descargado y ejecutado el JS
Client Side Rendering
- Tenemos un navegador y un servidor
- Cada vez que entramos a un sitio web el servidor responde un archivo JS
- La página comienza a renderizar HTML a partir del JS recibido
- Todo nuestro contenido principal sucede dentro del cliente [Navegador o Browser]
Server Side Rendering
- Nuestra página se conecta al servidor, pero este le envía un HTML ya renderizado, es decir que se salta el proceso de esperar el JS para mostrar el contenido
- El JS seguirá siendo usado, pero lo separaremos para la interactividad
RESUMEN: Server Side Rendering es una estrategia de enviar “ya comido” nuestra aplicación a nivel HTML es decir que no sera necesario esperar el JS para mostrar contenido
Si ahora el render se hace del lado de server.
No se generan unos problemas porque ya no se sabe el tamaño de la pantalla del cliente, supongo que una vez que llega al cliente debe aplicar otro render? para que se ajuste al browser del cliente?
Es muy interesante este tema, y muy buena observación por parte de Omar Alvarez, lo cual me surge una duda, es muy costoso el proceso para el servidor (tomando como ejemplo el proyecto) ?
Para considerar cuando uno renta servidores como los de amazon que te cobran por procesamiento… aumentaría un poco claro y dependiendo de cada plataforma pero aterrizandolo en este proyecto que es una llamada a la api (Mucho, poco, algo considerable, practicamente nada) … Muchas gracias 😄
Me gustaba ver el temario como se veia antes. Ahora tengo que hacer un scroll infinito para poder cerrar la pestania de Temario y ademas no hay como ir a la pagina principal del temario …
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?