Le transfert de la génération de miniatures d'un backend PHP vers Cloudflare Workers a éliminé toute la charge CPU du serveur d'origine pour un site d'hébergement vidéo qui sert des millions d'images par jour. Ce changement a également déplacé la latence de traitement d'images du centre de données vers l'edge, réduisant considérablement les temps de réponse et rendant les coûts de bande passante prévisibles.

Pourquoi l'ancien modèle a échoué

Le site, une plateforme qui affiche des dizaines de milliers de vidéos, intègre jusqu'à 40 miniatures sur une seule page. Chaque miniature est redimensionnée à la demande par un script PHP qui lit le fichier original et le redimensionne. Lorsque les robots d'indexation visitaient le site, le serveur backend se bloquait.

Le traitement à l'edge répond aux cinq exigences fondamentales

Une API de miniatures de qualité production doit gérer :

  • Fan-in – récupérer les images sources auprès de nombreux hébergeurs tiers.
  • Fan-out – produire plusieurs tailles (par ex. des cartes de 320 px, des images hero de 640 px).
  • Négociation de format – servir du WebP ou de l'AVIF lorsque le navigateur les supporte afin de réduire la bande passante.
  • Cache – s'assurer que si la première requête peut être coûteuse, chaque requête suivante est gratuite.
  • Sécurité – empêcher quiconque d'abuser du service pour traiter des images arbitraires.

Cloudflare Workers répondent à chacun de ces points sans solliciter le CPU de l'origine :

  1. Proximité – Les Workers s'exécutent dans des centres de données proches de l'utilisateur, l'image traitée parcourt donc un chemin plus court.
  2. Image Resizing intégré – La fonctionnalité Image Resizing de la plateforme effectue le travail au niveau des pixels, éliminant le besoin d'une bibliothèque personnalisée.
  3. Cache API – Les Workers stockent l'image redimensionnée à l'edge ; après la première requête, l'edge la sert directement.
  4. Sécurité programmable – Un petit script valide les signatures HMAC, applique une liste d'autorisation (allow-list) de noms d'hôtes et de largeurs, et normalise les clés de cache pour éviter l'empoisonnement du cache (cache poisoning).

Fonctionnement du système

  1. L'origine crée des URL signées – Le backend détient une clé secrète et ajoute une signature HMAC à chaque requête de miniature. L'URL inclut également la largeur et le format souhaités.
  2. Le Worker vérifie la signature – À la réception, le Worker recalcule l'HMAC avec le secret partagé. Si la signature est manquante ou incorrecte, la requête est rejetée, ce qui empêche les abus.
  3. Application de la liste d'autorisation – Le script vérifie que le nom d'hôte source figure sur une liste prédéfinie et que la largeur demandée fait partie des tailles prises en charge. Cela empêche la mise en cache d'hôtes malveillants.
  4. Normalisation de la clé de cache – La signature elle-même est supprimée de la clé de cache ; la clé ne contient que l'URL source, la largeur et le format. Cela augmente les chances que différents utilisateurs demandant la même image accèdent à la même entrée en cache.
  5. Récupération et redimensionnement à l'edge – Si l'image n'est pas déjà en cache, le Worker récupère l'original auprès de l'hébergeur tiers, exécute l'API Image Resizing et stocke le résultat dans le cache de l'edge.
  6. Préchauffage du cache (Cache warming) – Après chaque passage de robot, un script Python léger pré-requête les miniatures les plus récentes. Le premier utilisateur réel reçoit donc une réponse mise en cache au lieu d'attendre l'opération de redimensionnement.

Impact mesurable après un mois

  • CPU de l'origine pour les images – Tombé à zéro ; le backend ne traite plus jamais d'octets d'images.
  • Vitesse de service HTML – Amélioration notable car le serveur ne bloque plus sur le traitement des images.
  • Taux de réussite du cache edge (hit rate) – Atteint 96 %, ce qui signifie que presque chaque requête a été satisfaite depuis l'edge sans appel au backend.
  • Latence – Diminuée car les images sont désormais servies depuis un centre de données proche de l'utilisateur plutôt que depuis une origine centrale.
  • Prévisibilité de la bande passante – Grâce à la mise en cache à l'edge, le trafic sortant de l'origine est stable et facile à prévoir.

En résumé

Le déchargement de la génération de miniatures vers Cloudflare Workers a transformé un goulot d'étranglement lié au CPU en un cache edge à coût quasi nul. L'origine ne fait plus qu'émettre des URL signées, tandis que l'edge gère la récupération, le redimensionnement, la négociation des formats et la distribution des résultats mis en cache. Pour tout site dépendant fortement des images — en particulier les plateformes vidéo qui affichent des dizaines de miniatures par page — l'approche "edge-first" offre des pages plus rapides, des coûts prévisibles et une séparation plus nette entre « ce qu'il faut montrer » (l'origine) et « comment le livrer » (l'edge).