[🛠] Ajouter un compteur de visites à un blog GitHub Pages

✨ Résumé de GPT-5.5 　

Récit de l’ajout d’un Cloudflare Worker et de D1, dans la limite de l’offre gratuite, à un blog statique GitHub Pages afin de conserver les valeurs cumulées existantes de GA tout en affichant les visites du jour et les vues par article.

J’ai eu envie d’ajouter un compteur de visites au blog.

Pas parce que la fonctionnalité elle-même est impressionnante. C’est plutôt l’inverse. Elle paraît tellement évidente, mais sur un blog statique créé avec GitHub Pages, elle n’est pas présente naturellement.

Google Analytics était déjà installé. En tant qu’administrateur, je pouvais ouvrir GA et voir le nombre de visiteurs et de vues. Mais ces chiffres n’étaient pas visibles dans le blog. Les visiteurs ne pouvaient pas savoir si ce blog était encore lu aujourd’hui, ni dans quelle mesure les articles récents avaient été consultés.

Je voulais retrouver cette petite impression des indicateurs de Naver Blog, avec Aujourd'hui, Cumul et vues par article affichés discrètement. Ce n’était pas vraiment un chiffre pour se mettre en avant, mais plutôt un signal indiquant que le blog n’est pas une page statique morte, et qu’il continue d’être lu.

Le problème était donc simple.

Est-ce que je pouvais conserver les avantages d’un blog statique gratuit tout en ajoutant seulement une toute petite partie dynamique pour les statistiques de visite ?

J’ai d’abord fixé les conditions

Je ne voulais pas agrandir toute la structure simplement pour ajouter un compteur de visites.

Dès le départ, j’ai fixé quelques conditions.

• Conserver le flux d’écriture avec GitHub Pages et Jekyll.
• Ne pas utiliser de serveur payant.
• Résoudre le problème dans la limite de l’offre gratuite, que ce soit avec Cloudflare ou Firebase.
• L’afficher discrètement près du profil.
• Faire en sorte qu’il ne devienne pas étrangement long sur mobile.
• Afficher non seulement les statistiques de tout le blog, mais aussi les vues par article.
• Ne pas jeter les valeurs cumulées existantes de GA.

La dernière condition était particulièrement importante.

Si j’ajoutais un nouveau compteur et que les vues repartaient de 0, ce serait étrange. Le blog était déjà en ligne, et GA contenait déjà des vues accumulées depuis quelque temps. Mais continuer à lire uniquement GA restait éloigné de la sensation de compteur que je voulais.

Je pensais qu’il suffirait de lire GA

Au début, je pensais qu’il suffisait de lire l’API Google Analytics.

Puisque GA possédait déjà les données, il me semblait qu’un Cloudflare Worker pouvait simplement appeler l’API GA et renvoyer les chiffres. En pratique, j’ai créé un compte de service, ajouté les autorisations sur la propriété GA, et les appels API fonctionnaient.

Mais une fois le tout branché, ce n’était pas ce que je voulais.

GA est un outil d’analyse. Il est utile pour que l’administrateur observe les tendances plus tard, mais il était ambigu comme compteur de visites réagissant directement sur l’écran du blog. Le chiffre Aujourd'hui posait particulièrement problème. Si je venais moi-même d’entrer sur le blog et que la valeur du jour restait affichée à 0, pour un visiteur cela ressemblait simplement à quelque chose de cassé.

Les noms des métriques prêtaient aussi à confusion. Les utilisateurs actifs et les vues de page sont des valeurs différentes. Si je définis le nombre de visiteurs de façon stricte, le chiffre paraît trop conservateur. Si j’utilise les vues de page, la sensation est plus naturelle, mais il faut faire attention au libellé.

Au final, le jugement était simple.

Utiliser GA comme valeur de référence historique, et compter moi-même les augmentations à partir de maintenant.

J’ai séparé la base de référence et l’incrément

La structure finale a pris cette forme.

Vues publiques = base GA + incrément Cloudflare D1

La base GA correspond au nombre déjà accumulé. Je choisis une date de référence et j’enregistre les vues totales du site ainsi que les vues par article jusqu’à ce moment-là.

À partir de là, le Cloudflare Worker compte directement. Quand un visiteur entre sur le blog, JavaScript appelle le Worker, et le Worker enregistre dans D1 les incréments du jour, du mois, du total et de chaque chemin de page.

En résumé, cela donne ceci.

Valeurs cumulées existantes : base Google Analytics
Nouvel incrément : Cloudflare Worker + D1
API publique : Cloudflare Worker
Affichage du blog : inclusion Jekyll + JavaScript

J’ai aimé cette méthode parce qu’elle ne jette aucun des deux côtés.

Elle conserve les données existantes de GA. En même temps, les comptages futurs réagissent immédiatement sur l’écran du blog.

Pourquoi Cloudflare Worker et D1

Firebase faisait aussi partie des candidats. Mais pour une fonctionnalité de cette taille, le côté Cloudflare était plus simple.

GitHub Pages est un site statique, il n’y a donc aucun endroit où placer du code serveur. Worker comble ce vide avec une petite pièce. D1 est basé sur SQLite, ce qui suffit pour stocker des nombres simples comme ceux d’un compteur de visites.

La condition de coût convenait aussi. Un compteur de visites pour un blog personnel peut être géré dans la limite de l’offre gratuite. Si beaucoup de monde arrive soudainement, une partie du comptage peut devenir légèrement imprécise, mais les articles eux-mêmes ne se cassent pas. Au départ, ce n’est ni un système de paiement ni un grand livre financier.

Ce que je voulais, ce n’était pas une comptabilité exacte, mais montrer le flux d’un blog qui est en train d’être lu.

J’ai limité les robots et les visites répétées avec modération

Quand on ajoute un compteur à une page publique, les robots peuvent aussi faire monter les chiffres.

Les bloquer parfaitement est difficile. Et si je bloque trop strictement, je m’éloigne au contraire de la sensation de compteur que je voulais. Je préférais une manière de compter un peu généreuse, comme sur Naver Blog.

Le Worker ne traite donc que quelques points.

• Exclure les agents utilisateur qui sont clairement des robots.
• Ne pas recompter la même combinaison visiteur et page pendant un certain délai.
• Accumuler les vues par article de la même manière, avec des incréments basés sur le chemin.

Autrement dit, je l’ai ajusté pour un compteur de visites public, pas pour un outil d’analyse strict.

Je l’ai affiché discrètement à l’écran

Au début, j’ai essayé d’afficher les statistiques dans plusieurs cases. Mais l’interface placée à côté du profil devait rester petite. Quand les chiffres deviennent trop nombreux, le premier écran du blog se salit plutôt qu’autre chose.

J’ai donc finalement gardé trois valeurs.

Aujourd'hui / Mois / Total

Aujourd'hui donne la sensation que le blog est lu maintenant. Mois montre l’échelle récente. Total montre le temps que le blog a accumulé.

Dans les listes d’articles, j’ai ajouté un nombre de vues à chaque article.

10 vues

Cette valeur utilise aussi la même structure que les statistiques globales.

Vues par article = base GA par article + incrément Cloudflare D1 par article

Par exemple, si un article avait 9 vues selon la base GA et qu’il a été lu une fois de plus après le passage au nouveau compteur, l’écran affiche 10 vues.

C’était ce qui semblait le plus naturel. Les vues passées ne sont pas jetées, et les vues futures s’accumulent immédiatement.

Résultat

Au final, des chiffres comme ceux-ci sont apparus près du profil du blog.

Aujourd'hui 1 / Mois 66 / Total 4,944

Et les listes d’articles affichent les vues sous cette forme.

10 vues

Si l’on regarde seulement la fonctionnalité, elle est petite. Mais j’aime beaucoup ce travail.

Le problème était clair. Un blog GitHub Pages n’avait pas de compteur de visites. GA existait, mais il ne suffisait pas comme compteur visible sur l’écran public. Pour autant, je ne voulais pas construire un gros serveur juste pour un seul blog.

J’ai donc conservé les données existantes de GA comme base de référence, puis ajouté une structure qui compte directement seulement les incréments suivants avec Cloudflare Worker et D1.

Les avantages du blog statique sont restés tels quels. J’écris en Markdown, je déploie avec GitHub Pages, et le coût de maintenance reste presque nul. En échange, j’ai posé une petite pièce sans serveur uniquement sur la partie exacte qui manquait.

Si plus tard je dois présenter ce blog comme un portfolio, ce genre de travail sera peut-être justement facile à expliquer. Ce n’est pas une fonctionnalité grandiose, mais elle est partie d’une gêne réelle, elle a limité le coût et la complexité, et elle a été menée jusqu’à une forme exploitable.