Hoy por la mañana estaba revisando nuestros resultados en Google Search y también nosotros notamos una caída significativa en el tráfico desde los resultados de búsqueda hacia nuestra instancia de Discourse (discourse.julialang.org) después del 4 de mayo (aproximadamente un 30%). No me di cuenta hasta ahora, porque Discourse representa solo alrededor de la mitad de nuestras visitas a páginas y el resto de nuestro sitio vio un aumento en el tráfico gracias a esta actualización, por lo que el efecto general fue ligeramente negativo en conjunto. Sin embargo, se vuelve muy evidente al separar el tráfico de Discourse del que no es de Discourse en el mismo dominio. Está subiendo lentamente, pero al mismo ritmo de crecimiento que el resto del sitio. ¿Hay algo que se pueda hacer respecto al problema del LCP? Eso parece un buen candidato para lo que está siendo penalizado por Google (y también veo decenas de miles de quejas sobre LCP en nuestra Search Console). Las métricas de Google reportan un LCP móvil de aproximadamente 3 segundos para muchas de nuestras páginas de Discourse, lo cual parece bastante alto. Eso parece ser un problema universal en Discourse. Por ejemplo, si ejecuto un informe sobre este mismo hilo, obtengo un LCP de 3,3 segundos. Lamentablemente, no soy desarrollador web, por lo que no tengo sugerencias concretas, pero espero que alguien que sepa más al respecto pueda proponer algo. Sería realmente genial recuperar ese 30% de tráfico 
.
Aquí está nuestro gráfico de impresiones de búsqueda con suavizado semanal, desglosado entre Discourse y el resto del dominio (que, asumo, tendría la misma calificación de confianza a nivel de dominio). La actualización de mayo es bastante notable. Irónicamente, tuvimos un aumento de tráfico no relacionado la misma semana para el resto del sitio, pero diría que el comportamiento general muestra una caída notable en las impresiones de Discourse y impresiones mayormente estables (ignorando el aumento de tráfico no relacionado) para el resto del sitio.
Eso es exactamente de lo que he estado quejándome durante meses, pero los administradores no lo están tomando en serio @Keno
También empezamos a experimentar con Vue.js para servir parte de nuestro contenido a través de Nuxt y mejorar el rendimiento de la pre-renderización en Discourse. Podemos ver los resultados: la actualización se publicó hace menos de un mes y, en los últimos 2-3 días, nuestras impresiones se han duplicado, volviendo exactamente a lo que eran antes de la actualización de mayo.
No sé si es una coincidencia o no, pero quizás tenga algo que ver con LCP. Seguiré monitoreando durante unas semanas más antes de sacar conclusiones.
Después de leer esta entrada del blog, esto es… un consejo súper genérico. Básicamente se puede resumir como “ten contenido de calidad”. Ni siquiera estoy seguro de qué podríamos cambiar específicamente en Discourse basándonos en esta entrada del blog. 
No estoy seguro de si se trata solo de la calidad del contenido; podría estar relacionado seriamente con el alto tiempo de LCP, lo cual supongo que se puede solucionar en Ember. Pero, en realidad, no estoy seguro; todavía estoy experimentando con otras soluciones para ver…
Creo que te estás centrando un poco demasiado en una sola métrica aquí. Te estás enfocando más en ella de lo que lo hace Google.
Publicaron sobre LCP el 28 de mayo y dijeron “Proporcionaremos un aviso de 6 meses antes de implementar estos cambios”. Ese aviso aún no ha sido proporcionado hoy.
Bueno, como dije, no tengo pruebas, ni me estoy centrando en ello. Todavía estoy experimentando con otras cosas y viendo un repunte en las impresiones hasta volver a lo que era. Empezando desde ayer, estaré pendiente para ver cómo evoluciona en las próximas semanas.
Sí, no sé si el LCP es en absoluto el culpable, pero es lo que más destaca en la Consola de Búsqueda, que para nosotros marca alrededor de 20.000 errores en páginas con un LCP elevado. Independientemente de cualquier impacto en el SEO, mejorar el tiempo de LCP parece un objetivo valioso. Por supuesto, cabe preguntarse en qué medida las métricas de Google reflejan la realidad, pero si lo hacen, entonces un tiempo de carga inicial de 5 segundos es bastante alto y seguro que hay una manera de hacerlo mejor. Especialmente para el caso de uso de usuarios desconectados que llegan directamente desde Google, servir páginas pre-renderizadas desde la CDN podría resultar muy útil.
Está señalando el LCP, pero creo que el problema sería el FCP… fíjate en los tiempos idénticos
La primera carga en Discourse es más lenta que las cargas posteriores porque estás cargando la aplicación y no solo esa primera página, así que creo que es una situación mucho más fácil de decir que de hacer reducir el tiempo de carga inicial para alcanzar el nivel “bueno” de Google (< 1s para FCP) en móviles.
Creo que ustedes se concentran demasiado en los factores duros “técnicos”. Lo que Google no les dirá es que en realidad también miden el rendimiento “percibido” de los sitios web.
Discourse tiene potencial para mejorar el “rendimiento percibido”, y debería hacerlo.
https://thepathforward.io/web-performance-how-to-affect-perceived-performance/
Hay muchas formas de hacerlo, por ejemplo, el prerenderizado de esqueletos antes de que se haya cargado la aplicación completa.
Básicamente, cualquier cosa que aparezca antes de que la aplicación esté completamente cargada ayuda a mejorar el rendimiento percibido. Incluso simplemente renderizar el encabezado (sin contenido, solo el color correcto) y el fondo con el spinner de carga de la página antes de que la aplicación completa esté disponible ayudaría en la visualización inicial de la página. Cualquier cosa que se construya por etapas para que el usuario sepa… que algo está ocurriendo, incluso en un dispositivo lento.
Por ejemplo, para Meta, algo como esto podría/debería renderizarse instantáneamente (podría hacerse con un CSS crítico simple) antes de que la aplicación completa esté disponible para el navegador:
Hay cientos de artículos para mejorar el rendimiento percibido de aplicaciones web individuales. Quizás algo para que el @team lo investigue.
Se puede implementar una página de “cargando” mediante un componente de tema, si lo deseas. ¿Quizás podrías probarlo y comentarnos si marca alguna diferencia en tu sitio?
No creo que el resultado deseado sea posible con un componente de tema sencillo. Para esto, necesito tener un bloque crítico de CSS en línea en el encabezado, que se coloque antes de cualquier otro script y metatag de CSS. Además, el solo se renderiza una vez que la aplicación completa se ha cargado. No veo cómo se puede utilizar un componente de tema para lograr los resultados deseados, como tener un bloque de CSS crítico en el encabezado y al menos algunos
Existe esto, que añade un loader ligeramente antes…
¿Tienes alguna fuente sobre el impacto percibido en el rendimiento que afecta al posicionamiento en los resultados de búsqueda, o te refieres a FCP/LCP? FCP y LCP son métricas específicas con requisitos técnicos, a pesar de basarse en conceptos de percepción. Ten en cuenta además que FCP no forma parte de las “Core Web Vitals” de Google (aunque LCP sí lo es).
Algunos detalles más de https://web.dev/lcp/:
Según la especificación actual de la API Largest Contentful Paint, los tipos de elementos considerados para Largest Contentful Paint son:
- Elementos
<img>- Elementos
<image>dentro de un elemento<svg>- Elementos
<video>(se utiliza la imagen de portada)- Un elemento con una imagen de fondo cargada mediante la función
url()(en contraposición a un gradiente CSS)- Elementos de bloque que contienen nodos de texto u otros elementos hijos de texto a nivel de línea.
Si una página elimina un elemento del DOM, ese elemento ya no se tendrá en cuenta. Del mismo modo, si cambia el recurso de imagen asociado a un elemento (por ejemplo, cambiando
img.srcmediante JavaScript), ese elemento dejará de considerarse hasta que se cargue la nueva imagen.
Estos requisitos lo hacen un poco complicado; quizás un elemento de carga con una imagen o texto grande podría funcionar si, en lugar de eliminarlo del DOM, lo ocultas de otra manera. El spinner anterior utiliza z-index para ocultarse, así que tal vez eso podría funcionar… pero el spinner por sí solo no es suficiente porque no es una imagen ni texto (es CSS).
Estoy de acuerdo en que algún tipo de loader sería bueno para los usuarios con conexiones lentas, pero hay requisitos específicos que cumplir para Google (y no sabemos si resolvería el problema planteado por el OP).
Requeriría una reescritura de Discourse de abajo hacia arriba, así que no espere que esto suceda pronto.
He revisado este componente, pero creo que no marca una gran diferencia, ya que se carga demasiado tarde, es decir, cuando la mayor parte de la aplicación ya ha arrancado. Google no revela exactamente qué factores tienen en cuenta y demás. Además del contenido, la experiencia de usuario (UX) subjetiva sin duda es algo que miden, incluso de forma indirecta, por ejemplo, mediante el rebote hacia su motor de búsqueda. Una carga (percibida) larga implica una tasa de rebote más alta en la primera visita. Por otro lado, aunque esto no sea 200 % relevante para el SEO según lo que Google declara oficialmente, sigue siendo relevante desde la perspectiva de la UX y el tráfico. Esto se debe a que un usuario abandonará si el rendimiento percibido en la carga inicial de la página no es lo suficientemente bueno.
Lo entiendo perfectamente. Y tengo que admitir que aún no entiendo del todo el proceso de renderizado de la aplicación.
Realmente, si quieres ganar en esta métrica, ve a un sitio estático pregenerado, como todo lo del proyecto Google Amp.
Porque siempre perderás frente a sitios que tienen páginas estáticas.
¿Me estás hablando? ¡Noooo, estoy súper feliz con Discourse 
! Y una buena experiencia de usuario no se trata solo de la primera carga de página; quizás pierdas algo en la carga inicial, pero una vez que la aplicación está cargada, los usuarios definitivamente se quedan más tiempo y vuelven con más frecuencia, en comparación con las páginas estáticas aburridas. Y estoy seguro de que Google también lo tiene en cuenta de alguna manera.
Además, desde que cambiamos a Discourse, ningún usuario se ha quejado de la velocidad. Y nuestro tráfico de búsqueda está aumentando en comparación con nuestra página Drupal súper optimizada, con un tiempo de carga de primera página a la velocidad de la luz mediante caché HTML completa a través de Fastly y CSS crítico.
@codinghorror Hola, chicos. Realicé algunas pruebas con dos dominios que tengo:
Ambos se vieron afectados por la actualización del 4 de mayo:
Caso de estudio 1: Enfocarse exclusivamente en la calidad del contenido (como muchos de arriba sugerían)
En el primero, me concentré en mejorar el contenido, las palabras clave, eliminar cualquier enlace dañino, hacer interconexiones internas, agregar nuevo contenido de calidad con mucho potencial, etc., etc.
Como pueden ver arriba, todo el esfuerzo fue en vano. Aunque los nuevos artículos fueron indexados correctamente, el contenido de baja calidad fue eliminado y los artículos antiguos mejorados, apenas se nota ninguna mejora. Es como si Google indexara el sitio web lo suficientemente bien para recibir un poco de tráfico, pero no lo suficiente.
Caso de estudio 2: Migrar a Vue+Nuxt (mejorar ligeramente la estructura + LCP y velocidad de renderizado)
En el segundo sitio web, solo trasladé algunas páginas a nuestra propia aplicación personalizada de Vue+Nuxt, que sirve el mismo contenido con cambios mínimos o nulos en la estructura a través de la API. No se realizaron otros esfuerzos de mejora (aunque en este caso, en realidad, mover la comunidad a un dominio .com propio y servir el contenido en el sitio web principal habría perjudicado más que beneficiado, lo cual ocurrió durante un breve período).
No estoy seguro de qué se puede concluir de lo anterior, pero seguiré probando y viendo. Ciertamente, ese pico repentino es interesante. Por cierto, verifiqué antes y después de mayo, y después de ese pico reciente, y noté que en todos esos casos muchos artículos perdieron impresiones y, de repente, casi esos mismos artículos recuperaron la misma cantidad de impresiones. Por lo tanto, no fue uno o dos artículos/páginas los afectados, sino algo que hizo que Google penalizara todo el sitio web y luego mantuviera la penalización en todo el sitio, independientemente de los esfuerzos realizados para mejorar la calidad del contenido.
Espero que lo anterior tenga sentido. Si tienen alguna pregunta, no duden en decírmelo.
¡Saludos!
Si no estoy equivocado, Discourse intenta servir una versión estática de sus páginas a los rastreadores, ¿correcto? ¿Sería posible servir esta versión estática a todos los usuarios que no han iniciado sesión? Estas penalizaciones por LCP sugieren que Google está viendo la versión no estática de nuestro foro.
Hemos estado investigando esto de forma intermitente durante meses, incluyendo la contratación de consultores externos, y todo sigue apuntando a que nuestro foro está siendo fuertemente penalizado por Google por violaciones de LCP después de la actualización del 4 de mayo.