Les 24h qui suivent la publication d'un article, d'après les logs d'accès nginx

Il y a quelques mois, j’ai lu l’article what happens to a new URL the first 10 minutes on the internet? de Mattias Geniar. Depuis, je me demandais occasionnellement ce qu’il en était pour les articles que je poste sur ce blog.

Finalement, j’ai fini par me pencher sur les logs des 24 heures qui ont suivi la publication du transcript de ma conférence « Notre environnement de développement n’est plus un bizutage ! » au Forum PHP 2016 Paris, début novembre 2016, pour voir ce que j’arrivais à en tirer d’intéressant.

Je souhaite voir toutes les requêtes, y compris celles effectuées par les bots (qui n’interprêtent pas forcément le code Javascript ou ne chargent pas toujours les images et ne sont donc pas visibles dans des outils comme Google Analytics) et je n’ai pas de système de cache devant mon serveur Web. Le log d’accès de mon nginx contient donc les informations dont j’ai besoin.

Cet article a été mis en ligne à 7h45. Il est immédiatement remonté dans le flux RSS de mon blog, mais je n’ai annoncé sa sortie via un Tweet qu’à 8h57. Pour cet article, je n’ai moi-même posté sur aucun autre réseau social (facebook / reddit / linkedin / autres).

La première heure après publication de l’article, je vois quelques visites de bots et les premières personnes arrivant via le flux RSS :

• 07:45:04 : je viens tout juste de mettre l’article en ligne. Je suis le premier à le charger, pour vérifier qu’il rend bien.
• 07:45:46 : moins d’une minute après publication, requête dont le User-Agent est Ruby, sans plus d’information. Un bot, ou un aggrégateur de flux RSS qui télécharge l’article ?
• 07:46:13 : au tour du bot de Facebook (User-Agent facebookexternalhit/1.1). D’autres suivent, comme Slackbot-LinkExpanding 1.0 à 07:50:19, via le flux RSS.
• 07:52:02 : 7 minutes après mise en ligne, première requête d’un vrai utilisateur (je ne sais pas d’où il est arrivé).
• 07:57:59 : je suis en train de préparer un tweet (qui sera posté plus tard par Buffer) et je vérifie donc que le lien renseigné dans Buffer est correct.
• 08:03:49 : un autre vrai utilisateur : le premier pour lequel je peux déterminer qu’il est arrivé via le flux RSS.
• 08:04:55 : premier passage de Twitterbot/1.0 rapidement suivi d’autres bots comme MetaURI API/2.0, Applebot/0.1 ou Twingly Recon – je n’ai pas encore tweeté de lien vers l’article, à ce moment là
• 08:16:03 : premier passage de Googlebot/2.1 – une demi-heure après mise en ligne, c’est presque tard.
• 08:31:18 : première requête avec journalduhacker.net comme Referer. C’est l’un d’entre vous, peut-être un de ceux arrivés via le flux RSS, qui a posté le lien là-bas, merci !
• 08:34:24 : on dirait que l’article vient d’être ajouté à Pocket pour la première fois. Je vois une requête avec le User-Agent PocketParser/2.0

À 8h57 (une heure et douze minutes après publication, donc), le tweet programmé un peu plus tôt via Buffer est envoyé !

• 08:57:44 : première requête arrivée suite à un clic sur le lien présent dans ce tweet (Referer https://t.co/HuefERR5HR). Dans la minute qui a suivi l’envoi du tweet !
• 09:03:13 : nouveau passage de Twitterbot/1.0, probablement pour voir ce qu’il y a derrière ce lien. Peut-être pour générer la vignette affichée sur la vue web de Twitter ?

La suite de la journée alterne des requêtes de vrais visiteurs et de bots. Je note quelques points intéressants :

• 11:25:37 : quelqu’un a du poster un autre lien sur twitter récemment, parce que plusieurs visiteurs sont arrivés avec https://t.co/uwIqlfASLk comme referer, sur une plage de quelques minutes.
• 14:17:02 : requête de Twitterbot/1.0 sur ?utm_content=buffer75bdd&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer suivie d’une série de requêtes avec ces mêmes paramètres ; et ça n’a pas l’air d’être moi qui ai twitté à ce moment là.
• 16:05:09 : j’ai twitté une seconde fois. Je vois rapidement passer une nouvelle série de robots, ainsi que quelques visiteurs.

En nombre de requêtes, heure par heure, sur les 24h suivant la publication, j’obtiens ceci :

Sur ce graphe, on voit clairement les consultations instantanées après la publication de l’article et sa remontée en flux RSS et sur Twitter. Les choses se tassent très vite ensuite et restent globalement constantes sur la journée.

En listant les Referer les plus classiques, voici les nombres de requêtes dont le Referer contient :

• HuefERR5HR (mon 1er tweet) : 83 requêtes
• journalduhacker.net : 32 requêtes
• uwIqlfASLk (un autre tweet, pas de moi) : 13 requêtes

Au vu des User-agents, j’ai l’impression que :

• 524 requêtes ont été effectuées par de vrais utilisateurs
• 100 requêtes ont été lancées par des outils : robots d’indexation, aggrégateurs de flux RSS, …

En parcourant rapidement et manuellement le Referer parfois envoyé lors des visites de vrais utilisateurs, je vois 29 accès depuis un lecteur de flux RSS – que ce soit depuis des solutions cloud comme Feedly ou via des approches auto-hébergées comme Tiny-Tiny-RSS que j’utilise moi-même.

Je vois également :

• 518 requêtes en HTTP/1
• 119 requêtes en HTTP/2

Et je note un dernier point intéressant dans le log nginx : j’observe trois tailles en octets, pour la page retournée par le serveur :

• 13248 octets : 136 requêtes – la page compressée en brotli
• 15766 octets : 250 requêtes – la page compressée en gzip
• 58076 octets : 128 requêtes – la page non compressée

Sans trop réfléchir, je suppose que de nombreux bots ne supportent pas la compression (le serveur retourne la page compressée au mieux, selon les algorithmes que le client indique supporter via l’en-tête Accept-Encoding). Je constate qu’environ un tier des pages servies compressées sont en brotli, c’est encourageant !

Et vous, regardez-vous les logs d’accès lorsque vous publiez sur votre blog ? Qu’en tirez-vous d’intéressant ?