Cloudflare Workers : repérer le calcul qui consomme les ressources

Un calcul de disponibilité ralentit une page, alors que ses images s’affichent correctement. Pour comprendre ce type de situation, il faut pouvoir examiner le travail de l’application qui répond au site. Cloudflare a annoncé le 9 octobre 2026 un profilage CPU et mémoire à la demande pour Workers et Durable Objects. Cet outil aide à retrouver les fonctions qui consomment des ressources pendant leur exécution.

Un Worker exécute du code sur l’infrastructure Cloudflare. Il peut, par exemple, calculer une réponse ou relier le site à un service externe. Un Durable Object est un composant de cette plateforme qui conserve un état pour coordonner un usage. Ce sont des fonctions à identifier dans votre architecture : placer un site derrière les protections Cloudflare ne prouve pas qu’il utilise l’un de ces composants.

Lire la bonne mesure

Un profil CPU montre où le processeur consacre son temps de calcul. Un profil Heap observe les allocations, c’est-à-dire les réservations de mémoire effectuées par le code pendant la capture. La documentation de profilage précise que ce dernier n’établit pas quelle mémoire reste occupée ensuite. Pour rechercher une mémoire qui s’accumule, il faut donc rapprocher ce profil d’autres observations ; une fonction qui alloue beaucoup n’est pas automatiquement la preuve d’une fuite.

Les résultats apparaissent notamment dans un flamegraph, un graphique de rectangles associés aux appels de fonctions. Leur largeur représente la part de temps CPU ou de mémoire allouée selon le profil choisi. Leur position horizontale n’indique pas l’ordre chronologique des opérations. Un grand rectangle sert de piste : il faut regarder ce qu’il contient et pourquoi ce travail existe avant de le modifier.

Le temps CPU diffère aussi du délai ressenti par un client. Une application peut calculer peu et attendre longtemps une réponse distante. Réduire un calcul n’éliminera pas nécessairement cette attente. Pour une PME, l’enjeu est de relier la mesure à une action précise du visiteur, plutôt que de demander un meilleur score sans savoir ce qui gêne.

Préparer un essai qui représente la demande

La capture documentée dure de 1 à 50 secondes, soit 1 000 à 50 000 millisecondes. Elle vise une version déjà chargée et active, qui doit recevoir du trafic avant et pendant l’observation. Choisir une période passée dans les journaux ne rejoue pas ces anciennes demandes. L’annonce présente le profilage continu comme un travail à venir : l’outil à la demande peut donc manquer un incident apparu hors de sa fenêtre.

• Identifiez avec le prestataire l’action concernée et le composant Workers qui y participe. Gardez un cas de test autorisé et un résultat attendu.
• Faites relever la version réellement en service, le type de profil et le créneau d’observation. La dernière version créée peut différer de celle qui reçoit les demandes.
• Après une correction, comparez le même parcours et son résultat. Le maintien de la bonne réponse compte autant que le changement de consommation.

Dans un exemple hypothétique, un distributeur affiche le délai de plusieurs références. Le profil révèle qu’une fonction parcourt deux fois les mêmes données. Le prestataire peut étudier ce doublon, puis vérifier que chaque référence conserve son délai exact. Ce scénario illustre une décision possible ; il ne prédit ni le diagnostic de votre application ni un gain chiffré.

Faites confirmer l’accès au profilage pour le compte et l’environnement concernés avant de prévoir l’intervention. La documentation mentionne des requêtes de capture limitées en fréquence et des environnements où la fonction peut être indisponible ; elle ne donne pas ici un quota numérique à appliquer à vos clients. Conservez le profil avec la version et le cas observé. Cela donne une preuve de diagnostic exploitable, sans transformer une courte capture en bilan de toute l’application.