Depuis 2016, BiiG utilise Angular, un framework (cadre de travail) JavaScript, pour le développement de ses applications Web. Nous verrons ensemble pourquoi ces dernières ne sont pas une solution idéale au référencement naturel et comment y remédier.
Dans l’univers des frameworks JavaScript, l’analyse de page web par les crawlers (robots) est complexe, voire impossible nativement. Le fonctionnement d’un crawler est réparti en 2 étapes :
- Le téléchargement de la page
- L’analyse du contenu
Les ressources JavaScript sont dans la plupart des cas ignorées par le robot si le temps de rendu est trop long. L’incapacité du crawler à bien lire le contenu de l’application web entraîne indéniablement une baisse du référencement, ce que nous voulons éviter sur des applications publiques.
N.D.L.R — Il est vrai que dorénavant les crawlers de Google sont capables d’interpréter les applications conçues avec des frameworks JavaScript, cependant ce n’est pas encore optimal. Il peut en résulter un décalage entre l’application rendue aux visiteurs et celle rendue au robot, et celui-ci peut être pénalisant.
Depuis l’avènement des frameworks JavaScript tels que Backbone, EmberJS ou encore AngularJS, les sites web comme nous les connaissons ont évolué vers une nouvelle entité de site : les Application Web Monopage (Single Page Application ou SPA).
Cela consiste à garder l’utilisateur sur la même page tout au long de sa visite, et donc de le faire interagir sans temps de chargement de nouvelles pages. Cependant, nous sommes en droit de comprendre les raisons de cette démocratisation alors qu’à première vue, ces SPA font l’impasse sur le SEO.
Comment réconcilier les frameworks JavaScript et le référencement ?
La majorité des projets chez BiiG sont des applications métiers qui n’ont pas vocation à être accessibles au grand public, c’est pourquoi nous accordions peu d’importance au référencement naturel de ces dernières.
Nous développons principalement avec Angular et c’est avec cet outil que nous avons mis en place depuis peu une solution. En effet, depuis sa version 5, Angular ouvre la porte du rendu côté serveur (Server-Side Rendering ou SSR). Le Server-Side Rendering est le processus permettant de déléguer la construction complète de la page au serveur avant de l’envoyer au navigateur de l’utilisateur.
Pour exemple, ci-dessous, deux corps HTML de la même page web, sans et avec le rendu côté serveur :
Nous avons eu l’opportunité d’utiliser cette solution, dénommée Angular Universal, pour l’application Web d’un client qui souhaitait bénéficier des dernières technologies web et pouvoir travailler le référencement naturel de son application. Une demande importante a été faite sur l’optimisation des pages pour le partage sur les réseaux sociaux. En effet, ces derniers utilisent également des robots pour analyser les pages web que vous souhaitez partager et en fournir une prévisualisation qui attire l’oeil sur votre publication. C’est principalement pour répondre à cette ligne du cahier des charges que nous avons mis en place le Server-Side Rendering.
Comment ça marche ?
Côté technique, Angular Universal se base sur une structure NodeJS et Express pour pouvoir générer les pages statiques demandées par l’utilisateur. Sa mise en place requiert une étape supplémentaire au temps de production de l’application mais la documentation d’Angular sur le Server-Side Rendering est plutôt bien fournie.
Une attention toute particulière est à porter tout au long du développement afin de se prémunir contre les erreurs récurrentes lors du lancement du rendu côté serveur.
Certaines fonctionnalités que le développeur peut mettre en place pour le confort de l’utilisateur ne pourront pas être exécutées par le robot qui recevra une erreur JavaScript, erreur qui peut interrompre le rendu de la page. Par exemple, toutes les fonctionnalités se basant sur les objets JavaScript Window et Document sont à proscrire car les robots n’y ont pas accès du fait de l’absence de navigateur côté serveur.
Toutefois, si l’utilisation de tels objets est indispensable, il est toujours possible avec Angular de conditionner l’exécution des lignes de codes faisant référence au navigateur en dissociant le type de plateforme de rendu utilisée ou de simuler ces objets avec des librairies JavaScript.
Avec cette solution, nous sommes dorénavant en mesure de livrer des applications web, non seulement performantes mais également référencées comme un site traditionnel !
Le point bonus
Et ce n’est pas tout… Le Server-Side Rendering a deux autres avantages.
Avec 53% de visites mobiles abandonnées si le temps de chargement de la page excède les 3 secondes, le Server-Side Rendering permet d’afficher plus rapidement la première page visitée car elle n’est que pur HTML. Le navigateur client a en fin de compte uniquement à lire l’HTML et non interpréter le JavaScript pour le construire, un avantage certain pour les navigateurs installés sur des appareils d’entrée de gamme ou fatigués qui n’exécuteront pas ou mal le JavaScript.
Dans un autre cas, les internautes voulant bloquer simplement l’exécution de code JavaScript ne pourront pas accéder aux pages de l’application, chose que le rendu en pur HTML permettra.
