Je creusais nos résultats Google Search plus tôt aujourd’hui et nous avons également constaté une baisse significative du trafic provenant des résultats de recherche vers notre instance Discourse (discourse.julialang.org) après le 4 mai (environ 30 %). Je ne l’avais pas remarqué jusqu’à présent, car Discourse ne représente qu’environ la moitié de nos pages vues et le reste de notre site a enregistré une augmentation du trafic grâce à cette mise à jour, si bien que l’effet global était légèrement négatif dans l’ensemble. Cependant, cela devient très évident lorsqu’on sépare Discourse du reste du site sur le même domaine. Le trafic remonte lentement, mais à peu près au même rythme de croissance que le reste du site. Y a-t-il quelque chose qui puisse être fait concernant le problème de LCP ? Cela semble être un bon candidat pour ce qui est pénalisé par Google (et je vois également des dizaines de milliers de plaintes concernant le LCP dans notre Search Console). Les métriques de Google indiquent un LCP mobile d’environ 3 secondes pour de nombreuses pages de notre instance Discourse, ce qui semble assez élevé. Cela semble être un problème universel de Discourse. Par exemple, si j’exécute un rapport sur ce fil lui-même, j’obtiens 3,3 s pour le LCP. Malheureusement, je ne suis pas développeur web, je n’ai donc aucune suggestion concrète, mais j’espère que quelqu’un qui en sait plus à ce sujet pourra proposer quelque chose. Ce serait vraiment bien de récupérer ces 30 % de trafic 
.
Voici notre graphique des impressions de recherche avec un lissage hebdomadaire, séparé entre Discourse et le reste du domaine (que j’imagine avoir la même note de confiance à l’échelle du domaine). La mise à jour de mai est très visible. Ironiquement, nous avons connu la même semaine une augmentation de trafic sans rapport pour le reste du site, mais je dirais que le comportement global se traduit par une baisse notable des impressions pour Discourse et des impressions globalement stables pour le reste du site (en ignorant la hausse de trafic sans rapport).
C’est exactement ce que je dénonçais depuis des mois, mais les administrateurs ne le prennent pas au sérieux @Keno
Nous avons également commencé à expérimenter avec Vue.js pour servir une partie de notre contenu via Nuxt afin d’améliorer les performances de pré-rendu de Discourse. Et nous constatons un effet : la mise à jour a été publiée il y a moins d’un mois, et depuis 2 ou 3 jours, nos impressions ont doublé, revenant exactement au niveau d’avant la mise à jour de mai.
Je ne sais pas si c’est une coïncidence ou non, mais cela pourrait être lié au LCP. Je continuerai à surveiller la situation pendant encore quelques semaines avant de tirer des conclusions.
Après avoir lu cet article de blog, c’est… un conseil ultra-générique. On peut essentiellement le résumer par : « proposez du contenu de qualité ». Je ne suis même pas sûr de savoir ce que nous pourrions spécifiquement modifier dans Discourse en nous basant sur cet article de blog ? 
Je ne sais pas si cela concerne uniquement la qualité du contenu, cela pourrait sérieusement être lié au temps LCP élevé, ce que je suppose peut être corrigé dans Ember, mais je ne suis vraiment pas sûr, j’expérimente encore d’autres solutions pour voir…
Je pense que vous vous concentrez un peu trop sur une seule métrique ici. Vous vous y intéressez davantage que Google lui-même.
Ils ont publié des informations sur le LCP le 28 mai et ont indiqué : « Nous fournirons un préavis de six mois avant de mettre en œuvre ces modifications. » Ce préavis n’a même pas encore été donné aujourd’hui.
Comme je l’ai dit, je n’ai pas de preuve, et je ne me concentre pas là-dessus. Je continue à expérimenter d’autres choses. Si je constate une augmentation des impressions pour revenir à ce qu’elles étaient, cela commencera dès hier. Je vais surveiller la situation pour voir comment cela évolue au cours des prochaines semaines.
Oui, je ne sais pas si le LCP est en cause, mais c’est le seul élément qui ressort dans la Search Console, qui signale environ 20 000 erreurs pour des pages avec un LCP élevé. Indépendamment de tout impact SEO, améliorer le temps de chargement du LCP semble être un objectif valable. Bien sûr, on peut se demander dans quelle mesure les métriques de Google reflètent la réalité, mais si c’est le cas, un temps de chargement initial de 5 secondes est assez long et il doit bien y avoir un moyen de faire mieux. En particulier pour le cas d’utilisation d’un utilisateur déconnecté arrivant directement depuis Google, il semble que la diffusion de pages pré-rendues via le CDN pourrait être très utile.
Cela signale le LCP, mais je pense que le problème concerne le FCP… remarquez les temps identiques
Le premier chargement sur Discourse est plus lent que les chargements suivants, car vous chargez l’application et pas seulement cette première page. Je pense donc qu’il est beaucoup plus facile à dire qu’à faire de réduire le temps de chargement initial pour atteindre le niveau « bon » de Google (< 1 s pour le FCP) sur mobile.
Je pense que vous vous concentrez trop sur les facteurs « techniques » et concrets. Ce que Google ne vous dira pas, c’est qu’ils mesurent également la « performance perçue » des sites web.
Discourse a peut-être le potentiel d’améliorer la « performance perçue », et il devrait le faire.
https://thepathforward.io/web-performance-how-to-affect-perceived-performance/
Il existe de nombreuses façons de le faire, par exemple le pré-rendu de squelettes avant que l’application complète ne soit chargée.
En gros, tout ce qui s’affiche avant le chargement complet de l’application contribue à améliorer la performance perçue. Même le simple rendu de l’en-tête (sans contenu, juste la bonne couleur) et de l’arrière-plan avec le spinner de chargement de la page avant que l’application complète ne soit disponible aiderait lors de la première visualisation de la page. Tout ce qui se construit par étapes permet à l’utilisateur de savoir… qu’il se passe quelque chose, même sur un appareil lent.
Par exemple, pour Meta, quelque chose comme cela pourrait/devrait être rendu instantanément (cela pourrait être fait avec un simple CSS critique) avant que l’application complète ne soit disponible pour le navigateur :
Il existe des centaines d’articles sur l’amélioration de la performance perçue des applications web uniques. Peut-être quelque chose à examiner pour l’équipe @team ?
Une page de « chargement » peut être implémentée dans un composant de thème, si vous le souhaitez. Pourquoi ne pas essayer et nous dire si cela fait une différence pour votre site ?
Je ne pense pas que le résultat souhaité soit possible avec un simple composant de thème. Pour cela, il faut un bloc CSS critique en ligne dans l’en-tête, placé avant tout autre script et balise méta CSS. De plus, le n’est rendu qu’une fois l’application entièrement chargée. Je ne vois pas comment un composant de thème pourrait permettre d’atteindre les résultats souhaités, par exemple inclure un bloc CSS critique dans l’en-tête et faire en sorte qu’au moins certaines
Il y a ceci, qui ajoute un chargeur légèrement plus tôt…
Avez-vous une source sur l’impact perçu sur le classement dans les résultats de recherche, ou faites-vous référence au FCP/LCP ? Le FCP et le LCP sont des concepts spécifiques avec des exigences techniques, même s’ils sont basés sur la perception. Notez également que le FCP ne fait pas partie des « Core Web Vitals » de Google (mais le LCP, si).
Voici quelques détails supplémentaires depuis Largest Contentful Paint (LCP) | Articles | web.dev :
Tel que spécifié actuellement dans l’API Largest Contentful Paint, les types d’éléments pris en compte pour le Largest Contentful Paint sont :
- Les éléments
<img>- Les éléments
<image>à l’intérieur d’un élément<svg>- Les éléments
<video>(l’image d’affichage est utilisée)- Un élément avec une image de fond chargée via la fonction
url()(par opposition à un dégradé CSS)- Des éléments au niveau du bloc contenant des nœuds de texte ou d’autres enfants d’éléments de texte au niveau en ligne.
Si une page supprime un élément du DOM, cet élément ne sera plus pris en compte. De même, si la ressource d’image associée à un élément change (par exemple, en modifiant
img.srcvia JavaScript), alors cet élément cessera d’être pris en compte jusqu’à ce que la nouvelle image soit chargée.
Ces exigences rendent la chose un peu difficile ; peut-être qu’un élément de chargement avec une grande image ou du texte pourrait fonctionner si, au lieu de le supprimer du DOM, vous le cachez d’une autre manière ? Le chargeur ci-dessus utilise z-index pour se cacher, donc cela pourrait fonctionner… mais le chargeur seul ne suffit pas car ce n’est pas une image ni du texte (c’est du CSS).
Je suis d’accord pour dire qu’un certain type de chargeur serait bénéfique pour les utilisateurs sur des connexions lentes, mais il y a des obstacles spécifiques à franchir pour Google (et nous ne savons pas si cela résoudrait le problème soulevé par l’auteur du sujet original).
Cela nécessiterait une réécriture complète de Discourse de bas en haut, donc je ne vous conseille pas de trop y compter.
J’ai examiné ce composant, mais je ne pense pas qu’il fasse une grande différence, car il se charge bien trop tard, c’est-à-dire lorsque la majeure partie de l’application est déjà démarrée. Google ne divulgue pas exactement ce qu’il prend en compte et autres. Outre le contenu, l’expérience utilisateur subjective est certainement quelque chose qu’ils mesurent, même indirectement, par exemple en cas de retour sur leur moteur de recherche. Un temps de chargement (perçu) long entraîne un taux de rebond plus élevé dès la première visite. De plus, même si cela n’est pas à 200 % pertinent pour le référencement selon ce que Google déclare officiellement, cela reste pertinent d’un point de vue expérience utilisateur et trafic. En effet, un utilisateur rebondira si les performances perçues lors du premier chargement de la page ne sont pas suffisantes.
Je comprends tout à fait cela. Et je dois admettre que je ne comprends pas encore entièrement le processus de rendu de l’application.
Vraiment, si vous voulez gagner sur cette métrique, allez vers un site statique pré-généré, comme tout le système Google AMP.
Car vous perdrez toujours face aux sites qui ont des pages statiques.
Vous me parlez ? Nonnn, je suis super content de Discourse 
Et une bonne UX ne se résume pas au premier chargement de page. Vous pouvez peut-être perdre quelques points au chargement initial, mais une fois l’application chargée, les utilisateurs restent plus longtemps et reviennent plus souvent, par rapport à des pages statiques ennuyeuses. Et je suis sûr que Google en tient également compte d’une manière ou d’une autre.
D’ailleurs, depuis que nous sommes passés à Discourse, aucun utilisateur ne s’est plaint de la vitesse. Et notre trafic de recherche augmente par rapport à notre page Drupal ultra-optimisée, avec un temps de chargement initial ultra-rapide grâce à la mise en cache HTML complète via Fastly et au CSS critique.
@codinghorror Salut les gars, j’ai effectué quelques tests avec deux domaines que je possède,
Les deux ont été touchés par la mise à jour du 4 mai :
1er cas d’étude : Se concentrer exclusivement sur la qualité du contenu (comme beaucoup le suggéraient plus haut)
Sur le premier, je me suis concentré sur l’amélioration du contenu, des mots-clés, la suppression de tous les mauvais liens, l’inter-lien, l’ajout de nouveau contenu de qualité avec beaucoup de potentiel… etc… etc
Comme vous pouvez le voir ci-dessus, tous les efforts ont été vains. Même si les nouveaux articles ont bien été indexés, que le contenu mince a été supprimé et que les anciens articles ont été améliorés, on ne voit presque aucune amélioration. C’est comme si Google indexait le site suffisamment bien pour recevoir un peu de trafic, mais pas autant !
2e cas d’étude : Migration vers Vue+Nuxt (amélioration légère de la structure + LCP et vitesse de rendu)
Sur le deuxième site, j’ai simplement déplacé certaines pages vers notre propre application Vue+Nuxt personnalisée, qui sert le même contenu avec des changements de structure minimes ou nuls via l’API. Aucun autre effort d’amélioration n’a été fait (même si, dans ce cas, déplacer la communauté vers une autre communauté, quelque chose en .com, et servir le contenu sur le site principal aurait nui davantage qu’aidé, ce qui a été le cas pendant une courte période).
Je ne suis pas sûr de ce que l’on peut conclure de ce qui précède. Je continuerai à tester et à observer, mais ce pic soudain est certainement intéressant. D’ailleurs, j’ai vérifié avant/après mai et après ce récent pic, et j’ai remarqué que dans tous ces cas, de nombreux articles ont perdu des impressions, puis soudainement, presque exactement les mêmes articles ont regagné le même nombre d’impressions. Ce n’est donc pas un ou deux articles/pages qui ont été touchés, mais quelque chose qui pousse Google à pénaliser l’ensemble du site, puis à laisser cette pénalité sur l’ensemble du site, indépendamment des efforts déployés pour améliorer la qualité du contenu.
J’espère que tout cela est clair. N’hésitez pas à me poser des questions si nécessaire,
Salutations !
Si je ne m’abuse, Discourse tente de servir une version statique de ses pages aux robots d’indexation, n’est-ce pas ? Serait-il possible de fournir cette version statique à tous les utilisateurs non connectés ? Ces pénalités LCP suggèrent que Google voit la version non statique de notre forum.
Nous enquêtons sur ce problème par intermittence depuis des mois, y compris en engageant des consultants externes, et tout indique que notre forum est lourdement pénalisé par Google pour des violations LCP suite à la mise à jour du 4 mai.