Chibi-nah::blog

Des geekeries, de la MAO, de tout et de rien…

Archives

Pour votre confort, ce blog utilise ces technologies avancées : NoJS, NoAds, NoCDN et NoCookie

Introduction

Vous avez sans doute (ou pas) remarqué cette phrase au bas de ce blog : « Pour votre confort, ce blog utilise ces technologies avancées : NoJS, NoAds, NoCDN et NoCookie. »

Concrètement, qu'est-ce que cela signifie ?

Note

Certaines explications seront volontairement simplifiées pour que cela soit plus facile à comprendre.

Site statique vs. site dynamique

Revenons un peu en arrière. En 2020, j'ai changé de moteur de CMS (le logiciel qui génère ce blog), pour passer sur un générateur de site statique.

  • site statique : site dont le contenu est généré une seule fois et mis à disposition directe. Pratique pour un site dont le contenu ne change que très peu. À opposer à site dynamique.
  • site dynamique : site dont le contenu est créé de manière dynamique, lorsque l'on veut consulter une page. Cela permet de modifier complètement le contenu sans à avoir à recréer toute la page à la main. Pratique pour un site dont le contenu change sans arrêt, comme un journal, ou dont ce qui doit s'afficher sur la page est complètement imprévisible (comme un moteur de recherche ou un site météorologique).

Ces deux approches ont leur avantages et leurs inconvénients.

L'ancien blog utilisait un générateur de site dynamique.

Avantage : possibilité d'éditer ou d'ajouter du contenu depuis n'importe où, possibilité d'ajouter des commentaires (vu la quantité de spam reçu dessus, c'était pas non plus le meilleur truc).

Cependant, un générateur de site dynamique est plus compliqué à faire fonctionner, parce que du code doit être exécuté côté serveur (pour construire la page) avant de le fournir au navigateur web. Un affichage d'une page signifie une génération complète de cette page, et ce, à chaque demande.

Admettons qu'une page d'un site web dynamique ait 1 000 vues dans la journée. Cette page devra être générée 1 000 fois. Systématiquement. À chaque affichage. Pour limiter cela, on peut ajouter un peu plus de complexité pour mettre en cache (générer la page dynamique comme une page statique) et ne mettre à disposition que cette page qui ne sera générée qu'une seule fois dans la journée.

De plus, pour éditer du contenu, il faut ajouter de la gestion de comptes.

Notamment des comptes admin (gestion du site) et rédaction (pour rédiger le contenu).

Comment différencier un compte anonyme d'un compte authentifié ? Il faut que le service sache qui est connecté.

Pour cela, on utilise un cookie (un fichier texte contenant des informations utilisées par le serveur pour déterminer qui est connecté avec quel compte).

Éditer du contenu, c'est bien. Faciliter la rédaction, c'est mieux.

Du coup, on ajoute du code côté navigateur (javascript), qui va alors proposer de voir en temps réel le contenu au cours de sa rédaction, simplifier l'application du texte en gras, en italique, et plus.

Ça devient très vite lourd. Parce qu'il faut :

  • un logiciel/service pour exécuter du code côté serveur (par exemple PHP) ;
  • un logiciel/service pour stocker les données (par exemple MariaDB/MySQL) ;
  • un logiciel/service pour mettre à disposition à un navigateur web les différentes ressources (contenu, images, style, …), par exemple Apache httpd, nginx, lighttpd… ;
  • un logiciel/service s'exécutant côté navigateur pour pouvoir rédiger du contenu ;
  • s'assurer que tout fonctionne correctement, sans problème de performances, en appliquant les correctifs de sécurité, et veiller à ce que rien ne tombe en rade lors d'une mise à jour (c'est arrivé à plusieurs reprises).

Pour un site personnel, s'occuper de tous ces problèmes, c'est long et pénible sur la durée.

On peut passer par des plate-formes ou des sites s'occupant de tous ces problèmes, moyennant paiement direct, en euros, dollar, yen… ou en grattant un maximum de données possible (qui est venu, quand, comment, via qui, google ? facebook ?, qu'est-ce qu'il/elle lit, centre d'intérêt ?)

En 2020, je me suis posé ces questions, et j'ai fini par déterminer qu'un site statique serait plus adapté à mes propres besoins au niveau blog.

Le blog

Mes contraintes étaient simples :

  • contenu statique généré une seule fois ;
  • abandon des commentaires ;
  • pas de partie administration/rédaction ;
  • avoir le site le plus simple possible.

Avec ces éléments, on peut donc retirer :

  • le logiciel/service pour stocker les données ;
  • le logiciel/service pour exécuter du code côté serveur ;
  • le logiciel/service s'exécutant côté navigateur pour pouvoir rédiger du contenu.

Il ne reste donc plus que :

  • un logiciel/service pour mettre à disposition à un navigateur web les différentes ressources.

Arrivé ici, cela simplifie pas mal la gestion côté serveur.

Cependant, on n'a pas résolu le problème. On n'a fait que le déplacer. Où ça ? Sur mon ordinateur :

  • Je dois toujours pouvoir rédiger du contenu (comme celui-ci en cours de rédaction) ;
  • Les différents articles doivent être stockés quelque part ;
  • Un logiciel doit s'exécuter pour transformer les différents articles en pages différentes d'un site web.

Le blog étant généré avec le logiciel Pelican. Plus précisément, c'est un CMS, pour Content Management System, ou système de gestion de contenus.

Ce logiciel impose une structure pour rédiger les articles :

  • une certaine organisation pour les répertoires, dont ceux pour les articles, ceux pour le style, ceux pour le template ou patron de conception qui va permettre de générer les différentes pages… ;
  • un fichier texte par article, articles rédigés dans un langage de mise en forme adapté comme Markdown ou RestructuredText.

Cela impose une petite gymnastique mentale au début, et après 2-3 erreurs, on arrive à générer quelques pages simples.

L'import des anciens articles étant relativement compliqué (et j'en ai déjà parlé par le passé), je ne m'étendrai pas dessus.

cf. https://blog.chibi-nah.fr/nouvelles-du-blog-2020 et https://blog.chibi-nah.fr/nouveau-blog-2020

Une fois les articles écrits et passé à la moulinette via pelican, j'obtiens des pages html (en fait, un site web complet) tout prêt. Ne reste qu'à copier tous ces fichiers sur un site pour le rendre accessible.

Bien entendu, j'ai automatisé ces tâches de passage à la moulinette et copie sur le site :D

Du coup, pas de contenu dynamique, pas besoin de suivre les comptes. Cela me permet donc de retirer les cookies et javascript.

Donc :

  • noJS (pas de javascript) ;
  • NoCookie (pas de cookies).

La publicité

Sujet toujours épineux entre les personnes payant un service d'hébergement pour le blog mais souhaitant que cela revienne le moins cher possible, ou les hébergements “gratuits” mais affichant de la publicité (sur Internet, il y a toujours quelqu'un qui paie), et ceux voulant gagner un maximum d'argent sans faire le moindre effort…

Ne souhaitant toujours pas monnayer le contenu (aucun intérêt, pas de recherche de « sponsors » ni de création d'articles escroclic), il n'y a pas de publicité.

Donc :

  • NoAds (Pas de publicité).

Le contenu distribué

Ou comment mettre les ressources essentielles chez quelqu'un d'autre.

Le contenu distribué, ou Content Delivery Network, à la base, cela semblait partir d'une bonne idée.

Plutôt que de stocker toujours les mêmes fichiers sur différents sites, autant les stocker au même endroit. Par exemple, si un site sur cent utilise la même ressource, comme le fichier LaLibSuperÀLaModeVersion3.14.js, alors si on le stocke sur un site spécialisé, le CDN, ce fichier sera chargé une seule fois et sera réutilisé (parce que stocké en local/mis en cache dans le navigateur) et ne sera plus à re-télécharger par la suite.

Dans la pratique…

  • il y a presque autant de versions différentes des fichiers ressources que de site web (la version 1.14, la version 1.15, la version 2.03, la version 3.14, 3.145…
  • les ressources étant centralisées en un seul point, cela permet de suivre facilement où sont les gens (quand le navigateur interroge le CDN, il est en fait assez bavard), et par extension, si ce site tombe en panne, les ressources ne sont plus disponibles. Dans le meilleur des cas, ça ne fait que perturber l'affichage. La plupart du temps, le site ne fonctionne pas.

Au niveau des ressources, outre les fichiers javascript (déjà évoqué plus haut), c'est aussi pas mal utilisé pour les polices de caractères (souvent hébergées chez Alphabet, notamment sa filiale publicitaire qu'est Google).

Ne souhaitant pas participer à cette masquarade qu'est le CDN (accessoirement, qui est plutôt limite voire illégal vis-à-vis du RGPD en Europe), on va se passer de ce genre de “service”.

Donc :

  • NoCDN (Pas de CDN).

Au final

En fait, pas de technologie avancée, juste différents choix technologiques pour me simplifier la vie (et celle des personnes visitant le site), en n'utilisant pas des technologies qui sont ici inutiles.

Si je récapitule :

  • NoJS, pas de javascript ;
  • NoAds, pas de publicité ;
  • NoCDN, pas de CDN ;
  • NoCookie, pas de cookies.

Une dernière chose

En fait deux :

  • Certaines pages ont des vidéos intégrées. Il s'agit soit d'une simple balise video html5, soit d'un cadre pointant vers mon instance PeerTube, s'exécutant en dehors du blog ;
  • L'affichage avec un thème clair ou sombre dépend du navigateur web, et de l'utilisation  « intelligente » des feuilles de style (MediaQueries).

Pour aller plus loin

En fait, on peut très bien avoir un blog gé(né)ré différement. Voir par exemple Gemini https://geminiquickst.art/ (article en anglais), https://ploum.net/gemini-le-protocole-du-slow-web/index.html (article en français), voire gopher (pour les personnes plus expérimentées).