Los tiempos de carga de páginas web más rápidos juegan un papel importante en la experiencia del usuario y el SEO, siendo la velocidad de carga de la página un factor determinante clave para el algoritmo de Google.

Un desarrollador web front-end debe decidir la mejor manera de representar un sitio web para que ofrezca una experiencia rápida y contenido dinámico.

Dos métodos de renderizado populares incluyen el renderizado del lado del cliente (CSR) y el renderizado del lado del servidor (SSR).

Todos los sitios web tienen requisitos diferentes, por lo que comprender la diferencia entre la representación del lado del cliente y del lado del servidor puede ayudarle a representar su sitio web para que coincida con sus objetivos comerciales.

Google y JavaScript

Google tiene una extensa documentación sobre cómo maneja JavaScript, y los empleados de Google ofrecen información y responden preguntas sobre JavaScript con regularidad a través de varios formatos, tanto oficiales como no oficiales.

Por ejemplo, en un podcast de Search Off The Record, se discutió que Google representa todas las páginas para la Búsqueda, incluidas las que tienen mucho JavaScript.

Esto provocó una conversación sustancial en LinkedIn, y otro par de conclusiones tanto del podcast como de las discusiones posteriores son las siguientes:

• Google no realiza un seguimiento de lo costoso que resulta representar páginas específicas.
• Google muestra todas las páginas para ver el contenido, independientemente de si usa JavaScript o no.

La conversación en su conjunto ha ayudado a disipar muchos mitos y conceptos erróneos sobre cómo Google podría tener Se acercó a JavaScript y asignó recursos.

El comentario completo de Martin Splitt en LinkedIn sobre esto fue:

“No hacemos un seguimiento de “¿cuán cara nos costó esta página?” o algo así. Sabemos que una parte sustancial de la web utiliza JavaScript para agregar, eliminar y cambiar contenido en las páginas web. Sólo tenemos que renderizar, para verlo todo. Realmente no importa si una página usa o no JavaScript, porque solo podemos estar razonablemente seguros de ver todo el contenido una vez que se haya renderizado”.

Martin también confirmó una cola y un posible retraso entre el rastreo y la indexación, pero no solo porque algo sea JavaScript o no, y no es un problema “opaco” que la presencia de JavaScript sea la causa principal de que las URL no se indexen.

Mejores prácticas generales de JavaScript

Antes de entrar en el debate entre el lado del cliente y el lado del servidor, es importante que también sigamos las mejores prácticas generales para que cualquiera de estos enfoques funcione:

• No bloquee los recursos de JavaScript a través de Robots.txt o reglas del servidor.
• Evite el bloqueo de renderizado.
• Evite inyectar JavaScript en el DOM.

¿Qué es el renderizado del lado del cliente y cómo funciona?

La renderización del lado del cliente es un enfoque relativamente nuevo para la renderización de sitios web.

Se hizo popular cuando las bibliotecas de JavaScript comenzaron a integrarlo, siendo Angular y React.js algunos de los mejores ejemplos de bibliotecas utilizadas en este tipo de renderizado.

Funciona representando el JavaScript de un sitio web en su navegador en lugar de en el servidor.

El servidor responde con un documento HTML básico que contiene los archivos JS en lugar de obtener todo el contenido del documento HTML.

Si bien el tiempo de carga inicial es un poco lento, las cargas de página posteriores serán rápidas ya que no dependen de una página HTML diferente por ruta.

Desde gestionar la lógica hasta recuperar datos de una API, los sitios renderizados por el cliente hacen todo de forma “independiente”. La página está disponible después de que se ejecuta el código porque cada página que visita el usuario y su URL correspondiente se crean dinámicamente.

El proceso de RSE es el siguiente:

• El usuario ingresa la URL que desea visitar en la barra de direcciones.
• Se envía una solicitud de datos al servidor en la URL especificada.
• En la primera solicitud del sitio por parte del cliente, el servidor entrega los archivos estáticos (CSS y HTML) al navegador del cliente.
• El navegador del cliente descargará primero el contenido HTML, seguido de JavaScript. Estos archivos HTML conectan JavaScript e inician el proceso de carga mostrando símbolos de carga que el desarrollador define al usuario. En esta etapa, el sitio web aún no es visible para el usuario.
• Una vez descargado el JavaScript, el contenido se genera dinámicamente en el navegador del cliente.
• El contenido web se vuelve visible a medida que el cliente navega e interactúa con el sitio web.

¿Qué es el renderizado del lado del servidor y cómo funciona?

La representación del lado del servidor es la técnica más común para mostrar información en una pantalla.

El navegador web envía una solicitud de información desde el servidor, recupera datos específicos del usuario para completarlos y envía una página HTML completamente renderizada al cliente.

Cada vez que el usuario visita una nueva página del sitio, el servidor repetirá todo el proceso.

Así es como el proceso SSR va paso a paso:

• El usuario ingresa la URL que desea visitar en la barra de direcciones.
• El servidor entrega al navegador una respuesta HTML lista para ser procesada.
• El navegador muestra la página (ahora visible) y descarga JavaScript.
• El navegador ejecuta React, haciendo así que la página sea interactiva.

¿Cuáles son las diferencias entre el renderizado del lado del cliente y del lado del servidor?

La principal diferencia entre estos dos enfoques de renderizado está en los algoritmos de su funcionamiento. CSR muestra una página vacía antes de cargar, mientras que SSR muestra una página HTML completamente representada en la primera carga.

Esto le da al renderizado del lado del servidor una ventaja en velocidad sobre el renderizado del lado del cliente, ya que el navegador no necesita procesar archivos JavaScript grandes. El contenido suele ser visible en un par de milisegundos.

Los motores de búsqueda pueden rastrear el sitio para mejorar el SEO, lo que facilita la indexación de sus páginas web. Esta legibilidad en forma de texto es precisamente la forma en que aparecen los sitios SSR en el navegador.

Sin embargo, la renderización del lado del cliente es una opción más económica para los propietarios de sitios web.

Alivia la carga en sus servidores, pasando la responsabilidad de renderizar al cliente (el bot o usuario que intenta ver su página). También ofrece interacciones ricas con el sitio al proporcionar una interacción rápida con el sitio web después de la carga inicial.

Se realizan menos solicitudes HTTP al servidor con CSR, a diferencia de SSR, donde cada página se representa desde cero, lo que resulta en una transición más lenta entre páginas.

SSR también puede fallar bajo una carga alta del servidor si el servidor recibe muchas solicitudes simultáneas de diferentes usuarios.

El inconveniente de CSR es el mayor tiempo de carga inicial. Esto puede afectar el SEO; Es posible que los rastreadores no esperen a que se cargue el contenido y salgan del sitio.

Este enfoque de dos fases plantea la posibilidad de ver contenido vacío en su página al perder contenido JavaScript después de rastrear e indexar por primera vez el HTML de una página. Recuerde que, en la mayoría de los casos, CSR requiere una biblioteca externa.

Cuándo utilizar el renderizado del lado del servidor

Si desea mejorar su visibilidad en Google y obtener una clasificación alta en las páginas de resultados del motor de búsqueda (SERP), la representación del lado del servidor es la opción número uno.

Los sitios web de aprendizaje electrónico, los mercados en línea y las aplicaciones con una interfaz de usuario sencilla con menos páginas, funciones y datos dinámicos se benefician de este tipo de representación.

Cuándo utilizar el renderizado del lado del cliente

La representación del lado del cliente suele combinarse con aplicaciones web dinámicas como redes sociales o mensajería en línea. Esto se debe a que la información de estas aplicaciones cambia constantemente y deben manejar datos grandes y dinámicos para realizar actualizaciones rápidas para satisfacer la demanda de los usuarios.

La atención se centra aquí en un sitio rico con muchos usuarios, priorizando la experiencia del usuario sobre el SEO.

¿Qué es mejor: renderizado del lado del servidor o del lado del cliente?

Al determinar qué enfoque es mejor, no solo debe tener en cuenta sus necesidades de SEO, sino también cómo funciona el sitio web para los usuarios y ofrece valor.

Piense en su proyecto y en cómo la representación elegida afectará su posición en las SERP y la experiencia del usuario de su sitio web.

Generalmente, CSR es mejor para sitios web dinámicos, mientras que SSR es más adecuado para sitios web estáticos.

Frecuencia de actualización de contenido

Los sitios web que presentan información altamente dinámica, como sitios web de apuestas o FOREX, actualizan su contenido cada segundo, lo que significa que probablemente elegiría CSR en lugar de SSR en este escenario, o elegiría usar CSR para páginas de destino específicas y no para todas las páginas, dependiendo de su estrategia de adquisición de usuarios.

SSR es más eficaz si el contenido de su sitio no requiere mucha interacción del usuario. Influye positivamente en la accesibilidad, los tiempos de carga de la página, el SEO y el soporte de las redes sociales.

Por otro lado, CSR es excelente para proporcionar renderizado rentable para aplicaciones web y es más fácil de construir y mantener; es mejor para el retardo de la primera entrada (FID).

Otra consideración de CSR es que las metaetiquetas (descripción, título), las URL canónicas y las etiquetas Hreflang deben representarse en el lado del servidor o presentarse en la respuesta HTML inicial para que los rastreadores las identifiquen lo antes posible, y no solo aparezcan en la respuesta HTML representada. HTML.

Consideraciones de plataforma

La tecnología CSR tiende a ser más costosa de mantener porque la tarifa por hora para los desarrolladores expertos en React.js o Node.js es generalmente más alta que la de los desarrolladores de PHP o WordPress.

Además, hay menos complementos listos para usar o soluciones listas para usar disponibles para marcos de CSR en comparación con el ecosistema de complementos más grande al que también tienen acceso los usuarios de WordPress.

Para aquellos que estén considerando una configuración de WordPress sin cabeza, como usar Frontity, es importante tener en cuenta que deberán contratar desarrolladores de React.js y PHP.

Esto se debe a que WordPress sin cabeza depende de React.js para el front-end y al mismo tiempo requiere PHP para el back-end.

Es importante recordar que no todos los complementos de WordPress son compatibles con configuraciones sin cabeza, lo que podría limitar la funcionalidad o requerir un desarrollo personalizado adicional.

Funcionalidad y propósito del sitio web

A veces, no es necesario elegir entre los dos, ya que hay soluciones híbridas disponibles. Tanto la RSS como la RSC se pueden implementar dentro de un único sitio web o página web.

Por ejemplo, en un mercado en línea, las páginas con descripciones de productos se pueden representar en el servidor, ya que son estáticas y los motores de búsqueda deben indexarlas fácilmente.

Siguiendo con el comercio electrónico, si tiene altos niveles de personalización para los usuarios en varias páginas, no podrá renderizar SSR el contenido para los bots, por lo que deberá definir algún tipo de contenido predeterminado para el robot de Google que rastrea sin cookies y apátrida.

Las páginas como las cuentas de usuario no necesitan clasificarse en las páginas de resultados del motor de búsqueda (SERP), por lo que un enfoque CRS podría ser mejor para UX.

Tanto CSR como SSR son enfoques populares para renderizar sitios web. Usted y su equipo deben tomar esta decisión en la etapa inicial del desarrollo del producto.

Más recursos:

Imagen destacada: tippapatt/Shutterstock