Representación del lado del servidor versus representación del lado del cliente: una guía para el desarrollo web

muestra que el 53% de las visitas a sitios web móviles se abandonan si las páginas tardan más de tres segundos en cargarse, lo que destaca lo fundamental que es la renderización rápida para mantener el interés del usuario.

Para garantizar un rendimiento óptimo, los desarrolladores suelen utilizar SSR, CSR o un enfoque híbrido conocido como renderizado universal/isomorfo (hablaremos de esto un poco más adelante). Cada método tiene sus pros y sus contras en cuanto a optimización SEO, tiempo de carga inicial, velocidad de interactividad, escalabilidad y mantenibilidad, entre otros factores.

SSR proporciona una vista previa inmediata de la página web porque envía archivos HTML completamente completos desde el servidor al navegador, pero puede comprometer la interactividad de la página hasta que todo el JavaScript esté completamente cargado. Por otro lado, CSR ofrece velocidades de interacción más rápidas una vez cargado, ya que JavaScript se ejecuta directamente en el navegador del cliente, pero sufre tiempos de carga inicial más lentos debido al HTML vacío enviado mientras se espera que se ejecute JavaScript.

La incorporación de tecnologías modernas como aplicaciones web progresivas (PWA) puede ayudar a optimizar los enfoques de SSR y CSR, permitiendo que los sitios web funcionen más como aplicaciones nativas, ofreciendo funcionalidad fuera de línea y mejorando la experiencia general del usuario (UX) independientemente de las condiciones de la red, garantizando así la retención de clientes incluso en situaciones adversas.

Pero basta de usuarios: hablemos de renderizado.

¿Qué es RSS?

Básicamente, SSR implica generar HTML renderizado en el servidor antes de enviarlo al cliente: el navegador del usuario final. Este proceso de representación del lado del servidor ocurre cada vez que un usuario final realiza una solicitud de página. En esencia, cuando alguien escribe o hace clic en la URL de su sitio web en su dispositivo, cada página web solicitada ya es una página HTML completamente renderizada, preparada en servidores de élite repartidos en diferentes regiones del mundo.

Contrariamente a la percepción de que este enfoque puede consumir muchos recursos, los marcos de renderizado del lado del servidor están diseñados para simplificar las acciones realizadas por los clientes y al mismo tiempo aprovechar los recursos de procesamiento de los servidores de manera eficiente. Esto minimiza las solicitudes frecuentes al servidor, que pueden resultar costosas, especialmente en una conexión a Internet lenta.

Una ventaja clave derivada de RSS radica en sus tiempos de Primera Pintura Significativa (FMP) , una métrica de rendimiento que se refiere a la rapidez con la que el contenido fuente crítico aparece a los usuarios al cargar un archivo HTML. Dado que las páginas pre-renderizadas se entregan inmediatamente, los usuarios son inmediatamente absorbidos por la interfaz de usuario, mitigando así las posibilidades de rebotes repentinos debido a retrasos percibidos, lo cual es de suma importancia para las plataformas de alto tráfico que buscan mayores métricas sobre las tasas de retención y participación de clientes.

¡Pero espera hay mas! Uno de los mayores dolores de cabeza para los desarrolladores web con CSR es que debido a que la página de inicio es casi básica, los robots de los motores de búsqueda como los utilizados por Google a veces no logran capturar el contenido de la página web, lo que, como se puede esperar, es una sentencia de muerte para el SEO. De hecho, esta es la razón por la que SSR, un marco de código abierto, ha ganado popularidad: finalmente ha resuelto uno de los mayores dolores de cabeza de las SPA.

A primera vista, los servidores pueden no parecer el componente más glamoroso de su ecosistema digital: una fuerza invisible que zumba detrás de escena mientras los desarrolladores disfrutan del centro de atención jugando con animaciones CSS o experimentando con aplicaciones AR/VR.

Sin embargo, imagine tener una actuación de ballet coreografiada por expertos sin ningún acompañamiento musical: los matices y la profundidad disminuirán notablemente. Este es precisamente el vacío que un enfoque mediocre en la comprensión de los servidores crearía en su modelo de negocio.

SSR opera como director de orquesta responsable de gestionar las sinfonías a petición de los visitantes en nuestros sitios web. Estos fragmentos de código ayudan a pintar las pantallas del navegador con soluciones de renderizado procesadas en el lado del servidor mucho antes de que lleguen a los dispositivos de los usuarios. Piense en completar las piezas del rompecabezas con anticipación para que los usuarios finales pasen menos tiempo esperando.

La solución SSR interpreta todas las solicitudes realizadas por los navegadores a través de una red de protocolo HTTP y entrega páginas HTML terminadas directamente al usuario. Esto elimina la necesidad de analizar la biblioteca JavaScript del lado del cliente y el complicado trabajo de procesar el JavaScript del lado del servidor. Como ya no dependemos del JavaScript del lado del cliente, tenemos mucho más control sobre nuestro sitio web o aplicación, pero esto obviamente tiene un costo.

Servir a unos cientos de usuarios no es un problema para un servidor pequeño, pero ¿qué pasa si atiende a millones de usuarios? Recuerde que algunos de los sitios más importantes reciben cientos de millones de usuarios al día; de repente, todas estas solicitudes piden a nuestros servidores "Oye, crea una vista". Si simplemente solicitar información es suficiente para cerrar un sitio web, tener que mostrar la página a millones de usuarios es una tarea difícil.

Detrás de escena: la mecánica del renderizado del lado del cliente

La RSE se ha convertido en una estrategia muy eficaz para los desarrolladores web, principalmente debido a su capacidad para proporcionar experiencias de usuario interactivas y optimizadas.

El primer paso para comprender la RSE es reconocer que todas las acciones clave ocurren dentro de su navegador. A diferencia de los procesos del lado del servidor, donde los cálculos se realizan en servidores potentes antes de entregar HTML estático a los navegadores, CSR aprovecha un marco de JavaScript de código abierto para impulsar estos motores: Chrome V8 o Firefox's Spidermonkey, por ejemplo.

Sí, los sitios web renderizados en el lado del cliente tienen un costo de carga inicial relativamente más alto que sus contrapartes renderizados en el servidor porque necesitan descargar más recursos, incluido un único archivo JavaScript, en lugar de solo documentos de una sola página. Pero recuerda que esto sólo sucede una vez; A medida que la información se almacena en caché en el hardware del usuario, la navegación posterior se vuelve más fluida y rápida, proporcionando una experiencia de navegación perfecta, ¡exactamente lo que exige el usuario impaciente de hoy!

Tradicionalmente, con CSR, la obtención de datos se produce a través de API después de las descargas iniciales de JavaScript, lo que permite cargar datos asincrónicos y actualizar partes de forma independiente en lugar de volver a cargar páginas enteras, una mejora significativa con respecto a la forma anterior de hacer las cosas. Y para ayudar a mejorar el intercambio de contenido web en la web, los desarrolladores también pueden implementar el protocolo Open Graph de Facebook para una mejor representación en las plataformas de redes sociales (oye, Django y WordPress, te estoy mirando).

Como mencionamos antes, se podría argumentar que los problemas de SEO eran un punto débil para los CSR porque los motores de búsqueda tenían dificultades para interpretar el código JavaScript de manera efectiva. Sin embargo, con los avances y la integración de componentes de interfaz de usuario reutilizables, esto ha mejorado un poco. El robot de Google, por ejemplo, ahora puede "leer" tipos dependientes de JavaScript. No es una solución perfecta desde ningún punto de vista: cuanto más creativo sea con su JavaScript, más probabilidades tendrá de condenar su sitio al infierno del SEO. Pero es mucho mejor que hace unos años.

Dada su gran dependencia de los recursos locales (es decir, los navegadores de los usuarios), las capacidades avanzadas de interactividad hacen que los CSR sean ideales para aplicaciones web que requieren interacciones constantes, como actualizaciones o animaciones en tiempo real, escenarios típicos que incluyen SPA, análisis posteriores al primer renderizado y -Plataformas de comercio con muchas opciones de detalle de productos, etc.

Pros y contras del renderizado del lado del servidor

Cuando se trata de una empresa de desarrollo web, elegir entre SSR y CSR a menudo puede parecer como navegar por un laberinto. Sin embargo, intentaremos profundizar en las complejidades de ambos enfoques y ver si podemos ayudarle a descubrir cuál se adapta mejor a sus necesidades.

Accesibilidad a los motores de búsqueda: una ventaja sobre la RSE

Una ventaja innegable que tiene SSR sobre su contraparte es su excelente accesibilidad a los rastreadores de motores de búsqueda. Esto significa que Googlebot o Bingbot pueden indexar rápidamente su contenido a medida que los motores de búsqueda reciben una página completamente renderizada desde el servidor. Entonces, si desea un excelente rendimiento de SEO, SSR puede marcar esa casilla de manera convincente.

Experiencia de usuario protegida: Catering First Contentful Paint

Los usuarios de hoy son notoriamente impacientes cuando se trata de sitios web lentos; Quieren su información allí mismo. Con SSR en acción, el usuario no se quedará mirando una pantalla en blanco hasta que se carguen todos los scripts (un error común en CSR), ya que los servidores envían HTML listo para su visualización, logrando instantáneamente lo que se conoce como "la primera pintura con contenido" más rápido. .

Una opción económica para los usuarios

Piense en los usuarios finales con dispositivos de gama baja o aquellos que luchan con una conectividad a Internet inferior. Ao separar as operações pesadas em componentes prontamente renderizáveis ​​no lado do servidor, em vez de terceirizá-las totalmente nas máquinas dos clientes, como faz o CSR, garantimos uma experiência justa do usuário, independentemente das capacidades do dispositivo, sem quebrar seus bancos ¡de dados!

El otro lado…

Por muy virtuosas que parezcan estas ventajas, ninguna tecnología es perfecta –ni tampoco la SSR–, por lo que señala algunas desventajas dignas de consideración junto con sus puntos positivos:

Preocupaciones por la carga del servidor: ¿una presión potencial sobre el rendimiento?

En términos de arquitectura operativa (específicamente en términos de carga), los SSR ejercen una presión adicional sobre los servidores y pueden tener un profundo impacto en las velocidades y costos de carga. Los servicios basados ​​en la nube pueden escalarse dinámicamente para manejar el problema, pero esto a su vez significa que hay que tener mucho cuidado con la estructura de costos.

Lidiar con actualizaciones frecuentes

Los sitios que requieren actualizaciones dinámicas continuas pueden enfrentar desafíos en un entorno SSR porque cada nueva interacción requiere nuevo HTML obtenido del servidor. Recargar páginas dificultará la interactividad en tiempo real, algo crucial en sitios como portales de subastas en vivo o aplicaciones de juegos de deportes de fantasía.

Lo bueno, lo malo y lo feo: evaluación del renderizado del lado del cliente

Para empezar, revelemos algunos aspectos que hacen que la renderización del lado del cliente sea tan atractiva.

Interacción dinámica

Un aspecto clave de CSR es su capacidad para una interacción del usuario más dinámica en comparación con las aplicaciones renderizadas por el servidor. Debido a que las acciones basadas en eventos se procesan más rápido en el navegador del usuario que los viajes de ida y vuelta al servidor, los visitantes disfrutan de una experiencia de navegación increíblemente fluida y fluida.

Carga reducida del servidor

Al descargar las tareas informáticas a los dispositivos de los clientes en lugar de solo a los servidores, esto da como resultado una menor carga del servidor, lo que potencialmente podría reducir los costos operativos asociados con el mantenimiento de servidores de alto rendimiento.

Consideraciones de escalabilidad

Debido a la menor dependencia de los servidores para la representación de páginas debido al cambio de cálculos directamente en los navegadores de los clientes, las complejidades de escalabilidad, especialmente durante los períodos pico de visitas, se pueden mitigar con el tiempo, brindando así oportunidades de ahorro de costos y mejorando la solidez del sitio web.

El otro lado…

Complicaciones de SEO

No todos los rastreadores de motores de búsqueda están acostumbrados o suficientemente adaptados a la indexación de sitios implementados en torno a complejos marcos de JavaScript ampliamente utilizados en arquitecturas de representación del lado del cliente; Esto puede comprometer la visibilidad de la página web, lo que genera bajas tasas de descubrimiento orgánico.

Advertencias de rendimiento

Si bien las conversaciones sobre velocidades de carga a menudo se centran en la rapidez con la que aparecen los elementos estáticos (que de hecho tiende a ser más rápido debido a las ligeras respuestas iniciales del servidor), cuando tomamos en cuenta otros factores como el tiempo total necesario antes de renderizar un archivo totalmente habilitado para interactividad página web – la imagen no es tan bonita. Gracias a una mayor dependencia de las condiciones de la red y de los recursos informáticos del usuario, las actualizaciones de contenido posteriores a la carga inicial pueden convertirse en un punto delicado para los usuarios.

Seguridad y vulnerabilidad

Desafortunadamente, hacer que el cliente administre tantas cosas puede ser un riesgo de ciberseguridad. Para ser justos, este no es realmente un problema del que deba preocuparse si sus desarrolladores tienen un buen conocimiento de las prácticas de ciberseguridad. Pero tenga en cuenta que ocurren errores y que a veces la biblioteca que utilizamos en nuestros proyectos puede compartir más datos de los que pretendíamos. En estos casos, la información está ahí para que cualquiera la vea.

¿Qué es eso de JavaScript isomórfico?

SSR con Javascript isomórfico o renderizado universal es una técnica que combina lo mejor de dos mundos: la velocidad de SSR y la interactividad de RSE.

Con la representación universal, la página primero se representa en el servidor y luego se envía un pequeño archivo JavaScript al navegador para terminar de representar la página. Esto proporciona la velocidad de SSR, porque el navegador no tiene que hacer ningún trabajo para representar la página de inicio, y la interactividad de CSR, porque el navegador puede actualizar la página sin tener que volver a cargarla por completo.

Beneficios del renderizado universal:

• Tiempos de carga inicial más rápidos: la página se representa en el servidor antes de enviarse al navegador, por lo que puede cargarse instantáneamente.
• Mejor SEO: los motores de búsqueda indexan más fácilmente las páginas SSR, lo que puede ayudar a mejorar la clasificación de búsqueda de su sitio.
• Más interactividad: el navegador puede actualizar la página sin tener que recargar toda la página, lo que puede mejorar la experiencia del usuario.
• Más flexibilidad: puede utilizar cualquier marco de JavaScript para representar la página, tanto en el servidor como en el navegador.

Desventajas del renderizado universal:

• Más complejo de implementar: el renderizado universal es más complejo de implementar que SSR o CSR.
• Puede ser más lento para las cargas de páginas posteriores: después de que se cargue la página inicial, las cargas de páginas posteriores serán más lentas que con CSR porque el navegador tendrá que descargar el archivo JavaScript del servidor.

En general, el renderizado universal es una buena opción para sitios que necesitan ser rápidos y compatibles con SEO. Si está dispuesto a hacer un esfuerzo adicional para implementarlo, el renderizado universal puede brindarle lo mejor de ambos mundos.

A continuación se muestran algunos ejemplos de sitios que utilizan renderizado universal:

• Búsqueda de Google: la Búsqueda de Google utiliza representación universal para garantizar que la página de resultados de búsqueda se cargue rápidamente para los usuarios con conexiones a Internet lentas.
• Twitter: Twitter utiliza renderizado universal para garantizar que los tweets se carguen instantáneamente para los usuarios.
• Medio: Medio utiliza renderizado universal para brindar una experiencia de lectura fluida e interactiva.

Si está pensando en utilizar el renderizado universal en su sitio web, hay algunas cosas que debe tener en cuenta:

• Asegúrese de que su servidor sea lo suficientemente rápido: el servidor debe poder representar la página rápidamente para que pueda cargarse instantáneamente para los usuarios.
• Utilice un buen marco de JavaScript: el marco de JavaScript que utilice debe estar bien optimizado para el rendimiento.
• Pruebe su sitio a fondo: asegúrese de que su sitio funcione correctamente con renderizado universal antes de implementarlo en producción.

Ejemplos de marcos para renderizado universal.

Si bien un desarrollador puede utilizar cualquier marco para crear una página de representación universal, hemos visto un aumento en marcos extremadamente potentes y fáciles de usar que están cambiando el panorama del desarrollo web.

React.JS: pionero en arquitectura basada en componentes

React.js ha remodelado el panorama del desarrollo web moderno con su filosofía centrada en componentes. Además, la renderización del lado del servidor en React mejora el rendimiento de las aplicaciones y el SEO. Diseñado para crear interfaces de usuario ricas, presenta un DOM virtual que garantiza actualizaciones y renderizado eficientes.

El enfoque de este marco en componentes reutilizables agiliza el código y acelera el desarrollo. La adopción generalizada de React por parte de gigantes tecnológicos y nuevas empresas resalta su importancia en los debates sobre tecnología.

Next.JS: Robustez combinada con versatilidad

Next.js es lo que debería esforzarse por ser un marco: es flexible, está bien documentado y ofrece una multitud de enfoques para implementar nuestras páginas web.

Next.js se destaca por su función de división automática de código, lo que resulta en cargas de página más rápidas, lo que impacta directa y positivamente las tasas de participación del usuario, ¡una métrica crítica que a menudo se discute durante las reuniones de la junta directiva!

Svelte: enfoque preparado para el futuro

Svelte adopta un enfoque preparado para el futuro para crear aplicaciones web responsivas. Compila su código en pequeños módulos JavaScript independientes en el momento de la compilación en lugar de interpretarlo en el tiempo de ejecución, lo que proporciona importantes ventajas de velocidad cruciales para mantenerse competitivo en el acelerado panorama del mercado actual.

Fresco: la respuesta de Deno

Para aquellos que están listos para dejar atrás NodeJS, Deno es un potente tiempo de ejecución creado por el mismo desarrollador que NodeJS, y Fresh es su respuesta a los marcos web JavaScript modernos, con un enfoque minimalista y creado para Typecript. Puede que Fresh sea un recién llegado, pero tiene el potencial de crecer y conquistar el mundo.

Me encantaría dar una declaración definitiva sobre qué enfoque debe adoptar. Pero la realidad de los servicios de desarrollo de JavaScript es que no existe una respuesta única para todos. Cada proyecto representa su propio conjunto único de requisitos. Por lo tanto, nuestro consejo más valioso es deliberar cuidadosamente, basándose en lo que hemos discutido hasta ahora. ¿Qué solución se alinea mejor con usted, su proyecto y su equipo? Independientemente de su elección, tenga la seguridad de que hay una multitud de herramientas y soluciones disponibles para impulsar su viaje de desarrollo.

Si le gustó esto, asegúrese de consultar nuestros otros artículos sobre desarrollo web.

• Desarrollo de arquitectura escalable
• Limpieza de primavera del software
• Los mejores chatbots para sitios web
• Las 7 herramientas de desarrollo web más populares utilizadas por los profesionales
• 5 trucos geniales para acelerar el tiempo de carga de tu página