Un compteur pour les sites statiques

L'hébergement statique est devenu, discrètement, la manière raisonnable de mettre un petit site sur Internet. GitHub Pages, Codeberg Pages, Neocities, ou simplement un dossier de fichiers chez n'importe quel hébergeur bon marché : pas de base de données, pas de langage côté serveur, rien à mettre à jour, rien qui puisse être compromis.

Il présente exactement une lacune. Il n'y a pas de journal serveur à consulter, ni aucun moyen d'exécuter quoi que ce soit qui compterait à la place du site. La publication a lieu, et ensuite plus rien n'indique si quelqu'un est venu.

C'est exactement la situation pour laquelle le compteur de visiteurs a été inventé, et c'est pourquoi il n'est en réalité pas obsolète.

Ce qu'il faut faire

L'extrait de code fourni sur la page de statistiques se colle dans le HTML, à l'endroit prévu pour le compteur. C'est toute la procédure. Cela fonctionne parce que le compteur est une image et un petit script — deux choses que n'importe quel hébergement statique sert sans savoir ni se soucier de ce qu'elles sont.

Le comptage a lieu sur notre serveur. L'hébergement reste un simple dossier de fichiers.

Le script n'a pas sa place dans le dépôt

C'est le seul conseil qui justifie à lui seul tout cet article, parce que les habitudes propres aux sites statiques poussent fortement dans l'autre sens. Intégrer ses dépendances dans son propre dépôt est normalement une bonne pratique — c'est reproductible, cela survit à la disparition d'une source amont, et cela économise une requête.

Cela ne vaut pas ici.

Un script copié reste figé au jour de la copie. Il continue à faire ce qu'il faisait ce jour-là, indéfiniment, à chaque visite, et rien de ce qui se passe en amont ne peut plus l'atteindre. Ce n'est pas une hypothèse d'école : quand la résolution d'écran a été retirée du compteur cette année, les copies de l'ancien script ont continué à l'envoyer, et le seul moyen de mettre fin à cette collecte a été de faire en sorte que le serveur refuse cette valeur, quel qu'en soit l'expéditeur.

Le même principe s'applique aux correctifs de sécurité, aux changements dans ce qui est envoyé, et à tout ce qui devrait atteindre les visiteurs du site. Un lien vers le script suffit. C'est une seule requête, elle est mise en cache, et elle reste à jour.

Ce que cela donne, et ce que cela ne donne pas

Le résultat comprend le nombre de visiteurs, les jours, les pays, les navigateurs, les domaines référents, les pages les plus visitées, et une vue en direct de qui se trouve sur le site en ce moment. Pour un site personnel, une page de projet ou une petite vitrine, c'est généralement l'ensemble des questions qui se posent.

Il n'y a pas d'analyse de journaux, parce qu'il n'y a pas de journal. Rien non plus sur les requêtes qui échouent, les fichiers en erreur 404, ou la bande passante. Si ces éléments comptent, l'hébergement statique n'était de toute façon pas la solution adaptée au problème.

Encore un point qui convient bien aux sites statiques

Rien ici ne nécessite de compte. Pas d'inscription, pas de mot de passe à stocker dans un dépôt, et pas de clé susceptible de fuiter dans un commit public — un type d'incident dans lequel les projets de sites statiques excellent particulièrement.