Choisir un CMS pour construire sont site
La première question qu'on peut se poser avant de créer un site Web, est quelle solution choisir.
De nombreuses solutions s'offraient à moi :
De nombreuses solutions s'offraient à moi :
- Utiliser un CMS en SAAS
- Utiliser un CMS dynamique avec rendu côté serveur
- Utiliser un static site generator, permettant de générer directement des pages html.
CMS en SASS ?
Utiliser un CMS en SAAS a plusieurs intérêts valides. Le premier est de n'avoir pas à gérer l'infrastructure du site, car le back-office et le front est géré par la solution.
De plus les solutions SASS se sont améliorées avec le temps, que ce soit en terme d'inteface ou tout simplement en possibilité du customisations.
On pourrait penser à Wix, car les publicités de cette solution inondent le web, mais il existe, je trouve, des solutions plus modernes et innovantes, comme Webflow par exemple.
J'ai malgré tout écarté cette solution, car je voulais être maître de mon contenu. Il ne faut pas oublié qu'utiliser une solution SASS, vous lie pieds et mains avec la plateforme.
Si demain, la solution décide de doubler ses prix ou si l'entreprise ferme, passer sur une autre solution, sera moins aisé.
L'autre problématique souvent relevée, est lié au référencement.
Le fait que les site builders comme wix, sont souvent plus lent à s'afficher, impacte le référencement.
De plus les solutions SASS se sont améliorées avec le temps, que ce soit en terme d'inteface ou tout simplement en possibilité du customisations.
On pourrait penser à Wix, car les publicités de cette solution inondent le web, mais il existe, je trouve, des solutions plus modernes et innovantes, comme Webflow par exemple.
J'ai malgré tout écarté cette solution, car je voulais être maître de mon contenu. Il ne faut pas oublié qu'utiliser une solution SASS, vous lie pieds et mains avec la plateforme.
Si demain, la solution décide de doubler ses prix ou si l'entreprise ferme, passer sur une autre solution, sera moins aisé.
L'autre problématique souvent relevée, est lié au référencement.
Le fait que les site builders comme wix, sont souvent plus lent à s'afficher, impacte le référencement.
CMS dynamique ?
Ce que j'entends par CMS dynamique, c'est un CMS avec rendu côté serveur, souvent en PHP, utilisant une base de donnée pour stocker le contenu du site.
On pense forcément à Wordpress qui reste de loin la solution la plus utilisée, mais on pourrait également penser à Drupal.
Sur le papier, cela semble la solution idéale, car de nombreux thèmes existent pour développer un site rapidement, de nombreux modules / plugins, sont dévéloppés pour aider à intégrer des fonctionnalités que ce soit pour le référencement, l'analytics ...
Mais le fait que ce soit la solution la plus utilisée, est également le frein le plus important.
En effet, wordpress est le vecteur d'attaque le plus commun. Car posséder un site wordpress oblige à mettre à jour régulièrement le site.
En effet, car les hackers savent qu'il est plus rentable de s'attaquer à la solution la plus utilisée.
De plus, la qualité des modules tierses est aléatoire et les failles de sécurité peuvent arriver par ce biais là.
On pense forcément à Wordpress qui reste de loin la solution la plus utilisée, mais on pourrait également penser à Drupal.
Sur le papier, cela semble la solution idéale, car de nombreux thèmes existent pour développer un site rapidement, de nombreux modules / plugins, sont dévéloppés pour aider à intégrer des fonctionnalités que ce soit pour le référencement, l'analytics ...
Mais le fait que ce soit la solution la plus utilisée, est également le frein le plus important.
En effet, wordpress est le vecteur d'attaque le plus commun. Car posséder un site wordpress oblige à mettre à jour régulièrement le site.
En effet, car les hackers savent qu'il est plus rentable de s'attaquer à la solution la plus utilisée.
De plus, la qualité des modules tierses est aléatoire et les failles de sécurité peuvent arriver par ce biais là.
Static Site Generator
Pour mon besoin, aucun système nécessitant un back-end. Rendre des pages html est suffisant. L'intérêt de n'avoir aucun language côté serveur est de pouvoir mettre son site sur un CDN entièrement sans avoir des stratégies de cache compliquées. Car tous les assets, pages seront mis en cache de la même manière. L'autre intérêt est un coût moindre car un CDN coûte moins cher qu'un serveur.
En faisant le comparatif entre les différentes solutions que ce soit javascript (Nextjs, Nuxt..), Go (Hugo) ou Ruby (Jekyll), mon choix s'est porté sur HUGO.
Les solutions javascript sont souvent très lourdes en terme de dépendances.
En essayant de démarrer un nouveau site nuxt, je me suis rendu compte que NPM téléchargeait plus de 400mo dépendances.
J'ai également le souvenir le souvenir dans le passé, d'être revenu sur un projet Javascript qui avait deux ans. Le simple fait d'essayer de récupérer les dépendances pouvait être une gageure.
Partant de ce constat, et en analysant les fonctionnalités d'HUGO, je me suis qu'il était le choix parfait pour mon besoin.
Si j'ai besoin un jour de fonctionnalité intéractives, comme par exemple un système de commentaires, une page de contact, ces fonctionnalités seront externalisées.
En faisant le comparatif entre les différentes solutions que ce soit javascript (Nextjs, Nuxt..), Go (Hugo) ou Ruby (Jekyll), mon choix s'est porté sur HUGO.
Les solutions javascript sont souvent très lourdes en terme de dépendances.
En essayant de démarrer un nouveau site nuxt, je me suis rendu compte que NPM téléchargeait plus de 400mo dépendances.
J'ai également le souvenir le souvenir dans le passé, d'être revenu sur un projet Javascript qui avait deux ans. Le simple fait d'essayer de récupérer les dépendances pouvait être une gageure.
Partant de ce constat, et en analysant les fonctionnalités d'HUGO, je me suis qu'il était le choix parfait pour mon besoin.
Si j'ai besoin un jour de fonctionnalité intéractives, comme par exemple un système de commentaires, une page de contact, ces fonctionnalités seront externalisées.
