Site Personnel : Blog & Portfolio

Objectifs

Ce projet, en tant que site personnel/portfolio, se devait dès le départ d'être ambitieux. En tant que développeur indépendant, je pense sincèrement qu'il est dur de paraître crédible sans pouvoir apporter la preuve de son expertise. Aussi, ce site se devait d'être plaisant visuellement parlant, ergonomique, responsive mais, aussi et surtout, performant.

En plus d'être ma principale vitrine, le site devrait également accueillir toute une partie blog, qui sera complétée plus tard par une section formations.

Choix de la stack technologique

Régulièrement contraint, le choix de la stack technologique est pourtant un des moments que j'affectionne le plus dans mon travail. Travailler pour soi et sans limites d'infrastructure, c'est s'offrir un immense terrain de jeu qui ne demande qu'à prendre forme, et c'est aussi l'occasion d'expérimenter ou de consolider ses connaissances dans certains domaines.

Les contraintes :

• Avoir de hautes performances
• Être bien référencé
• Pouvoir facilement ajouter et modifier du contenu

Le choix de ReactJS et de NextJS

Lorsque l'on recherche la performance, bien souvent, c'est ReactJS ou VueJS qui nous viennent en tête, pour le côté Front-End tout du moins. Mais ces dernières apportent un inconvénient majeur pour moi : les sites qui les utilisent sont généralement moins bien référencés par les moteurs de recherches. Or le référencement naturel (SEO) revêt une importance cruciale pour moi, autant que pour mes clients.

De nos jours, les robots qui analysent les pages pour les référencer (bots ou crawlers), sont en partie capable d'interpréter le JavaScript sur les pages qu'ils consultent. Cependant, cette interprétation peut parfois rester incertaine et augmente en général le temps d'indexation par rapport à la normale. D'ordinaire, React, Vue, Angular et compagnies, sont utilisées pour créer des applications web où l'interaction utilisateur prime face au référencement naturel et sont fréquemment accessible aux utilisateurs authentifiés uniquement.

Dans ce genre de situations, l'utilisation de ces technologies est pertinente dans la mesure où elles n'ont pas besoin d'être bien référencées, ou tout du moins, pas dans leur intégralité (on ne cherchera à référencer que les landing pages).

Tous ces éléments en tête, mon choix s'est porté vers ReactJS principalement pour sa popularité et son utilisation récurrente dans les projets, aussi bien professionnels qu'amateurs (bien que VueJS m'ait fortement fait de l'œil à de nombreuses reprises).

Cependant, pour pallier toutes les problématiques liées au SEO évoquées plus haut, il me fallait utiliser rendu côté serveur (ou Server Side Rendering - SSR) pour éviter de charger une "coquille vide", comme le dit Grafikart, au chargement de la page et ainsi prendre le risque de pénaliser le référencement. Pour l'implémentation du SSR, j'ai choisi NextJS pour sa popularité et la qualité des outils qu'il offre.

Avec NextJS, je suis ainsi en mesure d'automatiquement optimiser mes images, d'avoir une navigation sans rechargement complet de la page et surtout, d'éviter les problèmes de SEO. De plus, étant un framework NodeJS, il m'offre tout le potentiel de NodeJS et de ses fonctions asynchrones, tout en utilisant le même langage côté serveur que côté client (et donc une meilleure réutilisation du code).

TailwindCSS : le choix de la consistance et de la performance

TailwindCSS, si vous n'en n'avez jamais entendu parler, est une librairie qui repose sur le principe de classes utilitaires. Ces classes offrent un très haut niveau de granularité et c'est l'association de ces dernières qui permet de styliser les éléments.

Mon texte

Aux premiers abords, on peut penser que le code HTML sera très vite très "touffu" et illisible. Cependant, cette technologie prend tout son sens lorsqu'elle est utilisée avec des librairies de templating ou d'interface graphique (UI) tels que ReactJS en JavaScript, ou Twig en PHP. Cerise sur le gâteau, TailwindCSS vient scanner le code source et purge le code CSS qu'il produit pour ne garder que les classes CSS que vous utilisez réellement. C'est un gros coup de cœur !

Strapi pour la Gestion de Contenu

Étant donné mon envie d'écrire (félicitations pour être arrivé jusqu'ici) et ma volonté de créer un blog, il me semblait important d'inclure une couche CMS (Content Management System) à ce projet. Ayant développé ces cinq dernières années sur WordPress, j'en savais assez pour être sûr de ne pas vouloir l'utiliser ici, en partie à cause de ses problèmes de performance, son expérience de développement incertaine et une conception pas aussi flexible que l'on voudrait nous le faire croire (à moins d'avoir beaucoup de temps devant soi). De plus, pourquoi ne pas choisir là aussi un CMS basé lui aussi sur JavaScript ?

C'est tout ce cheminement qui m'a finalement mené à Strapi, un CMS Headless (sans interface graphique en Front, tout passe par une API) et qui fonctionnant sous NodeJS. La grande force de Strapi, en plus d'être français, c'est sa grande flexibilité. À l'image de Drupal, le CMS nous laisse créer nos propres types de contenu et n'est pas limité à une utilisation Blog, loin de là.

Seul bémol, Strapi est encore jeune et a sorti une version majeure (V4) l'an dernier. La communauté et le support sont parfois manquants, mais le projet est en pleine expansion, avec une équipe professionnelle dédiée à son développement.

Résultats

Ce projet aura été pour moi l'occasion d'explorer de nouveaux horizons, notamment au travers de NextJS et de Strapi. Le résultat final répond à mes attentes en affichant d'excellentes performances, sans que cela ne se fasse au détriment du référencement naturel.

Pour ce qui est de Strapi, je suis globalement satisfait de mon expérience. L'expérience d'utilisation est très agréable, mais la prise en main côté développement pour la personnalisation reste encore brumeuse à l'heure actuelle. Le projet reste néanmoins très intéressant et je pense qu'il a un grand avenir devant lui !