Optimisation d'images Webflow gratuite avec Cloudflare (2026) : notre Worker O2O open source

MIS À JOUR (2 octobre 2026) : cet article a été entièrement réécrit pour la version 6 de notre Worker, désormais gratuite, open source et sur GitHub. Si vous avez suivi la version de janvier de ce guide (celle avec les liens /cdn-cgi/image/, une variable DOMAIN et un CodePen à coller dans le tableau de bord), descendez directement à la section « Mettre à jour depuis l'ancien Worker ». Tout le reste ci-dessous est nouveau.

Ça fait à peu près quatre ans qu'on essaie de faire bien s'entendre Webflow et Cloudflare. D'abord, il y a eu une bidouille avec les réglages SSL et l'app Cassette pour mettre en cache et optimiser les images. Puis Cloudflare a supprimé les apps et nous avons écrit notre propre Worker pour faire transiter et mettre en cache les images Webflow. Puis Webflow a déplacé son hébergement sur Cloudflare, l'Orange-to-Orange (O2O) s'est enfin mis à fonctionner correctement, et en janvier nous avons publié la première version de ce guide, avec un Worker plus gros et plus costaud qui gérait aussi le CSS, le JS et les polices.

Et maintenant, honnêtement, on s'est un peu emballés. Le Worker a été reconstruit de zéro, il tourne sur notre propre site depuis fin septembre et sur un deuxième site depuis le 1er octobre, il a été testé sur cinq vraies pages issues de quatre sites Webflow différents, et nous avons mis le tout sur GitHub, gratuitement, avec un bouton Deploy. Fini de copier un script depuis un CodePen. Vous cliquez sur un bouton, vous collez un secret, vous ajoutez une ligne, et c'est terminé.

Nous l'avons baptisé Milk Moon Webflow Optimizer. Voici ce qu'il fait, pourquoi il respecte les règles de Webflow, comment fonctionne le cache, ce qu'il fait économiser, chaque réglage, toute la configuration du DNS jusqu'à la fin, et tout ce qui peut mal tourner. C'est long, alors allez vous chercher un café.

La version courte

Le Milk Moon Webflow Optimizer est un Worker Cloudflare qui se place devant votre site Webflow (en pratique, un reverse proxy Webflow pour vos fichiers). Au fil du streaming de chaque page, il remplace l'adresse de chaque image, feuille de style, script et police Webflow par une adresse sur votre propre domaine. Quand le navigateur demande ces fichiers, le Worker les récupère une seule fois chez Webflow, compresse les images en AVIF ou en WebP (selon ce que le navigateur du visiteur sait ouvrir) et garde le tout dans le cache de Cloudflare, près de vos visiteurs, jusqu'à un an. Tous ceux qui passent ensuite reçoivent la copie en cache.

Ce que vous obtenez :

• Chaque image PNG, JPG, GIF et WebP convertie à la volée en AVIF ou en WebP. Personne n'a rien à réexporter dans Webflow.
• Images, CSS, JS et polices servis depuis votre domaine et mis en cache à la périphérie de Cloudflare.
• Beaucoup moins de données qui sortent de Webflow, et c'est justement ça que Webflow vous facture.
• Des pages qui se mettent toujours à jour dès que vous cliquez sur publier.
• Des images d'aperçu pour les réseaux sociaux qui fonctionnent à tous les coups (converties en JPEG pour LinkedIn, Facebook, WhatsApp et X), plus la balise og:url que Webflow n'ajoute jamais.
• En option, des images téléchargées à la taille à laquelle elles sont réellement affichées, et non à la taille devinée par Webflow.
• Votre site reste exactement le même. Même design, mêmes interactions, même contenu.

Sur notre page d'accueil aujourd'hui, les 38 fichiers d'images principaux pèsent 8 762 Ko directement depuis Webflow et 1 755 Ko via le Worker. Soit 80 % de moins, et pas une seule image n'est ressortie plus lourde que l'originale. La pire de la bande, une capture d'écran de projet en PNG de 2,7 Mo, arrive maintenant sous la forme d'un WebP de 198 Ko. Même image.

Pourquoi s'embêter ? Le problème des serveurs de fichiers de Webflow

Webflow est génial pour créer et héberger des sites, sinon nous ne serions pas un studio Webflow. Mais la façon dont il livre vos fichiers cache trois pièges, et ils vous coûtent tous de l'argent ou de la vitesse.

1. Vos images partent telles que vous les avez importées. Webflow crée bien quelques copies plus petites de chaque image pour différentes tailles d'écran (les fichiers -p-500, -p-800 que vous avez sans doute déjà croisés), et il propose dans le panneau Assets un outil Compress qui convertit les images en AVIF ou en WebP. Mais c'est un travail manuel, il remplace vos originaux, et tout ce que vous n'avez pas converti part toujours exactement tel que vous l'avez importé. Une capture d'écran importée en PNG reste un PNG, et elle part en PNG vers chaque téléphone. Les formats modernes comme AVIF et WebP peuvent réduire cette même image à une fraction de sa taille, sans aucune différence visible à l'œil.

2. Webflow facture la bande passante. Chaque plan de site comprend un quota mensuel de bande passante, et selon la propre définition de Webflow, la bande passante totale correspond à « chaque octet que le CDN de Webflow livre pour votre site, y compris le HTML, le CSS, le JavaScript et les assets ». Les bots comptent. Les 404 comptent. Dépassez deux mois de suite et votre plan passe automatiquement au palier supérieur. Ce sont les images lourdes et les téléchargements répétés qui font grimper ce chiffre.

3. Vos fichiers ne sont pas sur votre domaine. Même avec l'O2O activé, vos images, votre CSS et vos polices restent sur cdn.prod.website-files.com (et sur quelques anciens hôtes Webflow). Ce n'est pas votre domaine, donc votre zone Cloudflare ne peut pas y toucher. Pas de règles de cache Cloudflare, pas d'optimisation d'images, rien. Le nuage orange ne couvre que vos pages.

Le Worker règle les trois problèmes, et il le fait sans rien changer à votre projet Webflow.

Est-ce autorisé ? Webflow, l'O2O et les règles

Réponse courte : oui, et c'est la partie dont on est le plus fiers, parce que les anciennes méthodes n'étaient franchement pas terribles. L'app Cassette, les astuces SSL avec le nuage gris, les sous-domaines pour les assets, tout ça, c'était nous qui nous battions contre la plateforme. Là, ce n'est pas le cas.

Voici où on en est, avec les mots de Webflow :

• Le centre d'aide de Webflow indique que « l'O2O est la méthode prise en charge pour faire tourner des fonctionnalités Cloudflare devant Webflow », et que l'O2O est disponible sur toutes les offres Cloudflare, y compris la Free.
• Le tableau de compatibilité des produits avec l'O2O de Cloudflare indique que les Workers sont pris en charge, avec un avertissement plein de bon sens : un Worker sur votre hôte O2O peut gêner vos visiteurs s'il se comporte mal. C'est exactement pour ça que le nôtre a les verrous de sécurité dont vous lirez le détail plus bas. Le même tableau précise aussi que mettre en cache de votre côté est généralement déconseillé, surtout pour le HTML, parce que Webflow met déjà vos pages en cache. C'est pour ça que, par défaut, le Worker laisse les pages à Webflow et ne met en cache que les fichiers de Webflow, qui ne changent jamais à une même adresse.
• La seule chose que le centre d'aide de Webflow cite nommément, c'est de mettre votre domaine de staging *.webflow.io derrière un reverse proxy, ce qui, selon lui, enfreint ses conditions. Nous n'y touchons jamais. Le Worker ne tourne que sur votre domaine personnalisé, c'est-à-dire là où Webflow dit qu'il faut placer le proxy.
• Le guide de Webflow sur le reverse proxy demande aussi de transmettre le chemin complet et la chaîne de requête, et d'éviter toute réécriture HTML qui modifie les liens internes. Le Worker transmet chaque requête de page sans y toucher et ne réécrit jamais que les adresses des fichiers de Webflow lui-même. Vos liens, vos formulaires, vos pages CMS, votre recherche et vos filtres restent exactement tels que Webflow les a créés.

Deux réserves, en toute honnêteté. D'abord, l'équipe support de Webflow ne dépannera pas un Worker pour vous ; ils le disent clairement (« You manage your proxy »). C'est de bonne guerre, et c'est aussi pour ça que le désactiver tient en une ligne (on y revient dans la partie retour en arrière). Ensuite, nous ne prétendons pas que Webflow a approuvé notre Worker. Ce que nous disons, c'est qu'il repose entièrement sur la configuration que Webflow prend officiellement en charge, avec une fonctionnalité Cloudflare dont Cloudflare lui-même dit qu'elle est compatible. Aucune bidouille.

Comment ça marche, en termes simples

Imaginez Webflow comme une usine qui fabrique tout pour votre boutique. Sans le Worker, chaque commande client part directement de l'usine, dans son emballage d'origine encombrant, à chaque fois.

Le Worker, c'est un gérant d'entrepôt local. La première fois qu'un article est commandé, il va le chercher à l'usine, le reconditionne dans le plus petit carton possible (un carton différent selon ce que le client sait ouvrir) et en pose une copie sur l'étagère. Ensuite, les clients sont servis depuis l'étagère locale. C'est plus rapide pour eux, et l'usine n'expédie presque plus rien. Le gérant suit aussi des règles strictes : il ne traite que les commandes dont il a lui-même écrit les étiquettes, il ne touche jamais à certaines livraisons (les contrôles de sécurité, l'analytics), et si quoi que ce soit tourne mal, il s'écarte et laisse la commande partir directement de l'usine, exactement comme avant.

Voici la même chose sous forme de vrai schéma.

Étape par étape

1. Un visiteur demande une page. Quelqu'un ouvre votre site. Grâce à l'O2O, la requête arrive d'abord au centre de données Cloudflare le plus proche de lui.
2. Le Worker récupère la page chez Webflow. Exactement telle que Webflow la sert.
3. Il vérifie qu'il s'agit bien d'une page Webflow. Chaque page Webflow porte un petit marqueur dans la balise <html> (data-wf-site). Pas de marqueur (une app, une API, une page de connexion), et le Worker transmet la réponse octet pour octet, sans rien faire d'autre.
4. Il réécrit les adresses des fichiers au fil du streaming de la page. Chaque adresse d'image, de feuille de style, de script et de police Webflow devient une adresse signée sur votre domaine. Ça se passe pendant que la page arrive encore, donc le navigateur commence à l'afficher tout de suite. Le Worker n'attend jamais d'avoir la page entière.
5. Le navigateur demande ces fichiers à votre domaine.
6. Le Worker vérifie la signature, convertit les images et stocke tout. Les images passent par le convertisseur d'images de Cloudflare, et si la version convertie devait être plus lourde que l'originale (ça arrive avec des photos déjà compressées), vous recevez l'originale à la place.
7. Tous ceux qui passent ensuite reçoivent la copie stockée. Depuis le cache de Cloudflare, sans même que le Worker tourne et sans rien demander à Webflow.

Les liens signés (et pourquoi personne ne peut abuser de votre Worker)

C'est ce qui distingue la version 6 de tout ce qu'on a fait avant, alors accrochez-vous.

Les serveurs de fichiers de Webflow sont partagés. Les images de tous les clients Webflow vivent sur le même hôte cdn.prod.website-files.com, simplement dans des dossiers différents. Donc un Worker qui dit « je récupère et j'optimise tout ce qui vient du serveur de fichiers de Webflow » propose, sans le vouloir, de récupérer et d'optimiser les fichiers Webflow de n'importe qui, via votre domaine, sur votre facture Cloudflare. Notre ancien Worker avait exactement cette faille, et nous l'avons trouvée nous-mêmes en septembre (nous l'avons verrouillé sur les ID de notre propre site le jour même, puis nous sommes partis en quête d'une meilleure solution).

La version 6 fait les choses proprement. Chaque adresse que le Worker écrit dans votre page reçoit une courte signature : 16 caractères générés avec HMAC-SHA256 et une clé secrète que seul votre Worker connaît (la SIGNING_KEY que vous définirez pendant l'installation). Quand une requête arrive pour un fichier, le Worker recalcule la signature pour cette adresse exacte. Si elle correspond, parfait. Sinon, parce que quelqu'un a inventé le lien, modifié le chemin du fichier, l'a fait pointer vers les fichiers d'un autre site ou a simplement fait une faute de frappe, il reçoit une 403 et rien n'est récupéré. Rien de récupéré, donc rien que Webflow ou le convertisseur d'images puisse vous facturer.

L'effet secondaire sympa : il n'y a rien à configurer site par site. Pas de liste d'ID de sites Webflow, pas de domaines autorisés. Le Worker ne sert que ce qu'il a écrit, point final.

Comment fonctionne le cache

Le cache, c'est là que se font les gains de vitesse et les économies de bande passante, et c'est aussi là que les gens deviennent nerveux (« et si mes visiteurs voient une ancienne version ? »). Alors voici exactement ce qui est stocké, où, et pour combien de temps.

Les fichiers : un an, et c'est sans risque

Les images, le CSS, le JS et les polices sont stockés pendant un an, dans le cache de Cloudflare et dans le navigateur du visiteur. Si c'est sans risque, c'est grâce à une habitude de Webflow qui joue énormément en notre faveur : dès qu'un fichier change, Webflow lui donne une nouvelle adresse. Remplacez une image et elle reçoit un nouvel ID dans son nom de fichier. Publiez un changement de style et votre fichier CSS reçoit un nouveau hash. Votre page pointe simplement vers le nouveau fichier, donc personne ne peut jamais recevoir une copie périmée d'un fichier modifié. Pas de bouton de purge, pas de webhook.

Le cache que nous utilisons, c'est le Workers Cache. Une requête répétée pour un fichier reçoit sa réponse de Cloudflare sans que le code du Worker s'exécute du tout. Vous pouvez le vérifier vous-même : ouvrez les DevTools sur notre site, cliquez sur n'importe quelle image ou feuille de style, et vous verrez cf-cache-status: HIT et cache-control: public, max-age=31536000, immutable. Le fichier CSS que je viens de vérifier dormait dans le cache depuis deux jours.

Les images ont droit à une astuce de plus : une adresse, plusieurs versions. La même URL d'image est stockée une fois pour chaque type de navigateur (en AVIF pour ceux qui savent l'ouvrir, en WebP pour les autres, en original pour le vieux navigateur égaré), et chaque navigateur reçoit la copie qu'il a demandée (c'est le rôle de l'en-tête Vary: Accept). Vous n'avez rien de tout ça à gérer.

Les pages : fraîches à chaque publication

Les pages, c'est une autre histoire, parce qu'elles changent sans changer d'adresse. Webflow lui-même dit aux navigateurs de garder les pages 16 jours (max-age=1382400, jetez un œil aux en-têtes de réponse de votre propre site). C'est pour ça qu'un visiteur qui revient voit parfois votre ancienne page d'accueil après une publication. Le Worker remplace ça par max-age=0, must-revalidate, pour que les navigateurs revérifient à chaque visite.

Et par défaut, le Worker ne stocke pas du tout les pages dans votre zone. Webflow met déjà vos pages en cache sur sa propre configuration Cloudflare et vide ce cache quand vous publiez, donc le laisser faire son travail signifie qu'une publication apparaît immédiatement. Si vous voulez grappiller un peu plus, il existe un réglage (HTML_EDGE_TTL, plus bas) pour garder les pages quelques minutes dans votre zone. Chez nous, il est à 10 minutes, parce que nous avons appris à nos dépens que Webflow ne vide pas le cache de votre zone quand vous publiez (nous avons vu une publication rester coincée derrière une copie vieille de 47 minutes). Dix minutes, c'est un bon compromis pour nous. Pour la plupart des sites, laissez-le à 0.

Ce qui n'est jamais mis en cache

• Les erreurs serveur de Webflow : jamais stockées, donc une panne chez Webflow n'est jamais « mémorisée ».
• Les fichiers manquants (404) : stockés 60 secondes seulement, pour qu'un fichier brièvement absent ne reste pas figé comme manquant pendant un an.
• Une conversion d'image ratée : l'image originale est servie à la place et stockée une heure, pour que la version optimisée reprenne le relais dès que la conversion refonctionne.
• Tout ce qui n'est ni une page Webflow ni un fichier signé : transmis avec no-store.

Est-ce que ça économise vraiment de la bande passante Webflow ?

Oui. Webflow compte chaque octet que son CDN livre pour votre site. Sans le Worker, chaque visiteur tire chaque fichier depuis Webflow. Avec le Worker, un fichier sort de Webflow à peu près une fois par point de présence Cloudflare, la première fois que quelqu'un près de ce point de présence en a besoin, puis il est servi depuis le cache de Cloudflare à tous les autres visiteurs du coin pendant un an.

Lors de notre premier jour complet en ligne, 92 % des requêtes CSS, JS et polices et 79 % des requêtes d'images ont été servies directement depuis le cache, et ce alors que tous les points de présence Cloudflare du monde se remplissaient encore pour la première fois. Le chiffre devrait grimper une fois que chaque point de présence aura sa copie. Nous mesurons une journée normale prochainement, et nous mettrons cet article à jour quand nous aurons le chiffre.

Deux choses à savoir, cela dit. Vos pages viennent toujours de Webflow (c'est ce qui garde la publication instantanée), donc l'économie porte sur les fichiers, qui sont de toute façon ce qui pèse. Et comme le tableau de bord d'utilisation de Webflow mesure ce que son CDN envoie, le chiffre que vous verrez baisser, c'est la part fichiers de votre bande passante, pas la part pages.

Des images à la bonne taille (nouveau en 6.1)

Celle-ci est subtile et c'est ma préférée, parce qu'elle corrige un truc que personne ne remarque mais que tout le monde paie.

Webflow crée plusieurs tailles de chaque image que vous importez et indique au navigateur la largeur à laquelle l'image sera affichée, avec l'attribut sizes. Le navigateur choisit ensuite une copie. Le problème, c'est que Webflow calcule ce chiffre à partir du canevas du Designer, et pas de la façon dont l'image s'affiche réellement sur la page, et très souvent il indique 100vw (« cette image remplit tout l'écran »). Résultat : votre image de blog, qui tient en réalité dans une colonne de 840 pixels, est téléchargée dans sa version de 3 200 pixels sur ordinateur. Le navigateur a fait confiance à Webflow. La plupart de ces octets ne sont jamais vus.

Activez SIZES_AUTO et le Worker ajoute sizes="auto, …" aux images en lazy loading. Les images en lazy loading ne se chargent qu'une fois la mise en page connue, donc le navigateur peut mesurer l'espace réel et choisir la copie qui convient vraiment. Les navigateurs qui ne comprennent pas encore auto l'ignorent tout simplement et utilisent la valeur de Webflow comme avant, donc rien ne peut casser.

Mesuré dans un vrai navigateur sur notre site : la page d'accueil sur ordinateur est passée de 670 Ko d'images en lazy loading à 404 Ko, sur mobile de 376 Ko à 255 Ko, et un article de blog de 181 Ko à 95 Ko. Zéro image cassée ou floue. Le plus drôle, c'est que ça marche dans les deux sens : sur un autre site que nous avons testé, Webflow avait sous-dimensionné quelques images, et elles ressortent maintenant plus nettes (et un peu plus lourdes). C'est le navigateur qui fait enfin les choses correctement, et c'est tout l'intérêt. C'est désactivé par défaut, parce que ça change le fichier que choisit le navigateur, mais chez nous, c'est activé.

Tout le reste

Les gros titres, ce sont les images et le cache, mais il y a là-dedans une pile de petites choses que nous avons ajoutées après nous être pris les pieds dedans sur de vrais sites.

• Les GIF animés restent animés. Les GIF ne deviennent jamais que du WebP (qui peut être animé), jamais de l'AVIF (qui, à la sortie du convertisseur, ne l'est pas).
• Jamais plus lourd que l'original. Un gros JPEG d'appareil photo déjà compressé peut carrément grossir quand on le réencode. Nous avons vu une photo de 1,9 Mo revenir à 3,6 Mo sur un site. Donc, en cas de cache miss, le Worker compare l'image convertie à l'originale et envoie la plus légère des deux. Ce seul changement a fait passer un site de test de 17 % plus lourd à 10 % plus léger.
• Pas de double téléchargement. Webflow dit aux navigateurs de commencer à récupérer votre CSS en avance, avec un en-tête Link (que Cloudflare transforme en Early Hints). Le Worker fait pointer ces récupérations anticipées vers la même adresse que celle qu'utilise la page, donc rien n'est téléchargé deux fois. Les preloads de polices sont laissés tels quels exprès, parce que les polices se chargent depuis le CSS et que les réécrire provoquerait exactement le double téléchargement qu'on cherche à éviter.
• Des aperçus sociaux qui fonctionnent. og:image et twitter:image partent en JPEG compressé (configurable), le seul format que toutes les plateformes affichent de façon fiable.
• Le og:url manquant. Webflow ne le génère jamais, alors que c'est l'une des quatre balises Open Graph de base. Le Worker l'ajoute, à partir de l'adresse canonique de la page, pour que les partages d'une même page avec des codes de suivi, ou avec et sans www, comptent comme un seul.
• Favicons, icônes d'app, posters de vidéos, images de fond en ligne et blocs <style> ont tous droit au même traitement.
• Les noms de fichiers bizarres. Les exports Figma adorent les espaces, les parenthèses et les virgules, et Webflow stocke parfois un %20 littéral sous la forme %2520. Le Worker conserve le chemin octet pour octet, donc tout ça fonctionne (ça n'a pas toujours été le cas, et c'est comme ça qu'on le sait).
• La page 404 est optimisée aussi. La page « page introuvable » de Webflow est une page complète remplie de fichiers Webflow, facturée comme n'importe quelle autre.
• Votre sitemap reçoit la bonne étiquette. Webflow sert /sitemap.xml avec un type de flux RSS ; le Worker le corrige en application/xml.
• Des correctifs pour la rigueur du navigateur. Certains anciens hôtes Webflow envoient les scripts et les feuilles de style avec un type de fichier générique, qu'un navigateur avec nosniff refusera d'exécuter. Le Worker envoie le bon type. Les SVG servis depuis votre domaine reçoivent une politique de sécurité verrouillée, pour que rien à l'intérieur ne puisse s'exécuter.

Ce qu'il laisse volontairement de côté

• Cloudflare Turnstile (la vérification « êtes-vous humain »), Google Tag Manager, Google Analytics, Google Fonts, Webflow Optimize et les scripts des apps du marketplace. Ils changent régulièrement ou sont personnalisés pour chaque visiteur, et les mettre en cache pendant un an les casserait. Celui-là, on le connaît douloureusement bien : une première version faisait transiter Turnstile et a cassé la vérification Turnstile de notre propre scanner en juillet.
• Les chunks du runtime Webflow et les scripts Finsweet Attributes, qui doivent se charger depuis leur propre emplacement pour retrouver leurs fichiers voisins.
• La vidéo, qui a besoin des requêtes de plage (range requests).
• Vos liens, balises canonical, preconnects et tout ce qui n'est pas un fichier Webflow. CodePen, HubSpot, les embeds YouTube se chargent tous exactement comme d'habitude.

Le filet de sécurité

Ce Worker se place devant un site en production, le nôtre compris, donc il est conçu pour échouer sans faire d'histoires. Voici chaque verrou, et ce qu'il est là pour empêcher :

• Il ne tourne que sur la route que vous lui donnez. Pointez-le sur www.yoursite.com/* et c'est tout ce qu'il voit. (Notre panne de juillet venait d'une route wildcard qui atteignait les sous-domaines de nos apps. N'utilisez pas *.yoursite.com/*.)
• Il ne réécrit que de vraies pages Webflow. Pas de marqueur data-wf-site, pas de modification, pas de cache. Donc même si la route atteignait une app par erreur, l'app resterait intacte.
• Il ne sert que les liens qu'il a signés. Pas de relais ouvert, personne pour faire grimper votre facture.
• Il ne récupère que depuis les serveurs de fichiers de Webflow. Et uniquement /js/jquery… depuis l'hôte jQuery de Webflow.
• Un mauvais réglage, et il s'efface. SIGNING_KEY absente ou trop courte ? Chaque requête passe sans être modifiée, et l'erreur est journalisée.
• Une erreur, et c'est la page d'origine. Si quoi que ce soit tourne mal avant que la page commence à streamer, vous recevez la réponse de Webflow, intacte. Le pire scénario, c'est « aussi rapide que Webflow tout seul », jamais « le site est en panne ».
• Il ne stocke pas de fichiers cassés. Une police qui revient sous la forme d'une page d'erreur HTML est refusée plutôt que mise en cache comme police pendant un an.

La configuration complète, du début à la fin

Bon, voici la configuration. Deux parties : mettre votre domaine sur Cloudflare avec l'O2O (une fois par domaine), puis installer le Worker (une fois par site). Si vous êtes déjà en O2O, passez directement à la partie 2.

Ce qu'il vous faut

• Un plan de site Webflow payant avec un domaine personnalisé (l'O2O en a besoin).
• Un site sur l'hébergement Cloudflare de Webflow. Les sites créés après le 21 avril 2025 y sont déjà ; les sites plus anciens doivent avoir fait la migration DNS de Webflow (vérifiez dans Workspace settings → Domain updates).
• Un compte Cloudflare. N'importe quelle offre, la Free fonctionne. Notre deuxième installation tourne sur la Free.
• Un compte GitHub, pour le bouton Deploy (ou la ligne de commande, si vous préférez).

Partie 1, étape 1 : ajouter votre domaine à Cloudflare

Dans le tableau de bord Cloudflare, cliquez sur Onboard a domain, saisissez votre domaine racine (yoursite.com) et suivez les étapes. Ensuite, chez votre registrar, remplacez vos serveurs de noms par les deux que Cloudflare vous donne. La propagation peut prendre un moment (Webflow parle de 48 heures maximum, en général c'est beaucoup plus rapide). whatsmydns.net avec l'option NS vous montre quand c'est fait. Si le DNS traîne des pieds, nous avons un article sur l'accélération de la résolution DNS lors de la publication de votre site Webflow.

Partie 1, étape 2 : les enregistrements DNS avec le nuage orange activé

C'est la partie O2O. Dans DNS → Records, créez des enregistrements CNAME avec proxy :

• Type CNAME, nom @, cible cdn.webflow.com, statut du proxy Proxied (nuage orange ACTIVÉ)
• Type CNAME, nom www, cible cdn.webflow.com, statut du proxy Proxied (nuage orange ACTIVÉ)

Supprimez tout ancien enregistrement A qui pointe vers 198.202.211.1 (ou vers les très anciennes IP de Webflow, ou vers proxy-ssl.webflow.com). Vous ne pouvez pas avoir les deux. Si vous utilisez d'autres sous-domaines sur Webflow, ajoutez un CNAME avec proxy pour chacun d'eux. Et si votre domaine a des enregistrements CAA, assurez-vous qu'ils autorisent Let's Encrypt et Google Trust Services, sinon vos certificats ne se renouvelleront pas.

Partie 1, étape 3 : SSL/TLS en Full (strict)

Rendez-vous dans SSL/TLS dans Cloudflare et réglez le mode de chiffrement sur Full (strict). Avec n'importe quel autre réglage, vous passerez votre temps à courir après des erreurs 525.

Partie 1, étape 4 : connecter et publier dans Webflow

Côté Webflow, allez dans Site settings → Publishing → Production, connectez votre domaine (racine et www), définissez votre domaine par défaut et publiez.

Vous verrez probablement « Update needed » à côté de votre domaine. Ignorez-le. Une fois le nuage orange activé, la vérification de Webflow ne voit plus vos enregistrements DNS à travers le proxy, et l'article d'aide de Webflow lui-même dit que c'est normal. Si le site se charge, tout va bien. J'ai vu l'avertissement traîner pendant des lustres sur certains sites et disparaître sur d'autres.

Pour vérifier que l'O2O fonctionne : le site se charge, vos enregistrements dans Cloudflare affichent le nuage orange, et au bout de quelques minutes, les Analytics de votre domaine dans le tableau de bord Cloudflare commencent à montrer du trafic. (Ne vous fiez pas à l'en-tête cf-ray : tous les sites Webflow l'ont maintenant, O2O ou pas.) Voilà, la plateforme est réglée. Passons à la partie amusante.

Partie 2, étape 5 : cliquer sur Deploy to Cloudflare

Allez sur notre dépôt, github.com/J8kesVanEeden/milkmoon-webflow-optimizer, et cliquez sur le bouton orange Deploy to Cloudflare dans le README. Voici ce qui se passe, parce que ce n'est pas évident la première fois :

• Cloudflare vous demande de vous connecter et de relier GitHub.
• Il crée une copie de notre dépôt dans votre propre compte GitHub. Cette copie est à vous : vos réglages y vivent, et c'est à partir d'elle que Cloudflare compile.
• Il crée le Worker dans votre compte Cloudflare et le relie à votre copie, si bien qu'à chaque fois que vous y faites un commit, Cloudflare redéploie automatiquement (ça, c'est Workers Builds).

Partie 2, étape 6 : coller une SIGNING_KEY

Pendant le déploiement, on vous demandera une SIGNING_KEY. C'est le secret que votre Worker utilise pour signer ses liens. Collez une valeur aléatoire d'au moins 32 caractères. Sur Mac ou Linux, openssl rand -base64 36 dans le Terminal vous en donne une, sinon utilisez le générateur de votre gestionnaire de mots de passe. Gardez-la en lieu sûr, mais vous n'aurez plus jamais à la taper. Elle est stockée comme secret Cloudflare, pas dans votre code, et le Worker refusera de se déployer sans elle.

Partie 2, étape 7 : le mettre sur votre site

À ce stade, le Worker existe mais n'est pas encore sur votre site (exprès, pour que rien ne se passe par surprise). Dans votre copie du dépôt sur GitHub, ouvrez wrangler.jsonc, trouvez le bloc routes commenté (trois lignes qui commencent par //), retirez le // des trois et indiquez-y votre hôte Webflow :

"routes": [{ "pattern": "www.yoursite.com/*", "zone_name": "yoursite.com" }],

Faites un commit. Cloudflare le récupère et redéploie en une minute environ. Utilisez uniquement l'hôte qui sert votre site Webflow. Pas *.yoursite.com/*, surtout si vous avez des apps sur d'autres sous-domaines (croyez-nous). Et configurez la route ici, dans le fichier, plutôt que dans le tableau de bord, parce que c'est le fichier qui est déployé et qu'il écrasera les modifications faites dans le tableau de bord.

Partie 2, étape 8 : l'exception OWASP (offre Pro et au-delà)

Si votre zone est en Pro ou plus et que vous utilisez le OWASP Core Ruleset de Cloudflare dans les Managed Rules, ajoutez une exception, sinon certains visiteurs (et les moteurs de rendu de Google) recevront une page de challenge au lieu de vos images. La règle OWASP 949110 voit un nom d'hôte Webflow dans le chemin du fichier et devient soupçonneuse. On peut sans risque se passer de l'OWASP sur ces chemins, parce que chaque requête qui y passe est déjà vérifiée par la signature du Worker. Celle-là nous a mordus sur notre propre site : environ 11 % des requêtes de fichiers recevaient un challenge jusqu'à ce qu'on l'ajoute.

1. Tableau de bord Cloudflare → votre domaine → Security rules → Create → Managed rules.
2. Donnez-lui un nom du genre Skip OWASP on Webflow Optimizer paths.
3. Modifiez l'expression et collez : starts_with(http.request.uri.path, "/_wf/") or starts_with(http.request.uri.path, "/_img/")
4. Ensuite : Skip specific rules from a Managed Ruleset → sélectionnez le Cloudflare OWASP Core Ruleset → Select rules → sélectionnez tout → Next → Deploy.
5. Assurez-vous que l'exception se trouve au-dessus de la règle qui déploie le ruleset OWASP. Les exceptions n'ignorent que les règles listées après elles.

Sur l'offre Free, vous n'avez pas le ruleset OWASP, donc vous pouvez sauter cette étape.

Partie 2, étape 9 : vérifier que ça fonctionne

Lancez ceci dans le Terminal (ou regardez les en-têtes de réponse dans les DevTools) :

curl -s -o /dev/null -D - https://www.yoursite.com/ | grep -i x-edge-worker

(Utilisez exactement cette commande. Le curl -I, plus court, envoie une requête HEAD, que le Worker laisse tranquille exprès, donc l'en-tête n'apparaît jamais.)

Vous devriez obtenir x-edge-worker: webflow-o2o/6.1.0 (ou la dernière version en date). Ensuite :

• Affichez le code source de la page. Les adresses d'images doivent commencer par https://www.yoursite.com/_img/ et celles des feuilles de style par https://www.yoursite.com/_wf/.
• Ouvrez l'onglet Network des DevTools, filtrez par Img et rechargez. Les images doivent venir de votre domaine, avec content-type: image/avif ou image/webp.
• Rechargez encore une fois et cherchez cf-cache-status: HIT dans les en-têtes d'une image.
• Vérifiez qu'une page avec un formulaire ou Turnstile fonctionne toujours, ainsi que vos aperçus sociaux dans opengraph.xyz ou dans le Sharing Debugger de Facebook.

Le contrôle visuel le plus simple reste l'extension DrFlare pour Chrome. Elle avait été abandonnée, mais elle a été remise en service sous le nom de DrFlare Reloaded, à récupérer ici. Ouvrez-la depuis les DevTools, actualisez la page et survolez les images pour voir l'avant et l'après. Pensez bien à actualiser une fois DrFlare ouvert.

Et voilà pour l'installation. Pas d'interrupteur « Enable Image Transformations », pas de liste d'origines autorisées, pas de variable DOMAIN, pas de webhook de purge du cache. L'ancien guide avait tout ça, et rien de tout ça n'est plus nécessaire : le Worker convertit lui-même les images, ce que Cloudflare autorise sur toute zone qui fait tourner un Worker.

Vous préférez la ligne de commande ?

Même chose, à la main : clonez le dépôt, lancez npm ci, npx wrangler login, npx wrangler secret put SIGNING_KEY (collez votre clé), modifiez routes dans wrangler.jsonc, puis npm run deploy. Il vous faudra Node installé. Le README donne les commandes exactes.

Chaque réglage, expliqué

Tout est facultatif sauf la clé de signature. Les réglages se mettent dans la section vars de wrangler.jsonc, dans votre copie du dépôt (un commit et ça redéploie). Un nombre ou un format invalide revient discrètement à la valeur par défaut, donc vous ne pouvez rien casser en tapant de travers un réglage de qualité. Les deux exceptions sont la clé de signature et les réglages legacy plus bas : si vous vous trompez sur ceux-là, le Worker s'efface (votre site continue de fonctionner, simplement sans le Worker) jusqu'à ce que vous corrigiez.

• SIGNING_KEY (obligatoire, c'est un secret, pas une var). Au moins 32 caractères aléatoires. La changer plus tard donne une nouvelle adresse à chaque fichier, ce qui implique un remplissage ponctuel du cache. Pas une catastrophe, mais ne le faites pas pour le plaisir.
• IMAGE_QUALITY (par défaut 85, de 1 à 100). Qualité des images de page. À 85, c'est superbe. Descendez à 75 si vous voulez vraiment gratter des octets, mais nous n'irions pas beaucoup plus bas pour de la photo.
• OG_FORMAT (par défaut jpeg ; png et webp sont aussi acceptés). Format des images d'aperçu pour les réseaux sociaux. Laissez-le en JPEG, certaines plateformes n'affichent toujours rien d'autre.
• OG_QUALITY (par défaut 80). Qualité des images d'aperçu pour les réseaux sociaux.
• EDGE_TTL et BROWSER_TTL (par défaut 31536000, soit un an, en secondes). Durée pendant laquelle les fichiers restent dans le cache de Cloudflare et dans les navigateurs. Un an, c'est sans risque, parce que Webflow renomme les fichiers modifiés. Nous n'avons jamais eu la moindre raison de les changer.
• SIZES_AUTO (par défaut false). Réglez-le sur "true" pour la fonctionnalité d'images à la bonne taille décrite plus haut. Chez nous, il est activé, sur nos deux installations.
• HTML_EDGE_TTL (par défaut 0, jusqu'à 86400). Nombre de secondes pendant lesquelles garder les pages dans votre zone. Laissez-le à 0 sauf si votre route ne couvre rien d'autre que votre site Webflow, parce qu'une valeur positive met en cache chaque réponse de la route avant que le Worker ait pu vérifier qu'il s'agit d'une page Webflow. Si vous le réglez, une publication peut mettre jusqu'à cette durée pour apparaître (nous utilisons 600, soit dix minutes).
• LEGACY_ROUTES, WEBFLOW_SITE_IDS, LEGACY_DOMAIN. Uniquement pour ceux qui utilisaient notre ancien Worker. Voir la partie sur la mise à jour, plus bas. Les nouvelles installations n'en ont pas besoin.

Quelques éléments de wrangler.jsonc qui ne sont pas des réglages mais qu'il vaut la peine de connaître :

• "cache": { "enabled": true, … } active le Workers Cache, et c'est ce qui permet aux requêtes répétées de court-circuiter entièrement le Worker. Laissez-le activé.
• "secrets": { "required": ["SIGNING_KEY"] } explique pourquoi un déploiement sans clé échoue, au lieu de passer en ligne à moitié configuré.
• "observability" conserve les logs de 10 % des requêtes, ce qui suffit largement pour repérer un problème, et ne coûte pas grand-chose.
• "workers_dev": false, parce que ce Worker n'a de sens que sur votre propre domaine.

Ce que ça coûte

Le Worker est gratuit et sous licence MIT. Ce que vous payez, si vous payez quoi que ce soit, c'est Cloudflare :

• Les requêtes Workers. Chaque requête sur votre route compte : les pages, et chaque fichier image, CSS, JS et police, y compris ceux qui sont en cache (un cache hit évite le temps de traitement du Worker, pas le décompte de la requête). Workers Free couvre 100 000 requêtes par jour. Workers Paid coûte 5 $ par mois avec 10 millions de requêtes incluses, puis 0,30 $ par million (tarifs de Cloudflare). Calcul à la louche : une page avec 40 fichiers représente environ 41 requêtes, donc l'offre gratuite couvre à peu près 2 400 pages vues par jour. Beaucoup de petits sites tiennent là-dedans ; un site très fréquenté voudra l'offre à 5 $. Si vous dépassez les 100 000 sur Workers Free, Cloudflare ne vous facture rien : il arrête de faire tourner le Worker pour le reste de la journée. Réglez votre route en fail open (votre Worker → Settings → Domains & Routes) pour que les visiteurs reçoivent simplement Webflow tout court au lieu d'une page d'erreur.
• Les conversions d'images. Cloudflare inclut 5 000 transformations uniques gratuites par mois. Une transformation unique, c'est une image, avec un réglage, dans un format, par mois, et les vues répétées sont gratuites. Cloudflare dit qu'une image servie dans différents formats ne compte qu'une fois, mais nous demandons chaque format séparément, donc par prudence, prévoyez dans votre budget qu'une image puisse compter jusqu'à trois fois (AVIF, WebP et l'original). Au-delà de 5 000, les nouvelles conversions échouent et le Worker sert discrètement l'image originale jusqu'au début du mois suivant, sauf si vous êtes sur Images Paid, à 0,50 $ les 1 000 supplémentaires (tarifs). Pour vous donner une idée : notre site, avec ses quelque 600 pages, en a utilisé 732 sur tout le mois de septembre.

Comparez ça au passage forcé au palier supérieur de bande passante chez Webflow, et pas besoin de vous faire un dessin.

Est-ce que ça rend le site plus rapide ? De vrais chiffres

Nous sommes prudents avec les promesses de vitesse, parce que les scores PageSpeed font des bonds de 10 à 20 points entre deux tests identiques, et qu'une bonne partie de ce qui ralentit un site (scripts, animations, balises tierces) n'a rien à voir avec les images. Nous avons donc testé de façon équitable : les 8 mêmes pages sur notre site en production (avec le Worker) et sur la copie de staging de Webflow (sans Worker), même outil, mêmes appareils, côte à côte.

• Le Worker n'a jamais fait baisser un score.
• Les avertissements « image delivery » et « page weight » de PageSpeed étaient plus faibles avec le Worker, sur chaque page. Une page de projet pesait 3 196 Ko avec lui et 4 195 Ko sans.
• Les pages arrivent aussi vite qu'avant : un time to first byte médian de 95 ms sur la version 6, contre 94 ms sur la version précédente (20 pages, 5 passages chacune). La réécriture en streaming n'ajoute vraiment aucune attente.
• Images de la page d'accueil, mesurées aujourd'hui sur la 6.1.0 : 38 fichiers, 8 762 Ko directement depuis Webflow, 1 755 Ko via le Worker (80 % de moins), aucun plus lourd que l'original. De l'AVIF pour 20 d'entre eux, du WebP pour 17, et un PNG qui était déjà aussi léger que possible.
• Les premières 24 heures de la version 6 en ligne : zéro erreur du Worker, et une fois l'exception OWASP de l'étape 8 en place, 0,3 % des requêtes de fichiers refusées (presque toutes venant de bots qui demandaient des adresses que le Worker n'a jamais écrites, refusées exprès). Une vérification complète de chaque page et de chaque fichier du site a réussi (628 pages, 1 255 fichiers).

Et pour rester honnêtes : les gros gains viennent des gros fichiers non optimisés, comme les captures d'écran en PNG. Si vos images sont déjà de petits WebP, certaines ne changeront pas du tout, parce que Cloudflare garde l'original quand c'est déjà le plus léger. C'est le système qui fonctionne, pas qui échoue.

Sous le capot (pour les curieux)

Cette partie est pour les développeurs, et pour le jour où quelque chose tourne mal et où vous voulez savoir où regarder. Voici chaque décision que prend le Worker pour une requête.

Quelques détails à connaître :

• La page est réécrite avec HTMLRewriter de Cloudflare, qui analyse les vrais attributs HTML au fil du streaming de la page (la version de janvier faisait huit passes de regex sur une page entièrement mise en mémoire tampon, et c'est comme ça qu'elle a raté les images sociales et les favicons pendant des mois : Webflow écrit content= avant property=, et la regex ne regardait que dans un sens).
• Les adresses signées ressemblent à /_img/img/<signature>/<webflow host>/<path> pour les images et à /_wf/<signature>/<webflow host>/<path> pour tout le reste. Il n'y a que deux presets d'image, img et og. Un visiteur ne peut jamais demander une autre taille ou une autre qualité, et c'est ce qui empêche les petits malins de générer des conversions sur votre compte.
• La conversion d'image se fait dans le Worker avec un fetch cf.image, qui choisit AVIF ou WebP d'après l'en-tête Accept du navigateur.
• Le code est du JavaScript tout simple, réparti dans dix petits fichiers (le README en donne la carte), avec 146 tests automatisés qui tournent dans le même runtime que celui de Cloudflare, y compris sur cinq vraies pages issues de quatre sites Webflow différents (et toute une deuxième installation par-dessus le marché). Tout est sur GitHub, allez fouiller.

En option : il peut se surveiller lui-même

Webflow peut changer son balisage ou ses hôtes de fichiers à n'importe quelle publication, de son côté, sans prévenir. Les filets de sécurité du Worker l'empêchent de casser votre site, mais ils ne vous disent pas si un changement laisse discrètement vos images non optimisées. Votre copie du dépôt inclut donc un moniteur facultatif qui tourne sur GitHub Actions : toutes les heures, il vérifie que vos pages se chargent et que vos fichiers passent par le Worker ; tous les jours, il vérifie chaque page de votre sitemap et chaque fichier qu'elles contiennent ; et si quelque chose cloche, il ouvre une issue GitHub (GitHub vous envoie un e-mail), puis la referme quand tout est rentré dans l'ordre. (GitHub lance les tâches planifiées quand il en a le temps, donc « toutes les heures » peut être un peu approximatif un jour de forte affluence.) Il ne fait rien tant que vous ne l'avez pas configuré ; le README explique la configuration, qui prend deux minutes. Il ne modifie jamais votre site.

Mettre à jour depuis l'ancien Worker

Si vous avez suivi la version de janvier de cet article, voici la marche à suivre :

1. Installez la version 6 comme indiqué plus haut (c'est un nouveau Worker, créé via le bouton Deploy).
2. Gardez vos anciens liens fonctionnels. Google Images, les anciens partages sociaux et les pages en cache vont encore demander pendant un moment les anciennes adresses /img-original/, /img-cache/, /asset-cache/ et /cdn-cgi/image/. Réglez LEGACY_ROUTES sur "true", WEBFLOW_SITE_IDS sur les ID de votre site et de votre CMS Webflow (séparés par des virgules : ce sont les ID de 24 caractères qui figurent dans les adresses de vos fichiers Webflow) et LEGACY_DOMAIN sur l'hôte exact sur lequel tourne votre site, du genre www.yoursite.com (et pas le domaine nu si vous êtes sur www). Réglez les trois ensemble : si LEGACY_ROUTES est activé et que les ID ou le domaine manquent, le Worker s'efface complètement jusqu'à ce que vous corrigiez, et l'en-tête x-edge-worker disparaît. Avec les trois réglés, le nouveau Worker répond aussi aux anciens formats d'adresse, verrouillés sur vos propres fichiers.
3. Déplacez la route. Retirez la route de l'ancien Worker et ajoutez-la au nouveau. Ensuite, vous pouvez supprimer l'ancien Worker.
4. Laissez Image Transformations activé pour l'instant. Les anciens liens /cdn-cgi/image/ sont servis directement par Cloudflare, pas par le Worker, donc gardez les transformations (et vos origines autorisées) activées tant que l'ancien trafic continue d'arriver au compte-gouttes, et verrouillez ce point d'accès avec une règle WAF pour que personne d'autre ne puisse s'en servir. Une fois que vos logs montrent que les anciens liens se sont éteints, vous pouvez tout désactiver.

Mettre à jour la version 6 elle-même par la suite est simple : récupérez notre dernière version dans votre copie du dépôt (ajoutez notre dépôt comme remote et mergez-le) puis faites un commit, et Cloudflare redéploie. Vos réglages et votre secret restent en place. N'utilisez pas le bouton Deploy pour les mises à jour : il crée une toute nouvelle copie et un tout nouveau Worker au lieu de mettre à jour le vôtre. L'en-tête x-edge-worker vous indique quelle version tourne.

Dépannage

Rien n'a changé, les adresses d'images pointent toujours vers Webflow

• Vérifiez que la route est décommentée dans wrangler.jsonc et qu'elle correspond exactement à votre hôte (www.yoursite.com/*, et non l'apex si votre site vit sur www).
• Vérifiez que le déploiement a bien eu lieu : tableau de bord Cloudflare → votre Worker → Deployments (ou l'onglet Builds).
• Vérifiez l'en-tête x-edge-worker. Pas d'en-tête, ça veut dire que le Worker n'est pas sur cette route, ou que la SIGNING_KEY manque (auquel cas il laisse tout passer sans y toucher et journalise pourquoi).
• Faites un rechargement forcé (Cmd/Ctrl + Maj + R). Votre navigateur a peut-être encore une copie de la page d'avant.

Certaines images affichent un challenge ou une 403

• Une page de challenge, ou des images qui n'échouent que pour certains visiteurs : c'est le ruleset OWASP. Ajoutez l'exception de l'étape 8 et assurez-vous qu'elle se trouve au-dessus de la règle OWASP.
• Une simple 403 « Bad or missing signature » : le lien n'a pas été écrit par votre Worker. En général, c'est une ancienne copie d'une page datant d'avant le changement de votre SIGNING_KEY, ou quelqu'un (ou un bot) qui bricole un lien. Rechargez la page pour obtenir des liens tout neufs.

Les images ne sont ni en AVIF ni en WebP

• Vérifiez que l'adresse contient /_img/. Les SVG et les images que vous avez importées en AVIF sont servis tels quels, exprès (Cloudflare ne sait pas convertir l'AVIF, et les SVG n'en ont pas besoin). Importez du JPG ou du PNG dans Webflow et laissez le Worker se charger de la conversion ; Webflow ne crée même pas de tailles responsive pour les fichiers importés en AVIF.
• Si vous avez épuisé vos 5 000 conversions gratuites du mois, les nouvelles images arrivent en version originale jusqu'au début du mois suivant. Le tableau de bord Cloudflare (Images → Transformations) affiche votre compteur.

Ma publication n'apparaît pas

• Avec le HTML_EDGE_TTL par défaut à 0, elle devrait être instantanée. Si vous l'avez réglé plus haut, attendez cette durée, ou purgez la page dans Cloudflare (Caching → Configuration → Custom Purge).
• Essayez une fenêtre de navigation privée, pour mettre votre propre navigateur hors de cause.

Les aperçus sociaux ne s'affichent pas correctement

• Passez la page dans le Sharing Debugger de Facebook ou dans opengraph.xyz. Le og:image doit être une adresse /_img/og/ sur votre domaine et revenir en JPEG. Les plateformes gardent les aperçus en cache un moment, alors utilisez la fonction « scrape again » du débogueur.
• Les images sociales que vous avez importées en AVIF restent exprès sur l'adresse de Webflow, parce que les scrapers des réseaux sociaux gèrent mal l'AVIF. Importez un JPG pour votre image Open Graph.

Webflow affiche « Update needed » pour mon domaine

C'est normal avec l'O2O. Webflow ne voit pas votre DNS à travers le nuage orange. Si le site se charge, ignorez-le.

Erreur 525 Handshake

Ça, c'est le SSL, pas le Worker. Réglez SSL/TLS sur Full (strict). Si votre zone utilise Zone Hold, la documentation de Webflow dit de le lever le temps que le certificat soit émis.

Limites (rien n'est parfait)

• Il ne voit que ce qui se trouve dans le HTML de la page. Les images ajoutées plus tard par JavaScript, et les images de fond référencées à l'intérieur de la feuille de style de Webflow, se chargent toujours depuis Webflow. Même chose pour les fichiers d'animation Lottie et les polices référencées dans le CSS.
• Les pages viennent toujours de Webflow à chaque visite (par défaut), et c'est ce qui garde la publication instantanée. Les économies portent sur les fichiers.
• Cache Reserve ne s'applique pas. La documentation de Cloudflare indique que Cache Reserve est contourné en O2O, donc les fichiers vivent dans le cache en périphérie normal, qui peut évincer plus tôt les fichiers rarement demandés. Ils sont simplement récupérés à nouveau.
• Il ne rend pas votre JavaScript plus rapide. Si votre site est lent à cause d'interactions lourdes ou de scripts tiers, c'est le site, pas les images.
• Il ne peut pas réduire une image qui est déjà aussi légère que possible.

Retour en arrière

Si quelque chose tourne vraiment très mal (ça ne devrait pas, mais on ne sait jamais) : dans le tableau de bord Cloudflare, ouvrez votre Worker, allez dans Settings → Domains & Routes et supprimez la route. C'est effectif tout de suite. Ensuite, recommentez la ligne routes dans wrangler.jsonc et faites un commit, pour que le prochain build ne la remette pas. Votre site recommence immédiatement à tout charger depuis Webflow, et l'O2O comme toutes vos autres fonctionnalités Cloudflare restent exactement tels qu'ils étaient. Les fichiers en cache ne sont tout simplement plus utilisés. Pour le retirer complètement, supprimez aussi le Worker.

Petite histoire de notre combat contre la plateforme

Pour les nostalgiques, et pour que vous compreniez pourquoi la version 6 ressemble à ce qu'elle est :

• 2022 : l'app Cassette et la bidouille SSL. Ça a marché, jusqu'au jour où ça n'a plus marché.
• 2023 : notre premier Worker pour les images, uniquement les images.
• Janvier 2026 : l'O2O arrive pour de bon, avec la première version de ce guide, qui gère le CSS, le JS et les polices. La vidéo de l'époque, un point d'étape sur le travail en cours, se trouve ci-dessous.
• Juillet 2026 : reconstruit pour streamer les pages au lieu de les mettre en mémoire tampon, ce qui a aussi réparé les images sociales et les favicons qui, sans que personne ne s'en rende compte, n'avaient jamais fonctionné. C'est aussi le mois où notre propre route wildcard a cassé la vérification Turnstile de notre scanner. Leçon retenue, route verrouillée.
• Septembre 2026 : découverte et correction de la faille du serveur de fichiers partagé. Puis reconstruction complète en version 6, générique pour n'importe quel site Webflow, avec des liens signés, et mise en ligne sur GitHub.
• Octobre 2026 : la version 6.1 avec les images à la bonne taille, un deuxième site installé directement depuis le modèle public, et la surveillance automatique.

Pas envie de le faire vous-même ?

On vous comprend. Toucher au DNS d'un site en production, c'est stressant, et tout le monde n'a pas envie d'ouvrir un compte GitHub. La performance Webflow, c'est un peu notre truc (nous sommes un petit studio Webflow qui passe un temps franchement malsain dans les tableaux de bord Cloudflare), alors écrivez-nous et nous mettrons tout en place pour vous : l'O2O, le Worker, l'exception OWASP, les vérifications. Et si vous devez convaincre un client (ou votre patron) de l'importance de tout ça, notre article sur la façon dont la vitesse de page favorise la réussite d'une entreprise plaide la cause.

Questions fréquentes

Le Milk Moon Webflow Optimizer est-il gratuit ?

Oui. Il est open source, sous licence MIT, sur GitHub. Vous ne payez Cloudflare que si vous choisissez de passer à une offre payante. Si vous dépassez les quotas gratuits (100 000 requêtes Worker par jour, 5 000 conversions d'images uniques par mois), rien n'est facturé : les images partent sans conversion jusqu'au début du mois suivant, et le Worker cesse de tourner jusqu'au lendemain (réglez votre route en fail open pour que les visiteurs reçoivent Webflow tout court).

A-t-on le droit d'utiliser un Worker Cloudflare avec Webflow ?

Oui, sur votre domaine personnalisé. Webflow qualifie l'O2O de « méthode prise en charge pour faire tourner des fonctionnalités Cloudflare devant Webflow », et Cloudflare indique que les Workers sont compatibles avec l'O2O. Ce que les conditions de Webflow interdisent, c'est de mettre votre domaine de staging *.webflow.io derrière un proxy, ce que ce Worker ne fait jamais. Le support Webflow ne dépannera pas le Worker pour vous, c'est pourquoi le désactiver tient en une ligne.

Webflow utilise-t-il Cloudflare ?

Oui. Webflow a déplacé son hébergement sur Cloudflare en 2025. Les sites créés après le 21 avril 2025 y sont déjà, et les sites plus anciens sont passés aux nouveaux enregistrements DNS (cdn.webflow.com). C'est précisément ce changement qui rend possibles l'O2O, et ce Worker.

Est-ce que ça réduit ma bande passante Webflow ?

Oui, pour les fichiers. Webflow compte chaque octet que son CDN livre. Avec le Worker, chaque image, feuille de style, script et police sort de Webflow à peu près une fois par point de présence Cloudflare, puis est servi depuis le cache de Cloudflare pendant un an maximum. Les pages, elles, viennent toujours de Webflow.

Qu'est-ce que cdn.prod.website-files.com ?

C'est le serveur de fichiers de Webflow, là où vivent réellement vos images, votre CSS, votre JavaScript et vos polices. Comme ce n'est pas votre domaine, votre zone Cloudflare ne peut rien y mettre en cache ni y optimiser, même avec l'O2O. Le Worker réécrit ces adresses pour que les fichiers soient optimisés et mis en cache via votre propre domaine.

Dois-je encore activer Image Transformations dans Cloudflare ?

Pas pour la version 6. Le Worker convertit lui-même les images, ce que Cloudflare autorise sur toute zone qui fait tourner un Worker. Vous n'avez besoin d'activer les transformations que si vous servez encore d'anciens liens /cdn-cgi/image/ issus de la version précédente.

Comment vider le cache après une publication dans Webflow ?

Vous n'en avez pas besoin. Par défaut, le Worker ne met pas les pages en cache, donc une publication apparaît tout de suite, et les fichiers modifiés reçoivent automatiquement de nouvelles adresses de la part de Webflow. Si vous avez réglé HTML_EDGE_TTL au-dessus de 0, attendez cette durée ou purgez la page sous Caching → Configuration dans Cloudflare.

Est-ce que ça va casser mes formulaires, Turnstile ou mes analytics ?

Normalement, non. Turnstile, Tag Manager, Google Analytics, Google Fonts, Webflow Optimize et les scripts des apps du marketplace ne sont jamais touchés, et les pages sans le marqueur Webflow passent sans aucune modification. Testez quand même un formulaire après l'installation, ça prend une minute.

C'est tout

Voilà, en gros, c'est tout. Un bouton, un secret, une ligne, et votre site Webflow sert des images plus légères depuis votre propre domaine, tout droit sorties du cache de Cloudflare, pendant que Webflow n'envoie plus qu'une fraction de ce qu'il envoyait avant. Si vous l'installez, j'adorerais sincèrement savoir comment ça s'est passé (et ce que ça vous a fait économiser). Écrivez-nous, et jetez un œil à la section How-To de notre blog pour d'autres tutoriels.