Hugo est un générateur de sites statiques. Depuis quelques années, ces générateurs ont le vent en poupe à cause de leur simplicité (enfin, façon de parler), mais qui offre une bonne flexibilité aux développeurs.

Ce qui est surtout intéressant est qu’on assiste à un retour assez drastique aux fondamentaux du web. On est parti de sites totalement statiques pour des sites de plus en plus riches avec énormément de contenus et de librairies de toutes sortes. Et à force d’empiler couche sur couche, on s’est aperçu d’un constat que le web était devenu un gros sac d’excrément et qu’il fallait absolument arrêter cette course vers les usines à gaz sous peine d’atteindre une saturation certaine.

Une fuite vers l’avant des technologies du web

Quand le web a commencé à se populariser, on faisait des sites très basiques avec du HTML et un peu de CSS. Ensuite, on a commencé à rajouter des scripts CGI avec Perl et le JavaScript a tout changé. Le JavaScript a donné le jQuery et d’autres libraries qui permettaient d’enrichir de plus en plus, mais la base des sites ne pouvaient plus supporter. Et si vous ajoutez le PHP qui est considéré comme le pire des langages en terme d’optimisation, alors on peut dire que le web a cumulé le pire du pire au fil des années. Avec chaque itération, personne n’a pris la peine de refaire des piliers plus solides et plus simples. Comme le Hardware et la connexion augmentait également, alors on s’est dit qu’on allait s’en battre les couilles et que l’ensemble tiendrait quand même le coup. Et il tient le coup. La plupart des sites vont se lancer sur le navigateur, mais est-ce qu’on doit manger un plat paraissant appétissant si on sait qu’il est fait avec des déchets ?

L’avènement et la malédiction des CMS prêts à l’emploi

Il n’y pas à dire, des CMS prêts à l’emploi ont permis à des milliers de gens de se lancer sur le web. Wordpress, Joomla, Drupal pour les plus connus ont révolutionné de nombreux aspects du web, mais c’est au détriment de la qualité. Quand des milliers de gens utilisent des outils, alors il faut constamment les étendre pour convenir aux besoins de tout le monde. Et on ne peut pas dire qu’on a chômé. Les plugins et les thèmes surchargés ont fait leur apparition dont 90 % d’entre eux étaient totalement inutile. Quand vous voyez qu’il y a des plugins sous Wordpress qui existent juste pour mettre un lien à la con en NoFollow, alors on se dit que la paresse et la médiocrité n’a plus de limite.

Mais ce n’est la faute de personne. La plupart des gens, qui utilisent les CMS, n’ont aucune connaissance du web et c’est justement pour eux qu’on a inventé le CMS. Avant les CMS “gratuits”, les CMS commerciaux coutaient la peau des fesses. Mais plutôt que de créer des CMS flexibles, légers et robustes en fournissant des formations de qualité aux nouveaux webmestres en herbe, on a préféré baisser leur qualité pour qu’ils soient les plus lisses et le prêt à l’emploi par définition. Les développeurs de Wordpress prétendent que leur CMS est utilisé par 25 millions des sites web, mais à quel prix ? Ils rajoutent constamment du code par dessus de l’ancien code en transformant l’ensemble comme un code spaghetti. Oh, Wordpress ou Joomla sont performants, mais ils sont performants sur le visual et le Bling Bling, mais sous le capot, il y a des câbles dénudés qui pendouillent dans les coins en provoquant des courts-circuits à n’importe quel moment. C’est pourquoi Wordpress corrige parfois les failles en catastrophes, car ces fondations sont loin d’être flexibles et solides.

Mais c’est un cercle vicieux insoluble. Au départ, on crée des outils les plus légers, mais on est obligé de rajouter des fonctionnalités à mesure qu’ils se popularisent et on continue sans regarder en arrière en étant porté par la Hype du moment. Mais vient toujours un temps où cela pète à la gueule. Je ne crache pas sur Wordpress ou sur Joomla, en fait, plusieurs de mes sites sont sous Wordpress, mais je le fais pour mon boulot, mais pour des questions personnelles, il faut revenir aux plus fondamentaux. Et il ne faut pas oublier que les sites personnels représentent une grande partie du web. Si des gens prennent conscience que leur CMS patauge dans la merde et la surcharge à l’extrême, alors peut-être qu’ils se tourneront vers des générateurs de site statique comme Hugo et les autres. Ou peut-être que la majorité des gens préfère le confort et la facilité d’utilisation et qu’ils vont préférer se pincer le nez en se disant que ce n’est pas leur problème puisque ce ne sont pas eux qui ont déféqués dans chaque CMS. Et ce ne sont pas les rustines comme AMP et Instant Articles qui vont régler le problème.

Accelerated Mobile Pages et Instant Articles, un prétexte pour mettre la main sur le contenu

A la fin de 2015, Google a lancé en grande pompe son format AMP (Accelerated Mobile Pages) qui voulait proposer des pages ultra-lègères et rapides pour le mobile. Il est Open Source et Google a fait des partenariats juteux avec plusieurs médias pour le pousser au maximum. Le format AMP était intéressant… à la base. L’hypocrisie de Google est sans limite avec l’AMP. Pendant le lancement, il a juré avec la main sur le coeur que l’AMP resterait aussi propre que possible et qu’il interdirait une majorité des balises HTML lourdes et surtout le JavaScript à part quelques Shortcodes autorisés. Mais au fur et à mesure, Google a implémenté de plus en plus de code pour convenir à tout le monde et on s’est retrouvé au point de départ, mais avec des problèmes bien pires.

Accelerated Mobile Pages est une technologie de cache. Donc, quand vos pages sont compatibles et validés par l’AMP, alors Google va les copier à travers ses serveurs dans le monde entier pour les distribuer à la vitesse de l’éclair. Et quand on parle de copie, c’est une vraie copie. Cela signifie que si votre site est indisponible, alors Google pourra toujours afficher vos pages en cache comme si de rien n’était. Cela parait cool, mais les dangers sont immenses. Etant donné qu’elles sont copiés sur les serveurs de Google, rien ne l’empêche celui-ci de les modifier à sa guise en intégrant des publicités par exemple. Si on veut supprimer une page, alors on ne pourra rien faire, car AMP est peut-être Open Source, mais l’accès à ses serveurs CDN est aussi verrouillé que la culotte d’une vierge musulmane.

Le contenu est le pilier le plus crucial du web. Sans contenu, pas de Google, de Facebook ou de Twitter. Sans contenu, ces géants du web ne sont que des coquilles vides sans aucune valeur. Progressivement, Google va extorquer le contenu aux éditeurs avec quelques miettes publicitaires et vous verrez que dans quelques années, tout le contenu sera disponible directement à partir de son moteur de recherche et en fait, c’est déjà le cas pour de nombreuses requêtes à fort potentiel publicitaire. Facebook n’est pas mieux en sortant son Instant Articles qui verrouille totalement le contenu sur sa plateforme. Contrairement à AMP, Instant Articles est totalement propriétaire et on n’a aucune idée de son fonctionnement. Heureusement, Facebook s’est pris un mur avec Instant Articles puisque tout le monde semble s’en battre les couilles.

Google peut utiliser des leviers beaucoup plus puissants. Etant donné que l’AMP est assez rapide et que la rapidité est un critère de référencement sur l’index mobile, alors vous pouvez être certain que tous les rats vont suivre le joueur de flute les yeux fermés. Sous prétexte d’alléger et d’accélérer le web, Google en a profité pour lancer sa plus grande attaque pour mettre la main sur le contenu. Notons que l’AMP fonctionne principalement sur Chrome, car UC Browser provoque souvent des erreurs d’affichage. En sachant qu’UC Browser est utilisé par plus de 500 millions d’utilisateurs, notamment en Asie où la connexion n’est pas la plus fameuse. Donc, les géants du web ne nous apporteront rien et les développeurs Mainstream vont constamment suivre la tendance parce qu’il faut bien faire bouillir la marmite. Mais à un niveau individuel, on peut décider de refuser ce matraquage systématique sur le fait d’avoir les plus beaux sites alors que la valeur ajoutée est proche de zéro.

Hugo, Jekyll et Octopress

Hugo est un générateur de site statique. Il est assez récent puisqu’il est apparu en 2014. Avant ça, on avait Jekyll et Octopress, mais leur installation est destiné aux développeurs et qu’elle est assez complexe. Jekyll est assez similaire à Hugo, mais celui-ci est plus simple et plus flexible. Notons que les pages publiques de Github sont développées avec Jekyll.

Hugo est développé avec le langage Go et il est considéré comme l’un des plus légers. Je ne vais pas dire que sa configuration et son installation soit facile, mais si vous lisez bien la Doc, notamment le guide d’installation (en anglais), et que vous avez déjà de l’expérience avec les sites (Pas l’expérience à la con d’une installation Wordpress), alors vous devriez en sortir. Notons qu’Octopress est également très populaire, mais faut simplement se lever de bonne heure. Mais le principe d’un générateur de sites statiques est assez simple :

  • On fait tout le développement en local
  • La structure reste très simple
  • On copie simplement les fichiers, le CSS et le JavaScript sur un dossier distant qui peut être un serveur ou un service de stockage

Et ce dernier aspect qui est le plus intéressant et montre déjà un avantage majeur de Hugo des autres générateurs de sites statiques. Ainsi, avec Hugo ou Jekyll, on peut créer le site en local, générer tous les fichiers nécessaires dans un dossier public et ce dossier, on peut le mettre sur BitBucket ou Github. Github propose un service pour héberger ses pages, mais on peut aussi utiliser un service comme Amazon S3 que j’utilise personnellement pour héberger ce site. Une fois que vous avez mis les fichiers sur BitBucket, Github ou S3, alors vous pourrez associer un nom de domaine via à ce dossier public dans le service de stockage via un CNAME.

Vous voyez tout de suite l’avantage non ? Vous n’avez pas besoin de serveur ! Plus de maintenance, de connaissances techniques avancées ou de mises à jour pour chaque faille de sécurité à cause de la fainéantise des développeurs. L’inconvénient majeur est que le dossier public doit être accessible à tout le monde pour que le site puisse fonctionner. Et donc, n’importe qui peut changer le site public. Mais on s’en fout puisque dans le cas de Hugo, votre dossier public va juste générer du HTML, du CSS et du JavaScript (ce dernier n’est pas nécessaire). Des trucs emmerdants à souhait et non pas des choses complexes telles qu’une base de donnée ou des données personnelles. Et si quelqu’un déface le site, ce n’est pas grave, car vous pourrez restaurer le site avec quelques commandes puisque tous les fichiers restent sur votre machine locale. On peut “pirater” votre site autant qu’on veut, mais vous pourrez toujours le restaurer.

Mon expérience avec Hugo, Amazon S3 et les couts d’un site statique

C’est uniquement mon expérience personnelle et j’ignore si cela peut fonctionner pour vous. En fait, j’expliquerais plus tard pourquoi ce type de changement doit toujours être une décision personnelle. Comme je l’ai dit, il existait déjà des générateurs de sites statiques comme Jekyll, mais il fallait une expérience certaine du développement et de déploiement pour les utiliser. Hugo est beaucoup plus facile à utiliser et on peut l’installer sur Windows, Mac et Linux. Une fois que vous avez installé et créer un répertoire fonctionnel de Hugo, vous devrez mettre le binaire de Hugo dans votre fichier PATH. Je sais que la configuration d’un PATH sous Windows est une abomination et je vous conseille donc d’utiliser un logiciel comme Path Editor qui vous propose une interface graphique permettant d’ajouter ce que vous voulez à votre PATH. Si vous avez créer le répertoire de Hugo dans C:\ (ce qui est recommandé), alors votre PATH doit être C:\Hugo\bin.

Ensuite, vous pourrez lancer Hugo comme n’importe quelle commande DOS. Voici les principales commandes de Hugo :

hugo new site votresite.com

hugo new /articles/votre-article.md

hugo server --theme=votretheme

hugo --theme=votretheme

La première commande hugo new site votresite.com permet de créer un nouveau site. Il vaut mieux être dans le répertoire de Hugo pour créer le site. De ce fait, votre arborescence pour un site comme le mien (mister.maniacgeek.net) sera C:\Hugo\sites\mister.maniacgeek.net.

Ensuite, la commande hugo new /articles/votre-article.md permet de créer un article appelé article.md dans le répertoire articles. Le nom n’a pas d’importance, mais il est important de créer des répertoires différents pour vos différents contenus. Ainsi, vous pouvez créer des répertoires appelés Films, Séries, Manga, Logiciels, etc. Pour un site basique, cette structure n’est pas importante, mais Hugo donne la possibilité de créer des designs particuliers selon le type d’articles.

Hugo est fourni avec un serveur intégré et on peut le lancer avec la commande hugo server –theme=votretheme. Ce qui est exceptionnel avec Hugo est qu’il supporte le Live Reloading, c’est à dire que les changements sont répercutés en temps réel à mesure que vous modifiez vos articles à la volée. Une fois que vous avez lancé cette commande hugo server –theme=votretheme, alors vous pourrez accéder à votre site en local à l’adresse : http://localhost:1313/. Une fois que vous avez crée vos articles et choisi votre thème (vous pourrez trouver quelques bons thèmes sur http://themes.gohugo.io/), vous pouvez créer les fichiers statiques.

Et on le fait avec la dernière commande qui est hugo –theme=votretheme. Dans le répertoire de votre site, vous trouverez un nouveau répertoire appelé public. Et ce sont les fichiers dans ce répertoire que vous devrez mettre sur Github et un autre service de stockage. Notons que la mise en route et le déploiement sont plus complexe, car vous devrez comprendre le concept des thèmes, des Templates et de leur hiérarchie, mais ce sont les commandes que vous utiliserez systématiquement si vous adoptez Hugo. On vous recommande de lire le guide d’introduction, car je ne ferais pas mieux que lui.

Pour vos articles, vous le trouverez dans le répertoire content. Notons que vos articles doivent se terminer par l’extension .md et Hugo nécessite que vous utilisez le Markdown. Si vous êtes habitué à un éditeur WYSIWYG comme dans Wordpress, alors il faudra un peu de temps pour s’habituer à Markdown, mais c’est assez facile. Hugo utilise un moteur de rendu appelé Blackfriday de Markdown et parfois, il bogue. Et donc, si des balises Markdown s’affichent mal, alors vous pouvez aussi utiliser les balises HTML. L’avantage du Markdown et d’un article avec l’extension .md est que vous êtes totalement libre. L’éditeur de Wordpress est minuscule et il limite vraiment la liberté. Avec Hugo et vos articles en local, vous pouvez les modifier, en créer de nouveau et les publier plus tard. Avec Wordpress et d’autres CMS, vous devrez toujours être en ligne et parfois, ce n’est juste pas possible.

Donc, vous avez crée les fichiers publics de votre site Hugo. Il y a plusieurs solutions pour les héberger. Vous pouvez prendre un serveur web standard avec un hébergement mutualisé ou un VPS ou utiliser un service comme Github, Amazon S3 ou Bitbucket. Je ne connais pas BitBucket et il semble qu’on ne peut pas associer un nom de domaine personnalisé. Github et Amazon S3 le permettent et comme je ne maitrise pas totalement Github, je vais parler d’Amazon S3. Si vous utilisez les pages de Github qui sont gratuites pour héberger votre site statique, alors vous devrez simplement payer pour le nom de domaine. Votre site Github aura une URL sous la forme http://votrenomdutilisateur.github.io. Et il suffit d’associer votre nom de domaine à cette adresse via un CNAME. Github vous propose un guide pour associer un repo Github à un nom de domaine.

Pour ma part, j’utilise Amazon S3 parce que j’y suis habitué. Il est payant, mais les prix sont vraiment abordables. Ainsi, les prix d’Amazon S3 sont de 0,023 dollars par Go par mois et 0,005 par tranches de 1 000 requêtes et 0,004 par tranches de 10 000 requêtes. Les requêtes sont le nombre de fois où vous allez accéder à vos fichiers et donc, à votre site. Un site statique ne pèse que dalle. Un petit site personnel atteindra difficile le gigaoctet à moins que vous balanciez des milliers d’images ou des vidéos. Cependant, Amazon S3 fait partie d’AWS (Amazon Web Services) et il faut s’y connaitre pour éviter que la facture explose. Mais le principal avantage d’Amazon S3 est que vous pouvez l’utiliser comme un site statique. Quand vous créez votre Bucket sur Amazon S3, il y aura une option pour créer un site statique. Cochez-la et vous obtiendez un point de terminaison qui est l’URL publique du Bucket. Notons que vous devrez configurer une politique de permission spécifique pour que le site fonctionne avec un accès public à tous vos fichiers.

L'hébergement d'un site statique avec Amazon S3

La politique de compartiment pour que le site statique d’Amazon S3 fonctionne (La votre sera différente bien entendue) :

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadForGetBucketObjects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::mister.maniacgeek.net/*"
        }
    ]
}

Et- vous voyez dans l’image ci-dessus que qu’Amazon S3 vous donne un point de terminaison. C’est actuellement l’URL de votre site statique. Testez l’URL pour voir si le site fonctionne. Et si c’est le cas, vous associez votre nom de domaine à cette URL via un CNAME. Et c’est tout, votre site statique est en ligne et vous pourrez le modifier à partir de votre machine locale. Si vous passez à Amazon S3, pour publier vos fichiers publics, vous pouvez le faire à la main ou vous pouvez utiliser un logiciel comme S3 Browser qui fait très bien le boulot. Il propose de nombreuses options, notamment une synchronisation entre votre répertoire public en local et votre Bucket sur S3. De cette manière, vous publiez uniquement les fichiers qui sont changés pour éviter de republier tout le site à chaque fois.

Pour les couts, il faut comprendre que j’utilise également Amazon S3 pour mes autres sites qui sont sous Wordpress et je dois avoir des milliers d’images sans oublier les sauvegardes et mes dépenses (pour S3 uniquement) dépasse rarement les 5 dollars par mois. Même si vous avez un gros site et que vous dépassiez les 100 Go (ce serait étonnant), alors votre cout sera de 2,18 dollars par mois (c’est uniquement pour le stockage). Et si vous ajoutez environ 1 000 000 requêtes par mois toutes catégories confondues, alors vous atteignez la somme de 7,17 dollars par mois (un site avec une moyenne de 3 000 visites dépasse rapidement le million de requête). Vous pouvez utiliser le calculateur de couts d’AWS pour voir les couts selon vos besoins. Mais franchement, Hugo est fait pour les petits sites personnels et je ne pense pas que cela convienne pour les gros sites, mais cela ne signifie pas que c’est possible, car j’aimerais que tout le monde délaisse progressivement les CMS au profit de solutions plus “bricolées” et plus intéressantes. Mais si vous m’avez lu jusqu’ici, c’est que vous avez vraiment du temps à perdre, mais que vous vous intéressez surtout aux performances d’un site statique.

La vitesse et la performance d’un site sous Hugo

A la base, Hugo est très rapide justement parce qu’il ne génère que les fichiers statiques qui sont le HTML, le CSS et le JavaScript (ce dernier n’est pas nécessaire). Mais le choix du thème sera crucial et j’ai choisi de créer mon propre thème à partir d’un thème existant pour virer les trucs inutiles. Vous pouvez le trouver sur Github. Mais avant ça, il faut parler de 2 articles qui m’ont incité à m’intéresser et à utiliser un générateur de site statique. Le premier s’intitule Most of the web really sucks if you have a slow connection qui nous dit que la majorité des sites web dans le monde sont inaccessibles si vous avez une connexion de merde. L’auteur utilise Octopress qui est trop difficile à mon gout. L’article est vraiment à lire, car la totalité des webmestres, des développeurs et des intégrateurs ont une vision occidentalo-centriste du web. Quand vous voyez un péquenot de designer qui vous disait qu’en 2015, la norme d’un site web est d’avoir une image en arrière-plan d’une résolution de 1024 x 768 pixels, alors on a envie de le battre avec une batte hérissée d’épines juste pour lui faire comprendre qu’un site web doit être accessible par tout le monde.

D’autres péquenots vont constamment utiliser l’argument fallacieux de la connexion moyenne des internautes au niveau mondial. On va nous dire que cette moyenne de connexion est de 3,6 Mbps et que donc, ce n’est pas un problème pour afficher la totalité. Ce type de raisonnement est tellement stupide que c’est navrant. C’est comme si on disait qu’il y a 2 500 meurtres par pays dans le monde en sachant que le nombre total des homicides tourne aux alentours de 500 000 pour l’année 2012. Donc, on peut dire que les Etats de Tuvalu dans l’Océan Pacifique sont le pays le plus meurtrier au monde puisqu’il ne possède que 40 000 habitants. On voit que l’établissement d’une moyenne n’a pas de sens. Même aux Etats-Unis, l’Etat du Nebrasaka possède des vitesses minables dans certaines de ses zones et on peut dire la même choses des régions rurales en France. Si vous créez votre site en se basant sur une moyenne de connexion, alors vous devriez quitter ce métier parce que vous n’avez rien compris.

Le second article intitulé The Fastest Blog In The World par Jacques Mattheij qui prétend que son blog est le plus rapide au monde. Quand on parle de la vitesse de chargement d’un site, il y a beaucoup de facteurs, mais le plus important est le ratio du téléchargement et de l’affichage. Cela indique ce que le navigateur de l’utilisateur doit télécharger pour afficher le contenu principal qui est généralement du texte. En gros, combien devez-vous télécharger pour lire 100 ko de texte ? Les naifs me diront que c’est 100 ko et bien non, c’est beaucoup plus, car aujourd’hui, dans ce web qui est atteint d’une obésité maladive, on atteint des ratios de 30 : 1, c’est à dire que pour lire 100 ko, vous devrez télécharger 3 Mo de contenus divers. Faisons quelques tests. Pour tester le nombre d’élément et le nombre de requêtes, j’utilise Firefox avec la touche de raccourci Shift + Ctrl + Q (pour le réseau et la vitesse). Pour rigoler, testons le site presse-citron.net en prenant un article au hasard (http://www.presse-citron.net/mwc-samsung-presente-galaxy-tab-s3-galaxy-book/). Si on prend uniquement le texte, alors le poids de l’article est de 3,39 ko, mais que nous dit le test dans Firefox :

Test des éléments chargés sur presse-citron

Presse-citron, un régime drastique est nécessaire. La page fait 490 ko et près de 29 requêtes ! En sachant que ce sont des résultats avec uBlock Origin et Disconnect qui sont activés. Cela doit doubler si on charge toutes les pubs et autres merdes. On a donc un ratio hallucinant de 130:1. Télécharger 490 Ko alors que le texte pèse seulement 3,39 ko, c’est vraiment du n’importe quoi. A sa décharge, l’article possède aussi 4 images qu’on peut considérer comme faisant partie du contenu. Allons voir du coté de Korben avec cet article (https://korben.info/pouvez-faire-mozilla.html). Le contenu purement textuel pèse 1,08 ko et les résultats sont effarants :

Test des éléments chargés sur Korben

1669 ko pour 1 ko de contenu et 38 requêtes ! On doit ajouter l’image, mais j’estime que l’utilisation des images est vraiment superflue. Si tu peux décrire ton contenu uniquement avec du texte, alors n’utilise pas d’images. Les captures d’écran ci-dessus sont nécessaires, car il faut prouver ce qu’on avance. J’ai pris l’exemple de Korben et de Presse-Citron, car il parait que ce sont des “blogueurs technologiques” et je dois dire que pour des technos, ils sont sauté l’étape de l’optimisation dans leurs carrières. Parce que oui, on pourrait pardonner à des blogueurs lambdas s’ils n’optimisent pas leurs sites, mais quand on est un vendeur d’aspirateurs, alors il est tout à fait bienséant de s’en servir pour nettoyer sa propre baraque avant de les refourguer aux autres. Je ne parle même pas des médias de masse ou des plateformes comme Medium avec cet article pour un contenu texte qui frole les 12 Ko, on a 3,3 mégaocets de données et 35 requêtes :

Test des éléments chargés sur Medium

On peut aussi insulter Twitter pour les mêmes raisons, car l’affichage d’un Tweet de 140 caractères nécessite une page qui pèse 2,4 Mo pour 14 requêtes. Et encore une fois, je répète que ces affichages sont obèses à l’extrême, alors que j’utilise des bloqueurs à pleine puissance. Tout ça pour dire qu’on a un énorme problème d’obésité sur le web et les prétendus “élites du web” s’en foutent totalement. Mais revenons à cette histoire de blog le plus rapide du monde. Regardons ses stats :

Test d'un site ultra-rapide

Ici, nous devons regarder deux valeurs. La première est qu’il lui faut seulement 2 requêtes pour charger toute la page et qu’elle pèse 49,44 ko. Mais là où ce article atteint des sommets d’optimisation est les valeurs en dessous. Il transfère seulement 13,21 Ko pour un total de 48,88 Ko. Son contenu textuel fait environ 5 ko ce qui nous donne un ratio de 3:1 ce qui est excellent. En gros, le contenu pèse 5 ko et il transfère un peu plus du double avec 13 ko. Sur les sites obèses, ce ratio doit se calculer par 30, 50 ou même 100. Et son blog est très rapide indépendamment de ses pages. Il a fait uniquement des optimisations de base en supprimant les trucs inutiles. Le JavaScript à la poubelle et le CSS est au minimum et il n’y a que quelques images. Et on le voit, son blog propose un design tout à fait acceptable et il faut se mettre dans le crane que c’est votre contenu principal qui intéresse les gens et non le fait que vous savez utiliser des librairies jQuery dont tout le monde s’en fout. Il est vrai que le blog de Jacques Mattheij est rapide, mais le mien peut rivaliser sans aucun problème. Voyons cet article : http://mister.maniacgeek.net/articles/inexistence-fantome/ avec un contenu textuel de 2,65 ko.

Test de la vitesse de mon site

Au total, la page pèse 17 ko et seulement 4,84 ko sont transférés, soit à peine un ratio de 2:1. Et non, il n’y a aucun problème de vitesse avec le HTTPS (on va en parler du HTTPS par la suite). Si on prend un article plus long (l’article que vous lisez actuellement par exemple en sachant que la version publiée peut-être plus lourde parce qu’il m’arrivera de rajouter des trucs par la suite) :

Test de la vitesse de mon site

Le contenu textuel est de 25 Ko pour un poids total de 75 Ko que j’affiche en 2 requêtes (le nombre de requêtes va augmenter en fonction du nombre d’image.) Je suis à un ratio de 3:1 à la limite du 4:1 ce qui est encore très acceptable. Et évidemment, il n’y a aucun code tiers. C’est à dire que vous ne verrez aucune différence sur le contenu que vous utilisiez ou non des bloqueurs. Pas de pubs, pas de tracking Google Analytics, pas de merde, pas de problème. Jacques Mattheij prétend que son article d’exemple se charge en 200 millisecondes, mais mes tests montrent que c’est plus proche de 1800 millisecondes, soit 1,8 seconde. En sachant que son article est assez court et il ne possède pas d’images. Moi, un article assez court et sans images, je peux atteindre une vitesse de 280 millisecondes. Si je rajoute une seule image, alors le temps passe à 1500 millisecondes, ce qui fait seulement 1,5 secondes. Et donc, je vais répéter mon conseil sur la modération extrême des images. Un gros article totalisant 2000 mots sera plus léger qu’un article de 500 mots avec une seule image. A la question de pourquoi j’ai utilisé mon propre thème, en fait, j’ai commencé avec un thème appelé Robust. Son principal problème est qu’il utilise Bootstrap pour le Responsive et c’est complètement con. Donc, j’ai viré cette usine à gaz de Bootstrap et je l’ai remplacé par PocketGrid développé par Arnaud Leray. Il pèse moins de 1 Ko et l’avantage est qu’on doit fournir ses propres définitions ce qui permet de définir uniquement ce qu’on a besoin.

Quand tu atteint 100100 sur l’outil PageSpeed Insights de Google

Evidemment, avec une telle optimisation sous le capot, j’obtient de très bons scores sur l’outil de PageSpeed Insights de Google. La page d’accueil (la note peut changer selon le type d’articles affichés) :

Une note de 100/100 sur PageSpeed Insights de Google

Oui, je sais que vous ragez, car votre site n’arrive même pas à dépasser les 60100 et même les 40100 sur mobile. Et j’ai 100100 sur mobile alors il est évident que c’est identique sur Desktop. Mais il suffit que votre contenu possède une seule image pour que la note baisse :

Test de PageSpeed Insights de Google

Mais on va me dire que 99100 est excellent, mais voici la petite histoire. L’image dans l’article se trouvait au milieu de l’article et j’avais une note de 91100 sur Mobile et 95100 sur Desktop. Il a suffit que je mette l’image en bas pour que la note bondisse de plusieurs points. Encore une fois, ne mettez pas des images au début d’article à moins que ce ne soit nécessaire. En comparaison, un article très long, mais sans aucune image va me donner un 100100.

Test de PageSpeed avec un article long

Evidemment, cela peut varier, car il suffit d’une petite latence sur le serveur pour que la note baisse. Et si vous utilisez des images, optimisez-les en privilégiant le JPEG en progressif et en activant les tables d’Huffman. J’utilise XnView pour Windows avec les réglages suivants. On voit que cela peut diviser le poids par 2 dans certains cas :

Optimisation du JPEG avec XnView

Je parlais de l’importance du thème. Quand j’utilisais un thème “prêt à l’emploi”, je ne dépassais pas les 75100 sur PageSpeed Insights et il a suffi que je vire cet gros lard de Bootstrap pour que je dépasse les 90100. Si vous continuez à utiliser Bootstrap dans vos projets, alors vous êtes déjà irrécupérable.

Le HTTPS, c’est pas sécurisé, mais faut avoir le beau cadenas vert

Le HTTPS m’a posé un énorme problème. Le souci est que mon site statique n’a absolument pas besoin du HTTPS. Je ne collecte pas de données d’utilisateur, je n’ai pas d’outils de statistique, je ne gère pas de paiement. C’est juste du HTML et du CSS emmerdant à souhait. Le souci est qu’aujourd’hui, le HTTPS est devenu l’argument marketing à la mode. On se contente de voir si l’URL de son site affiche le beau cadenas vert et on se fout de savoir si c’est vraiment sécurisé derrière.

Personnellement, j’aurais pu m’en battre les couilles du HTTPS, mais voilà que Chrome et Firefox affichent de plus en plus des messages anxiogènes aux utilisateurs s’ils visitent des sites qui ne sont pas en HTTPS en évitant de vérifier si le site a vraiment besoin du SSL. C’est tellement con comme mentalité, car tu peux avoir le site le plus propre du monde, mais tu peux être marqué comme dangereux par Google et Mozilla. Merci les mecs, on voit qu’il y a des mecs vraiment intelligents qui bossent dans ces boites…

Et c’est un souci parce que mon site statique n’est pas sur un serveur, mais uniquement sur Amazon S3. Je ne peux pas installer de certificat SSL comme Let’s Encrypt sans serveur. Mais j’ai trouvé 2 solutions. La première est d’utiliser Amazon Cloudfront qui est le CDN d’AWS. L’année dernière, AWS a lancé son Certificat Manager qui vous permet d’avoir des certificats SSL gratos pour les services Elastic Load Balancer et Cloudfront. Elastic Load Balancer ne nous intéresse pas, mais on peut le faire avec Cloudfront. Je ne vous détaille pas la procédure, mais en gros, il faut créer une distribution Cloudfront et vous configurez son origine comme étant le point de terminaison publique de votre Bucket Amazon S3. Dans la distribution, vous spécifiez que vous utilisez un CNAME personnalisé et vous mettez votre nom de domaine. Dans la partie SSL, vous indiquez que vous voulez utiliser Certificat Manager. Sachez que Amazon vous fournira uniquement des certificats SSL dans la zone de Virginie, donc pensez à basculer dans cette zone au moment de la demande de votre certificat sinon il ne va pas s’afficher dans Cloudfront. En général, laissez les réglages par défaut pour le SSL dans Cloudfront, car l’activation d’une seule option peut vous couter très cher. Ainsi, dans cette zone SSL, choisissez toujours l’option Certificats SSL personnalisés SNI (Server Name Indication). Mais évitez l’option Certificats SSL personnalisés à IP dédiée, car cela peut vous couter plus de 600 dollars par mois. En général, si vous n’êtes pas expérimenté avec AWS, je vous conseille vraiment d’éviter Cloudfront.

La génération du certificat SSL est un jeu d’enfant. Vous indiquez le nom de domaine que vous voulez mettre en HTTPS. Amazon va ensuite envoyer un mail à l’adresse associé à votre nom de domaine chez votre registrar. Il suffira de valider la demande et votre certificat sera généré. Ensuite, il faut associer l’URL de votre distribution Cloudfront à votre nom de domaine via un CNAME chez votre registrar. Donc, nous avons un schéma du genre : Utilisateur -> Nom de domaine avec le CNAME vers Cloudfront -> La distribution Cloudfront -> votre bucket Amazon S3.

J’ai réussi à le faire, mais comme Cloudfront est un vrai CDN dans la mesure où il va dupliquer votre contenu sur tous ses Datacenters à travers le monde, je ne pouvais plus mettre à jour mon site puisque seule la version en cache s’affichait. Je pense qu’il y a un oubli dans ma configuration de Cloudfront qui provoque ce problème, mais j’ai laissé tomber. De plus, Cloudfront est payant et la facture peut grimper si vous avez beaucoup de visites.

Ensuite, je suis passé chez Cloudflare. Et j’ai réussi à le faire. Il faut bidouiller un peu, mais ça marche et vous voyez que ce site est en HTTPS. Malheureusement, Cloudflare vous donne une impression de sécurité, mais il n’utilise pas un chiffrement optimal. Il se contente de chiffrer la connexion entre l’utilisateur et les serveurs de Cloudflare, mais la connexion entre les serveurs de Cloudlfare et votre site est en clair. De plus, Cloudflare est assez dangereux et je pense qu’il faudra que je le délaisse à l’avenir. Malheureusement, comme Google et les autres débiles promeuvent le HTTPS à toutes les sauces, je suis obligé de passer par Cloudflare pour le moment. C’est un incroyable non ? Vous passez des semaines à optimiser votre blog en réduisant les risques au maximum et ce sont les recommandations des prétendus géants du web qui vous mettent dans la mouise. C’est comme si on traitait le cancer avec une injection de VIH !

Un cheminement personnel et revenir au concept fondamental du blog en tant qu’un journal intime

Toutes les étapes que je viens de décrire concerne simplement mon cheminement personnel et ma vision de ce qu’est le web aujourd’hui. Cela fait presque 15 ans que je suis sur le web et que j’ai vu passer de bonnes choses, mais également que les meilleures intentions deviennent des vraies saloperies qui enchainent constamment les utilisateurs dans des systèmes de minitel 2.0 et totalement verrouillés. Si le mec lambda possède une petite entreprise ou une épicerie du coin et qu’il veut lancer un blog parce qu’un crétin de marketing 2.0 lui a de le faire, alors il est évident qu’il va passer sous Wordpress.

Il s’en fout d’avoir un 100100 sur PageSpeed Insights ou qu’une page qui fait 3 Mo pour afficher un seule paragraphe montre simplement que les développeurs et les designers sont pires que des fainéants ou qu’ils sont juste médiocres. Et s’il vient me demander conseil, alors je le dirigerais aussi vers Wordpress ou Joomla. Mais peut-être que dans 15 ans, il se posera les mêmes questions que moi et que peut-être qu’il tombera sur cette page (elle sera sans doute sur Web Archive puisque ce blog aura sans doute disparu) et qu’il trouvera l’aide nécessaire. Mais il ne faut pas oublier que nous sommes pionniers et que ceux qui vont nous suivre s’inspireront de ce que nous avons fait. Quand nous avons des blogueurs technologiques qui parlent du web comme des experts alors qu’ils continuent à la transformer en une véritable poubelle, alors on se dit que l’espoir est mince et que l’avenir du web, comme une plateforme de connaissances, disponible pour le monde entier, indépendamment de son statut social, est une chimère. Le web est pour les riches et il le sera davantage à l’avenir. Tous les autres secteurs tels que les Smartphones, les tablettes, les jeux vidéos sont déjà réservé pour une classe de personnes ultra-riches.

Une autre raison qui m’a poussé à lancer ce blog statique est justement de revenir au concept de blog comme un journal intime. Dans un journal intime, on peut parler de la dernière fille qu’on a pécho dans une soirée ou faire des hypothèses macroéconomiques pour refaire le monde. Ou encore, qu’on a une nouvelle idée sur la gravitation quantique. Dans le web actuel, la centralisation de l’identité est sanctifiée à l’extrême. Par exemple, sous Blogger, vous pouvez avoir 10 blogs sur des sujets totalement différents et pourtant, vous êtes obligé d’utiliser la même identité (on me dit dans l’oreille que des pseudos sont possibles, mais ce n’est pas suffisant). Je ne parle même pas de Facebook où le fait d’utiliser un pseudo est criminel. En empêchant une personne d’avoir plusieurs identités afin de s’exprimer en toute liberté, on crée un espace totalement restreint où la moindre chose que vous publiez se colle à vous comme un PQ de mauvaise qualité après un festin particulièrement gras

Il y a un autre problème qui est totalement négligé sur le web et qui va à l’encontre de la nature humaine. Le fait qu’une personne peut changer d’avis. Aujourd’hui, on est classé dans une seule catégorie. Tu es un blogueur Tech, ou un activiste ou un partisan d’extrême-droite ou que tu te balades souvent avec des musulmans. Et le pire est qu’on considère ce qu’on a dit il y a 10 ans comme étant toujours d’actualité aujourd’hui, alors que les gens changent en une décennie. Mais évidemment, on va me dire que des générateurs de site statique comme Hugo ne vont pas résoudre tous ces problèmes, car au final, c’est juste une plateforme technique. Oui, mais le point important est qu’on doit régulièrement faire autre chose. Si vous vous encroutez dans une routine, que vous continuez à utiliser la même plateforme, alors vous allez progressivement être verrouillé par les changements forcément négatifs qui vont se produire comme la grenouille qui ne sent pas que l’eau bouillit progressivement. La totalité des plateformes, qui vous facilite énormément la vie, sont également celles qui vous emprisonnent le plus. Hugo propose des outils, plus ou moins performants, pour exporter vos contenus d’autres plateformes, notamment Wordpress.

Mais tout le monde sait que l’exportation et l’importation de Wordpress est codé à la pisse et qu’il est impossible que ce processus, en apparence simple, devienne un cauchemar. Des gens ont perdu la totalité de leur blog à cause d’une mauvaise importation. Est-ce qu’on peut penser réellement que c’est simplement un mauvais codage. Non, ce codage minable est artificiel, car cela dissuade les gens de faire autre chose ou de passer à une alternative.

J’ignore si ce blog existera toujours la semaine ou l’année prochaine. Mais je sais qu’il faudra tenter de nouvelles choses pour éviter les systèmes dominants actuels du web qui vont tous dans le mauvais sens. Cet article aborde le problème différemment en estimant que c’est un mensonge et une énorme propagande que le web est compétitif et que chacun peut réussir. Google, Facebook, eBay et Amazon faussent déjà les résultats pour promouvoir leurs propres outils. Concernant Amazon, on peut me reprocher le choix de S3 alors qu’il fait partie des GAFAM alors que j’aurais pu passer par Github. Il est vrai qu’Amazon possède des pratiques dégueulasses, notamment dans ses conditions de travail inhumaines pour les employés, mais je sais aussi que sa réputation se base sur l’autonomie de ses services pour ses clients. Github propose des services gratuits pour héberger ses pages. Mais on ne peut pas garantir que cela existera dans quelques années. On se souvient de Google Code qui hébergait des milliers de projet et du jour au lendemain, Google l’a fermé sans préavis en disant aux développeurs d’aller se faire foutre. Vu l’apport financier gigantesque d’AWS pour Amazon, alors il serait étonnant qu’il pourrisse son service et surtout, n’oubliez pas qu’il n’y pas de services gratuits sur le web. Vous payez d’une façon ou d’une autre et c’est mieux quand on nous demande de payer en toute transparence en nous proposant un service garanti.

Et quand on fait ce type de cheminement, il faut penser après la mort du blog. Comme je l’ai dit, j’ignore si ce blog va exister pendant longtemps. Mais étant donné que je l’ai crée avec les composants les plus simples et les plus standardisés qui soient, alors j’ai la garantie que des services comme Web Archive pourront l’archiver plus facilement. J’ai déjà parcouru des pages sur Web Archive et il y en a beaucoup qui sont illisibles pour la bonne et simple raison qu’une grande partie de leur contenu est fourni par des parties tierces et que la page est totalement cassé en l’état.

Un site statique, c’est vraiment Has Been !

Je vois déjà des blogueurs de la pensée dominante ou des développeurs qui ont une formation de merde me dire que les sites statiques, c’est un truc des années 2000. Et surprise, de nombreux sites universitaires n’ont pas changé depuis plus de 20 ans. Est-ce que les instituts scientifiques sont trop cons pour créer des sites ultra-cools, mais codés par des macaques ? Non, parce que du moment que ça marche, alors pourquoi se précipiter vers la dernière mode ? Allez faire un tour sur l’annuaire du CNRS et vous m’en direz des nouvelles. Et concernant l’aspect ringard, les générateurs des sites statiques seront la prochaine grande tendance. En tout cas, j’aime à le croire. Ils combinent le meilleur des 2 mondes. Ca permet d’avoir un site très flexible et très simple avec les derniers outils du web. Le langage Go est très récent et Hugo est fait avec le Go. La simplicité de Hugo surpasse largement la prétendue facilité de Wordpress par un facteur de 1000. Mais testons si un site statique comme le mien respecte les standards du web actuel :

  • C’est un site très rapide et la rapidité est un critère crucial pour le Desktop et le mobile
  • C’est un site entièrement Responsive. En fait, mon site s’affiche plus rapidement sur le mobile que les technologies AMP et Instant qui prétendent un affichage instantané.
  • Il est en HTTPS même on a vu que c’est juste un argument marketing.
  • Il propose des boutons de partage vers les principaux réseaux sans aucun tracking
  • Il inclut des métadonnées pour la balise NewsArticle et je peux facilement en ajouter de nouvelles selon la norme Schema.org

Et voilà, ce sont les standards du web et mon blog les respecte plus que de nombreux sites sur le web. Evidemment, je vais manquer le fameux argument du dynamisme. Mais comme c’est un blog purement personnel, je n’ai pas besoin de spammer les utilisateurs avec des Newsletters à la con ou de foutre des bandeaux publicitaires à chaque fois qu’un utilisateur prend la peine de venir. Le concept de base de donnée et de langages dynamiques n’a aucun intérêt pour un site personnel. On ne traite pas les données de millions d’utilisateurs, on ne fait pas de transaction et on n’est pas des grosses entreprises. Et je défie n’importe qui de me décrire une chose qu’on ne peut pas faire avec du simple HTML. Le contact, le partage, l’intégration d’un flux RSS, tout peut faire via du HTML et à la rigueur du JavaScript. Mais même Hugo n’échappe à la médiocrité ambiante. J’ai parlé de l’utilisation de Bootstrap pour les thèmes et c’est ironique de l’utiliser, car Bootstrap est le principal coupable qui a pourri définitivement le Responsive Design. Et donc, à force d’intégrer constamment de nouveaux éléments pour faire comme tout le monde, alors l’outil le plus léger va prendre du poids comme un malotru.

J’ignore quand est-ce que ça s’est passé, mais à une époque, tous les blogueurs ont subi la propagande qu’il fallait qu’ils ressemblent à des pros. Il fallait toujours mettre une image de couverture à l’article, il fallait mettre 154 boutons de partage, il fallait inciter les utilisateurs à fournir leur adresse, il fallait faire ceci ou cela. Moi même je l’ai fait il y a plus de 10 ans parce les conseils de blogging étaient à la monde, mais aujourd’hui, je me sens comme un employé d’un casino dont le patron aurait obligé à forcer des milliers de personnes naives à dépenser tout leur salaire dans une table de roulette. Donc, abandonnez tous les conformismes de cool, de marketing et de SEO et privilégiez la vitesse, la vitesse, la vitesse et encore la vitesse. Si votre site n’est pas rempli de toutes les merdes possibles, alors les gens reviendront vous voir (voilà que je me remet aux conseils de blogging). Et ils vont revenir, car la majorité des sites seront largement inférieurs aux autres. Est-ce que vous avez déjà vu un article qui parle de CMS et de site statique qui fait 8 000 mots ?