Contes de mise en garde et comment les éviter

J’ai récemment lu l’article fascinant de Ziemek Bucko, File d’attente de rendu : Google a besoin de 9 fois plus de temps pour explorer JS que HTMLsur le blog Onely.

Bucko a décrit un test qu’ils ont effectué montrant des retards importants de la part de Googlebot en suivant les liens dans les pages dépendantes de JavaScript par rapport aux liens en HTML en texte brut.

Bien que ce ne soit pas une bonne idée de se fier à un seul test comme celui-ci, leur expérience correspond à la mienne. J’ai vu et soutenu de nombreux sites Web trop compter sur JavaScript (JS) pour fonctionner correctement. Je suppose que je ne suis pas le seul à cet égard.

Mon expérience est que le contenu uniquement JavaScript peut prendre plus de temps à être indexé par rapport au HTML brut.

Je me souviens de plusieurs cas d’appels téléphoniques et d’e-mails de clients frustrés demandant pourquoi leurs affaires n’apparaissaient pas dans les résultats de recherche.

Dans tous les cas sauf un, le défi semblait être dû au fait que les pages étaient construites sur une plate-forme JS uniquement ou principalement JS.

Avant d’aller plus loin, je tiens à préciser qu’il ne s’agit pas d’un “hit piece” sur JavaScript. JS est un outil précieux.

Comme tout outil, cependant, il est préférable de l’utiliser pour des tâches que d’autres outils ne peuvent pas effectuer. Je ne suis pas contre JS. Je suis contre l’utiliser là où ça n’a pas de sens.

Mais il y a d’autres raisons d’envisager judicieusement utiliser JS au lieu de compter dessus pour tout.

Voici quelques histoires de mon expérience pour illustrer certains d’entre eux.

1. Texte ? Quel texte ?!

Un site que j’ai soutenu a été relancé avec un tout nouveau design sur une plate-forme qui s’appuyait fortement sur JavaScript.

Moins d’une semaine après la mise en ligne du nouveau site, le trafic de recherche organique a chuté à près de zéro, provoquant une panique compréhensible parmi les clients.

Une enquête rapide a révélé qu’en plus du site étant considérablement plus lent (voir les prochains contes), le test de page en direct de Google a montré que les pages étaient vierges.

Mon équipe a fait une évaluation et a supposé qu’il faudrait un certain temps à Google pour afficher les pages. Après 2-3 semaines de plus, cependant, il était évident que quelque chose d’autre se passait.

J’ai rencontré le développeur principal du site pour comprendre ce qui se passait. Dans le cadre de notre conversation, ils ont partagé leur écran pour me montrer ce qui se passait en arrière-plan.

C’est alors que le “ah !” moment frappé. Au fur et à mesure que le développeur parcourait le code ligne par ligne dans sa console, j’ai remarqué que le texte de chaque page se chargeait en dehors de la fenêtre d’affichage à l’aide d’une ligne de CSS, mais était tiré dans le cadre visible par certains JS.

Cela visait à créer un effet d’animation amusant où le contenu du texte “glissait” dans la vue. Cependant, comme la page s’affichait si lentement dans le navigateur, le texte était déjà visible lorsque le contenu de la page a finalement été affiché.

L’effet de glissement réel n’était pas visible pour les utilisateurs. J’ai supposé que Google ne pouvait pas capter l’effet de diapositive et n’a pas vu le contenu.

Une fois cet effet supprimé et le site réexploré, les chiffres du trafic ont commencé à se redresser.

2. C’est juste trop lent

Cela pourrait être plusieurs contes, mais je vais en résumer plusieurs en un. Les plates-formes JS comme AngularJS et React sont fantastiques pour développer rapidement des applications, y compris des sites Web.

Ils sont bien adaptés aux sites nécessitant un contenu dynamique. Le défi survient lorsque les sites Web ont beaucoup de contenu statique qui est piloté dynamiquement.

Plusieurs pages d’un site Web que j’ai évalué ont obtenu un score très faible dans l’outil PageSpeed Insights (PSI) de Google.

En creusant à l’aide du rapport de couverture dans les outils de développement de Chrome sur ces pages, j’ai constaté que 90 % du code JavaScript téléchargé n’était pas utilisé, ce qui représentait plus de 1 Mo de code.

Lorsque vous examinez cela du côté de Core Web Vitals, cela représente près de 8 secondes de temps de blocage car tout le code doit être téléchargé et exécuté dans le navigateur.

S’adressant à l’équipe de développement, ils ont souligné que s’ils chargent tout le JavaScript et le CSS qui seront nécessaires sur le site, cela rendra les visites de pages ultérieures beaucoup plus rapides pour les visiteurs puisque le code sera dans les caches du navigateur. .

Alors que l’ancien développeur en moi était d’accord avec ce concept, le SEO en moi ne pouvait pas accepter que la perception négative apparente de Google de l’expérience utilisateur du site était susceptible de dégrader le trafic de la recherche organique.

Malheureusement, d’après mon expérience, le référencement perd souvent par manque de volonté de changer les choses une fois qu’elles ont été lancées.

3. C’est le site le plus lent de tous les temps !

Semblable à l’histoire précédente, un site que j’ai récemment examiné n’a obtenu aucun score sur le PSI de Google. Jusqu’à ce moment-là, je n’avais jamais vu un score nul auparavant. Beaucoup de deux, trois et un, mais jamais de zéro.

Je vais vous donner trois hypothèses sur ce qui est arrivé au trafic et aux conversions de ce site, et les deux premières ne comptent pas !

Recevez la newsletter quotidienne sur laquelle les spécialistes du marketing de recherche comptent.

Parfois, c’est plus que du JavaScript

Pour être juste, un CSS excessif, des images beaucoup plus grandes que nécessaire et des arrière-plans vidéo en lecture automatique peuvent également ralentir les temps de téléchargement et causer des problèmes d’indexation.

J’en ai parlé un peu dans deux articles précédents :

Par exemple, dans mon deuxième récit, les sites concernés avaient également tendance à avoir un CSS excessif qui n’était pas utilisé sur la plupart des pages.

Alors, que doit faire le SEO dans ces situations ?

Les solutions à des problèmes comme celui-ci impliquent une collaboration étroite entre le référencement, le développement et le client ou d’autres équipes commerciales.

Construire une coalition peut être délicat et implique des concessions. En tant que praticien SEO, vous devez déterminer où des compromis peuvent et ne peuvent pas être faits et agir en conséquence.

Recommencer depuis le début

Il est préférable d’intégrer le référencement dans un site Web dès le départ. Une fois qu’un site est lancé, le modifier ou le mettre à jour pour répondre aux exigences de référencement est beaucoup plus compliqué et coûteux.

Travaillez à vous impliquer dans le processus de développement du site Web dès le début, lorsque les exigences, les spécifications et les objectifs commerciaux sont définis.

Essayez d’obtenir des robots des moteurs de recherche en tant qu’histoires d’utilisateurs tôt dans le processus afin que les équipes puissent comprendre leurs particularités uniques pour aider à indexer rapidement et efficacement le contenu spidered.

Être un enseignant

Une partie du processus est éducation. Les équipes de développeurs ont souvent besoin d’être informées de l’importance du SEO, vous devez donc leur dire.

Mettez votre ego de côté et essayez de voir les choses du point de vue des autres équipes.

Aidez-les à comprendre l’importance de mettre en œuvre les meilleures pratiques de référencement tout en comprenant leurs besoins et en trouvant un bon équilibre entre eux.

Parfois, il est utile d’organiser un dîner-causerie et d’apporter de la nourriture. Partager un repas pendant les discussions aide à faire tomber les murs – et cela ne fait pas de mal non plus un peu de pot-de-vin.

Certaines des discussions les plus productives que j’ai eues avec des équipes de développeurs ont porté sur quelques tranches de pizza.

Pour les sites existants, faites preuve de créativité

Vous devrez faire preuve de plus de créativité si un site a déjà été lancé.

Souvent, les équipes de développeurs sont passées à d’autres projets et n’ont peut-être pas le temps de revenir en arrière et de “réparer” les choses qui fonctionnent conformément aux exigences qu’elles ont reçues.

Il y a aussi de fortes chances que les clients ou les propriétaires d’entreprise ne veuillent pas investir plus d’argent dans un autre projet de site Web. Cela est particulièrement vrai si le site Web en question a été lancé récemment.

Une solution possible est le rendu côté serveur. Cela décharge le travail côté client et peut accélérer considérablement les choses.

Une variante consiste à combiner le rendu côté serveur avec la mise en cache du contenu HTML en texte brut. Cela peut être une solution efficace pour le contenu statique ou semi-statique.

Cela permet également d’économiser beaucoup de frais généraux côté serveur, car les pages ne sont rendues que lorsque des modifications sont apportées ou selon un calendrier régulier au lieu de chaque fois que le contenu est demandé.

D’autres alternatives qui peuvent aider mais ne résolvent pas totalement les problèmes de vitesse sont la minification et la compression.

La minification supprime les espaces vides entre les caractères, ce qui rend les fichiers plus petits. La compression GZIP peut être utilisée pour les fichiers JS et CSS téléchargés.

La minification et la compression ne résolvent pas les problèmes de temps de blocage. Mais, au moins, ils réduisent le temps nécessaire pour extraire les fichiers eux-mêmes.

Indexation Google et JavaScript : qu’est-ce que ça donne ?

Pendant longtemps, j’ai cru qu’au moins une partie de la raison pour laquelle Google était plus lent à indexer le contenu JS était le coût plus élevé de son traitement.

Cela semblait logique compte tenu de la façon dont j’ai entendu cela décrit:

Une première passe saisit tout le texte brut.
Une deuxième passe était nécessaire pour saisir, traiter et rendre JS.

J’ai supposé que la deuxième étape nécessiterait plus de bande passante et de temps de traitement.

J’ai demandé à John Mueller de Google sur Twitter si c’était une hypothèse juste, et il a donné une réponse intéressante.

D’après ce qu’il voit, Les pages JS ne sont pas un facteur de coût énorme. Ce qui coûte cher aux yeux de Google, c’est de respider des pages qui ne sont jamais mises à jour.

En fin de compte, le facteur le plus important pour eux était la pertinence et l’utilité du contenu.

Les opinions exprimées dans cet article sont celles de l’auteur invité et pas nécessairement Search Engine Land. Les auteurs du personnel sont répertoriés ici.

Ajoutez Search Engine Land à votre flux Google Actualités.

Nouveau sur Search Engine Land

A propos de l’auteur

Elmer Boutin est vice-président des opérations chez WrightIMC, une agence de marketing numérique à service complet basée à Dallas. Après une carrière dans l’armée américaine en tant que traducteur et analyste du renseignement, il a travaillé dans le marketing numérique pendant plus de 25 ans, allant du codage et de l’optimisation de sites Web à la gestion des efforts de gestion de la réputation en ligne en tant qu’entrepreneur indépendant, webmaster d’entreprise et en agence. Il possède une vaste expérience et une expertise de travail pour des entreprises de toutes tailles, des PME aux entreprises de la taille de Fortune 5, y compris Wilsonart, Banfield Pet Hospital, Corner Bakery Cafe, Ford Motor Company, Kroger, Mars Corporation et Valvoline ; optimiser les sites Web axés sur le commerce local, le commerce électronique, l’information, l’éducation et l’international.

— to news.google.com

Magazine Gadgets