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

Voy a prefacio diciendo que este artículo está destinado a actuar como una sinopsis de alto nivel basada en una excelente investigación existente. Como tal, simplemente estoy consolidando los puntos que considero más importantes al iniciar el SEO de JavaScript. Me vincularé a estos artículos de recursos en todo momento, así como incluiré una lista en la parte inferior, así que asegúrese de revisarlos si desea profundizar en las malas hierbas.

¿Qué es JavaScript SEO?

En esencia, JavaScript SEO es básicamente la práctica de asegurarse de que el contenido de una página (ejecutado a través de JS) se muestre, indexe y clasifique correctamente en los resultados de búsqueda de los motores de búsqueda. Esto es especialmente pertinente debido a la creciente popularidad de la representación del lado del cliente y los sitios web creados sobre marcos JavaScript. Antes de continuar, veamos los dos tipos predominantes de renderizado:

  • Representación del lado del servidor (SSR): el método de representación tradicional, básicamente todos los recursos de su página se alojan en el servidor. Luego, cuando se solicita la página, el HTML se entrega al navegador y se procesa, JS y CSS se descargan, y el render final aparece para el usuario / bot.
  • Representación del lado del cliente (CSR): un tipo de método de representación más reciente, que se basa en JS ejecutado en el lado del cliente (navegador) a través de un marco de JavaScript. Esencialmente, el cliente primero solicitará el código fuente que tendrá muy poco HTML indexable, luego se realizará una segunda solicitud para el archivo .js que contiene todo el HTML en JavaScript como cadenas.

¿Las principales diferencias entre SSR y CSR?

La representación del lado del servidor puede ser un poco más rápida en la solicitud inicial, simplemente porque no requiere tantos viajes de ida y vuelta al servidor. Sin embargo, esto no termina aquí, el rendimiento también depende de algunos factores adicionales. Todo lo cual puede resultar en experiencias de usuario drásticamente variadas:

  • La velocidad de Internet del usuario que realiza la solicitud.
  • Cuántos usuarios activos están accediendo al sitio en un momento dado
  • La ubicación física del servidor.
  • Qué tan optimizadas son las páginas para la velocidad
  • Etc ...

La representación del lado del cliente, por otro lado, es más lenta en la solicitud inicial porque está haciendo múltiples viajes de ida y vuelta al servidor. Sin embargo, una vez que se completan estas solicitudes, CSR ofrece una experiencia increíblemente rápida a través del marco JS.

Aquí hay una metáfora útil que describe la diferencia entre SSR y CSR:

Con la representación del lado del servidor, cada vez que desee ver una nueva página web, debe salir y obtenerla, esto es análogo a que conduzca al supermercado cada vez que quiera 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, cuando quieras comer, simplemente abres el refrigerador. ”- Adam Zerner

¿Por qué está sucediendo esta tendencia?

Con la creciente popularidad de los marcos de JavaScript, como Angular, React y Vue.js, los desarrolladores ahora pueden entregar páginas web de manera más eficiente y también proporcionar una experiencia de usuario increíblemente rápida para arrancar. Sin embargo, si no se planifica cuidadosamente, este salto en la eficiencia puede tener un precio considerable de SEO en el presente.

Antes de continuar, retrocedamos rápidamente y cubramos la diferencia entre cómo se usó generalmente JavaScript en el pasado y cómo ha cambiado en el presente. Esta progresión se ilustra en el siguiente gráfico de DeepCrawl / Elephate.

Progresión del uso de JavaScript en la web

En el pasado, JS se usaba principalmente para agregar varios niveles de interacción a una página web. Esto se logró haciendo referencia a bibliotecas JS como JQuery. Debido a que JS simplemente estaba manipulando el contenido HTML ya presente en el código fuente, hubo pocos problemas con los motores de búsqueda que descubrieron e indexaron el contenido. Sin embargo, con algunos de los marcos de trabajo de JS y CSR de la actualidad, de repente el código fuente de una página web está prácticamente en blanco y el contenido se representa exclusivamente por la ejecución de JS en el lado del cliente.

Esto complica las cosas para los motores de búsqueda, pero Google es realmente el único motor de búsqueda hoy en día que incluso se plantea para manejarlo. Ninguno de los otros motores de búsqueda tiene cerca de las capacidades de renderización JS que actualmente emplea Google. Esto significa que incluso si Google puede indexar su contenido de CSR, es probable que ningún otro motor de búsqueda lo indexe.

¿Cómo maneja Google la representación de JavaScript hoy?

Google ha revelado recientemente su proceso actual de dos ondas para la renderización e indexación de JS en Google I / O.

Proceso de representación de JavaScript de dos ondas de Google

La primera ola solicita el código fuente, rastrea e indexa cualquier HTML y CSS actual, agrega los enlaces actuales a la cola de rastreo y descarga los códigos de respuesta de la página.

  • Sin embargo, en un sitio renderizado del lado del cliente, básicamente no hay nada que Google pueda indexar en el código fuente durante esta primera ola.

La segunda ola puede ocurrir unas horas o incluso unas semanas más tarde, Google vuelve a la página cuando hay recursos adicionales disponibles para procesar e indexar completamente el contenido generado por JS.

  • Esto significa que, como en el caso de SSR, generalmente no hay problema con la demora de representación de Google porque el contenido está todo en el código fuente e indexado durante la primera ola. En CSR, donde el contenido indexable solo se revela en el procesamiento, este retraso considerable puede significar que el contenido no puede indexarse ​​o aparecer en los resultados de búsqueda durante días o incluso semanas.

¿Por qué Google Struggle with JavaScript Rendering?

Puedes preguntarte a ti mismo,

"¿Por qué Google necesita un proceso de dos pasos para representar JavaScript?"

Es importante recordar que renderizar JavaScript a escala requiere muchos recursos. Esto significa un aumento sustancial en el uso de electricidad, la potencia del procesador, la posible reducción de la velocidad de rastreo y más. Esto a su vez se traduce en un costo monetario significativamente mayor.

¿La razón?

JavaScript requiere que el motor de búsqueda dedique más tiempo al renderizado, lo que significa que se gasta electricidad adicional, una mayor demanda de CPU y una disminución drástica del proceso de renderizado estándar. Ahora, imagine cada sitio web en la web usando CSR directo y puede comenzar a ver por qué representar JavaScript a tal escala puede ser problemático para los motores de búsqueda que intentan operar de manera eficiente.

Sin embargo, este trabajo adicional para renderizar JS no es exclusivo de los motores de búsqueda, también puede presenciar los efectos del aumento de la tensión de renderización de JS en sus propios dispositivos:

  • Para las composiciones de usuario (computadoras de escritorio, computadoras portátiles, dispositivos móviles, tabletas, etc.), sus capacidades de CPU pueden diferir enormemente para cada tipo de dispositivo, por ejemplo, la CPU de un dispositivo móvil generalmente tendrá más dificultades con un sitio cargado de JS que con una computadora de escritorio.
  • JavaScript pesado puede consumir una gran cantidad de CPU, memoria e incluso la duración de la batería de un dispositivo. Esto muestra hasta dónde puede llegar el impacto de JavaScript en el rendimiento, desde el robot de Google hasta el dispositivo móvil de un usuario.
  • Como resultado, siempre es una buena idea probar las páginas con la pestaña "Rendimiento" de Chrome Dev Tools para probar el rendimiento del tiempo de ejecución. Aquí puede probar el rendimiento del dispositivo a través de la "limitación" de la red, que ayuda a simular diferentes capacidades de CPU de dispositivos móviles, diferentes velocidades de Internet y qué tan bien se manejan sus páginas con esas especificaciones.

¿Cuáles son las implicaciones SEO de SSR y CSR?

Para la representación del lado del servidor, todo el contenido HTML está presente en el código fuente, lo que significa que el motor de búsqueda puede solicitarlo, rastrearlo e indexarlo de inmediato. Resultando en un tiempo más rápido para aparecer y clasificarse en los resultados de búsqueda.

Para la representación del lado del cliente, el HTML que necesita ser indexado solo se revela cuando el JS se representa completamente en el lado del cliente. Por lo tanto, con el sistema de dos ondas que Google emplea actualmente, puede tomar desde unas pocas horas hasta una semana antes de que el contenido pueda rastrearse, indexarse ​​y comenzar a clasificarse en los resultados de búsqueda.

Este período de tiempo tampoco tiene en cuenta si hay una lógica de priorización en funcionamiento al final de Google. Si es así, en algunos casos podría tomar aún más tiempo.

¿Cual es la solución?

Si bien Google está trabajando actualmente en la actualización de sus capacidades de representación de JavaScript para que se incluyan en futuras versiones de Chrome, esta vaga línea de tiempo no ayuda a los webmasters de hoy que luchan con que su contenido de CSR no se indexe. Esto tampoco tiene en cuenta todos los demás motores de búsqueda que ni siquiera están a la altura de las capacidades actuales de representación JS de Google.

Hay dos soluciones principales para este problema:

1. Representación previa: esencialmente consiste en escuchar y enviar una instantánea HTML pura al bot del motor de búsqueda cuando solicita su página. Esto garantiza que el usuario pueda seguir disfrutando de las velocidades rápidas proporcionadas por CSR, al mismo tiempo que ofrece a los motores de búsqueda el contenido HTML necesario para indexar y clasificar sus páginas.

2. JavaScript isomorfo: recomendado por Google, esta opción consiste en que tanto el cliente como los motores de búsqueda reciban una página previamente representada de contenido HTML indexable en la carga inicial (esencialmente actuando como SSR). Toda la funcionalidad de JS se superpone a esto para proporcionar un rendimiento rápido del lado del cliente. También funciona mejor tanto para usuarios como para bots de motores de búsqueda, sin embargo, hay algunos problemas evidentes con el renderizado isomorfo:

  • La implementación puede ser complicada, y muchos desarrolladores luchan con ella. También puede ser bastante costoso dados los recursos necesarios para implementar con éxito. Se debe realizar una investigación exhaustiva para determinar la mejor manera de realizar SSR con su marco JS. Aquí hay algunos recursos sobre cómo hacer SSR para Angular y React.

Conclusión

Está claro que el uso de JavaScript para mejorar interactivamente, la experiencia del usuario y renderizar páginas web solo está aumentando. Como tal, depende de nosotros, como SEO, comunicar mejor estas consideraciones con nuestros desarrolladores al abordar nuevos proyectos.

Google, y los motores de búsqueda en general, continuarán mejorando su capacidad para renderizar páginas JS a escala. Sin embargo, esto sin duda revelará nuevos obstáculos a superar ya que las técnicas de desarrollo también continúan avanzando. Las ideas cubiertas en este artículo están diseñadas para darle un resumen de alto nivel de JavaScript SEO y las implicaciones que lo generaron. Si desea obtener más información, le sugiero comenzar con este excelente artículo escrito por los expertos en SEO de JavaScript de Elephate.

Otras lecturas

  • https://www.elephate.com/blog/ultimate-guide-javascript-seo/
  • https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4
  • https://speedcurve.com/blog/your-javascript-hurts/
  • https://www.deepcrawl.com/blog/events/webinar-recap-javascript-bartosz-goralewicz/
  • https://www.briggsby.com/auditing-javascript-for-seo
  • https://www.briggsby.com/dealing-with-javascript-for-seo
  • http://www.stateofdigital.com/javascript-seo-crawling-indexing/
  • https://medium.com/@adamzerner/client-side-rendering-vs-server-side-rendering-a32d2cf3bfcc
  • https://medium.freecodecamp.org/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d
  • https://artandlogic.com/2015/05/the-what-and-why-of-javascript-frameworks/