Original article: Client-side vs. server-side rendering: why it’s not all black and white

Desde el principio de los tiempos, el método convencional para mostrar su HTML en una pantalla fue mediante el uso de la renderización desde el servidor. Era la única manera. Cargabas tus páginas .html en tu servidor, luego tu servidor las convertía en documentos útiles en los navegadores de tus usuarios.

La renderización desde el servidor también funcionó muy bien en ese momento, ya que la mayoría de las páginas web eran en su mayoría solo para mostrar imágenes y texto estáticos, con poca interactividad.

A día de hoy ese ya no es el caso. Se podría argumentar que los sitios web en estos días son más como aplicaciones que fingen ser sitios web. Puede usarlos para enviar mensajes, actualizar información en línea, comprar y mucho más. La web es mucho más avanzada de lo que solía ser.

Por lo tanto, tiene sentido que la renderización desde el servidor esté comenzando lentamente a quedar relegada al creciente método de renderización de páginas web en el lado del cliente.

Entonces, ¿qué método es la mejor opción? Como con la mayoría de las cosas en desarrollo, realmente depende de lo que planee hacer con su sitio web. Debe comprender los pros y los contras, luego decidir por sí mismo qué ruta es mejor.

Cómo funciona la renderización desde el servidor

La renderización desde el servidor es el método más común para mostrar información en la pantalla. Funciona convirtiendo archivos HTML del servidor en información utilizable para el navegador.

Cada vez que visita un sitio web, su navegador realiza una solicitud al servidor que contiene los contenidos del sitio web. La solicitud generalmente solo toma unos pocos milisegundos, pero eso depende en última instancia de una multitud de factores:

  • Tu velocidad de internet
  • la ubicación del servidor
  • cuántos usuarios intentan acceder al sitio web
  • y qué tan optimizado está el sitio web, por nombrar algunos

Una vez que se procesa la solicitud en el servidor, su navegador recupera el HTML completamente renderizado y lo muestra en la pantalla. Si luego decide visitar una página diferente en el sitio web, su navegador volverá a solicitar la nueva información. Esto ocurrirá cada vez que visite una página de la que su navegador no tenga una versión en caché.

No importa si la nueva página solo tiene algunos elementos que son diferentes a la página actual, el navegador solicitará la nueva página completa y volverá a mostrar todo desde cero.

Tomemos como ejemplo este documento HTML que se ha colocado en un servidor imaginario con una dirección HTTP de example.testsite.com.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Ejemplo de sitio web</title>
  </head>
  <body>
    <h1>Mi sitio Web</h1>
    <p>Esto es un ejemplo de mi nuevo sitio web</p>
    <a href="http://example.testsite.com/other.html.">Link</a>
  </body>
</html>

Si tuviera que escribir la dirección del sitio web que usamos como ejemplo en la URL de su navegador, su navegador haría una solicitud al servidor que utiliza esa URL y esperaría una respuesta de algún texto para mostrar en el navegador. En este caso, lo que verías visualmente sería el título, el contenido del párrafo y el link.

Ahora, suponga que desea hacer clic en el enlace de la página renderizada que contiene el siguiente código.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Ejemplo de sitio web</title>
  </head>
  <body>
    <h1>Mi sitio Web</h1>
    <p>Esto es un ejemplo de mi nuevo sitio web</p>
    <p>Esto es más contenido desde other.html</p>
  </body>
</html>

La única diferencia entre la página anterior y esta es que esta página no tiene un enlace y en su lugar tiene otro párrafo. La lógica dictaría que solo se debería renderizar el nuevo contenido y dejar el resto. Por desgracia, no es así como funciona la renderización desde el servidor. Lo que sucedería en realidad sería que se renderiza toda la página de nuevo, y no solo el contenido nuevo.

Si bien estos dos ejemplos pueden no parecer gran cosa, la mayoría de los sitios web no son tan simples. Los sitios web modernos tienen cientos de líneas de código y son mucho más complejos. Ahora imagine navegar por una página web y tener que esperar a que se muestren todas y cada una de las páginas al navegar por el sitio. Si alguna vez ha visitado un sitio de WordPress, habrá visto lo lentos que pueden ser. Esta es una de las razones del porqué.

Por el lado positivo, la renderización desde el servidor es excelente para SEO. Su contenido está cargado antes, por lo que los motores de búsqueda pueden indexarlo y rastrearlo sin problemas. Algo que no ocurre con el renderizado del lado del cliente. Al menos no simplemente.

Como funciona la renderización por el lado del cliente

Cuando los desarrolladores hablan de renderización del lado del cliente, se refieren a la renderización de contenido en el navegador mediante JavaScript. Entonces, en lugar de obtener todo el contenido del documento HTML en sí, está obteniendo un documento HTML básico con un archivo JavaScript que renderizara el resto del sitio usando el navegador.

Este es un enfoque relativamente nuevo para renderizar sitios web, y realmente no se volvió popular hasta que las bibliotecas de JavaScript comenzaron a incorporarlo en su estilo de desarrollo. Algunos ejemplos notables son Vue.js y React.js.

Volviendo al sitio web que creamos anteriormente, example.testsite.com, suponga que ahora tiene un archivo index.html con las siguientes líneas de código.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Ejemplo de sitio web</title>
</head>
<body>
  <div id="root">
    <app></app>
  </div>
  <script src="https://vuejs.org"type="text/javascript"></script>
  <script src="location/of/app.js"type="text/javascript"></script>
</body>
</html>

Puede ver de inmediato que hay algunos cambios importantes en la forma en que index.html funciona cuando se procesa con el cliente.

Para empezar, en lugar de tener el contenido dentro del archivo HTML, tiene un contenedor div con un ID "root". También tiene dos elementos script justo encima de la etiqueta </body>. Uno que cargará la biblioteca JavaScript de Vue.js y otro que cargará un archivo llamado app.js.

Esto es radicalmente diferente al uso de la renderización desde el servidor porque el servidor ahora solo es responsable de cargar una parte mínima del sitio web. El código principal repetitivo. Todo lo demás es manejado por una biblioteca de JavaScript del lado del cliente, en este caso, Vue.js y código de JavaScript personalizado.

Si hiciera una solicitud a la URL con solo el código anterior, obtendría una pantalla en blanco. No hay nada que cargar, ya que el contenido real debe procesarse mediante JavaScript.

Para solucionarlo, necesita las siguientes líneas de código en el archivo app.js.

var data = {
        title:"Mi sitio web",
        message:"Esto es un ejemplo de mi sitio web"
      }
  Vue.component('app', {
    template:
    `
    <div>
    <h1>{{title}}</h1>
    <p id="moreContent">{{message}}</p>
    <a v-on:click='newContent'>Link</a>
    </div>
    `,
    data: function() {
      return data;
    },
    methods:{
      newContent: function(){
        var node = document.createElement('p');
        var textNode = document.createTextNode('Esto es más contenido desde other.html');
        node.appendChild(textNode);
        document.getElementById('moreContent').appendChild(node);
      }
    }
  })
  new Vue({
    el: '#root',
  });

Ahora, si visita la URL, verá el mismo contenido que vio en el ejemplo del lado del servidor. La diferencia clave es que si hiciera clic en el enlace de la página para cargar más contenido, el navegador no realizará otra solicitud al servidor. Está procesando elementos con el navegador, por lo que utilizará JavaScript para cargar el contenido nuevo y Vue.js se asegurará de que solo se procese el contenido nuevo.

Esto es mucho más rápido, ya que solo está cargando una sección muy pequeña de la página para obtener el nuevo contenido, en lugar de cargar toda la página.

Sin embargo, con el uso de la renderización del lado del cliente, el contenido no se procesa hasta que la página se carga en el navegador y el SEO del sitio web se verá afectado. Hay formas de evitar esto, pero no es tan fácil como lo es con la renderización desde el servidor.

Otra cosa a tener en cuenta es que su sitio web/aplicación no podrá cargarse hasta que TODO el JavaScript se descargue en el navegador. Lo cual tiene sentido, ya que contiene todo el contenido que se necesitará. Si sus usuarios están utilizando una conexión a internet lenta, podría hacer que su tiempo de carga inicial sea un poco largo.

Las ventajas y los contras de cada enfoque

Así que ahí lo tienes. Esas son las principales diferencias entre el renderizado del lado del servidor y del lado del cliente. Solo usted, el desarrollador, puede decidir qué opción es mejor para su sitio web o aplicación.

A continuación se muestra un desglose rápido de los pros y los contras de cada enfoque:

Ventajas renderizando desde el servidor:

  1. Los motores de búsqueda pueden rastrear el sitio para un mejor SEO.
  2. La carga de la página inicial es más rápida.
  3. Ideal para sitios estáticos.

Contras renderizando desde el servidor:

  1. Solicitudes frecuentes al servidor.
  2. Una renderización generalmente lenta.
  3. Recargas de página completa.
  4. Interacciones de sitios web pobres.

Ventajas renderizando desde el cliente:

  1. Muchas interacciones en los sitios web.
  2. Renderizado rápido del sitio web después de la carga inicial.
  3. Ideal para aplicaciones web.
  4. Sólida selección de bibliotecas de JavaScript.

Contras renderizando desde el cliente:

  1. SEO bajo si no se implementa correctamente.
  2. La carga inicial puede requerir más tiempo.
  3. En la mayoría de los casos, requiere una biblioteca externa.