Un ami veut relire votre article de blog en cours de rédaction, mais sa prévisualisation ne tourne que sur localhost:8080. Plusieurs outils peuvent aider. Certains sont des services commerciaux, comme ngrok ou Cloudflare Quick Tunnels. D’autres peuvent être auto-hébergés, mais exigent un client dédié, comme frp ou localtunnel. D’autres encore se contentent d’un simple client SSH, mais reposent sur un serveur SSH spécifique, comme sish. Voyons comment mettre en place une solution auto-hébergée avec juste OpenSSH et nginx !

$ ssh -R 0:localhost:8080 http-over-ssh
Allocated port 41535 for remote forward to localhost:8080
https://6J3jK1WmB15c6WmjW_X-Wg--1789928654@p41535.ssh.luffy.cx/

Configuration de base

Tout d’abord, nous redirigeons vers votre service local les connexions reçues sur un port d’un serveur distant :

$ ssh -N -R 0:localhost:8080 web02.luffy.cx
Allocated port 41535 for remote forward to localhost:8080

Lorsque nous indiquons 0 comme port distant, le serveur alloue un port libre. Ensuite, nous configurons nginx pour relayer les requêtes de https://p41535.ssh.luffy.cx vers http://127.0.0.1:41535 :

server {
  listen 0.0.0.0:443 ssl ;
  listen [::0]:443 ssl ;
  server_name ~^p(?<port>\d\d\d\d\d)\.ssh\.luffy\.cx$;
  location / {
    proxy_pass http://127.0.0.1:$port;
  }
}

Il faut aussi ajouter des enregistrements DNS pour *.ssh.luffy.cx et obtenir un certificat générique auprès de Let’s Encrypt :

*.ssh.luffy.cx.               CNAME web02.luffy.cx.
ssh.luffy.cx.                 CAA   0 issuewild "letsencrypt.org"
_acme-challenge.ssh.luffy.cx  CNAME ssh.luffy.cx.acme.luffy.cx.

acme.luffy.cx est une zone hébergée sur Route 53. Je l’utilise pour les défis ACME DNS-01, aussi bien pour les certificats génériques que pour les domaines servis par plusieurs serveurs web. Dans mon cas, NixOS obtient les certificats automatiquement.

Contrôle d’accès

Le port est le seul « secret¹ » qui protège la confidentialité du contenu. D’autres solutions de redirection ajoutent une chaîne aléatoire au nom de domaine pour empêcher un intrus d’énumérer les valeurs possibles.

Grâce au module ngx_http_secure_link_module, nous pouvons renforcer un peu la sécurité de cette configuration. Ce module calcule une empreinte² sur un ensemble de valeurs, dont un secret, et la compare à celle fournie dans la requête. L’empreinte est encodée en base64 : impossible donc de la placer dans le nom de domaine, qui est insensible à la casse. Nous l’insérons plutôt dans l’URL, comme nom d’utilisateur, avec sa date d’expiration³ :

https://6J3jK1WmB15c6WmjW_X-Wg--1789928654@p41535.ssh.luffy.cx/fr/blog
        ╰─────────┬──────────╯  ╰───┬────╯  ╰─┬─╯             ╰──┬───╯
              empreinte        expiration   port              chemin

Le client envoie le nom d’utilisateur au serveur avec l’authentification HTTP basique. Cela fonctionne avec la plupart des clients HTTP, dont curl. Nginx expose le nom d’utilisateur dans la variable $remote_user. Le module attend l’empreinte et la date d’expiration séparées par une virgule. À l’aide d’une directive map, nous extrayons les deux parties de $remote_user et les formatons comme attendu⁴. Nous fournissons aussi au module la chaîne à hacher. Elle contient la date d’expiration, le port et un secret :

map $remote_user $httpssh_link {
  "~^([-_A-Za-z0-9]{22})--([0-9]+)$" "$1,$2";
}
server {
  # […]
  location / {
    secure_link $httpssh_link;
    secure_link_md5 "$secure_link_expires $port ZuPerS3cr3!";
  }
}

Le module renvoie le résultat de la vérification dans la variable $secure_link :

• vide si les empreintes ne correspondent pas ;
• "0" si elles correspondent, mais que le lien a expiré ;
• "1" sinon.

Si l’empreinte est incorrecte ou absente, nous renvoyons une erreur 401 avec un en-tête WWW-Authenticate pour réclamer des identifiants. Si le lien a expiré, nous renvoyons une erreur 410. Nous retirons l’en-tête Authorization avant de transmettre la requête et ajoutons quelques directives pour relayer les connexions WebSocket. Voici la configuration complète⁵ :

map $remote_user $httpssh_link {
  "~^([-_A-Za-z0-9]{22})--([0-9]+)$" "$1,$2";
}
server {
  listen 0.0.0.0:443 ssl ;
  listen [::0]:443 ssl ;
  server_name ~^p(?<port>\d\d\d\d\d)\.ssh\.luffy\.cx$;
  location / {
    secure_link $httpssh_link;
    secure_link_md5 "$secure_link_expires $port ZuPerS3cr3!";
    if ($secure_link = "") {
      add_header WWW-Authenticate 'Basic realm="tunnel"' always;
      return 401;
    }
    if ($secure_link = "0") {
      return 410;
    }
    proxy_pass http://127.0.0.1:$port;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Authorization "";
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_buffering off;
    proxy_read_timeout 30m;
  }
}

Je pense que vous vous posez maintenant la question évidente : « Comment générer l’empreinte ? » Un jeu d’enfant !

$ expires=$(( $(date +%s) + 86400 ))
$ port=41535
$ secret='ZuPerS3cr3!'
$ printf '%s %s %s' "$expires" "$port" "$secret" \
>   | openssl md5 -binary \
>   | openssl base64 \
>   | tr +/ -_ | tr -d =
6J3jK1WmB15c6WmjW_X-Wg

Bon, je suppose que vous vous dites maintenant : « Vincent, ce n’est pas très pratique ! Si ça ne te dérange pas, je vais garder ngrok. » D’accord, d’accord. Écrivons un script pour fluidifier ça.

Script utilitaire

La principale difficulté est de trouver le port éphémère alloué par OpenSSH, car il n’apparaît dans aucune variable d’environnement⁶. Pour contourner cet obstacle, nous cherchons parmi les ancêtres les processus sshd-session⁷ :

pids=$(
  pid=$$
  while [ "$pid" -gt 1 ]; do
    line=$(ps -o comm=,pid=,ppid= -p "$pid")
    echo "$line"
    pid=${line##* }
  done | awk '$1 == "sshd-session" { printf "pid=%s,\n", $2 }'
)
if [ -z "$pids" ]; then
  echo "not an ssh session" >&2
  exit 1
fi

Ensuite, nous récupérons les ports en écoute associés à ces processus sshd-session⁸ :

ports=$(sudo -n ss --listening --numeric --tcp --processes --no-header \
  | grep -F "$pids" \
  | awk '{ print $4 }' | awk -F: '{ print $NF }' \
  | sort -un)
if [ -z "$ports" ]; then
  echo "no forwarded port, use ssh -R 0:localhost:PORT" >&2
  exit 1
fi

Enfin, nous affichons les URL et gardons la session ouverte :

lifetime=86400
secret='ZuPerS3cr3!'
expires=$(( $(date +%s) + lifetime ))
for port in $ports; do
  token=$(printf '%s %s %s' "$expires" "$port" "$secret" \
            | openssl md5 -binary \
            | openssl base64 \
            | tr +/ -_ | tr -d =)
  echo "https://$token--$expires@p$port.ssh.luffy.cx/"
done
sleep infinity

J’installe ce script sous le nom http-over-ssh sur le serveur et j’ajoute cette entrée à mon ~/.ssh/config :

Host http-over-ssh
  Hostname web02.luffy.cx
  RemoteCommand http-over-ssh
  ControlPath none

Avec cette solution, je ne dépends que d’OpenSSH et de nginx, deux logiciels qui tournent déjà sur ce serveur. Une commande toute simple me fournit un tunnel auto-hébergé et une URL à partager. Pour l’essayer, récupérez le script utilitaire complet, qui contient quelques petites améliorations. Si vous utilisez NixOS, comme toute personne de goût, jetez aussi un œil à mon http-over-ssh.nix. ❄️

En 2016, j’ai retiré Google Analytics de ce blog pour ne pas me rendre complice de la plus grande machine à aspirer les données personnelles. À la place, j’analysais les journaux de mes serveurs¹ avec GoAccess. Depuis quelques années, les statistiques ne veulent plus rien dire, malgré mes tentatives pour filtrer les robots : les robots pilleurs des IA gonflent le nombre de visiteurs à environ 2 000 par jour. J’ai fini par adopter GoatCounter, une plateforme libre de mesure d’audience, respectueuse de la vie privée. J’ai remplacé le client JavaScript pour filtrer les robots de façon plus agressive et ajouté une solution de repli en CSS. Pour gagner en fiabilité, j’ai écrit un proxy local, installé sur chacun des cinq serveurs web qui hébergent ce blog. La suite de cet article détaille comment ces éléments s’articulent et comment je déploie l’ensemble sur NixOS. ❄️

Pourquoi GoatCounter ?

GoatCounter ne collecte aucune donnée personnelle : au lieu de stocker l’adresse IP du lecteur ou de s’appuyer sur des cookies, il crée un identifiant de session valide 8 heures à partir de l’agent utilisateur et de l’adresse IP. Ses fonctionnalités sont modestes, mais suffisantes pour un blog. Pour un aperçu de l’interface, l’auteur de GoatCounter propose une instance publique pour son site. Une version en ligne permet de l’essayer avant de l’héberger soi-même. Avec un seul binaire et une base de données SQLite, GoatCounter est l’une des solutions auto-hébergées les plus légères. Parmi les alternatives respectueuses de la vie privée figurent, par ordre croissant de complexité, Umami, Plausible et Rybbit.

Client JavaScript sur mesure

GoatCounter fournit un petit client JavaScript : 2 189 octets une fois minifié et compressé avec gzip. Il embarque des fonctionnalités dont je ne me sers pas : un compteur de visites, le suivi des clics, divers réglages, etc. Je le remplace par cette fonction pour enregistrer une visite :

const count = ({ event, title } = {}) => {
  const params = new URLSearchParams({
    p: event || location.pathname,
    t: title || document.title,
    r: document.referrer,
    q: location.search,
    s: document.documentElement.clientWidth,
    e: !!event,
    rnd: Math.random().toString(36).slice(2, 7),
  });
  fetch(`/count?${params}`, { keepalive: true }).catch(() => {});
};

Pour filtrer les robots², je vais plus loin en exigeant une interaction de l’utilisateur, une idée reprise de Bear Blog.

let sendHit = () => (sendHit = () => {}, count());
["touchmove", "mousemove", "keydown", "pointerdown"].forEach((eventName) =>
  document.addEventListener(eventName, sendHit, {
    once: true,
    passive: true,
  }),
);

Si un lecteur a désactivé JavaScript dans son navigateur, j’enregistre la visite à l’aide d’une image CSS. La pseudo-classe :hover ne la charge qu’après une interaction, une autre astuce piquée à Bear Blog. Environ 2 % de mes visiteurs entrent dans cette catégorie³.

<!DOCTYPE html>
<html lang="en" class="nojs">
  <head>
    <script>
      // Le code JavaScript de ce blog requiert ES6
      if ("noModule" in HTMLScriptElement.prototype)
        document.documentElement.classList.remove("nojs");
    </script>
  </head>
  <body>
  <!-- ... -->
    <style>
      .nojs body:hover {
        border-width: 0;
        border-image: url('/count?p=/en/blog/2026-kpi-goodhart&t=Building...&r=NoJS&e=false');
      }
    </style>
  </body>
</html>

Là où GoAccess annonçait environ 2 000 visiteurs par jour, GoatCounter compte moins de 200 humains⁴. Je suppose que ces pilleurs privilégient le moindre effort : si le contenu est accessible sans obstacle, comme sur ce blog, ils ne vont pas lancer une usine à gaz qui déclencherait une page vue. Même les robots qui exécutent JavaScript, comme Googlebot avec son Chromium sans interface, n’interagissent pas avec la page et ne déclenchent jamais les événements que j’écoute. La « preuve d’humanité » par l’interaction que j’utilise me semble pouvoir durer⁵.

Proxy local

Cinq serveurs à travers le monde en Europe et en Amérique du Nord servent le contenu de ce site, mais GoatCounter ne tourne que sur l’un d’eux. Pour ne pas perdre la trace des visiteurs quand GoatCounter est indisponible, j’exécute un proxy local qui écoute sur le même point de terminaison /count. Sur chaque serveur, il conserve les visites en mémoire, avec un tampon assez grand pour tenir plusieurs jours en cas d’indisponibilité. Il les envoie par lots au serveur amont via le point de terminaison authentifié /api/v0/count.

J’ai proposé le code du proxy dans la pull request #909. Le mainteneur de GoatCounter a refusé de maintenir cet amas de code pour un cas d’usage aussi niche. Développant moi aussi des logiciels libres, j’adopte souvent la même position pour mes propres projets : l’effort ponctuel d’un contributeur peut se transformer en engagement sur le long terme pour le mainteneur.

J’expose le point de terminaison du proxy sur le domaine de ce site pour échapper aux bloqueurs de publicité. Cela donne l’impression que je ne respecte pas le choix du lecteur, mais comme GoatCounter respecte la vie privée, je trouve cela acceptable.

location = /count {
  access_log off;
  proxy_pass http://127.0.0.3:8087/count;
  proxy_pass_request_headers off;
  proxy_set_header Accept-Language $http_accept_language;
  proxy_set_header User-Agent $http_user_agent;
  proxy_set_header X-Real-Ip $remote_addr;
}

Déploiement sur NixOS

Mes serveurs web tournent sous NixOS, une distribution Linux déclarative avec une gestion de configuration intégrée. Je gère ce petit troupeau avec Colmena, un outil de déploiement sans état pour NixOS. Ma configuration est disponible sur GitHub.

Déployer des applications dans des conteneurs

Pour une meilleure isolation, chaque application tourne dans un conteneur léger et éphémère, propulsé par systemd-nspawn. Chaque conteneur exécute une instance allégée de NixOS. Un module encapsule les options containers de NixOS pour éviter de répéter les mêmes options pour chaque application⁶. Les conteneurs partagent la pile réseau de l’hôte : l’isolation supplémentaire ne vaut pas la complexité accrue. Pour les alléger, je désactive aussi quelques services non essentiels.

{ config, lib, ... }:
let
  cfg = config.luffy.containers;
in
{
  # Réglages configurables pour notre module
  options.luffy.containers = lib.mkOption {
    default = { };
    description = "Ephemeral containers sharing the host network.";
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        config = lib.mkOption {
          type = lib.types.deferredModule;
          default = { };
          description = "NixOS configuration of the container.";
        };
      };
    });
  };

  # Traduit nos options en conteneurs NixOS
  config = {
    containers = lib.mapAttrs
      (name: container: {
        ephemeral = true;
        autoStart = true;
        privateNetwork = false;
        extraFlags = [ "--resolv-conf=replace-host" ];
        config = {
          imports = [ container.config ];
          networking.firewall.enable = false;
          system.stateVersion = config.system.stateVersion;
          systemd.services = {
            console-getty.enable = false;
            systemd-logind.enable = false;
            systemd-oomd.enable = false;
          };
        };
      })
      cfg;
  };
}

Pour configurer une instance GoatCounter tournant dans un conteneur et écoutant sur 127.0.0.4:8088, nous importons le module⁷ et déclarons le conteneur dans l’ensemble d’attributs config.luffy.containers :

{ pkgs, config, ... }: {
  imports = [ ./modules/container.nix ];
  config.luffy.containers.goatcounter = {
    config = {
      services.goatcounter = {
        enable = true;
        address = "127.0.0.4";
        port = 8088;
        proxy = true;
      };
    };
  };
}

Comme les conteneurs sont éphémères, il faut conserver les données persistantes dans des répertoires de l’hôte. Nous ajoutons une option mounts et demandons aux conteneurs de NixOS d’exposer les répertoires ainsi configurés via l’option bindMounts.

{ config, lib, ... }:
let
  cfg = config.luffy.containers;
in
{
  options.luffy.containers = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        mounts = lib.mkOption {
          type = lib.types.listOf lib.types.str;
          default = [ ];
          description = "Host directories mounted read-write at the same place.";
        };
      };
    });
  };

  config = {
    containers = lib.mapAttrs
      (name: container: {
        bindMounts =
          lib.genAttrs container.mounts (path: { hostPath = path; isReadOnly = false; });
      })
      cfg;
  };
}

Par exemple, pour conserver la base de données de GoatCounter dans le répertoire /var/db/goatcounter de l’hôte, nous ajoutons ce répertoire à l’option mounts et modifions la définition du service pour indiquer à GoatCounter où trouver la base de données.

{ config, ... }:
let
  databaseDirectory = "/var/db/goatcounter";
in {
  config.luffy.containers.goatcounter = {
    mounts = [ databaseDirectory ];
    config = {
      services.goatcounter = {
        extraArgs = [ "-db=sqlite+${databaseDirectory}/db.sqlite" ];
      };
    };
  };
}

Un conteneur peut aussi avoir besoin de secrets. Colmena peut envoyer des secrets sans les stocker dans /nix. Nous ajoutons une option keys à nos conteneurs. Elle prend un ensemble d’attributs associant le nom de chaque secret à la commande qui le fournit. Ensuite, le module déclare les secrets requis à Colmena dans l’option deployment.keys, fait dépendre le conteneur de la présence des secrets, puis les attache au conteneur.

{ config, lib, ... }:
let
  cfg = config.luffy.containers;
in
{
  options.luffy.containers = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        keys = lib.mkOption {
          type = lib.types.attrsOf (lib.types.listOf lib.types.str);
          default = { };
          description = "Secrets, as a command to run locally. They are mounted in /etc.";
        };
      };
    });
  };

  config = {
    # Colmena place chaque secret dans `/var/keys` et le rend accessible
    # au groupe "keys".
    deployment.keys = lib.concatMapAttrs
      (_: container: lib.mapAttrs
        (_: keyCommand: {
          inherit keyCommand;
          group = "keys";
          permissions = "0640";
          destDir = "/var/keys";
        })
        container.keys)
      cfg;

    # Le conteneur ne peut démarrer que si les secrets requis sont disponibles.
    systemd.services = lib.mapAttrs'
      (name: container:
        let
          units = map (key: "${key}-key.service") (lib.attrNames container.keys);
        in
        lib.nameValuePair "container@${name}" {
          requires = units;
          after = units;
        })
      cfg;

    # Attache chaque secret dans le conteneur.
    containers = lib.mapAttrs
      (name: container: {
        bindMounts = lib.mapAttrs'
          (key: _: lib.nameValuePair "/etc/${key}" {
            hostPath = "/var/keys/${key}";
            isReadOnly = true;
          })
          container.keys;
      })
      cfg;
  };
}

Par exemple, GoatCounter a besoin d’identifiants pour télécharger la base de données GeoIP. Je fournis une commande locale pour récupérer le secret depuis mon gestionnaire de mots de passe et je l’expose dans le conteneur via le fichier d’environnement /etc/goatcounter.env.

{ pkgs, config, ... }: 
let
  keyCommand = variable: [
    "${pkgs.runtimeShell}"
    "-c"
    "pass show personal/nixops/secrets | grep '^${variable}='"
  ];
in {
  config.luffy.containers.goatcounter = {
    keys."goatcounter.env" = keyCommand "GOATCOUNTER_GEODB";
    config = {
      systemd.services.goatcounter.serviceConfig = {
        EnvironmentFile = "/etc/goatcounter.env";
        SupplementaryGroups = [ "keys" ];
      };
    };
  };
}

Serveur GoatCounter

Nixpkgs fournit déjà un paquet pour GoatCounter. En surchargeant les attributs src et vendorHash, je réutilise sa définition pour ma version personnalisée avec le proxy :

{ goatcounter, fetchFromGitHub }:
goatcounter.overrideAttrs (_: {
  src = fetchFromGitHub {
    owner = "vincentbernat";
    repo = "goatcounter";
    rev = "feature/proxy";
    hash = "sha256-dJRlQlFu3tjcEgabT1LEbyFrasJlhmYu4L/T7EkoNcY=";
  };
  vendorHash = "sha256-c9Q5OrbZR+q6pD3SgPPWe8JUzcZco1AVUKGaV61k5DE=";
})

J’ai écrit un module NixOS pour encapsuler GoatCounter : la définition du conteneur, celle du service et les secrets. Le module accepte les options suivantes : package, serve.enable, serve.listenAddress, serve.port et serve.databaseFile. J’ai déjà détaillé la configuration du conteneur dans la section précédente. Finalement, j’ai choisi de ne pas réutiliser le module GoatCounter de NixOS : il est plutôt simple et le réécrire permet de me protéger de changements futurs inattendus.

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.goatcounter;
  databaseDirectory = builtins.dirOf cfg.serve.databaseFile;
  chown = "${pkgs.coreutils}/bin/chown -R";
in {
  config.luffy.containers.goatcounter = {
    config.systemd.services.goatcounter = {
      description = "GoatCounter Web Analytics";
      wantedBy = [ "multi-user.target" ];
      serviceConfig = {
        EnvironmentFile = "/etc/goatcounter.env";
        SupplementaryGroups = [ "keys" ];
        DynamicUser = true;
        Restart = "always";
        ExecStart = lib.escapeShellArgs [
          (lib.getExe cfg.package)
          "serve"
          "-listen=${cfg.serve.listenAddress}:${toString cfg.serve.port}"
          "-tls=none"
          "-db=sqlite+${cfg.serve.databaseFile}"
          "-automigrate"
        ];
        # Donne la base de données à l'utilisateur dynamique "goatcounter".
        ExecStartPre = "+${chown} goatcounter:goatcounter ${databaseDirectory}";
        ReadWritePaths = databaseDirectory;
      };
    };
  };
}

Le bout de code suivant configure GoatCounter pour écouter sur 127.0.0.4:8088 :

{
  luffy.goatcounter = {
    serve = {
      enable = true;
      listenAddress = "127.0.0.4";
      port = 8088;
    };
  };
}

La dernière étape consiste à configurer nginx pour exposer GoatCounter sur Internet. Je désactive le point de terminaison /count, car sa fonction est assurée par le proxy local.

{ config, ... }:
let
  cfg = config.luffy.goatcounter.serve;
in
{
  services.nginx.virtualHosts."goatcounter.luffy.cx" = {
    forceSSL = true;
    locations = {
      "/" = {
        proxyPass = "http://${cfg.listenAddress}:${toString cfg.port}";
      };
      "= /count".extraConfig = ''
        return 404;
      '';
    };
  };
}

Proxy GoatCounter

Le même module NixOS configure le proxy local, avec les options suivantes : proxy.enable, proxy.listenAddress, proxy.port et proxy.site (le site qui reçoit les lots de pages vues). Le proxy local n’a aucune donnée persistante, mais il a besoin de la clé d’API pour s’authentifier auprès de l’instance principale de GoatCounter : son conteneur utilise l’option keys, mais pas l’option mounts.

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.goatcounter;
  keyCommand = _: [ "…" ];
in
{
  config.luffy.containers.goatcounter-proxy = {
    keys."goatcounter-proxy.env" = keyCommand "GOATCOUNTER_API_KEY";
    config.systemd.services.goatcounter = {
      description = "GoatCounter Proxy.";
      wantedBy = [ "multi-user.target" ];
      serviceConfig = {
        EnvironmentFile = "/etc/goatcounter-proxy.env";
        SupplementaryGroups = [ "keys" ];
        DynamicUser = true;
        Restart = "always";
        ExecStart = lib.escapeShellArgs [
          (lib.getExe cfg.package)
          "proxy"
          "-site=${cfg.proxy.site}"
          "-listen=${cfg.proxy.listenAddress}:${toString cfg.proxy.port}"
          "-ratelimit=10/1"  # 10 requêtes par seconde par IP
        ];
      };
    };
  };
}

Sur chaque serveur, j’active le proxy local avec le bout de code suivant. La configuration nginx présentée plus haut expose le point de terminaison /count sous le même domaine que mon blog.

{
  luffy.goatcounter = {
    proxy = {
      enable = true;
      site = "goatcounter.luffy.cx";
      listenAddress = "127.0.0.3";
      port = 8087;
    };
  };
}

Sauvegarde de la base de données SQLite avec Litestream

Litestream est un outil de réplication en continu pour les bases de données SQLite. Il compresse les changements placés dans le journal d’écriture anticipée (WAL) situé à côté de la base de données et les envoie vers une destination distante. J’encapsule sa configuration dans un module NixOS, qui prend un ensemble d’attributs databases associant un nom au chemin de la base de données à sauvegarder.

Litestream tourne lui aussi dans un conteneur. Je monte les bases de données à répliquer, ainsi que les secrets pour pousser les sauvegardes vers une storage box de Hetzner via SFTP :

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.litestream;
  databaseDirs = lib.unique (map builtins.dirOf (builtins.attrValues cfg.databases));
in
{
  config = lib.mkIf (cfg.databases != { }) {
    luffy.containers.litestream = {
      mounts = databaseDirs;
      keys."litestream.env" = [
        "${pkgs.runtimeShell}"
        "-c"
        "pass show personal/nixops/secrets | grep '^SQLITE_BACKUP_'"
      ];
    };
  };
}

Dans le conteneur, je configure Litestream à travers les options services.litestream de NixOS :

• des instantanés complets chaque jour, conservés 15 jours ;
• trois niveaux de compactage pour les transactions : 5 minutes, 30 minutes et 3 heures ;
• la reprise automatique⁸ ;
• un réplica stocké dans un répertoire portant le nom de l’hôte ;
• des identifiants lus depuis /etc/litestream.env et exposés par expansion de variables.

{ config, pkgs, lib, ... }:
let
  cfg = config.luffy.litestream;
in
{
  config.luffy.containers.litestream = {
    config = {
      # Les bases de données appartiennent à des utilisateurs dynamiques, dont
      # l'UID n'est pas connu ici : Litestream tourne donc en root.
      systemd.services.litestream.serviceConfig = {
        User = lib.mkForce "root";
        Group = lib.mkForce "root";
      };
      # Utilise le service NixOS.
      services.litestream = {
        enable = true;
        environmentFile = "/etc/litestream.env";
        settings = {
          auto-recover = true;
          snapshot = {
            interval = "24h";
            retention = "360h";
          };
          levels = [
            { interval = "5m"; }
            { interval = "30m"; }
            { interval = "3h"; }
          ];
          dbs = lib.mapAttrsToList
            (name: path: {
              inherit path;
              replica = {
                type = "sftp";
                host = "\${SQLITE_BACKUP_HOST}";
                user = "\${SQLITE_BACKUP_USER}";
                password = "\${SQLITE_BACKUP_PASSWORD}";
                host-key = "\${SQLITE_BACKUP_HOSTKEY}";
                path = "${config.networking.hostName}/${name}";
              };
            })
            cfg.databases;
        };
      };
    };
  };
}

Pour sauvegarder la base de données de GoatCounter, je déclare un attribut goatcounter dans luffy.litestream.databases avec pour valeur le chemin de la base de données :

{ config, ... }:
let
  cfg = config.luffy.goatcounter.serve;
in
{
  luffy.litestream.databases.goatcounter = cfg.databaseFile;
}

Sur le serveur SFTP, nous pouvons inspecter le travail de Litestream, avec les transactions compactées et les instantanés complets :

❯ ls web02/goatcounter/ltx
web02/goatcounter/ltx/0
web02/goatcounter/ltx/1
web02/goatcounter/ltx/2
web02/goatcounter/ltx/3
web02/goatcounter/ltx/9
❯ ls -lh web02/goatcounter/ltx/1
29.1K Sep  5 01:25 0000000000003f2a-0000000000003f2b.ltx
72.4K Sep  5 02:03 0000000000003f2c-0000000000003f2d.ltx
63.3K Sep  5 02:24 0000000000003f2e-0000000000003f2f.ltx
[…]
❯ ls -lh web02/goatcounter/ltx/9
 8.5M Sep  5 02:00 0000000000000001-0000000000003f2b.ltx
 8.5M Sep  6 02:03 0000000000000001-0000000000004008.ltx
 8.6M Sep  7 02:03 0000000000000001-00000000000043a8.ltx
[…]

Nous pouvons restaurer la base de données depuis la sauvegarde avec quelques commandes shell. D’abord, nous arrêtons les conteneurs. Ensuite, nous mettons de côté la base de données endommagée, invoquons litestream restore depuis le bon environnement et redémarrons les conteneurs⁹.

# systemctl stop container@goatcounter container@litestream
# mv /var/db/goatcounter/db.sqlite{,.old}
# ( . /etc/nixos-containers/litestream.conf ; 
>   set -a ; . /var/keys/litestream.env ; set +a ;
>   $SYSTEM_PATH/sw/bin/litestream \
>     restore -config $SYSTEM_PATH/etc/litestream.yml /var/db/goatcounter/db.sqlite)
# ls -lh /var/db/goatcounter/db.sqlite
-rw-r--r-- 1 root root 20M Sep 20 07:33 /var/db/goatcounter/db.sqlite
# systemctl start container@goatcounter container@litestream

Dix ans après avoir retiré Google Analytics, les statistiques en JavaScript sont de retour sur ce blog, mais sans stocker de cookies ni d’adresses IP, et sans se reposer sur un tiers. J’écris d’abord pour moi, notamment parce que cela me permet de creuser un sujet et de m’y référer des années plus tard. Cependant, en savoir un peu plus sur mes lecteurs humains est un bonus appréciable, y compris sur ceux qui n’activent pas JavaScript. 🐐

Je fais un usage intensif des notes de marge¹ : elles gardent le contenu optionnel à côté du texte au lieu de renvoyer le lecteur en bas de page. Tufte CSS les affiche sans JavaScript, mais n’accepte qu’un seul paragraphe. Le positionnement par ancre CSS, désormais pris en charge par les navigateurs récents², est une alternative élégante. Les notes peuvent contenir plusieurs blocs, toujours sans JavaScript, et se positionnent sous le paragraphe qui les appelle sur les fenêtres étroites et les navigateurs plus anciens.

En 2023, Eric Meyer a présenté cette technique dans « Nuclear Anchored Sidenotes ». Le principal avantage par rapport aux autres solutions est que les notes peuvent se trouver n’importe où dans le document HTML. Il est possible de les placer après le paragraphe qui les appelle, comme des éléments de bloc ordinaires, afin que les navigateurs en mode texte, les lecteurs d’écran, les agrégateurs de flux et le mode lecture les affichent correctement :

Lorsque la fenêtre est trop étroite ou que le navigateur ne prend pas en charge le positionnement par ancre, il est possible de leur appliquer un style qui permet au lecteur de les sauter ou d’y jeter un œil sans perdre sa place dans le texte :

Dès que la fenêtre est assez large, elles apparaissent dans la marge, à la même hauteur que l’appel de note correspondant, sauf si elles entrent en collision avec une note précédente, comme dans l’exemple ci-dessous³ :

Le principe de l’ancrage CSS est de positionner un élément par rapport à un autre élément, l’ancre. Pour les notes de marge, l’ancre est l’appel de note. J’utilise le balisage suivant, avec un attribut de données pour indiquer le nom de l’ancre :

<sup id="fnref:YYY" data-anchor="--lf-sn-YYY">
  <a href="#sidenote-YYY">1</a>
</sup>

La note correspondante est un élément <aside> portant le même attribut de données pour le nom de l’ancre. Elle est placée après le paragraphe contenant l’appel de note :

<aside role="note" id="sidenote-YYY" data-anchor="--lf-sn-YYY">
  <sup>1</sup>
  <p>Un premier paragraphe.</p>
  <p>Un second paragraphe.</p>
</aside>

Sur une fenêtre étroite ou lorsque le navigateur est trop ancien pour l’ancrage CSS, la note reçoit une couleur atténuée et reste sous son paragraphe :

aside[role="note"] {
  margin-block: 1rlh;
  color: #444;
}

Sur une fenêtre plus large et lorsque le navigateur est assez récent, la note est déplacée dans la marge de droite :

@supports (anchor-name: attr(data-anchor type(<custom-ident>))) {
  @media (min-width: 72rem) {
    main {
      position: relative;
      sup[data-anchor] {
        anchor-name: attr(data-anchor type(<custom-ident>));
        /* → anchor-name: --lf-sn-YYY */
      }
      aside[role="note"][data-anchor] {
        anchor-name: --lf-sidenote;
        position: absolute;
        position-anchor: attr(data-anchor type(<custom-ident>));
        /* → position-anchor: --lf-sn-YYY */
        top: max(anchor(top), anchor(--lf-sidenote bottom, -1rlh) + 1rlh);
        left: 100%;
        margin: 0 2rem;
        width: 18rem;
        color: inherit;
      }
    }
  }
}

attr() extrait le nom de l’ancre de l’appel de note depuis l’attribut data-anchor. Elle renvoie une chaîne de caractères, sauf si une unité CSS ou un type est précisé, comme ici : le navigateur analyse l’attribut de données comme un identifiant personnalisé, que anchor-name valide comme un identifiant à tirets, c’est-à-dire un identifiant personnalisé commençant par deux tirets⁴.

La note elle-même est positionnée de manière absolue au-delà du bord droit du bloc principal. Elle choisit l’appel de note correspondant comme ancre grâce à position-anchor, dont la valeur provient de l’attribut data-anchor. Chaque note est elle-même une ancre nommée --lf-sidenote. Elle sert à empêcher la note suivante d’entrer en collision avec celle-ci.

La fonction CSS anchor() permet de positionner le bord supérieur de la note par rapport à son ancre : anchor(top) aligne le bord supérieur de la note avec le bord supérieur de l’appel de note. Elle accepte aussi une autre ancre en paramètre : anchor(--lf-sidenote bottom) alignerait le bord supérieur de la note avec le bord inférieur de l’ancre précédente la plus proche nommée --lf-sidenote, c’est-à-dire la note précédente⁵. Comme attr(), anchor() accepte une valeur de repli en second paramètre et l’utilise lorsque l’ancre nommée n’existe pas.

La propriété top gère trois cas, illustrés dans le schéma suivant :

1. Le bord supérieur de la première note s’aligne avec le bord supérieur de son appel de note : en l’absence de note précédente, anchor(--lf-sidenote bottom, -1rlh) + 1rlh vaut 0 et max() renvoie anchor(top).
2. Lorsque l’appel de note d’une note ultérieure se trouve au-dessus du bas de la note précédente, augmenté d’un espace vertical, la note passe sous la précédente pour éviter une collision. max() renvoie anchor(--lf-sidenote bottom) + 1rlh.
3. Sinon, max() renvoie anchor(top) et le bord supérieur de la note s’aligne avec le bord supérieur de l’appel de note.

Jetez un œil à la feuille de style complète, qui adapte aussi l’appel de note à l’emplacement de la note : une flèche « ↓ » lorsque la note se trouve sous le paragraphe, une flèche « → » lorsqu’elle part dans la marge. « Sidenotes In Web Design », de Gwern, recense d’autres implémentations et leurs compromis.

Certains blogueurs se fixent pour objectif d’écrire un billet en 30 minutes. Je comptais publier trois articles liés au web ce week-end. À la place, j’ai passé un temps fou sur n’importe quoi : une quinzaine de changements sur le système de construction du site, une contribution pour mettre à jour la coloration CSS des sélecteurs imbriqués dans Pygments et une petite correction de l’article de MDN sur la fonction CSS anchor(). L’illustration SVG a demandé un peu moins d’une heure et l’article lui-même quelques heures. La fonction attr() est arrivée après que je me suis demandé : « n’y-a-t-il pas plus élégant que de placer le nom de l’ancre dans un style en ligne ? » Mais bon, je trouve que ça en vaut malgré tout la peine ! 🎨

L’IA inonde le web de contenus insipides. Les articles sur LinkedIn avec une image générée par IA, remplis d’émojis, publiés par des soi-disant experts sur un sujet auquel ils ne portent pas assez d’intérêt pour écrire eux-mêmes, sont les pires spécimens. Bien que je sois très contrarié de cette situation, je m’appuie sur des LLMs pour la grammaire, les révisions linguistiques et la traduction. Je ne trouve pas cela incohérent.

Ma langue maternelle est le français mais j’écris la plupart des articles en anglais et en français. Quand j’ai commencé à écrire ce blog en 2011, je rédigeais d’abord en français avant de traduire en anglais. J’ai fini par comprendre qu’il était préférable de le faire dans l’autre sens afin de rendre le texte plus naturel et idiomatique. J’essaie d’écrire un anglais « correct » mais cela n’a jamais été mon point fort¹. Par exemple, j’ai toujours eu des difficultés sur l’accord des temps. J’apprends les règles et je les oublie immédiatement. Je ne me vois pas non plus embaucher un éditeur pour quelque chose que je considère comme un loisir.

À titre d’exemple, j’ai gardé l’historique des modifications successives lors de l’écriture de « Scaling Akvorado BMP RIB with sharding » :

1. la première ébauche rédigée à l’aide d’un dictionnaire de synonymes² ;
2. la version modifiée par la compétence « révision linguistique » ;
3. la traduction en français générée par la compétence « traduction » ;
4. la version révisée par un humain avec quelques modifications sur la version anglaise.

Je sais que les IA peuvent dénaturer la voix de l’auteur pendant l’édition, mais les corrections apportées lors de la seconde étape sont mineures. Les instructions sont « d’appliquer de légères modifications de style » tout en demandant d’éviter les formes passives, les phrases trop longues, les verbes peu expressifs et les mots inutiles. Elles définissent également l’audience cible : technique avec un niveau d’anglais B2.

Dans l’extrait suivant, j’ai utilisé « long time » au lieu de « long-standing ». Outre le trait d’union manquant, le premier s’applique à des personnes (a long-time friend), tandis que le second concerne des situations (a long-standing agreement). J’ai mis pas mal de temps à comprendre la seconde modification : l’IA préfère cette forme grammaticale pour introduire la définition de « RIB sharding ».

As the Internet routing table contains more than 1 million routes, Akvorado needs to scale to tens of millions of routes. This has been a long time long-standing challenge, but I expect this issue is now fixed by using RIB sharding, a method to split that splits the routing database into several parts to enable concurrent updates.

Dans la modification ci-dessous, l’IA utilise le mot « device » plutôt que le mot « équipement » car ce dernier est indénombrable. Je le sais mais je tombe régulièrement dans ce piège.

When Akvorado does not find a route from a specific device, it falls back to a route sent by another equipment device.

J’encourage l’IA à utiliser des verbes descriptifs et elle s’exécute en remplaçant une périphrase par un verbe précis :

The benchmarks demonstrate it has better performance than outperforms other packages, both packages for lookups, insertions, and memory usage.

Elle corrige aussi les erreurs de grammaire. Dans le passage suivant, « list of routes » est au singulier. De plus, « stored » représente un état et il ne faut pas le faire suivre de « into » qui indique un changement.

The list of routes for each prefix are is not stored directly into in the prefix tree.

Voici un dernier exemple : le verbe « require » doit être suivi d’un nom ou d’un objet suivi d’un infinitif. Il n’est pas possible de le faire suivre directement par un infinitif.

An alternative would be to have one prefix tree for each peer but it would require to configure configuring all routers to export their routes.

Même si je lis beaucoup d’anglais³, je bute toujours sur ces règles de grammaire. Le français est une langue relativement simple une fois les bases acquises alors que l’anglais est rempli d’irrégularités.

J’indique dans chaque pied de page si une IA a été utilisée pour modifier le contenu. Il y a 3 niveaux :

• 🧠: pas d’IA ou pratiquement pas (par exemple, des corrections grammaticales)
• ✨: amélioré par l’IA (par exemple, des révisions linguistiques)
• 🤖: généré par IA (par exemple, traduit depuis une autre langue)

Survolez avec la souris ou tapotez sur l’icône pour révéler le nom de l’IA et son rôle dans la modification du document.

Le graphique ci-dessous représente par année les outils utilisés pour modifier chaque article. J’ai récemment demandé à une IA des corrections grammaticales sur les anciens articles, aussi bien en anglais qu’en français. Depuis 2018, les articles sont traduits en français à l’aide de DeepL puis ensuite d’une IA. Depuis 2024, je m’appuie sur une IA pour les révisions linguistiques des articles en anglais.

Si vous êtes fermement opposé à l’utilisation des LLM dans l’écriture, j’espère que vous acceptez mon point de vue plus nuancé comme une contrepartie pour des articles en français, l’IA mâchant énormément le travail de traduction. En ce qui concerne l’anglais, la littérature sur le sujet s’accorde sur l’importance de choisir le bon mot pour capturer l’attention du lecteur jusqu’à la fin.

[…] Bien écrire consiste à maîtriser un certain nombre de choses fondamentales, à savoir le vocabulaire, la grammaire et le style, et à remplir le troisième compartiment de sa boîte à outils avec les bons instruments.

― Stephen King, On Writing

Le rythme vertical structure les lignes selon un espacement régulier de haut en bas. Il permet de guider l’œil de manière fluide et prévisible. Grâce à l’unité CSS rlh, ce rythme est simple à mettre en place pour le texte¹. Mais les illustrations et les tableaux peuvent perturber la mise en page. Le typographe amateur en moi aspire à suivre la sagesse de Bringhurst :

Les titres, intertitres, citations, notes de bas de page, illustrations, légendes et autres intrusions dans le texte créent des syncopes et des variations par rapport au rythme de base d’un interlignage régulier. Ces variations peuvent et doivent animer la page, mais le texte principal doit également reprendre, après chaque variation, précisément la mesure et la phase.

― Robert Bringhurst, The Elements of Typographic Style

Pour le texte

Trois facteurs régissent le rythme vertical : la taille de police, la hauteur de ligne et la marge ou le remplissage. Posons la base avec une police de 18 pixels et une hauteur de ligne de 1,5 :

html {
  font-size: 112.5%;
  line-height: 1.5;
}
h1, h2, h3, h4 {
  font-size: 100%;
}
html, body,
h1, h2, h3, h4,
p, blockquote,
dl, dt, dd, ol, ul, li {
  margin: 0;
  padding: 0;
}

Le CSS Values and Units Module Level 4 définit l’unité rlh, égale à la hauteur de ligne de l’élément racine. Tous les navigateurs la gèrent depuis 2023². Utilisez-la pour insérer des espaces verticaux ou corriger la hauteur de ligne quand la taille de police change³ :

h1, h2, h3, h4 {
  margin-top: 2rlh;
  margin-bottom: 1rlh;
}
h1 {
  font-size: 2.5rem;
  line-height: 2rlh;
}
h2 {
  font-size: 1.5rem;
  line-height: 1rlh;
}
h3 {
  font-size: 1.25rem;
  line-height: 1rlh;
}
p, blockquote, pre {
  margin-top: 1rlh;
}
aside {
  font-size: 0.875rem;
  line-height: 1rlh;
}

Vérifions le résultat en superposant une grille⁴ au-dessus du texte :

Si un sous-élément utilise une police aux métriques intrinsèques plus hautes, il peut étirer la boîte de la ligne au-delà de la hauteur configurée⁵. Une astuce consiste à ramener la hauteur de ligne à 1. Les glyphes débordent mais ne poussent pas la ligne plus haut.

code, kbd {
  line-height: 1;
}

Pour les images adaptatives

Les images adaptatives, dont la taille s’ajuste à la largeur de l’affichage, sont difficiles à aligner sur la grille car leur hauteur nous est inconnue. Le CSS Rhythmic Sizing Module Level 1 introduit la propriété block-step pour ajuster la hauteur d’un élément à un multiple d’une unité de pas. Cependant, la plupart des navigateurs ne la gèrent pas encore.

Avec JavaScript, nous pouvons ajouter un remplissage autour de l’image pour qu’elle ne perturbe pas le rythme vertical :

const targets = document.querySelectorAll(".lf-media-outer");
const adjust = (el, height) => {
  const rlh = parseFloat(getComputedStyle(document.documentElement).lineHeight);
  const padding = Math.ceil(height / rlh) * rlh - height;
  el.style.padding = `${padding / 2}px 0`;
};

targets.forEach((el) => adjust(el, el.clientHeight));

Comme l’image est adaptative, sa hauteur peut varier. Il faut appeler la fonction adjust() dans un observateur :

const ro = new ResizeObserver((entries) => {
  for (const entry of entries) {
    const height = entry.contentBoxSize[0].blockSize;
    adjust(entry.target, height);
  }
});
for (const target of targets) {
  ro.observe(target);
}

Pour les tableaux

Les cellules d’un tableau pourraient fixer leur hauteur à 1rlh mais paraîtraient à l’étroit. Passer à 2rlh gaspille trop d’espace. À la place, nous utilisons l’interligne incrémental : une ligne sur cinq est alignée sur la grille.

table {
  border-spacing: 2px 0;
  border-collapse: separate;
  th {
    padding: 0.4rlh 1em;
  }
  td {
    padding: 0.2rlh 0.5em;
  }
}

Pour aligner les éléments après le tableau, il faut ajouter un peu de remplissage. Nous pouvons soit réutiliser le code JavaScript des images, soit utiliser quelques lignes de CSS qui comptent les lignes régulières et calculent le remplissage vertical manquant :

table:has(tbody tr:nth-child(5n):last-child)   { padding-bottom: 0.2rlh; }
table:has(tbody tr:nth-child(5n+1):last-child) { padding-bottom: 0.8rlh; }
table:has(tbody tr:nth-child(5n+2):last-child) { padding-bottom: 0.4rlh; }
table:has(tbody tr:nth-child(5n+3):last-child) { padding-bottom: 0 }
table:has(tbody tr:nth-child(5n+4):last-child) { padding-bottom: 0.6rlh; }

Une cellule d’en-tête a deux fois le remplissage d’une cellule régulière. Avec deux lignes régulières, le remplissage total vaut 2×2×0,2+2×0,4=1,6. Il faut ajouter 0.4rlh pour atteindre 2rlh de remplissage vertical supplémentaire autour du tableau.

Rien de tout cela n’est indispensable, mais une fois l’œil entraîné, il devient difficile de ne plus le remarquer. En attendant que les navigateurs implémentent le CSS Rhythmic Sizing, un mélange de bidouilles CSS et d’un peu de JavaScript suffit. Le texte principal reprend désormais après chaque intrusion « précisément la mesure et la phase ». 🎼

En 2020, Google a introduit les métriques Core Web Vitals pour mesurer certains aspects de l’expérience utilisateur sur le web. Ce blog a constamment obtenu de bons scores pour deux de ces métriques : Largest Contentful Paint et Interaction to Next Paint. Cependant, l’optimisation de la troisième métrique, Cumulative Layout Shift, qui mesure les changements de mise en page inattendus, a été plus difficile. Soyons honnêtes : optimiser pour cette métrique n’est pas vraiment utile pour un site comme celui-ci. Mais obtenir un meilleur score est toujours une bonne distraction. 💯

Pour éviter le « flash de texte invisible » lors de l’utilisation de polices web, les développeurs sont encouragés à placer la propriété font-display sur swap dans les règles @font-face. Cette méthode permet aux navigateurs d’afficher initialement le texte en utilisant une police de substitution, puis de la remplacer par la police finale lorsqu’elle est chargée. Bien que cela améliore le score LCP, cela provoque des décalages de mise en page si les polices de substitution n’ont pas des métriques compatibles. Ces décalages affectent négativement le score CLS. CSS fournit des propriétés pour résoudre ce problème en adaptant les métriques des polices de substitution : size-adjust, ascent-override, descent-override et line-gap-override.

Deux articles complets expliquent chaque propriété et leurs méthodes de calcul en détail : Creating Perfect Font Fallbacks in CSS et Improved font fallbacks.

Outil interactif

Au lieu de calculer chaque propriété à partir des métriques moyennes des polices, j’ai créé un outil pour régler interactivement les métriques des polices de substitution¹.

Mode d’emploi

1. Chargez votre police personnalisée.

2. Sélectionnez une police de substitution.

3. Ajustez la propriété size-adjust pour faire correspondre la largeur de votre police personnalisée avec celle de la police de substitution. Avec une police proportionnelle, il n’est souvent pas possible d’obtenir une correspondance parfaite.

4. Affinez la propriété ascent-override. Essayez d’aligner le point final du dernier paragraphe tout en surveillant la ligne de base de la police. Pour un ajustement plus précis, désactivez l’option « Définir la hauteur de ligne ».

5. Modifiez la propriété descent-override. L’objectif est de faire correspondre les deux boîtes. Vous devrez peut-être alterner entre cette propriété et la précédente pour obtenir des résultats optimaux.

6. Si nécessaire, ajustez la propriété line-gap-override. Cette étape n’est généralement pas requise.

Le processus doit être répété pour chaque police de substitution. Certaines plateformes peuvent ne pas inclure certaines polices. Notamment, Android n’a pas la plupart des polices présentes dans d’autres systèmes d’exploitation. Il remplace Georgia par Noto Serif, qui n’est pas compatible au niveau des métriques.

Outil

Cet outil n’est pas disponible depuis le flux Atom.

Résultats

Pour la police utilisée pour le texte de ce blog, j’obtiens la définition CSS suivante :

@font-face {
  font-family: Merriweather;
  font-style: normal;
  font-weight: 400;
  src: url("../fonts/merriweather.woff2") format("woff2");
  font-display: swap;
}
@font-face {
  font-family: "Fallback for Merriweather";
  src: local("Noto Serif"), local("Droid Serif");
  size-adjust: 98.3%;
  ascent-override: 99%;
  descent-override: 27%;
}
@font-face {
  font-family: "Fallback for Merriweather";
  src: local("Georgia");
  size-adjust: 106%;
  ascent-override: 90.4%;
  descent-override: 27.3%;
}

font-family: Merriweather, "Fallback for Merriweather", serif;

Après un mois, la métrique CLS s’est bien améliorée à 0 :

À propos des polices personnalisées

L’utilisation de polices systèmes ou d’un ensemble de polices est souvent plus simple. Cependant, je préfère les polices web personnalisées. Merriweather et Iosevka, qui sont utilisées dans ce blog, améliorent l’expérience de lecture. Une approche alternative serait d’utiliser Georgia comme police principale. Malheureusement, la plupart des polices à chasse fixe par défaut sont laides.

De plus, les paragraphes qui combinent des polices à chasse variable et fixe peuvent créer une perturbation visuelle. Cela se produit en raison des différences des métriques verticales ou des graisses. Pour résoudre ce problème, j’ajuste les métriques d’Iosevka et sa graisse pour les aligner avec les caractéristiques de Merriweather.