La meilleure configuration CloudFlare pour passer les Core Web Vitals

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

Cloudflare offre une large gamme de paramètres qui peuvent avoir un impact sur les Core Web Vitals, à la fois positivement et négativement. Alors que certains paramètres améliorent les performances, d'autres introduisent des délais ou interfèrent avec le rendu de la page. Détaillons les options Cloudflare les plus courantes et dans quelles conditions vous devriez les activer !

Questions courantes sur la configuration CloudFlare : Je passe souvent en revue les configurations CloudFlare pour des clients. Bien que je pourrais écrire des livres sur la configuration d'un CDN comme CloudFlare, la plupart des questions tournent autour d'un simple 'devrais-je activer ce paramètre ?'. Cet article répond à ces questions avec les considérations appropriées pour les paramètres CloudFlare les plus courants liés aux Core Web Vitals.

Gratuit vs Pro : Une mise à niveau vaut-elle le coup ?

Vitesse > Optimisation

Polish 

Polish optimise les images hébergées sur votre domaine CloudFlare en les compressant et en supprimant les métadonnées des images et en les convertissant éventuellement  en images WebP. 

Des tailles d'image plus petites amélioreront généralement le Largest Contentful Paint en améliorant la durée de chargement de la ressource image. Cependant, comme le LCP est influencé par de multiples facteurs autres que la durée de chargement des ressources des images, ne vous attendez pas à des améliorations drastiques !

Recommandation : Activez et choisissez 'Lossy Webp' pour les meilleurs résultats.

Mirage

Mirage optimise les images en fonction des conditions du réseau. Bien que cette idée soit noble, l'implémentation est 'lente par conception'. Afin d'optimiser les images pour toutes les conditions de réseau, les images de la page doivent être bloquées jusqu'à ce que la vitesse de connexion réseau ait été mesurée.  Ce blocage des images peut entraîner des Layout Shifts et ironiquement un score Largest Contentful Paint plus bas.

Recommandation : Évitez d'activer en aucune circonstance !

Speed Brain

Speed brain utilise l'API Speculation Rules pour accélérer le Time to First Byte en préchargeant les navigations futures. Bien que les règles de spéculation soient extrêmement efficaces pour améliorer tous les Core Web Vitals, y compris le Largest Contentful Paint, je ne recommande pas d'activer cette fonctionnalité CloudFlare car l'auto-configuration des règles de spéculation est super facile et bien plus efficace que la solution 'taille unique' de CloudFlare, même avec leur intégration RUM ! 

Recommandation : Désactivez et configurez les règles de spéculation manuellement

CloudFlare Fonts

CloudFlare fonts automatise l'auto-hébergement des polices. C'est une excellente idée car l'auto-hébergement des ressources importantes élimine les nouvelles connexions externes qui sont par défaut plus lentes que la réutilisation de la connexion déjà ouverte vers votre site proxyfié par CloudFlare.

Il est plus efficace de prendre 15 minutes et de configurer manuellement les fichiers de polices auto-hébergés. Malheureusement, de nombreux systèmes CMS ne le permettent pas. Dans ce cas, activer CloudFlare fonts est une option parfaitement valable.

Recommandation : Désactivez par défaut ; activez seulement si l'auto-hébergement manuel n'est pas une option.

Early Hints

Les Early hints accélèrent la livraison des ressources critiques (comme les styles, les polices ou les images) en les suggérant avant que le contenu html réel ne soit envoyé au navigateur. Pour envoyer une indication de ressource via CloudFlare, CloudFlare préparera votre en-tête de réponse et en extraira les indications de ressource. 

Si vous êtes à l'aise avec l'envoi d'indications de ressources dans les en-têtes de réponse html, je suggère fortement d'activer cette fonctionnalité. Cependant, soyez conscient que les indications de ressources pourraient être beaucoup plus cachées pour votre équipe de développement que les indications de ressources dans l'en-tête de la page. Si elles sont mal configurées, elles peuvent ralentir les choses au lieu de les accélérer. Donc, à utiliser avec prudence.

Recommandation : Activez seulement si vous envoyez correctement les en-têtes d'indication de ressource.

Rocket Loader™

Rocket loader 'diffère' tous les JavaScripts sur une page web en les retenant temporairement puis en les réinjectant dans la page quelques instants plus tard.  C'est une astuce désagréable (ou soignée, selon votre point de vue) qui nécessite beaucoup de vérifications et de bidouillages pour s'assurer qu'elle fonctionnera correctement sur tous les navigateurs. De plus, cette astuce cache les scripts au scanner de préchargement, un mécanisme conçu pour accélérer le chargement des ressources critiques.

Pour les raisons ci-dessus, évidemment, je ne suis pas fan de l'activation aveugle de Rocket loader. Les scripts devraient être programmés en fonction de leur importance. Les scripts critiques doivent se charger et s'exécuter tôt, tandis que les scripts non essentiels peuvent attendre que le navigateur soit inactif.

Le Rocket Loader de CloudFlare fait cela. Il retient les scripts et à un certain moment les injecte sans tenir compte de leur importance. Rocket loader priorise seulement d'autres ressources comme l'élément LCP, les polices et les styles par rapport aux scripts. Si votre CMS ne permet pas le report de script ou un timing de script plus fin, rocket loader pourrait être votre meilleure option.

Recommandation : Désactivez et planifiez les scripts manuellement. Activez seulement si vous n'avez aucun autre moyen de différer ou de contrôler l'exécution des scripts.

Optimisation Automatique de Plateforme pour WordPress

L'APO de CloudFlare met en cache des pages entières sur ses serveurs en périphérie, une technique connue sous le nom de mise en cache complète de page en périphérie (full-page edge caching). Lorsqu'elle est implémentée correctement, elle améliorera le Time to First Byte (et par la suite le LCP et FCP) pour un certain type de visiteur ! 

Cependant, il y a un hic. La mise en cache complète de page en périphérie doit souvent être contournée automatiquement. Par exemple, lorsqu'un utilisateur se connecte ou ajoute des articles à son panier, APO est automatiquement désactivé car le contenu de la page devient personnalisé. À ce moment-là, servir une page générique mise en cache n'est plus une option. Parce qu'APO doit fonctionner pour tous les types de sites web, le cache sera contourné beaucoup plus que nécessaire pour votre site. C'est pourquoi la configuration manuelle du cache sera presque toujours plus efficace que l'APO de CloudFlare

Recommandation : Activez APO, ou mieux encore, configurez vos propres règles de mise en cache complète de page en périphérie pour un meilleur contrôle sur le contournement du cache.

HTTP/2 & HTTP/2 vers Origine & Priorisation HTTP/2 Améliorée

L'activation de HTTP/2, HTTP/2 vers Origine & Priorisation HTTP/2 Améliorée est une évidence.  HTTP/2 est une énorme amélioration par rapport à l'ancien protocole HTTP/1.1. HTTP/2 fait beaucoup de choses mais surtout il se débarrasse de l'ancien effet d'escalier en permettant à plusieurs fichiers d'être envoyés sur la même connexion en parallèle. HTTP/2 existe depuis 10 ans et est largement supporté par les navigateurs et les serveurs !

Recommandation : activer

HTTP/3 (avec QUIC)

HTTP/3 avec QUIC est encore plus rapide que HTTP/2  grâce à des améliorations dans l'établissement de la connexion et la latence. Fondamentalement, HTTP/3 permet à plusieurs flux d'être envoyés indépendamment même si l'un est retardé. QUIC combine les handshakes de transport et de chiffrement, ce qui réduit le temps de connexion. Cela se traduit par des temps TTFB jusqu'à 10% plus rapides !

Recommandation : activer

Reprise de connexion 0-RTT

La reprise de connexion 0-RTT accélère les connexions sécurisées en sautant le handshake initial lorsqu'un utilisateur revisite un site. Elle utilise des clés de chiffrement stockées précédemment, permettant aux données d'être envoyées immédiatement, réduisant la latence et améliorant les temps de chargement des pages. 

Recommandation : activer

Échanges signés automatiques (SXGs)

Les échanges signés (SXG) permettent à Google Search de précharger votre contenu tout en préservant la confidentialité de l'utilisateur. Cela signifie que les résultats affichés sur Google Search peuvent précharger quelques ressources clés (telles que HTML, JavaScript, CSS, images ou polices) de manière respectueuse de la vie privée. Les échanges signés automatiques amélioreront votre Largest Contentful Paint et Time to First Byte !

Recommandation : activer

Scrape Shield

Scrape Shield protège le contenu de votre site web. Bien que cela puisse sembler une bonne idée, je suis fermement contre l'activation des options Scrape shield. Scrape shield fonctionne en injectant du JavaScript dans votre page pour décoder le contenu précédemment obfusqué. Ce compromis entre vitesse et masquage du contenu n'a aucun sens pour moi. Les vrais spammeurs ne sont pas dupes tandis que les vrais utilisateurs reçoivent des scripts supplémentaires qui ralentissent la page.

Recommandation : désactiver l'obfuscation d'adresse email et désactiver la protection Hotlink

Mise en cache > Configuration

Purger le Cache

Purger le cache invalidera tous les fichiers mis en cache par CloudFlare, y compris les feuilles de style, le JavaScript, les images et même les caches de page complète. Et bien que purger le cache ne soit techniquement pas un paramètre, je dois mettre en garde contre l'effacement du cache. Effacer le cache rendra votre site plus lent jusqu'à ce que le cache ait été reconstruit !

Recommandation : évitez de purger tout le cache si possible. Purgez seulement les fichiers affectés !

Niveau de mise en cache

Le niveau de cache détermine comment CloudFlare gère les chaînes de requête (je sais : 'qu'y a-t-il dans un nom !'). Vous voudrez bien regarder ce paramètre. 

L'option la plus 'rapide' est 'ignorer la chaîne de requête'. Cela sert la même ressource quelle que soit la chaîne de requête. Ce n'est une bonne option que si vous êtes sûr à 100% que les chaînes de requête ne sont pas utilisées sur votre site. Dans ce cas, les chaînes de requête ajoutées par d'autres sont ignorées.

'Standard' sert un fichier mis en cache différent pour chaque chaîne de requête différente. C'est le paramètre par défaut pour CloudFlare mais en combinaison avec la mise en cache complète de page en périphérie et les paramètres de suivi comme les paramètres utm, ce paramètre peut causer une incohérence de cache et un taux de cache hit plus bas !

Recommandation : Ignorer la chaîne de requête chaque fois que possible ou standard, évitez l'option 'Pas de chaîne de requête' si possible.

TTL du cache navigateur

Le TTL du cache navigateur indique au navigateur combien de temps il peut mettre en cache les ressources statiques. Les ressources mises en cache peuvent être servies directement depuis le navigateur et sont disponibles beaucoup plus rapidement que les ressources réseau distantes. Cela signifie qu'un TTL de cache navigateur court invaliderait fréquemment le cache du navigateur, abaissant le taux de cache-hit. Donc, à moins que vos fichiers statiques ne changent fréquemment, réglez ce paramètre au maximum. 

Recommandation : régler sur 1 an si possible

Mode Développement

Le mode développement contournera toute la mise en cache CloudFlare lorsqu'il est activé. Il pourrait être tentant pour vous d'activer le mode développement pendant le développement. S'il vous plaît, n'activez pas le mode développement, cela désactive également la mise en cache pour tous les autres visiteurs. Configurez plutôt un domaine de développement où vous pouvez développer ou excluez-vous de la mise en cache CloudFlare en configurant des règles de cache..

Recommandation : ne pas activer !

Mise en cache > Tiered Cache

Le Tiered cache réduit le nombre de requêtes vers votre serveur d'origine et augmente le taux de cache hit en demandant à CloudFlare de rechercher d'abord les fichiers non mis en cache sur ses propres serveurs. Cela réduit encore plus la charge sur votre serveur back-end et libère des ressources supplémentaires.

Recommandation : activer la topologie de cache intelligente (smart cache topology)