Hola, antes que nada, me gustaría decir que no soy de los que persiguen el SEO o se esfuerzan por adaptarse a las demandas preferencias de Google sobre cómo debe verse y funcionar mi propio sitio. Pero vale la pena saber que Google acaba de enviarme un correo electrónico sobre la necesidad de que mi sitio mejore en su nueva “métrica Core Web Vital” que pronto comenzará a tener un gran peso en sus clasificaciones:
Aquí está el informe sobre Discourse Meta, que es un poco peor que mi propio sitio para INP (372 ms frente a 208 ms):
Dado que Discourse es básicamente una aplicación web Javascript, imagino que no será fácil mejorar esas métricas. Pero, por otro lado, Google parece basar su clasificación en la versión sin Javascript que ven sus rastreadores web, a pesar de afirmar que emulan un teléfono Moto G Power…
…así que realmente no creo ni me importa demasiado lo que determinen sus algoritmos y clasificaciones. Pero vale la pena que los desarrolladores y administradores de sitios estén al tanto.
Hola @rahim123: mejorar INP es una de las motivaciones para cambiar la animación de navegación de página de Discourse de un ‘spinner’ de página completa a un deslizador. Solo implementamos ese cambio en Meta la semana pasada, por lo que es un poco pronto para que el cambio aparezca en los datos de la encuesta de Core Web Vitals de Google.
Pero ten la seguridad de que estamos vigilando los datos y estudiaremos la posibilidad de realizar más ajustes si es necesario.
Muchas gracias por la respuesta. Me alegra saber que estás al tanto de esto.
Usé el probador de URL en vivo de Google https://pagespeed.web.dev, ¿así que eso no debería incluirse ya en la clasificación? Y dado que Google está viendo la versión sin Javascript, no estoy seguro de cómo tiene en cuenta el spinner frente al deslizador. ¿No tiene INP que ver con la navegación de una página a otra dentro del mismo sitio web? En ese caso, no entiendo realmente cómo mide esa métrica para una URL única. Disculpe mi ignorancia, estoy lejos de ser un experto en estas minucias relacionadas con la arquitectura de páginas y los últimos caprichos de Google.
Sí, ‘pagespeed insights’ y el rastreador de búsqueda de Google obtienen la versión básica de HTML de Discourse. Así que, desafortunadamente, estas herramientas bajo demanda no son muy útiles para nosotros.
Para la clasificación en los motores de búsqueda, Google utiliza datos del mundo real recopilados de usuarios de Chrome en escritorio y Android. Ponen esos datos a disposición del público en Overview of CrUX | Chrome UX Report | Chrome for Developers. Desafortunadamente, hay un retraso de 1 a 2 meses entre la recopilación y la publicación, es por eso que necesitamos esperar un tiempo antes de poder ver el impacto real de este nuevo control deslizante de carga.
Para ver los datos de Google de su propio sitio (o de Meta), vaya aquí e ingrese el dominio: https://developer.chrome.com/docs/crux/dashboard/. Una vez que haya cargado el informe, hay una pestaña para INP en el lado izquierdo. Si mal no recuerdo, Google se enfoca en los datos de ‘móvil’ para la clasificación en los motores de búsqueda, por lo que deberá usar el filtro de dispositivo para profundizar en eso.
El objetivo es obtener al menos el 75% de ‘bueno’, lo que significará que el valor P75 de INP que Google utiliza para la clasificación en los motores de búsqueda es inferior a 200 ms.
Como punto de datos, he estado utilizando exclusivamente el componente temático discourse-loading-slider desde que mi sitio estuvo en línea. Todavía estoy en la zona de “necesita mejora”.
En particular, parece que las páginas a las que acceden principalmente cuentas anónimas provenientes de Google tienen el peor rendimiento. Podría ser específico de mi foro, pero pensé que valía la pena compartirlo.
David, parece una gran mejora percibida, aunque me gusta el antiguo spinner ¿Puedes recordarme cuál es el cambio técnico de alto nivel en el enfoque que facilita esa mejora? ¿Se ha documentado en alguna parte?
Ember desmantela todo el DOM y limpia los componentes de la ruta anterior
El spinner se renderiza en pantalla
Una vez resuelta la solicitud de red, renderiza la nueva ruta en el DOM
Con el slider, omitimos el paso 2. El slider se renderiza inmediatamente, sin necesidad de esperar el costoso proceso de desmantelamiento.
Aquí debería aclarar: la principal motivación para cambiar el valor predeterminado es la mejora de la experiencia de usuario. La mejora de la métrica INP también es buena, pero no es la razón principal del cambio.
Es muy importante tener en cuenta que INP solo afectará el ranking del sitio en marzo de 2024, por lo que las mejoras en las que estamos trabajando hoy tienen tiempo para ser iteradas antes de que comience a afectar a Google.
Para los datos de tu propio dominio, como meta.discourse.org, siempre hay un informe reciente en Google Search Console oculto en ‘Experiencia’ –> ‘Métricas principales web’ –> ‘Móvil (Abrir informe)’ y desplázate hacia abajo hasta ‘Problema de INP: más largo que 200 ms (móvil)’
Editar: Esto está más en la escala de baja probabilidad/alto impacto. INP solo tiene en cuenta p75.
El INP podría verse influenciado por los procedimientos de post-cocción (?) (= mejora de características a través de JS al cargar) del núcleo de Matomo o de plugins que realizan ‘tareas pesadas’ de JS que tienen un ‘tiempo de bloqueo de renderizado’ considerable.
Especialmente cuando el usuario cambia a otro hilo, hay como 10-20 publicaciones que se “cocinan” a la vez.
Aquí siempre es bueno dividir las tareas para las publicaciones individuales en setTimeout() separados para permitir que el navegador pinte entre las tareas individuales y no espere a que termine todo el proceso.
Por ejemplo, algo como esto:
var initializeSliderSlickItem = function (item) {
/* haz la inicialización real aquí */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
Editar: Esto está más en la escala de baja probabilidad/alto impacto. INP solo tiene en cuenta p75.
… y después comienza la cocción. Si el usuario hace clic en algo mientras se está ejecutando una tarea de cocción de Discourse, Google mide INP como el tiempo hasta la siguiente pintura. La siguiente pintura puede aparecer lo antes posible al finalizar la tarea de cocción en ejecución.
“La vida de una interacción. Se produce un retraso de entrada hasta que los controladores de eventos comienzan a ejecutarse, lo que puede ser causado por factores como tareas largas en el hilo principal [por ejemplo, “cocción”]. Luego se ejecutan los controladores de eventos de la interacción y se produce un retraso antes de que se presente el siguiente fotograma”.
Google tiene en cuenta el tiempo de bloqueo de pintura más largo si hay varios eventos de bloqueo “a lo largo del ciclo de vida de toda la página”. Ciclo de vida como:
El hilo URL “A” se abre
se muestra el indicador
se cocinan las publicaciones en el hilo “A”
Clic 1: el usuario hace clic en el enlace al hilo “B”
se muestra el indicador
se está cargando el hilo “B”
se cocinan las publicaciones en el hilo “B”
Clic 2: el usuario hace clic en el enlace al hilo “C” mientras el hilo “B” todavía se está cocinando
la acción de cocción en ejecución en el hilo “B” finaliza (-- cuenta para INP en Clic 2 --)
“INP se calcula cuando el usuario abandona la página, lo que resulta en un único valor que es representativo de la capacidad de respuesta general de la página durante todo el ciclo de vida de la página”.
Menos mal que usar el p75 de la métrica significa que nadie tiene que preocuparse realmente por este escenario que has planteado, y claramente no es representativo de las interacciones normales con Discourse.
¿Puedes recordarme cuál es el cambio técnico de alto nivel en el enfoque que facilita esa mejora? ¿Se ha documentado en alguna parte?
