8 800 2563 123

[email protected]

Twitter Facebook-f Google-plus-g Pinterest-p Linkedin-in

Rendu JavaScript et problèmes de référencement en 2020

HomeBlog Rendu JavaScript et problèmes de référencement en 2020
7 mai 2020 by PremiumRéférencement Blog
Rendu JavaScript et problèmes de référencement en 2020


Résumé en 30 secondes:

  • Quiconque travaillant dans le référencement d’entreprise en 2020 aura rencontré ce scénario d’architecture Web avec un client à un moment donné. Des cadres tels que React, Vue et Angular rendent le développement Web plus simple.
  • Il existe des tonnes d’études de cas, mais une entreprise rencontrée par Croud a migré vers un cadre hybride Shopify / JS avec des liens internes et du contenu rendu via JS. Ils ont procédé à une perte de trafic estimée à 8 000 $ par jour au cours des 6 prochains mois… environ 1,5 million $ US.
  • Les lecteurs expérimentés parmi nous commenceront bientôt à sentir qu’ils rencontrent un territoire familier.
  • Anthony Lavall, vice-président des partenariats stratégiques de Croud, discute des cadres JavaScript qui traitent des éléments SEO les plus critiques.

Lors de la gestion de l’équipe SEO à Croud à New York au cours des trois dernières années, 60% de nos clients sont passés par une certaine forme de migration. Un autre ~ 30% est passé de ou vers une SPA (application à page unique) utilisant souvent un cadre AJAX (Javascript asynchrone et XML) à des degrés divers.

Quiconque travaillant dans le référencement d’entreprise en 2020 aura rencontré ce scénario d’architecture Web avec un client à un moment donné. Des cadres tels que React, Vue et Angular rendent le développement Web plus simple. Cela est particulièrement vrai lors de la création d’applications Web dynamiques qui offrent une interactivité relativement rapide des nouvelles requêtes (une fois que les bibliothèques initiales les alimentant ont été chargées – Gmail est un bon exemple) en utilisant la puissance du navigateur moderne pour rendre le code côté client (le JavaScript). Ensuite, en utilisant des travailleurs Web pour offrir une fonctionnalité de demande réseau qui ne nécessite pas un appel URL traditionnel sur serveur.

La fonctionnalité et les capacités de déploiement accrues entraînent un coût – la question des performances SEO. Je doute que toute lecture de SEO soit étrangère à cette question. Cependant, vous pouvez être encore dans le noir concernant une réponse.

Pourquoi est-ce un problème?

Chiffre d’affaires, sous forme de trafic organique perdu via des classements organiques perdus. C’est aussi simple que ça. Les développeurs Web qui ont recommandé des frameworks JavaScript (JS) ne sont généralement pas directement responsables des performances commerciales à long terme. L’une des principales raisons pour lesquelles les SEO existent en 2020 devrait être d’atténuer les erreurs stratégiques qui pourraient en découler. Le trafic organique est souvent considéré comme une donnée et n’est pas considéré comme important (ou contrôlable), et c’est là que des problèmes massifs se produisent. Il y a des tonnes d’études de cas, mais une entreprise que nous avons rencontrée a migré vers un cadre hybride Shopify / JS avec des liens internes et du contenu rendu via JS. Ils ont perdu du trafic estimé à 8 000 $ par jour au cours des 6 prochains mois… environ 1,5 million $ US.

Quel est le problème?

Il y a beaucoup de problèmes. Les SEO essaient déjà de traiter un grand nombre de signaux de l’algorithme commercial le plus investi jamais créé (Google… juste au cas où). L’éloignement d’un site Web traditionnel rendu par serveur (pensez à Wikipedia) à un cadre contemporain est potentiellement criblé de défis SEO. Certains sont:

  • Exploration, rendu et indexation des robots des moteurs de recherche – les robots des moteurs de recherche comme Googlebot ont adapté leur processus d’exploration pour inclure le rendu de JavaScript (à partir de 2010) afin de pouvoir comprendre pleinement le code sur les pages Web AJAX. Nous savons que Google comprend mieux le JavaScript complexe. Les autres robots de recherche peuvent ne pas l’être. Mais ce n’est pas simplement une question de compréhension. L’analyse de l’ensemble du Web n’est pas une tâche simple et même les ressources de Google sont limitées. Ils doivent décider si un site mérite d’être exploré et rendu sur la base d’hypothèses qui ont lieu bien avant que JS ait pu être rencontré et rendu (mesures telles qu’un nombre estimé de pages au total, l’historique du domaine, les données WhoIs, l’autorité de domaine, etc.) .

Processus d’exploration et de rendu de Google – La 2e phase de rendu / d’indexation (annoncée lors de Google I / O 2018)

  • La vitesse – l’un des plus grands obstacles pour les applications AJAX. Google explore les pages Web sans mise en cache, de sorte que ces premières charges lourdes d’applications d’une seule page peuvent être problématiques. La vitesse peut être définie de plusieurs façons, mais dans ce cas, nous parlons du temps nécessaire pour exécuter et afficher de manière critique toutes les ressources sur une page JavaScript lourde par rapport à une page HTML moins gourmande en ressources.
  • Ressources et rendu – avec le code côté serveur traditionnel, le DOM (Document Object Model) est rendu essentiellement une fois que le CSSOM (CSS Object Model) est formé ou pour le dire plus simplement, le DOM ne nécessite pas trop de manipulations supplémentaires après la récupération du code source. Il y a des mises en garde à cela, mais il est sûr de dire que le code côté client (et les multiples bibliothèques / ressources dont le code peut être dérivé) ajoute une complexité accrue au DOM finalisé, ce qui signifie plus de ressources CPU requises par les robots de recherche et les périphériques clients . C’est l’une des raisons les plus importantes pour lesquelles un cadre JS complexe ne serait pas préféré. Cependant, il est si souvent négligé.

Maintenant, tout ce qui précède cette phrase a fait l’hypothèse que ces pages AJAX ont été construites sans aucune considération pour le référencement. C’est un peu injuste pour l’agence de conception Web moderne ou le développeur interne. Il existe généralement un certain type de considération pour atténuer l’impact négatif sur le référencement (nous les examinerons plus en détail). Les lecteurs expérimentés parmi nous vont maintenant commencer à sentir qu’ils rencontrent un territoire familier. Un territoire qui a donné lieu à de nombreuses discussions par e-mail entre le client, les équipes de développement, de conception et de référencement relatives à la question de savoir si ladite migration va ou non classer les classements organiques (malheureusement, c’est souvent le cas).

Le problème est que les solutions pour créer des applications AJAX qui fonctionnent plus comme du HTML basé sur un serveur à des fins de référencement sont elles-mêmes embourbées en conflit; principalement liés à leur efficacité. Comment testons-nous l’efficacité de n’importe quoi pour le référencement? Nous devons déployer et analyser les changements SERP. Et les résultats des migrations vers les frameworks JavaScript sont associés à plusieurs reprises à des baisses de trafic. Jetez un œil aux histoires hebdomadaires qui se déversent dans le « Sites JS dans le groupe de travail de recherche » hébergé par John Mueller si vous voulez une preuve.

Jetons un coup d’œil à certaines des tactiques d’atténuation les plus courantes pour le référencement par rapport à AJAX.

Les différentes solutions pour l’atténuation AJAX SEO

1. JS universel / isomorphe

JavaScript isomorphe, AKA Universal JavaScript, décrit les applications JS qui s’exécutent à la fois sur le client et le serveur, car dans, le client ou le serveur peut exécuter le

Pour réitérer, suite à la demande, le serveur rend le JS et le DOM / CSSOM complet est formé et servi au client. Cela signifie que Googlebot et les utilisateurs ont reçu une version pré-rendue de la page. La différence pour les utilisateurs est que le HTML et le CSS qui viennent d'être servis sont alors rendu pour le remplacer par le JS dynamique afin qu'il puisse se comporter comme le SPA qu'il a toujours été censé être.

Les problèmes avec la création de pages Web / applications isomorphes semblent être juste que… en fait, la construction de la chose n'est pas facile. Il y a une série décente ici de Matheus Marsiglio qui documente son expérience.

2. Rendu dynamique

Le rendu dynamique est un concept plus simple à comprendre; il s'agit du processus de détection de l'agent utilisateur effectuant la demande de serveur et d'acheminement du code de réponse correct en fonction de cette demande provenant d'un bot validé ou d'un utilisateur.

C'est Méthode recommandée par Google de gérer JavaScript pour la recherche. Il est bien illustré ici:

JavaScript - Rendu dynamique de Google

Le processus de rendu dynamique expliqué par Google

La sortie est une itération pré-rendue de votre code pour les robots de recherche et le même AJAX qui aurait toujours été servi aux utilisateurs. Google recommande une solution telle que prerender.io pour y parvenir. Il s'agit d'un service de proxy inverse qui pré-affiche et met en cache vos pages. Il y a cependant quelques pièges avec le rendu dynamique qui doivent être compris:

  • Le camouflage - Dans un World Wide Web dominé principalement par HTML et CSS, le camouflage était un énorme négatif en ce qui concerne Google. Il n'y avait pas de raison de détecter et de diffuser un code différent à Googlebot en dehors de la tentative de recherche de résultats de recherche. Ce n'est pas le cas dans le monde de JavaScript. Le processus de rendu dynamique de Google est une recommandation directe pour le camouflage. Ils disent explicitement: «servez une chose aux utilisateurs et servez-nous une autre». Pourquoi c'est un problème? Google dit, "Tant que votre rendu dynamique produit un contenu similaire, Googlebot ne considérera pas le rendu dynamique comme un camouflage." Mais comment ça similaire? Comment pourrait-il être facile d'injecter plus de contenu à Googlebot que ce qui est montré aux utilisateurs ou d'utiliser JS avec un délai pour supprimer du texte pour les utilisateurs ou manipuler la page d'une autre manière que Googlebot est peu susceptible de voir (car elle est retardée dans le DOM par exemple ).
  • Mise en cache - Pour les sites qui changent fréquemment, comme les grands éditeurs de nouvelles qui exigent que leur contenu soit indexé le plus rapidement possible, une solution de pré-rendu peut tout simplement pas le couper. L'ajout et la modification constants de pages doivent être presque immédiatement pré-rendus afin d'être immédiats et efficaces. le temps de mise en cache minimum sur prerender.io est en jours, pas en minutes.
  • Les cadres varient considérablement - Chaque pile technologique est différente, chaque bibliothèque ajoute une nouvelle complexité, et chaque CMS traitera tout cela différemment. Les solutions de pré-rendu telles que prerender.io ne sont pas une solution unique pour des performances SEO optimales.

3. Les CDN apportent des complexités supplémentaires… (ou tout autre proxy inverse d'ailleurs)

Les réseaux de diffusion de contenu (tels que Cloudflare) peuvent créer des complexités de test supplémentaires en ajoutant une autre couche au réseau proxy inverse. Tester une solution de rendu dynamique peut être difficile car Cloudflare bloque les requêtes Googlebot non validées via recherche DNS inversée. La résolution des problèmes de rendu dynamique prend donc du temps. Il est temps que Googlebot explore à nouveau la page, puis une combinaison du cache de Google et d'une nouvelle Search Console boguée pour être en mesure d'interpréter ces modifications. le outil de test adapté aux mobiles de Google est un bon intervalle décent, mais vous ne pouvez analyser qu'une page à la fois.

Ceci est un champ de mines! Alors, que dois-je faire pour des performances optimales de référencement?

Pensez intelligemment et planifiez efficacement. Heureusement, seule une poignée d'éléments de conception sont essentiels pour le référencement lorsque l'on considère l'arène de la conception Web et beaucoup d'entre eux sont des éléments dans le et / ou métadonnées. Elles sont: