Aujourd'hui est arrivé dans mes flux un article de Marc Schillaci qui nous invite à méditer sur la question suivante : « Comment savoir quand une nouvelle fraîche ne l'est plus ? ».
J'ai trouvé l'exemple exposé réellement pertinent et faisant une veille ponctuelle sur les médias sociaux, c'était l'occasion pour moi de faire un petit exercice de Zététique.
L'URL www.example.com/foo n'est pas la même URL que www.example.com/foo/. Or, si cela n'est pas gênant dans une application monopage (plus loin SPA pour « Single Page Application »), cela devient critique pour de l'optimisation de moteur de recherche (plus loin SEO pour « Search Engine Optimization ») dès lors que le contenu est généré côté serveur.
Côté serveur, les routeurs comme celui d'Express possèdent un mode strict pour que l'adresse /foo ne soit pas la même que l'adresse /foo/. Mais qu'en est t-il de Vue Router ? Et surtout, comment faire concorder le routage client et le routage serveur pour que l'hydratation (la prise en main côté client d'un rendu côté serveur) concorde ?
Je vous le donne en mille : de base, là où Express en mode strict vous renverra une page 200 pour /foo/ et une page 404 pour /foo, Vue Router lui, en mode strict, vous renverra exactement l'inverse !
Comment dans ce cas utiliser Vue Router et Vue Server Renderer pour du routage strict dont les moteurs de recherche sont si friand pour une SEO à toute épreuve ? La réponse à la fin !
Cependant, afin que ce billet soit utile également pour ceux n'ayant pas (encore) ce problème et qui souhaitent découvrir par l'exemple comment fonctionne du SSR avec Vue (et de facto, qu'est-ce que c'est réellement), je vais élaborer un code pour vous accompagner dans cette compréhension, pas à pas. Seulement ensuite nous mettrons en évidence notre problème avant de le résoudre.
Nous allons voir dans cet article comment faire du rendu côté serveur ou SSR (Server-Side Render) avec le framework JavaScript client MVVM (Modèle-Vue-Vue Modèle) Vue couplé au framework JavaScript serveur MVC(2) (Model View Controller) NodeAtlas !
Alors ce titre parle peut-être aux habitués des architectures clientes MVVM qui ont des difficultés avec le référencement et semble peut-être barbare pour d'autres. Lançons-nous dans une petite explication histoire de rendre cet article intéressant également pour les néophytes : comprenons le problème et trouvons la solution à travers cette page.
Quel est le problème traité dans cet article ?
Le problème avec les frameworks MVVM client est qu'ils construisent le site à partir de rien. Fouillez la source du code de la réponse HTTP de la page courante, celle lue par les indexeurs de contenus ou les navigateurs sans JavaScript ; il n'y a rien. Aussi, si je crée une liste d'actions futures pour la roadmap de ma super App, et que je souhaite pouvoir manipuler aisément (ajout et retrait) ses éléments grâce à un coupleur de données vue-modèle ; le revers de la médaille sera que les informations utilisées pour cette construction proviendront de fichiers JavaScript ou morceaux de HTML qui ne veulent rien dire pour les indexeurs où même les validateurs de page. Vos sites sont donc souvent « SEO merdiques » et « W3C bancales ».
Quelle solution ?
Le SSR ou Rendu Côté Serveur. Voyons ça au travers de cette page exemple avec Vue et NodeAtlas !
AngularJS est un régale pour toute création d'Application Web de petite et moyenne taille. J'entends par là, des ensembles d'interfaces web ou l'utilisateur est sollicité à participer au remplissage de contenu par l'intermédiaire de champs, listes, boutons, etc.
Le principe est le suivant : sortir le contenu utile du HTML pour le ranger dans un scope JavaScript afin de le manipuler plus aisément et parsemer le HTML de référence à ce scope de contenu. L'avantage est que le contenu a sa propre vie, et n'est plus figé dans le HTML et surtout toute mise à jour de contenu dans le JavaScript entraîne sa mise à jour dans le HTML, bien pratique.
Le revers de la médaille est que la source HTML mangée par les moteurs de recherche pour le référencement ne ressemble plus qu'à un ensemble de variables, et les balises et attributs HTML rencontrés font pâlir n'importe quel validateur W3C.
C'est parti pour un tutoriel vous expliquant comment contenter le W3C pour pouvoir correctement implémenter vos recommandations SEO avec AngularJS.
C'est suite à plusieurs conversations m'invitant à ne pas utiliser de multiples balises h1 dans mes intégrations HTML (et plus récemment une demande « insistante » sur le fait de ne pas le faire) que je me vois forcé de marcher sur les pas de Raphaël Goetter -qui avait déjà abordé le sujet- pour expliquer pourquoi : en plus d'être tout à fait valide, cette pratique est bénéfique.
Tout document HTML5 dispose de cloison de contenu (Sectionneur de contenu) que sont article, aside, nav et section. Ces zones de contenu peuvent chacune contenir une balise header et footer (ne cloisonnant pas elles-mêmes le contenu) et de multiple éléments de titrage (Titre en HTML) allant de h1 à h6.
Bien que l'utilisation de plus d'une balise h1 ai pu rationnellement laisser à débattre (même si techniquement les standards ne l'interdise pas), les recommandations et même l'interdiction d'une telle pratique ne sont plus pertinentes et rationnelles à l'heure du HTML5.
Lire dans une autre langue