La guía del vendedor para la representación del lado del servidor
Publicado: 2021-07-26El lenguaje de programación no es un concepto fácil de comprender, especialmente cuando su trabajo de SEO se ha centrado principalmente en el lado no técnico. Pero esto es lo que pasa con el SEO técnico: conocerlo te ayuda a comprender los cambios que tu sitio web necesita hacer para mejorar su clasificación en los motores de búsqueda.
A medida que Google lanzó Core Web Vitals en junio, que es parte de su actualización de Page Experience, todos los especialistas en marketing que no hayan analizado más de cerca el SEO técnico querrán hacerlo ahora.
Y cuando su sitio web se basa en marcos de JavaScript, una parte en la que profundizar es la representación del lado del servidor.
¿Qué es el renderizado del lado del servidor?
La representación del lado del servidor es cuando el proceso de recuperar una página web, capturar el código, mostrar el contenido en una pantalla, todo sucede en el servidor.
En RSS:
- El servidor envía una respuesta lista para ser procesada al navegador;
- El navegador muestra la página, dejándola lista para ser vista y luego el navegador descarga el JavaScript;
- Luego, el navegador ejecuta React cuando la página está lista para ser vista, y
- La página web está entonces lista para la interactividad.
La forma en que sucede todo lo ha convertido en una mejor opción para otros tipos de renderizado: renderizado del lado del cliente (donde el JavaScript es renderizado por el navegador, también conocido como el cliente) y renderizado dinámico (donde los usuarios obtienen contenido renderizado por el servidor del cliente y los motores de búsqueda obtener contenido renderizado del lado del servidor). Incluso Google alienta a los desarrolladores web a elegir la representación del lado del servidor.
¿Por qué?
[Estudio de caso] Administrar el rastreo de bots de Google
Lea el estudio de casoLas ventajas de la RSS
- Ayuda a cargar una página web cuando la conexión a Internet de un usuario es lenta
- Permite la carga rápida de páginas, lo que contribuye a una mejor experiencia del usuario.
- Crea una página HTML completa, lo que evita el lento proceso de obtención de datos.
- Permite cargar páginas, con todos sus elementos, incluso cuando el usuario tiene un dispositivo con poca potencia, como un teléfono inteligente de última generación.
- Contribuye al rendimiento de SEO porque permite que los motores de búsqueda rastreen e indexen páginas con precisión; los bots pueden rastrear páginas fácilmente ya que entienden JS
En general, SSR lo ayuda a atender mejor a los clientes en línea porque los visitantes de su sitio no van a esperar a que las páginas se muestren en sus dispositivos. Las transiciones de página rápidas también aseguran que sus usuarios nunca obtengan una página en blanco, lo que les permite usar su sitio de inmediato.
Dado que Google está ampliando su campaña para ofrecer resultados más precisos con mejoras de algoritmos basadas en la experiencia del usuario, SSR es mejor para su rendimiento de SEO en comparación con la representación cliente-servidor.
Pero como todo lo demás en marketing digital, un enfoque único rara vez funciona para todos. En algunos casos, la representación del lado del servidor podría ser un problema. Como dice Google, SSR "no es una panacea".
Las desventajas de SSR
- Implica mucho trabajo porque está haciendo la misma aplicación dos veces: una vez en el cliente y luego en el servidor.
- Podría retrasar el tiempo hasta el primer byte.
- Podría afectar los enlaces internos o la calidad de la página, ya que no puede generar JS de terceros (por ejemplo, contenido generado por el usuario, reseñas de productos, etc.) o cualquier contenido que no esté en su HTML estático; los bots no podrán verlos
- Las URL que no se actualizan pueden significar que los bots no podrán ver nuevos artículos, lo que puede generar tráfico perdido.
Otro aspecto clave de SSR es que significa costos para el negocio, ya que el procesamiento se realiza en sus servidores. Pero es un costo en el que quizás desee invertir porque este tipo de representación podría contribuir a la optimización de Core Web Vitals.
¿Por qué SSR es relevante para CWV?
Los desarrolladores web y los SEO han estado trabajando durante meses en previsión del lanzamiento de CWV. Alrededor del 60 por ciento de las agencias de SEO encuestadas han estado ocupadas mejorando los puntajes CWV de los clientes. Si está utilizando SSR, es posible que no tenga que hacer un trabajo sustancial para cumplir con las expectativas.
Debido a que SSR facilita la velocidad, su sitio web ya podría funcionar bien con una de las métricas: la pintura con contenido más grande (LCP).
LCP se centra en la experiencia de carga percibida. Mide el tiempo de carga de la página cuando la imagen o el texto más grandes de una página web están visibles en la ventana gráfica. Lo que debe buscar para obtener una buena puntuación es una carga de página del 75 por ciento en <2,5 segundos.
Los principales desafíos para obtener un buen LCP son JS y CSS que bloquean el renderizado; tiempos de carga de recursos lentos, respuesta lenta del servidor y representación del lado del cliente.
Un cambio a SSR es solo una solución para mejorar la puntuación de LCP porque es posible que su problema no se limite a CSR. Querrá trabajar con sus desarrolladores web para identificar primero qué está causando que su LCP se retrase.
Si la fuente de la página revela un código que no tiene sentido (y su desarrollador se lo dirá), entonces el problema puede ser CSR. Si su desarrollador descubre que TTFB es deficiente, es posible que esté lidiando con un tiempo de respuesta lento del servidor.
Las otras métricas de CWV son:
- First Input Delay, que se centra en la capacidad de respuesta, y
- Cambio de diseño acumulativo, que se centra en la estabilidad visual.
Ambos no son relevantes para SSR, por lo que es posible que desee esforzarse más en estas métricas, ya que SSR se ocupa en parte del LCP.
Cómo saber si SSR está renderizando bien las páginas web
La mejor manera de saber si SSR está procesando correctamente sus páginas sería usar herramientas. Uno de los cuales es la prueba de compatibilidad móvil. Es una herramienta que le brinda una instantánea de cómo se verían sus páginas web para los robots de Google y le muestra los errores durante el procesamiento, si los hay.
Google Search Console también tiene una herramienta de inspección de URL que le permite ver si el motor de búsqueda está procesando sus páginas. Úselo para verificar si falta contenido o cualquier error relacionado con JavaScript o CSS bloqueado.
También puede ir a View Render Source, que es una extensión gratuita de Chrome. Le dirá cómo el navegador representa una página desde su HTML original a un DOM en funcionamiento. La extensión ilustrará la diferencia entre una versión sin formato y renderizada, con aspectos destacados de cómo el JS modificó las páginas en el momento de la renderización.
Otra extensión de Chrome para probar es SiteCrawler. El rastreador compatible con JS rastrea mapas de sitios, enlaces e imágenes y compara páginas solo HTML y páginas habilitadas para JS.
La recapitulación
Gran parte del trabajo de SEO implica la optimización de páginas que ya han sido "entregadas" al cliente o al navegador. Pero cuando examina cómo esas páginas "llegan" al cliente y cómo puede mejorar cómo sucede eso, los usuarios lo pasan mejor en su sitio web.
Los bots rastrean tus páginas correctamente. Tus páginas se indexan. Su sitio tiene una mejor clasificación en los motores de búsqueda.
Las actualizaciones del motor de búsqueda junto con los cambios en el comportamiento del consumidor también requieren cambios en su sitio web. Con el próximo lanzamiento de CWV, ahora sería un buen momento para analizar SSR, un aspecto técnico que afectaría sus esfuerzos de SEO.