ASA Compass · suite de K-47 · session hotel-saint-michel-97 · 1er septembre 2026 · retour au rapport K-47
Le rapport K-47 a trouvé que le budget gratuit de 100 000 requêtes par jour est celui du compte entier, partagé avec le Worker qui sert les images. Cette note mesure ce que le site actuel consomme vraiment par visite, chiffre le plafond de visiteurs avant et après avoir sorti les vignettes de ce budget, et dit ce qui a été fait et ce qui ne l'a pas été.
Une seule visite de la page des collections émet 248 requêtes d'images avant même de défiler. Une visite type du site actuel (accueil, index des collections, six collections) en émet 323. Sur le plan gratuit, cela plafonne le site à 309 visiteurs par jour, et la consommation réelle relevée (25 731 requêtes le 31 août, 35 824 le 1er septembre en milieu de journée) montre que ce budget se dépense déjà avec une poignée de visiteurs.
Karl a accordé l'accès public par clé au seau, et il a été activé et mesuré (section 5) : 60 vignettes au hasard servies en 200 avec des octets identiques à ceux du Worker, aucune énumération possible, 181 ms la première requête et 107 ms la seconde depuis Montréal. Mais l'adresse r2.dev est limitée en débit, et la limite a été atteinte : une rafale de 1 000 requêtes est refusée (429) à partir de la 600e environ, et deux origines qui chargent en même temps sont freinées toutes les deux. Elle absorbe une visite (248 images), pas une foule. Cloudflare la réserve au développement, et la mesure lui donne raison.
Ce qui en découle : le gain « 1 031 visiteurs par jour » de la première version de cette note était une déduction à partir du palier mensuel de R2 ; la mesure montre que, par r2.dev, la borne réelle est un débit, pas un quota. La voie de production, un domaine posé sur le seau, est reportée : elle exige de déplacer toute la zone DNS d'asacompass.com, qui sert aujourd'hui la landing page de Karl. Le levier qui reste, gratuit et sans risque, est celui de l'index : ramener ses 248 images à ce que l'écran montre, ce qui porte le plafond de 309 à 869 visiteurs par jour. Il appartient à la session chantier.
Geste : chaque page de site-public/ ouverte dans Chrome sans fenêtre par sonde/verifier-chrome.mjs, viewport émulé en 1 280 × 900 puis en 375 × 667, attente de 2,5 s après le chargement, comptage des entrées performance.getEntriesByType('resource') vers asa-compass-medias. Le 1er septembre à 13 h UTC. Aucun défilement : ce sont les requêtes qu'une arrivée sur la page émet toute seule.
| Page | images dans le HTML | requêtes émises, 1 280 | requêtes émises, 375 |
|---|---|---|---|
index.html, l'accueil | 38 | 27 | 18 |
collections.html, l'index des collections | 15 552 | 248 | 248 |
c/algokitten.html | 8 | 8 | 4 |
c/al-goanna.html | 8 | 8 | 4 |
| toutes les pages de collection (2 222, comptage dans le HTML) | médiane 9, p90 12, max 27 |
Les 15 552 images de l'index portent toutes loading="lazy", et le navigateur en charge pourtant 248 à l'arrivée, autant en mobile qu'en bureau. Ce n'est donc pas l'écran visible qui décide : c'est vraisemblablement la mosaïque ou une colonne dont les images sont considérées comme proches du viewport. Ce point appartient à sonde/site.mjs, donc à la session chantier ; il est signalé, pas corrigé.
Consommation réelle, lue dans l'analytique Cloudflare (GraphQL workersInvocationsAdaptive, par Worker et par jour) : asa-compass-medias 25 731 requêtes le 31 août, 35 824 le 1er septembre à 13 h UTC (ce second chiffre inclut mes propres campagnes de mesure) ; asa-compass-market 1 008 et 156. Le budget du compte est de 100 000 par jour, remis à zéro à minuit UTC ; au-delà, Cloudflare rend l'erreur 1027.
Le profil, le même dans toutes les lignes : une visite = l'accueil, l'index des collections, six pages de collection. Les pages du site statique sont servies par Pages et ne comptent pas ; seules les images comptent, et, dans le prototype K-47, les pages rendues. Les plafonds sont des divisions du palier gratuit par la consommation d'une visite ; le palier R2 (10 millions de lectures par mois, tarif lu le 1er septembre) est ramené à 333 333 par jour.
| Situation | requêtes Workers par visite | lectures R2 par visite | plafond, bureau | plafond, mobile |
|---|---|---|---|---|
| Aujourd'hui : vignettes par le Worker | 323 / 290 | 0 (le Worker lit R2, mais c'est le Worker qu'on compte) | 309 visiteurs/j | 344 visiteurs/j |
| Aujourd'hui, si l'index ne chargeait que ~40 images (levier chantier, sans décision) | 115 / 82 | 0 | 869 | 1 219 |
Vignettes depuis r2.dev (déduit du quota mensuel R2 ; mais voir la section 5 : la borne réelle est un débit, mesuré) | ~0 | 323 / 290 | 1 031 par le quota ; en pratique, borné par le débit | 1 149 par le quota ; idem |
Vignettes depuis r2.dev et index corrigé | ~0 | 115 / 82 | 2 898 par le quota ; même réserve | 4 065 par le quota ; même réserve |
| Vignettes depuis R2 derrière un domaine avec cache | ~0 | seulement les défauts de cache | au-delà de 10 000 : les 248 images de l'index sont les mêmes pour tous et restent chaudes | |
| Prototype K-47 (pages rendues) + vignettes depuis R2 | 8 | selon la page | 12 500 côté Workers | 12 500 |
Les lignes « par le quota » divisent le palier mensuel de R2 par la consommation d'une visite ; elles supposent que r2.dev laisse passer, ce que la section 5 dément sous charge. La ligne « avec cache » n'est pas une mesure : c'est le raisonnement que le palier R2 compte des opérations sur le seau et qu'une réponse servie par le cache n'en est pas une ; la documentation lue ne le dit ni ne le contredit. La seule ligne entièrement mesurée et disponible sans décision est celle de l'index corrigé : 869 visiteurs par jour.
Adresse r2.dev | Un domaine posé sur le seau | |
|---|---|---|
| Ce que c'est | Cloudflare donne au seau une adresse publique pub-….r2.dev ; une commande l'active, une la désactive | Un nom, par exemple media.asacompass.com, pointé sur le seau ; passe par le cache Cloudflare |
| Ce que la documentation en dit (1er sept.) | « Public access through r2.dev subdomains is rate-limited and should only be used for development purposes. » La limite n'est pas chiffrée. | « Domain access through a custom domain allows you to use Cloudflare Cache to accelerate access. » Prérequis : « The domain being used must have been added as a zone in the same account as the R2 bucket. » |
| Coût | 0 $ | 0 $, si le domaine est déjà une zone Cloudflare ; sinon, mettre un domaine ou un sous-domaine sur Cloudflare |
| Ce que Karl doit décider | rendre le seau publiquement lisible | rendre le seau publiquement lisible et poser un nom de son entreprise dessus : une configuration DNS, tournée vers l'extérieur |
| Réversibilité | une commande | plusieurs gestes, dont un DNS |
Ce que « publiquement lisible » autorise exactement, vérifié dans la documentation : servir un objet dont on connaît la clé. Pas l'énumération : « Currently, public buckets do not let you list the bucket contents at the root of your (sub) domain. » Les clés sont de la forme vignette/{identifiant d'actif}.jpg ou un CID IPFS ; elles sont déjà toutes dans le HTML public du site. L'exposition n'est donc pas nouvelle en substance, mais elle passe d'un Worker qui décide ce qu'il sert à un seau qui sert ce qu'on lui demande ; les 13 807 médias servis aujourd'hui à travers le Worker ne bougent pas et ne sont pas touchés par l'une ou l'autre voie.
Ce qui s'est passé : wrangler r2 bucket dev-url enable asa-compass-medias a d'abord été refusé par la garde de permissions de la session, comme action tournée vers l'extérieur. Karl a ensuite accordé l'accès public par clé, sur l'argument de la non-énumération, et la commande a été approuvée dans la fenêtre de la session. L'adresse est https://pub-e2367519212d44fba9230bd616acaa97.r2.dev/, et elle se retire par dev-url disable. Le sous-domaine, lui, est reporté : le greffier a vérifié avant d'agir qu'asacompass.com sert la landing page Tilda de Karl, avec des serveurs de noms Tilda ; poser un nom sur le seau exigerait de déplacer toute la zone DNS, et Karl a consenti à un sous-domaine, pas à cela. La marche à suivre, avec son inventaire DNS et son point de retour, est écrite dans cache-medias/LISEZMOI.md sans être exécutée.
Ce que la bascule demande ensuite, quelle que soit la voie : changer le préfixe des adresses d'images dans sonde/site.mjs (une constante), et garder le Worker comme repli onerror pour les clés en forme de CID, puisque le seau ne sait pas rattraper un média absent auprès des passerelles IPFS comme le Worker le fait. Ce changement appartient à la session chantier et suppose une régénération du site.
collections.html à celles de l'écran. De 309 à 869 visiteurs par jour, sans décision, sans exposition, sans changement d'architecture. C'est le meilleur rapport de toute cette note.r2.dev : l'adresse tient une visite, pas plusieurs à la fois, et Cloudflare la réserve au développement. La laisser activée ne coûte rien et permet de mesurer ; la désactiver si elle ne sert pas.r2.dev, une fois l'accès accordéGeste : 60 clés tirées au hasard dans le HTML du site (echantillon-vignettes.json), chacune demandée deux fois à r2.dev puis une fois au Worker, par curl depuis Montréal, le 1er septembre vers 14 h UTC ; empreintes SHA-256 comparées. Puis des rafales : les 248 images d'une visite de l'index, 1 000 clés distinctes de l'index, 24 requêtes en parallèle ; 300 clés à 3 en parallèle ; et une flotte de 24 invocations d'un Worker (50 requêtes chacune, la limite du plan gratuit par invocation) seule puis en même temps qu'une rafale locale. Pauses de 45 à 60 s entre les rafales.
| Ce qui a été mesuré | Résultat |
|---|---|
| 60 vignettes au hasard | 60 en 200, octets identiques à ceux du Worker, types image/jpeg et video/mp4, Cache-Control: public, max-age=31536000, immutable repris des objets |
| temps, médiane (p90) | première requête 181 ms (277) ; seconde 107 ms (143) ; le Worker, pour comparer, 103 ms (127). Aucun en-tête cf-cache-status : rien n'indique un cache devant r2.dev |
| énumération | racine en 404, clé absente en 404, ?list-type=2 en 404 : on ne peut pas lister le seau |
| rafale de 248 (une visite de l'index), 24 en parallèle | 248 en 200, 2 s |
| rafale de 1 000 clés distinctes, 24 en parallèle | 613 en 200 puis 387 en 429, premier refus à la 601e ; un autre essai a été refusé dès la 361e, la fenêtre étant encore entamée. Après 20 s, une requête passe à nouveau |
| 300 clés à 3 en parallèle (14 requêtes par seconde) | 300 en 200, 21 s : un débit modéré passe |
| flotte Worker seule (24 invocations × 50) | aucun 429 |
| flotte Worker et rafale locale de 1 000 en même temps | local : 249 en 200, 751 en 429 ; Worker : 33 en 429 sur 450 comptés. La limite est surtout par client, mais pas seulement : une seconde origine a été freinée pendant que la première saturait |
Ce que cela dit : r2.dev sert une visite entière du site actuel sans broncher, et refuse une charge de quelques centaines de requêtes en quelques secondes. Un site ouvert au public, où plusieurs visiteurs ouvrent l'index en même temps (248 images chacun), franchirait cette borne, et ses visiteurs verraient des images manquantes sans message. C'est exactement ce que la documentation annonçait ; la mesure en donne l'ordre de grandeur. Le plafond de visiteurs par r2.dev ne se calcule donc pas depuis le quota mensuel : il n'a pas de valeur sûre, et c'est pour cela que la recommandation revient à l'index et au domaine.
r2.dev et sa portée (par adresse, par seau) : encadrée par les rafales, pas établie ;