Le site statique généré par GitHub, ou le cache à la sauce geek !
Si vous avez digéré l’article précédent (ce qui peut être allé très vite, si vous êtes un vrai geek), il est temps maintenant de plonger dans la réalité de cette affirmation étonnante “un site statique, c’est mieux qu’un site dynamique”.
Et pour cela, le mieux est d’écouter cette vidéo, une présentation de Clément Delafargue, intitulée “les sites statiques, une alternative aux CMS“. La qualité est moyenne, mais elle n’est pas très longue – un quart d’heure – et très intéressante. (En dehors d’un petit WordPress Bashing).
J’avoue, au tout début, j’avais envie d’être plutôt caustique, ça ne commençait pas très bien, en réalité, même si nous sommes en désaccord sur certaines choses, je suis beaucoup plus en accord avec cette vidéo qu’avec l’article disant que le site statique était meilleur en tout !
La méthode consiste à utiliser GitHub pour générer des pages HTML qui sont ensuite publiées
Et c’est dit dès le début :
Le CMS c’est Git
Comment cela fonctionne ? C’est expliqué ici, sur l’accueil de Git Pages.
Vous utilisez un logiciel, soit GitHub pour Windows ou pour Mac, soit mieux encore un terminal.
Si vous utilisez un terminal, pour créer un fichier index.html qui dit “Hello World”, vous allez d’abord générer le fichier :
Créer une page qui dit “Hello World” dans Git Pages
Et ensuite vous allez le “Add, Commit, Push” pour avertir le monde que vous lui dites “Hello” … autrement dit l’enregistrer et le publier “via le FT¨” (dans notre monde de WordPresseurs et autres amateurs de sites dynamiques).
Publier une Git Page
L’interface est légèrement moins conceptuelle dans le cas du client Windows (on créé quand même son petit fichier .html), mais reste du même niveau d’austérité absconse.
Après, évidemment, on peut faire des sites avec des fichiers plus complexes : on va mettre des variables dans les fichiers html, par exemple pour le titre de la page. Pour créer un article de blog, on va d’abord créer un fichier dont le nom doit impérativement commencer par la date… On peut créer des templates complexes, créer des fichiers pour stocker des données. Il est impératif de respecter une structure de fichiers, de titres…
Et pour afficher une liste d’articles avec l’extrait, on fait quelque chose qui rappelle étrangement “The Loop” :
Liste d’article dans Jekyll, le blog de GitHub
J’arrête ici, si vous voulez voir en live ce que cela donne, le blog de Clément Delafargue est un bon exemple.
On a simplement, avec une approche “peu conviviale”, un CMS, qui gère dans GitHub des contenus éditables, pour générer ensuite des pages, qui vont être publiées.
Il s’agit d’un site dynamique, et pas d’un site statique. La seule différence : on a scindé la génération dynamique et le fichier stocké sur le serveur, autrement dit, on a fait un système de cache en supprimant toute possibilité d’interaction dynamique pour le visiteur.
Voici, au cas où vous n’auriez pas écouté la vidéo, quelques citations de Clément :
C’est vraiment un Workflow fait pour les développeurs
le CMS c’est Git
La publication c’est un peu galère – sans doute la phrase que j’ai préférée, sacrée la litote de l’année, voici une partie de l’explication (en anglais)
On retombe dans les mêmes travers que les CMS qui sont basés sur des moteurs de blog, quand on commence à faire de l’internationalisation il va se péter la gueule assez rapidement
Le gros problème, c’est que si vous demandez à des gens d’éditer le contenu et que c’est pas des devs ça va leur faire vraiment tout drôle et s’il se plante dans le MakeFile il y aura des conflits à résoudre très régulièrement
Autrement dit, un outil de geek et de techos, fait pour les techos.
On est à dix mille lieux de “le client peut modifier son site statique s’il le veut facilement” de l’argumentation précédente.
Je dirais même que le client normal, celui à qui on a déjà du mal à apprendre comment utiliser TinyMce qui ressemble tellement à Word, s’il quitte son développeur, il va regarder les fichiers .html, et il va venir sur le forum de support demander s’il ne peut pas récupérer automatiquement son contenu pour alimenter son thème Artisteer.
Une bonne âme va lui répondre que oui, il y a un outil pour faire ça…. un outil qui reprend tout le contenu de la page et la met dans le post_content, marquage html incompatible avec le thème inclus !
Les limitations d’un système de site statique généré automatiquement
L’absence (quasi totale) d’interactivité
C’est la construction du système qui le veut : l’absence totale d’interactivité, puisque le CMS est uniquement en “push” (envoi à partir du système central). Pour avoir malgré tout un système de commentaires sur son blog, Clément Delafargue est obligé d’utiliser Disqus, un outil externe.
Disqus a été très à la mode, il l’est encore beaucoup, plus dans le monde anglo-saxon que francophone. Comme tous les outils tiers, je n’aime pas, parce que les données ne sont pas “chez moi”, et parce que l’intégration de Disqus génère un grand nombre de liens dofollow vers la plateforme.
Le mailto au lieu du formulaire de contact
L’absence d’interactivité, c’est aussi l’absence de formulaire de contact. Tout dépend de ce que gère le site, vous pouvez considérer que les données de vos contacts sont confidentielles et que vous ne voulez pas leur faire courir de risque. Reste donc ce bon vieux mailto, un attrape-robots leecheurs de mail, votre boite sera inondée. Pire, si vous faites le site pour un client pas très calé en informatique, vous lui faites courir un autre risque : que sont adresse email, récoltée par des robots, soit ensuite utilisée pour un phishing qu’il ne saura pas identifier.
Markdown
Une partie du système repose sur l’utilisation de Markdown à la place du code html.
Markdown, qui va être ensuite interprétée comme du HTML, soit par un plugin dans un CMS (genre Jetpack pour WordPress), soit par le générateur de contenu statique, dans le cadre de Github.Elle a l’avantage très important d’être beaucoup plus lisible qu’un code source (pas de balises ouvrantes, fermantes…) et d’être utilisable dans un grand nombre d’outils.
Elle a deux inconvénients : contrairement à HTML, elle n’est pas standardisée. Et la syntaxe Markdown d’origine est très minimaliste. En conséquences, diverses versions de Markdown ont été développées, et si vous n’avez pas la bonne, votre document ne sera pas bien interprété.
Retour aux sources, à l’époque des grosses incompatibilités entre les navigateurs… dommage pour un outil de simplification.
L’optimisation pour le référencement
Or, dans la syntaxe Markdown manque tout ce qui est relatif aux données structurées, que ce soit sous la forme microdata ou schema.org (si vous trouvez une version de Markdown qui permette de rajouter des itemscopes par exemple, ça m’intéresse).
Si vous utilisez le gestionnaire de GitHub, vous avez la possibilité de créer vos documents en HTML, et donc d’insérer un marquage sémantique. Simplement, vous devrez le faire en code, sans éditeur de texte visuel, avec tous les risques d’erreurs… et une lisibilité largement inférieure à Markdown !
La sécurité ?
Là encore, j’attends le prochain article pour vraiment développer sur la sécurité. Mais en résumé :
- oui, une solution purement statique est difficilement hackable
- non, cela ne supprime pas les problèmes de sécurité, cela les déplace, notamment sur GitHub ou, éventuellement, au niveaux des scripts embarqués comme Disqus
- la complexité de l’outil, les risques de problèmes lors de la publication génèrent aussi de nombreuses possibilités de montrer un site “cassé”. S’il ne s’agit pas d’un piratage, l’effet sur le visiteur qui arrive au mauvais moment n’est pas bon non plus.
J’aurais pas aimé le faire sous WordPress … chiche ?
C’est un commentaire de Clément en montrant un site réalisé avec ce système, pour un événement un peu similaire à un WordCamp.
Voici le site : http://scala.io/2013/
Fonctionnalités assez simples, une liste des séances, des orateurs, la langue des orateurs.
Un fichier Markdown par Talk, un fichier Markdown par Speaker et tout est lié
Oui, mais lié comment ?
Parce que lier les orateurs aux séances, avec WordPress, c’est extrêmement simple !
- option 1 : on a un seul orateur ? C’est un “user“, qui va être considéré comme l’auteur du post décrivant la séance. Après, archive d’auteur (core de wordpress), archive des articles par auteur…
- option 2 : on a le risque d’avoir plusieurs orateurs pour une séance ? On peut utiliser des champs personnalisés (custom meta), avec une metabox qui présente la liste des “user”, et permet une sélection multiple. Uniquement des fonctions du core de WordPress et une connaissance du HTML et du PHP. Une heure pour faire ça avec la belle interface user-friendly, celle qu’on n’a pas dans GitPages.
Les autres éléments, que ce soit au niveau des séances (lieux, horaire, niveau, langue, etc) peuvent parfaitement être gérés par des taxonomies et des champs personnalisés, en standard de WordPress. Là encore, le plus gros du travail, si on n’utilise pas un framework comme WP ALCHEMY, sera de développer les métabox qui permettront à n’importe quel utilisateur de saisir les données sans risque d’erreur, et de faire le template d’affichage.
Les metas sur les horaires permettent de faire un calendrier.
Les metas permettent même aussi, via WP Query et quelques petites listes déroulantes très simplement faites avec la fonction standard de WordPress “Get Terms” de faire des formulaires de recherche en Front End.
Les sponsors seraient un article, éventuellement un custom post type, leur logo étant stocké dans l’image à la une, le niveau de sponsoring dans une taxonomie… possibilité de faire un affichage automatique très facilement.
Temps de travail estimé : de quelques heures à deux jours, tout dépend de l’importance de l’événement et de la nécessité de former / cadrer / contrôler les utilisateurs, avec un joli templating comme ici : https://montreal.wordcamp.org/2014-fr/
Ensuite, plus besoin de former l’utilisateur non totalement technicien à Git, ni de s’inquiéter de la procédure de publication. Et si on veut, on peut mettre un cache en place !
Le modèle de données de base de WordPress permet de faire cela très simplement.
On peut même, en poussant un peu sur le templating et les archives par catégories s’offrir le luxe de faire tout cela avec uniquement les taxonomies standard (catégories et mots clés) et les types de contenus standard (articles et pages), et uniquement les champs personnalisés.
A mon avis, c’est idiot, parce que cela voudrait dire classer les types d’articles par les catégories (mauvais), et faire plus de requêtes et tests basés sur les catégories pour faire l’affichage. C’est aussi mauvais, car cela impacte la performance en front-end beaucoup plus que la création, lors de l’init, de types de posts et de taxonomies personnalisées.
Un Workflow de développeur, un outil de développeurs pour les développeurs
En fait, ce type d’outil, qui génère et remplace un site statique par un contenu mis à jour en back end est réservé à des développeurs.
Ce qui est un défaut pour les autres, et en particulier mes clients, est un avantage pour eux. Parce qu’ils font du développement, des commit toute la journée, utiliser le même outil pour la documentation, un wiki ou leur propre blog est un gain de temps et de productivité.
Je comprends aussi très bien que, lorsqu’on ne veut rien de plus qu’un blog extrêmement simple, sans aucune fioriture stylistique, où on publie 25 articles en deux ans, grosso modo un par mois, un CMS dynamique, qu’il s’agisse d’un WordPress, d’un Dotclear ou d’un CMS Made Simple, semble trop lourd.
Mais cela reste des exceptions.
Pour tous les autres, un site dynamique est, sur le moyen terme, nettement préférable à un site statique.
Petite précision, j’ai l’impression qu’il y a quelques confusions dans ton article.
Quand je dis “le CMS c’est git”, je ne parle pas spécifiquement de github pages, mais du simple fait de versionner le contenu, ce qui n’est pas vraiment pratique dans une BDD (possible, mais à des années lumières de ce qui est possible avec un outil comme git). Ton article semble mélanger ces deux choses.
L’idée que je défends, c’est qu’il est pertinent de séparer la définition des données de leur présentation (c’est une bonne pratique assez basique en programmation). Si on a affaire à des développeurs, git est un outil plutôt adapté pour ça.
Jekyll (l’outil utilisé par github pages) a des limitations, mais elles ne sont pas intrinsèquement liées à la génération de site statique (en particulier la partie sur l’i18n, qui ne pose pas de soucis particuliers avec hakyll par exemple).
Pour finir, le déploiement un peu “galère” c’est uniquement lorsque l’on veut faire le *déploiement* via git (ce qui est globalement pas une super idée (git est fait pour gérer de la source, pas du fichier généré), mais certains services de déploiement l’utilisent comme canal unique).
Un site statique versionné sous git peut tout à fait se déployer avec des outils plus adaptés de manière très simple (une bête synchro de fichiers).
Pour finir, je t’encourage à regarder http://prismic.io qui t’intéressera peut-être. Cette solution combine l’intérêt d’avoir une gestion du contenu découplée de sa mise en page, tout en étant plus “customer-friendly”.
PS: quant à la normalisation de markdown, des gens (et pas des moindres) s’y sont attelés : http://commonmark.org/
Bonjour Clément, et tout d’abord merci de ton passage et de tes commentaires.
Je ne sais pas si tu as eu la curiosité de lire l’article précédent http://lumlune/site-statique-dynamique-kesako,2014,10 qui répondait à un autre article où ta vidéo avait été incluse, à mon avis totalement à tort.
Comme tu vois, c’est tout un contexte, et je fais un peu le grand écart en essayant de m’adresser à des gens qui sont nettement moins techniques que moi, et donc a fortiori que toi.
Ce que j’ai compris :)… et tu me diras si j’ai tort, c’est que les contenus sont stockés, et qu’un certain nombre de règles permettent de générer des pages statiques en intégrant ces contenus dans des templates ?
Ce qui, pour moi, correspond à un CMS, et pas à un véritable “site statique”, en tout cas au sens où c’était donné dans l’article initial, c’est à dire un petit site codé entièrement sous notepad. C’est un CMS sans base de données, et “en cache”, mais on a bien un outil qui sépare, comme tu le dis, le contenu de la mise en forme. Plus drastiquement que sous des outils CMS classiques, c’est vrai.
ça peut avoir des avantages, notamment en légèreté de serveur, ou même en sécurité.
Néanmoins, dans mon utilisation (des sites à destination de clients finaux qui ont parfois du mal à utiliser leur mail), c’est tout simplement impensable.
Prismic (que j’étais allée voir, j’explore beaucoup de choses) ne m’intéresse absolument pas. C’est une solution très intéressante pour les workflows complexes, mais au delà de ça, c’est paradoxalement assez cher par rapport à un hébergement classique avec un CMS Open Source, et je ne vois pas de véritable avantage dans le cas d’un site monoutilisateur (pour info, WordPress gère assez bien, en base de données, le versionning du contenu).
Par ailleurs, la question de la transférabilité se pose. Je vois mal un de mes clients trouver facilement un webmaster de remplacement sur Prismic. Pour des sites sous WordPress, Joomla ou Spip, il a tout ce qu’il faut sous la main. C’est important pour lui.
C’est un peu comme la normalisation de markdown. J’ai beaucoup de reconnaissance pour les défricheurs qui créent des langages et normalisent, mais je m’y intéresserai quand ce sera fait. Pour l’instant, je n’ai pas les outils nécessaires au référencement dans Markdown. J’ai une approche très “productive” qui me pousse à éviter les solutions trop innovantes et à ne pas faire essuyer les pots cassés par mes clients.
Il y a derrière tout ça la notion du “cost of ownership”, en fait.
Salut Marie-Aude,
Merci pour tes articles toujours succulents.
Il devient de plus en plus difficile de bosser sur WordPress pour moi (pour les autres, je sais pas). Je suis simple webmaster (même pas développeur) et je construis du site internet pour des petites PMEs bien souvent (ce qui me sauve pour vendre ce n’est pas ma technique mais mon sens du détail). Bref. On passe de version en version et cela semble de plus en plus lourd (le passage au flat design du backend a en plus rendu l’interface beaucoup moins lisible).
N’étant pas développeur, je n’ai jamais compris pourquoi il ne se développait pas de CMS/Logiciel (sous Windows par exemple). En gros, tu achètes un thème, tu le customises à ton grès sur ton logiciel dans une fenêtre qui imiterais un navigateur, tu y ajoutes le contenu souhaité et hop, la moulinette balance le tout en temps différé en version HTML (ou une nouvelle page lorsqu’il s’agit d’un blog).
Hier encore je bossais sur le site de l’un de mes clients. Juste pour retravailler sa page d’accueil avec Visual Composer, j’ai mis 5h (oui, j’aime travailler les petits détails). Même travailler en local n’a pas d’intérêt. J’en ai fait l’expérience (PC muni d’un SSD), WordPress reste lourd côté admin. Alors côté visiteur, j’te dis pas. WP Optimize + WP Rocket.
WordPress commence a vraiment me dégoûter du boulot. Pour un mec qui va faire du site vitrine pourri comme un porchon, là ça prend 1h. Mais dès que tu commences à tester 1000 configurations pour rendre un truc qui donne envie, ça devient très lourd. Pesant. Chiant! Et je dois dire qu’à 600/800 euros TTC le prix du site vitrine, en réalité, c’est un taffe où il ne faut carrément pas dormir si on veut faire un truc propre. J’ai 8 ans d’expérience depuis Joomla, ça devient super pesant.
Après les devs (certains disent que vous pissez du code), s’ils veulent innover, pourquoi se casser le cul avec des frameworks destinés à se dire que vous êtes bien entre-vous? Si vous avez des idées, apportez des solutions sur WordPress, Drupal, que sais-je?
Désolée de ne pas t’avoir répondu plus tôt, Avenir :( avec plus d’un an de retard…
Nous avons deux approches différentes, je développe, j’ai appris à développer pour pouvoir customiser mes sites, et pour moi, des outils comme Visual Composer sont juste “le mal”.
Je travaille toujours en local, et si la perf est un peu moins bonne qu’en ligne, elle ne doit pas être dramatique (sinon c’est un problème de config)
Wp “core” n’est pas lourd. Un WP mal optimisé, des plugins de daube (et je rentre le composer dedans), oui. En particulier les thèmes à options, depuis quelques mois je les passe entièrement en less et supprimer le code dans le header.
Sur les sites sur lesquels je travaille pour la performance (pas le mien, pas le temps), même avec des js facebook et sharethis qui ralentissent énormément, j’arrive à des résultats du type “votre site web est plus rapide que 80% des sites visités”
Maintenant, oui, le marché du site vitrine est très difficile, et à ce prix là, tu DOIS refuser toute personnalisation.
Bonne chance