Cet article a été rédigé initialement sur le site bee4.fr. Il s’agit d’un article invité, publié ici pour maintenir le contenu.

Vous aimez utiliser l’Ajax pour rendre votre site plus sympa? Que pense Google de tout ça ?

L’Ajax devient vraiment « à la mode » pour la conception des sites web. C’est normal car même si elle a ses contraintes, elle présente de très bons avantages :

  • Navigation dans le site sans jamais avoir à recharger la page du navigateur ;
  • Optimisation des temps de réponses en déportant les parties complexes une fois la page affichée ;
  • Intégration de contenus annexes pour améliorer l’expérience utilisateur ;
  • Le site se comporte comme une application ;
  • Amélioration de l’ergonomie et de l’expérience de navigation ;
  • De nouvelles possibilités de design et d’animations ;
  • …

Mais qu’en est-il d’un point de vue référencement naturel (SEO) ?

Actuellement, la plupart des sites créés qui chargent les contenus en Ajax, utilisent des URLs avec des hash (# ou #!). La bibliothèque AngularJS de Google est a été conçue pour aider à la conception de ce genre de site.

Par défaut, Google n’est pas capable d’accéder facilement à ces contenus pour les indexer (interprétation du JavaScript, complexité des pages…). Suite à la montée en puissance de ce genre de site, des recommandations officielles ont été faites pour faciliter le parcours de Googlebot.

La contrainte AngularJS : indexer vos pages dans Google – c’est bien, référencer parfaitement votre site – c’est mieux !

AngularJS est un framework JavaScript qui utilise un principe de composant dynamique pour construire les pages. Beaucoup d’autres librairies JavaScript permettent d’intégrer ce genre de comportement: Ember.js, Backbone.js, …

Ce genre de pratique offre un avantage important pour le chargement des pages web. Il est possible de ne télécharger le gabarit commun qu’une seule fois et ensuite de naviguer dans les pages en ne chargeant que les morceaux de contenus qui doivent changer.

Pour l’utilisateur, c’est un avantage certain en terme de performance de navigation même si ce principe ne se prête pas à tous les sites :

  • Si les différentes pages utilisent des gabarits très différents, le CSS pour gérer le style de toutes les pages peut être conséquent ;
  • Le code JavaScript nécessaire peut être vraiment important (de même tout le code nécessaire à toutes les pages du site doit être téléchargé dès la première page).

Il est possible de transformer ces contraintes en chargeant dynamiquement les CSS et les scripts nécessaires durant la navigation de l’utilisateur. Cette méthode peut vite devenir une « usine à gaz »…

La gestion d’URL : et oui, on revient aux « basiques »

Lors de la navigation d’un utilisateur, les URLs des différentes pages du site peuvent être gérées de deux façons sur un site en Ajax :

  • Grâce au hash (# ou #!) on obtient alors: http://domain.com/url/arrivee#!/fragment/content/specifique
  • Grâce à l’API History d’HTML5 : http://domain.com/fragment/content/specifique

L’avantage de la première solution est qu’elle est très simple à utiliser. Par contre, l’utilisation du hash demande à Google de transformer l’URL pour indexer le contenu de destination.

La deuxième solution est clairement la plus pérenne car les URLs de navigation dynamique sont les mêmes que les URLs « normales » des contenus. C’est la surcouche faite pour dynamiser le chargement des contenus qui apporte une optimisation de navigation. Elle a aussi l’avantage de présenter un seul point d’entrée au site pour les internautes comme pour les robots et de permettre la navigation même lorsque l’internaute désactive le JavaScript.

La solution PhantomJS : vous pensez avoir trouvé la solution miracle ?

PhantomJS est un navigateur headless disposant d’une API JavaScript. Il permet de simuler le comportement d’un navigateur pour faire le rendu d’une page HTML. On obtient ainsi la structure HTML complète de la page ciblée.

Pour pouvoir aider Google à indexer les sites en Ajax utilisant la technique du hash, il est nécessaire de calculer le HTML complet représentant une page. Le robot accède ensuite à la structure générée en utilisant le bricolage du “_espaced_fragment_” décrit dans les recommandations. Googlebot n’utilise donc pas la même URL qu’un internaute.

PhantomJS permet de répondre à cette problématique en pré-calculant les différentes pages du site qui doivent être fournies à Googlebot. La complexité du JavaScript est cachée aux robots.

Attention cependant, le calcul de la structure HTML est beaucoup plus couteux en utilisant PhantomJS que pour un rendu de page « normal » car il simule le comportement d’un navigateur (téléchargement des CSS et scripts, interprétation du JavaScript, requêtes Ajax, …). C’est donc beaucoup plus long que le rendu du HTML par le serveur.

Il est clairement conseillé d’utiliser un cache de fichiers statiques (à plat ou avec un logiciel comme “Varnish”) pour éviter ce genre de calcul à chaque passage du robot.

Au final, prenez le temps de vous poser quelques questions …

Faites un test ! Si vous vous apercevez que vos CSS et JS sont vraiment gros, posez-vous bien la question est-ce que votre site ne contient que le nécessaire pour la page en cours ou est-ce qu’il contient tout le nécessaire pour l’affichage des différentes pages ?

Comme Google ne récupère que page à page, il peut être intéressant de lui fournir uniquement les CSS utiles. Qu’en pensez-vous ?

A noter que vous pouvez aussi aller un peu plus loin dans la démarche et vous challenger un peu. Exemple : l’utilisation d’un pipeline d’asset est clairement recommandée pour ce genre de problématiques (avec Gulp, Grunt, …) pour éviter les interventions manuelles. Réfléchissez aussi à l’utilisation de l’API HTML5 History pour la gestion des URLs plutôt que le Hash. Ainsi, plus de double logique de récupération du contenu….

Besoin d’un conseil ou d’une vérification ?  Vous souhaitez savoir si votre Phantom ne transforme pas notre ami Google en fantôme ? Contactez-nous.

Stéphane Hulard & Teodor Dachev