La meilleure configuration Cloudflare pour valider les Core Web Vitals

Optimiser les Core Web Vitals avec Cloudflare : ce qu'il faut activer et ce qu'il faut éviter

Cloudflare propose de nombreux réglages qui peuvent impacter les Core Web Vitals, en bien comme en mal. Si certains améliorent les performances, d'autres introduisent des délais ou perturbent le rendu de la page. Passons en revue les options Cloudflare les plus courantes et les cas où il faut les activer !

Dernière révision par Arjen Karel en février 2026

Configuration Cloudflare : questions fréquentes : j'audite souvent la configuration Cloudflare de mes clients. Même si je pourrais écrire des livres entiers sur la configuration d'un CDN comme Cloudflare, la plupart des questions se résument à un simple « faut-il activer ce réglage ? ». Cet article y répond en détaillant les points clés pour les options Cloudflare les plus courantes liées aux Core Web Vitals.

Free vs Pro : la mise à niveau en vaut-elle la peine ?

Vitesse > Optimisation

Polish

Polish optimise les images hébergées sur votre domaine Cloudflare en les compressant, en supprimant leurs métadonnées et, en option, en les convertissant en WebP. Pour un guide complet sur l'optimisation des images, consultez optimiser les images pour les Core Web Vitals.

Des images plus légères améliorent généralement le Largest Contentful Paint en réduisant la durée de chargement de la ressource image. Cependant, le LCP étant influencé par plusieurs facteurs autres que le chargement des images, ne vous attendez pas à des améliorations spectaculaires.

Recommandation : activez l'option et choisissez « Lossy WebP » pour obtenir les meilleurs résultats. Notez que Polish ne prend pas en charge la conversion en AVIF ; pour l'AVIF, vous devez utiliser Cloudflare Image Resizing (un service payant distinct).

Mirage (déprécié)

Cloudflare a déprécié Mirage le 15 septembre 2025 et l'a automatiquement désactivé sur tous les domaines. Les navigateurs modernes prennent désormais en charge nativement le lazy loading via l'attribut loading="lazy", ce qui rend l'approche de Mirage basée sur JavaScript inutile.

Mirage optimisait autrefois les images selon les conditions réseau. Son implémentation était « lente par conception » : elle bloquait les images tant que la vitesse du réseau n'avait pas été mesurée. Ce blocage pouvait provoquer des layout shifts et, ironiquement, dégrader le Largest Contentful Paint.

Recommandation : ce réglage n'existe plus. Si vous le voyez dans un guide ancien, ignorez-le.

Speed Brain

Speed Brain utilise l'API Speculation Rules pour accélérer le Time to First Byte en préchargeant les navigations futures. Les Speculation Rules sont extrêmement efficaces pour améliorer l'ensemble des Core Web Vitals, y compris le Largest Contentful Paint. Speed Brain est disponible sur tous les forfaits (y compris l'offre gratuite) et utilise actuellement le niveau d'eagerness conservative, qui ne précharge que lorsqu'un utilisateur s'apprête à cliquer sur un lien.

Je déconseille de vous reposer sur Speed Brain : configurer les speculation rules manuellement est simple et bien plus efficace que l'approche générique de Cloudflare. Une configuration manuelle vous permet de choisir vos propres niveaux d'eagerness, de cibler des URL précises et d'exploiter le prerendering au lieu d'un simple prefetch.

Recommandation : désactivez l'option et configurez les speculation rules manuellement. Si vous ne comptez pas le faire vous-même, laisser Speed Brain activé reste préférable à l'absence totale de speculation rules.

Cloudflare Fonts

Cloudflare Fonts automatise l'auto-hébergement des polices. C'est une excellente idée : auto-héberger les ressources critiques évite d'ouvrir de nouvelles connexions externes, systématiquement plus lentes que la réutilisation de la connexion déjà ouverte vers votre site proxifié par Cloudflare.

Il est plus efficace de prendre 15 minutes pour configurer manuellement l'auto-hébergement des fichiers de polices. Malheureusement, de nombreux CMS ne le permettent pas. Dans ce cas, activer Cloudflare Fonts est une option tout à fait valable. Notez que Cloudflare Fonts est toujours en bêta (depuis 2023) et ne fonctionne pas lorsque l'APO est activée.

Recommandation : désactivez par défaut ; n'activez que si l'auto-hébergement manuel est impossible.

Early Hints

Les Early Hints accélèrent la transmission des ressources critiques (comme les styles, les polices ou les images) en les signalant avant même que le contenu HTML ne soit envoyé au navigateur. Pour transmettre un resource hint via Cloudflare, celui-ci lit vos en-têtes de réponse et en extrait les resource hints.

Si vous maîtrisez l'envoi de resource hints dans les en-têtes de réponse HTTP, je vous conseille vivement d'activer cette fonctionnalité. Attention toutefois : les resource hints placés dans les en-têtes sont souvent bien moins visibles pour votre équipe de développement que ceux intégrés dans le <head> de la page. Mal configurés, ils ralentissent le chargement au lieu de l'accélérer. À manier avec précaution. Bien qu'ils soient disponibles depuis des années, le taux d'adoption des Early Hints reste inférieur à 3 % selon le Web Almanac 2025.

Recommandation : n'activez l'option que si vous envoyez correctement les en-têtes de resource hints.

Auto Minify

Cloudflare peut minifier votre code HTML, CSS et JavaScript à la volée. La minification HTML supprime les espaces et les commentaires, réduisant légèrement le volume transféré. La minification CSS et JavaScript fait de même pour ces types de fichiers.

Recommandation : activez la minification HTML. Pour le CSS et le JavaScript, minifier au moment du build (durant votre processus de déploiement) produit de meilleurs résultats que l'approche à la volée de Cloudflare. Si vous n'avez aucun processus de build, activer les trois convient parfaitement.

Rocket Loader

Rocket Loader « diffère » l'exécution de tout le JavaScript d'une page en bloquant temporairement les scripts pour les injecter quelques instants plus tard. C'est une astuce bancale (ou élégante, selon le point de vue) qui exige de multiples vérifications et hacks pour fonctionner correctement sur tous les navigateurs. Elle masque également les scripts au preload scanner, un mécanisme pourtant conçu pour accélérer le chargement des ressources critiques.

Pour toutes ces raisons, je déconseille évidemment d'activer Rocket Loader à l'aveugle. Les scripts doivent être planifiés selon leur importance. Les scripts critiques doivent être chargés et exécutés au plus tôt, tandis que les scripts secondaires peuvent attendre que le navigateur soit inactif.

Rocket Loader ne fait pas cette distinction. Il retient tous les scripts pour les injecter d'un coup sans tenir compte de leur priorité. Rocket Loader se contente de faire passer les autres ressources, comme l'élément LCP, les polices et les styles, avant les scripts. Pire encore : Rocket Loader utilise le gestionnaire d'événements unload, une API dépréciée qui empêche le fonctionnement du Back-Forward Cache (bfcache) du navigateur. Les navigations précédent/suivant déclenchent alors un rechargement complet de la page au lieu d'une restauration instantanée.

Si votre CMS ne permet pas de différer les scripts ou d'en affiner l'ordonnancement, Rocket Loader peut représenter un recours. Mais pour la majorité des sites, planifier les scripts manuellement reste bien plus efficace.

Recommandation : désactivez l'option et planifiez vos scripts manuellement. Ne l'activez que si vous n'avez aucun autre moyen de différer ou de contrôler l'exécution de vos scripts.

Automatic Platform Optimization for WordPress

L'APO de Cloudflare met en cache des pages entières sur ses serveurs edge, une technique appelée full-page edge caching. Correctement mise en œuvre, elle améliore le Time to First Byte (et par ricochet le LCP et le FCP) pour une partie de vos visiteurs !

Il y a toutefois un piège. Le full-page edge caching doit souvent être contourné automatiquement. Par exemple, lorsqu'un utilisateur se connecte ou ajoute des articles à son panier, l'APO est automatiquement désactivée puisque le contenu de la page devient personnalisé. Dès lors, servir une page générique en cache n'est plus envisageable. Comme l'APO doit fonctionner pour tous les types de sites, le cache sera contourné bien plus souvent que nécessaire sur le vôtre. C'est pourquoi une configuration manuelle du cache sera presque toujours plus efficace que l'APO de Cloudflare.

Recommandation : activez l'APO, ou mieux encore, configurez vos propres règles de full-page edge caching pour maîtriser précisément les conditions de contournement du cache.

HTTP/2, HTTP/2 to Origin and Enhanced HTTP/2 Prioritization

Activer HTTP/2, HTTP/2 to Origin et Enhanced HTTP/2 Prioritization est une évidence. HTTP/2 apporte une amélioration majeure par rapport à l'ancien protocole HTTP/1.1. HTTP/2 offre de nombreux avantages, mais surtout, il supprime l'ancien effet d'escalier en permettant d'envoyer plusieurs fichiers en parallèle sur une même connexion. HTTP/2 existe depuis 10 ans et bénéficie d'une prise en charge massive par les navigateurs et les serveurs !

Recommandation : activez les trois options.

HTTP/3 (with QUIC)

HTTP/3 avec QUIC est encore plus rapide que HTTP/2 grâce aux optimisations de l'établissement de connexion et de la latence. HTTP/3 permet d'acheminer plusieurs flux de manière indépendante, même si l'un d'eux est ralenti. QUIC regroupe les handshakes de transport et de chiffrement, ce qui réduit le temps de connexion. Résultat : un gain pouvant atteindre 10 % sur le TTFB ! Selon le Web Almanac 2025, 38 % des sites web prennent désormais en charge HTTP/3.

Recommandation : activez l'option.

Brotli Compression

Brotli est un algorithme de compression qui produit des fichiers plus légers que Gzip. Cloudflare active Brotli par défaut sur tous ses forfaits. Assurez-vous qu'il reste activé. Selon le Web Almanac 2025, 46 % des requêtes servies par un CDN utilisent aujourd'hui la compression Brotli.

Recommandation : laissez activé (l'option est active par défaut).

0-RTT Connection Resumption

La reprise de connexion 0-RTT accélère les connexions sécurisées en supprimant le handshake initial lorsqu'un utilisateur revient sur un site. Elle s'appuie sur des clés de chiffrement stockées auparavant pour envoyer les données immédiatement, ce qui réduit la latence et améliore le temps de chargement de la page.

Recommandation : activez l'option.

Automatic Signed Exchanges (deprecated)

Les Signed Exchanges (SXG) permettaient à Google Search de précharger votre contenu tout en préservant la vie privée des utilisateurs. Les SXG pouvaient améliorer le LCP d'environ 450 ms pour les visiteurs provenant des résultats de recherche Google.

Cependant, Cloudflare a déprécié les SXG en octobre 2025. La fonctionnalité a été supprimée et n'est plus disponible. Si elle était activée, elle a été automatiquement coupée. Speed Brain (Speculation Rules) constitue l'alternative la plus proche pour le prefetch, même s'il ne fonctionne que pour les navigations same-site, et non pour le prefetch cross-origin depuis Google Search comme le faisaient les SXG.

Recommandation : ce réglage n'existe plus.

Scrape Shield

Scrape Shield protège le contenu de votre site web. Si l'idée peut sembler séduisante, je m'oppose fermement à l'activation de la moindre option de Scrape Shield. Son principe repose sur l'injection de JavaScript dans la page pour décoder du contenu préalablement obfusqué. Sacrifier la vitesse pour dissimuler du contenu n'a aucun sens. Les véritables spammeurs ne sont pas dupes, tandis que les vrais utilisateurs subissent des scripts supplémentaires qui ralentissent la page.

Recommandation : désactivez Email Address Obfuscation ainsi que Hotlink Protection.

Bot Fight Mode and Super Bot Fight Mode

C'est le réglage Cloudflare le plus destructeur pour vos Core Web Vitals. Lorsqu'il est activé, Bot Fight Mode injecte un script nommé invisible.js sur chaque page. Ce script exécute un challenge dans le navigateur qui ajoute plus de 2 000 millisecondes de temps d'exécution CPU à chaque chargement de page. C'est 2 secondes pleines de blocage du main thread avant que votre page ne devienne interactive.

En pratique, activer Bot Fight Mode peut faire chuter votre score PageSpeed de 20 points ou plus. Super Bot Fight Mode pose exactement le même problème. L'ironie : ces modes sont conçus pour bloquer les bots, mais ils pénalisent chaque utilisateur réel qui visite votre site.

Recommandation : désactivez à la fois Bot Fight Mode et Super Bot Fight Mode. Si vous avez besoin d'une protection contre les bots, utilisez plutôt les règles WAF ou le rate limiting de Cloudflare. Ces solutions n'injectent aucun JavaScript côté client.

Mise en cache > Configuration

Purge Cache

Purger le cache invalide l'ensemble des fichiers mis en cache par Cloudflare, y compris les feuilles de style, le JavaScript, les images et même le cache de pages entières. Et bien que purger le cache ne soit pas techniquement un réglage, je dois vous mettre en garde : vider le cache ralentira votre site tant qu'il n'aura pas été reconstruit !

Recommandation : évitez de purger tout le cache si possible. Ne purgez que les fichiers concernés !

Caching Level

Le niveau de mise en cache détermine la façon dont Cloudflare gère les query strings. Prenez le temps de bien vérifier ce réglage.

L'option la plus rapide est « Ignore query string ». Elle sert la même ressource quelle que soit la query string. C'est une bonne option uniquement si vous êtes sûr à 100 % que votre site n'utilise aucune query string. Dans ce cas, les query strings ajoutées par des tiers sont ignorées.

« Standard » met en cache un fichier distinct pour chaque query string différente. C'est le réglage par défaut de Cloudflare, mais combiné avec le full-page edge caching et des paramètres de tracking comme les paramètres UTM, il peut provoquer des incohérences de cache et faire chuter votre taux de cache hit ! Pensez à supprimer les paramètres de tracking avec Cloudflare Workers pour résoudre ce problème.

Recommandation : choisissez « Ignore query string » dès que possible, ou à défaut « Standard ». Évitez l'option « No query string ».

Browser Cache TTL

Le TTL du cache du navigateur indique à celui-ci combien de temps il peut conserver les ressources statiques en cache. Les ressources en cache sont servies directement par le navigateur et sont disponibles bien plus rapidement que les ressources distantes via le réseau. Un TTL de cache du navigateur trop court invalide fréquemment le cache, réduisant ainsi le taux de cache hit. Par conséquent, sauf si vos fichiers statiques changent fréquemment, réglez ce paramètre au maximum.

Recommandation : réglez sur 1 an si possible.

Development Mode

Lorsqu'il est activé, le mode développement contourne tout le cache de Cloudflare. Il peut être tentant de l'activer pendant que vous développez. Ne le faites surtout pas : il désactive aussi le cache pour l'ensemble des autres visiteurs. Configurez plutôt un domaine de développement ou excluez-vous du cache Cloudflare en créant des règles de cache.

Recommandation : ne l'activez pas !

Mise en cache > Tiered Cache

Tiered Cache réduit le nombre de requêtes envoyées à votre serveur d'origine et augmente le taux de cache hit en demandant à Cloudflare de chercher d'abord les fichiers non mis en cache sur ses propres serveurs. Cela allège encore davantage la charge de votre serveur backend et libère des ressources.

Recommandation : activez Smart Tiered Caching Topology.

Sur l'ensemble des sites suivis par CoreDash, ceux qui utilisent un CDN correctement configuré affichent un TTFB au p75 55 % plus rapide que ceux sans CDN. La combinaison de HTTP/3, Brotli et du tiered caching proposée par Cloudflare fait une différence mesurable sur le terrain. Utilisez le Real User Monitoring pour vérifier que votre configuration Cloudflare profite réellement à vos utilisateurs.