La prueba de SEO de Google muestra lo que sucede en una ventana de renderizado de 5 segundos

- Advertisement -spot_img

Una creencia común entre muchos SEO es que el servicio de renderizado web de Google tiene una ventana de renderizado de cinco segundos y que cualquier cosa que suceda después de esa ventana de cinco segundos no se incluirá en la versión de la página que indexa Google.

La idea comenzó con algo que Martin Splitt de Google dijo al menos en dos ocasiones y finalmente fue ampliamente aceptado como cierto. Dave Smart de Tame the Bots probó la teoría y descubrió no sólo que la ventana de cinco segundos no es cierta, sino también que el servicio de renderizado web de Google puede pausar y reiniciar el reloj de renderizado.

Entonces, ¿quién tiene razón, los SEO que basan sus opiniones en lo que dijo Martin Splitt, o Dave Smart, un SEO del Reino Unido? Mi dinero está en Dave Smart, y pronto entenderás por qué.

Lo que dicen los SEO

La idea promovida en muchos blogs de SEO es que hay una ventana de cinco segundos que es la cantidad de tiempo que el servicio de renderizado web (WRS) de Google espera antes de capturar el modelo de objetos de documento (DOM) renderizado de una página web.

El servicio de renderizado web de Google es una colección de servicios que hacen seis cosas:

  1. Recibe el HTML que rastreó el robot de Google.
  2. Obtiene los recursos de la página web, como CSS, JavaScript e imágenes.
  3. Carga la página en un navegador Chromium sin cabeza.
  4. A continuación ejecuta el JavaScript de la página.
  5. Y luego produce una instantánea del DOM de la página.
  6. En este punto, pasa esa instantánea DOM al sistema de indexación de Google.

Los SEO tienen dos variaciones de la teoría de la ventana de cinco segundos

1. Algunos SEO dicen que el proceso de renderizado dentro del servicio de renderizado web de Google tiene aproximadamente cinco segundos para producir el DOM que Google captura. Dicen que hay un período de cinco segundos durante el cual se carga la página, se ejecuta JavaScript y Google captura una instantánea del DOM renderizado para indexar.

Leer  Meta lanza ventanas emergentes en las tiendas Best Buy

2. La segunda variación es que el contenido importante debe aparecer en el DOM en cinco segundos porque es entonces cuando se espera que Google capture la instantánea del DOM.

Algunos SEO incluso afirman haber realizado una prueba y dicen haber confirmado que efectivamente existe una ventana de cinco segundos.

¿Qué dijo Martin Splitt?

Martin Splitt realizó al menos dos presentaciones de video en los últimos siete años en las que presentó al mundo del SEO el concepto de una ventana de renderizado de cinco segundos.

Esto es lo que Splitt realmente dijo sobre esa ventana de cinco segundos (aproximadamente en el minuto 18 del video):

“Entonces, ¿qué necesitas saber, qué necesitas sacar de esto?

Todos los sitios web se procesan sin importar si contienen JavaScript o no.

Lo que vemos después del renderizado es la instantánea del DOM que se incluirá en la indexación. Eso es lo que te importa.

Ni la captura de pantalla, ni ningún caché extraño en los resultados de la búsqueda. No uses eso.

No utilice Me gusta ver fuente. Ver fuente no le brinda información DOM. Utilice las herramientas de prueba que le proporcionamos. De hecho, te están dando lo que salió del renderizado.

En promedio, el procesamiento de una página se puso en cola durante cinco segundos.

Eso significa que antes de que uno de estos encantadores los recoja, estarán en una mediana de cinco segundos allí. El percentil 90 son unos pocos minutos. Entonces estamos hablando de minutos, no de semanas o meses.

El renderizado almacena en caché los recursos de forma agresiva, por lo que no necesita preocuparse demasiado por su presupuesto de rastreo con respecto al renderizado. No hace mucha diferencia.

Y si quieres probar tus cosas, no hagas cosas raras. Simplemente use la URL de inspección de Google Search Console. Te muestra lo que sucede en el renderizado, ¿de acuerdo?

No tengas miedo del renderizado o de JavaScript”.

Está claro que Splitt no describe un límite de cinco segundos para el servicio de renderizado web. Describe cuánto tiempo esperan las páginas, en promedio, en la cola de procesamiento antes de que comience el procesamiento. Una vez que un renderizador toma la página, no se dice nada sobre un límite de tiempo para renderizar.

Leer  El SEO ya no es una disciplina única

Está claro que existe una desconexión entre lo que los SEO piensan que dijo Splitt y lo que realmente dijo.

Prueba de servicios de renderizado web de Dave Smart

Dave Smart (perfil de LinkedIn) realizó un experimento para probar la teoría de la ventana de cinco segundos. Creó una página de prueba que retrasó intencionalmente el contenido mientras registraba múltiples mediciones de tiempo para determinar si el Servicio de renderizado web (WRS) de Google realmente dejaba de renderizar después de cinco segundos.

La forma en que funcionó la prueba fue que creó una página de prueba que realizaba solicitudes POST a un script PHP. Ese script PHP retrasó su respuesta aleatoriamente de tres a seis segundos antes de entregar el contenido. Smart utilizó dos de estas llamadas API en la prueba, por lo que juntas podrían tardar entre seis y doce segundos en completarse.

Lo que descubrió la prueba WRS

La prueba de Smart inicialmente consistía en probar la teoría de la ventana de cinco segundos, pero terminó con un segundo hallazgo que fue completamente inesperado.

Al principio, el experimento pareció confirmar la teoría de la ventana de cinco segundos porque el temporizador de JavaScript funcionó durante cinco segundos, dando la impresión de que el servicio de renderizado web de Google tenía un límite de renderizado de cinco segundos.

Él escribió:

“Al observar las capturas de pantalla, se puede ver que el bucle setInterval() se ejecutó durante 5 segundos y actualizó el elemento del título… Entonces, una conclusión racional sería que el WRS tiene un límite de renderizado de 5 segundos, ¿verdad?”

Pero otra medición contradijo esa conclusión. La página también realizó llamadas API del lado del servidor que tardaron entre seis y doce segundos en completarse, pero el servicio de renderizado web de Google aún esperó el contenido retrasado y lo incluyó en el DOM renderizado.

Leer  Marca, supervivencia y el estado de SEO

Smart encontró lo que parecía ser una paradoja, lo que planteó la pregunta: ¿Cómo puede el servicio de renderizado web de Google esperar más de cinco segundos si el cronómetro de JavaScript sólo avanzó cinco segundos?

La respuesta es que el servicio de renderizado web de Google utiliza un reloj virtual en lugar de depender del tiempo transcurrido real. Mientras espera solicitudes de red (como llamadas API del lado del servidor), puede pausar ese reloj virtual, permitiendo que pase más tiempo del mundo real del que informa el temporizador de JavaScript.

Inteligente explicó:

“El WRS mide el tiempo a su manera. En lugar del reloj de hardware, como el que tiene en su computadora o servidor, el WRS usa un reloj virtual que pueden controlar. Esto significa que pueden acelerar, desacelerar o incluso pausar el tiempo para la instancia sin cabeza de Chrome si así lo desean.

¿Cómo sabemos que 5 segundos no es un límite? ¿Recuerdas esas llamadas a la API que se hicieron? Estos se retrasan del lado del servidor, entre 3 y 6 segundos. Por lo tanto, el tiempo total para ambas llamadas a la API podría oscilar entre 6 y 12 segundos, más que el famoso límite de 5 segundos”.

Tenemos una mejor comprensión del renderizado web

La comunidad de SEO le debe a Dave Smart unas palabras de agradecimiento por realizar este inteligente experimento y confirmar que no existe un límite de tiempo de cinco segundos en relación con el servicio de renderizado web de Google. Dado que los comentarios de Martin Splitt también se alinean con los resultados de las pruebas de Smart, creo que podemos cerrar con confianza el libro sobre el mito del límite de renderizado de cinco segundos.

Mira a Martin Splitt aproximadamente en el minuto 18

Imagen destacada de Shutterstock/Cristina Conti

spot_img
spot_img

Artículos relacionados

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Artículos populares