Representación del lado del cliente frente a la representación del lado del servidor

Inicialmente, los marcos web tenían vistas representadas en el servidor. Ahora está sucediendo en el cliente. Exploremos las ventajas y desventajas de cada enfoque.

Actuación

Con la representación del lado del servidor, cada vez que desee ver una nueva página web, debe salir y obtenerla:

Diagrama de cómo funciona la representación del lado del servidor

Esto es análogo a que conduzcas al supermercado cada vez que quieras comer.

Con la representación del lado del cliente, vas al supermercado una vez y pasas 45 minutos caminando comprando un montón de comida durante el mes. Luego, cada vez que quiera comer, simplemente abra la nevera.

Diagrama de cómo funciona la representación del lado del cliente

Cada enfoque tiene sus ventajas y desventajas en lo que respecta al rendimiento:

  • Con la representación del lado del cliente, la carga inicial de la página será lenta. Debido a que la comunicación a través de la red es lenta y se requieren dos viajes de ida y vuelta al servidor antes de que pueda comenzar a mostrar contenido al usuario. Sin embargo, después de eso, cada carga de página posterior será increíblemente rápida.
  • Con la representación del lado del servidor, la carga inicial de la página no será terriblemente lenta. Pero no será rápido. Y tampoco lo hará ninguna de sus otras solicitudes.

Para ser más específico, con la representación del lado del cliente, la página inicial se verá así:


  
    
    
  
  
    
  

app.js tendrá todas las páginas HTML en JavaScript como cadenas. Algo como esto:

var páginas = {
  '/': ' ... ',
  '/ foo': ' ... ',
  '/ bar': ' ... ',
};

Luego, cuando se carga la página, el marco mirará la barra de URL, obtendrá la cadena en las páginas ['/'], e la insertará en

. Además, cuando hace clic en los enlaces, el marco interceptará el evento, insertará la nueva cadena (por ejemplo, páginas ['/ foo']) en el contenedor y evitará que el navegador active la solicitud HTTP como lo hace normalmente.

SEO

Supongamos que nuestro rastreador web comienza solicitando reddit.com:

var request = require ('solicitud');
request.get ('reddit.com', función (error, respuesta, cuerpo) {
  // el cuerpo se parece a esto:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Hacker News 
  // ... otras etiquetas  ...
});

El rastreador luego usa las cosas en el cuerpo de la respuesta para generar nuevas solicitudes:

var request = require ('solicitud');
request.get ('reddit.com', función (error, respuesta, cuerpo) {
  // el cuerpo se parece a esto:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Hacker News 
  // ... otras etiquetas  ...
  request.get ('espn.com', function () {...});
  request.get ('news.ycombinator.com', function () {...});
});

Después de eso, el rastreador continúa el proceso utilizando los enlaces en espn.com y news.ycombinator.com para seguir rastreando.

Aquí hay un código recursivo para hacer eso:

var request = require ('solicitud');
función crawlUrl (url) {
  request.get (url, función (error, respuesta, cuerpo) {
    var linkUrls = getLinkUrls (cuerpo);
    linkUrls.forEach (function (linkUrl) {
      crawlUrl (linkUrl);
    });
  });
}
crawlUrl ('reddit.com');

¿Qué pasaría si el cuerpo de respuesta se viera así?


  
    
    
  
  
    
  

Bueno, no hay ninguna etiqueta a seguir. Además, esta página web se ve bastante aburrida, por lo que probablemente no queremos priorizarla cuando mostramos resultados de búsqueda.

Poco sabe el rastreador, Client Side Framework está a punto de llenar

con un montón de contenido increíble.

Esta es la razón por la cual el renderizado del lado del cliente puede ser malo para el SEO.

Reprendiendo

En 2009, Google introdujo una forma de evitar esto.

https://webmasters.googleblog.com/2009/10/proposal-for-making-ajax-crawlable.html

Cuando el rastreador encuentra www.example.com/page?query#!mystate, lo convierte a www.example.com/page?query&_escaped_fragment_=mystate. De esta manera, cuando su servidor recibe una solicitud con _escaped_fragment_, sabe que la solicitud proviene de un rastreador, no de un humano.

Recuerde: el servidor quiere que el rastreador vea

...
(con el contenido dentro), no
. Por lo que entonces:

  • Cuando la solicitud proviene de un rastreador, podemos servir
    ...
    .
  • Cuando la solicitud proviene de un humano normal, podríamos servir
    y dejar que el JavaScript inserte contenido dentro.

Sin embargo, hay un problema: el servidor no sabe qué va a entrar dentro del

. Para descubrir qué hay dentro, tendría que ejecutar JavaScript, crear un DOM y manipular ese DOM. Como los servidores web tradicionales no saben cómo hacerlo, emplean un servicio conocido como Headless Browser para hacerlo.

Rastreadores más inteligentes

Seis años más tarde, Google anunció que su rastreador subió de nivel. Cuando Crawler 2.0 ve las etiquetas