En 2021 on ne présente plus le SEO (“Search Engine Optimization”). Véritable moteur pour de nombreuses entreprises (e-commerce, référenceurs spécialisés…), il peut aussi être un gros plus pour n’importe quel autre type de société, pour se faire connaître et/ou obtenir des offres commerciales, etc.

Optimiser son placement sur les moteurs de recherche est tout un domaine d’expertise… Pourtant extrêmement peu enseigné en école et parfois peu pris en compte lors des développements. 

C’est ainsi qu’il arrive que des ratés aient lieu, et ce notamment avec les SPA (sous React, Angular ou encore VueJS). En effet, ces technologies récentes ne sont pas vraiment compatibles par défaut avec les robots de parsing des moteurs de recherche. Nous allons voir en quoi et pourquoi, mais aussi les solutions à mettre en œuvre pour contrer ces problématiques.

Pourquoi les moteurs de recherche ont du mal avec les SPA ?

Mettons nous du point de vue de Google, Bing et les autres : il faut mettre en place un robot qui va parcourir tout internet, chaque jour idéalement pour être au plus pr ès de l’actualité. Un tel robot n’est pas gratuit, et encore moins s’il doit “parser” du JavaScript.

En effet, historiquement une page Web se récupère avec une simple requête réseau. Pour un robot, il suffit ensuite de lire le contenu puis l’ajouter dans une base de données, ce qu’on appelle en SEO l’indexation. S’y ajoute l’algorithme de placement pour comparer différents sites sur un même sujet et ainsi déterminer qui décroche la position n° 1, le graal en référencement. Et c’est tout ! Le coût de ces opérations est quasi-équivalent au temps de l’appel réseau, soit un ordre de grandeur d’environ 50 à 200 millisecondes. 



Dans le cadre d’une Single Page App au contraire, en plus de récupérer ce document HTML, il faut aller chercher les dépendances qu’il renseigne : les fichiers JavaScript, puis les exécuter dans un moteur JavaScript… que l’on appelle plus communément un navigateur. Une fois le tout fait, ça y est, le robot peut indexer le contenu. L’ordre de grandeur en temps passe ainsi ici à la seconde, voire la dizaine de secondes. Il faut aussi compter le coût en processeur et mémoire pour exécuter le JavaScript… Pour faire simple, on n’est plus du tout à la même échelle !

Concrètement quel est le risque en se lançant sur une Single Page App d’un point de vue SEO ?

C’est la raison pour laquelle il semble qu’hormis Google, aucun moteur de recherche n’indexe les applications JavaScript. C’est-à-dire que le site ou l’application ainsi mise à jour vers ces nouvelles technologies, depuis un monolithe classique par exemple, disparaîtra complètement des radars (hors celui de Google) !



Pour faire cette affirmation, chose toujours compliquée en SEO, je me base sur une étude en conditions réelles faite en 2017, dont voilà la conclusion en une image (qui est toujours valide mi-2021) :

“Oui mais Google c’est 90 à 95 % de part de marché” me direz-vous, ce n’est peut être pas vraiment une grosse perte ? Cela va dépendre de votre population cible. Si ce sont des personnes plutôt “geeks”, ces dernières auront tendance à plutôt utiliser DuckDuckGo ou autre moteur de recherche plus respectueux de la vie privée (une tendance qui prend de plus en plus d’ampleur de manière générale d’ailleurs). Si au contraire ce sont des personnes peu habituées avec l’outil informatique, il est plus probable de les trouver en grand nombre chez Bing, le moteur par défaut livré avec Edge et Windows. Tenir ce discours peut donc paraître assez risqué.

Je me base une nouvelle fois sur des données à ma disposition : je possède un blog où j’écris des critiques sur des films, des tutoriels sur jeux vidéo ou encore des articles de vulgarisation scientifique. Le thème est donc un peu “geek”. Or, un tiers des entrées ont lieu depuis d’autres moteurs de recherche que Google, on est assez loin des 90% de part de marché !

“Quid de l’avenir” ? Puisque les SPA fêtent leurs 10 ans et sont maintenant extrêmement populaires, il semble assez clair que la plupart des moteurs ne vont probablement pas chercher à supporter les coûts d’exécution du JavaScript avec leur robot, sinon ça serait déjà fait. Il vaut donc mieux chercher des solutions pour contrebalancer ce problème (le fait que ces solutions existent maintenant est peut être une raison de plus pour que ces moteurs ne cherchent pas plus loin).

À noter par ailleurs que tout partage de lien sur les réseaux sociaux (ou un Slack, etc.) affiche normalement une miniature avec une image et un peu de texte. Avec une SPA classique, ces miniatures sont entièrement vides pour la même raison que vue précédemment : Facebook ou Twitter ne vont pas s’embêter à exécuter un moteur JavaScript entier pour afficher une simple image avec une phrase. Exemple concret avec les images ci-dessous :

Quelles solutions pour garder des pratiques modernes de développement avec le SEO ?

Heureusement les équipes et communautés derrière les frameworks et librairies pour construire les SPA ont bien eu conscience de ce problème et ont mis en place des solutions, qui sont maintenant clairement considérées comme fiables avec la nouvelle décennie. C’est ce qu’on appelle le “Server Side Rendering” ou “rendu côté serveur” (SSR). 

Cela peut sembler comme un retour en arrière à première vue, mais selon la technologie on se retrouve plutôt avec le meilleur des deux mondes : des applications hybrides avec un rendu côté serveur puis une SPA qui prend le contrôle une fois la première page chargée par l’utilisateur – ou un site statique, construit et généré avec les outils modernes de développement JavaScript.

Pour React les plus connus sont  Next.js  et  Gatsby , qui sont maintenus par la communauté :

• Le premier permet ce type d’application hybride, proposant en même temps tous les bénéfices en termes UX des SPA et des sites Web classiques. 

• Le second cherche plutôt à concurrencer les CMS comme WordPress en offrant un site statique et les plugins correspondants. 

Pour Angular il faut regarder du côté  d’Universal , maintenu par l’équipe du framework. Quant à VueJS, ils proposent  une solution native à la librairie .

Dans tous les cas, ces solutions sont à prendre en compte et à implémenter dès le début des développements, on s’expose sinon à des coûts de migration qui peuvent être assez lourds. En effet ces frameworks agissent comme des surcouches aux outils pour construire les SPA, il faut donc effectuer pas mal de changements. Mais s’ils sont mis en place dès le début, le surcoût en développement sera quasiment invisible.

Conclusion

 Le monde du développement Web a énormément évolué ces 10 dernières années. De nos jours même l’hégémonie de WordPress est remise en jeu par des frameworks comme Gatsby à travers React. Il y a quelques années, comme en 2017 lors de l’apparition d’Angular 2, le SEO était une problématique majeure de ces nouveaux outils qui empêchait leur utilisation universelle. Mais ce n’est maintenant plus le cas, lorsqu’on a conscience des changements à apporter par rapport aux frameworks “vanilla”. 

Les techniques de rendu SSR s’imposent en effet de plus en plus et à juste titre, car en plus du SEO, la magie de ces outils permet d’avoir un Web de plus en plus rapide et de plus en plus pratique dans son utilisation ! Le tout en conservant le confort de développement apparu il y a 10 ans avec les SPA.