05 - Optimiser les performances : cache rules, workers et compression

Ce que tu vas apprendre

• Les Cache Rules avancees pour contrôler finement le cache
• Cloudflare Workers pour exécuter du code au edge
• Les optimisations de compression et de preloading
• L'impact sur les Core Web Vitals

Prerequisites

• 02 - Configurer Cloudflare : Cloudflare actif et configure
• 01 - Fonctionnement d'un CDN : comprendre le cache HTTP

Les Cache Rules avancees

Dans l'article 02, on a vu les bases. Ici on va plus loin. Les Cache Rules (qui remplacent les Page Rules) permettent de définir des stratégies de cache granulaires.

Le plan gratuit offre 10 Cache Rules. C'est beaucoup. Voici les regles que j'utilise sur mes projets :

Regle 1 : cache agressif sur les assets statiques

Si: URI path matches "*.css" OR "*.js" OR "*.woff2" OR "*.webp" OR "*.avif"
Cache eligibility: Eligible for cache
Edge TTL: 1 an
Browser TTL: 1 mois

Un an de cache edge, ca parait long. Mais si tu utilises du cache busting par hash dans tes noms de fichiers (app.a8f3b2.js), le nom change a chaque deploy. L'ancienne URL ne sera plus jamais demandee, donc un TTL d'un an est sans risque.

Regle 2 : cache court sur le HTML

Si: URI path matches "*.html" OR URI path ends with "/"
Cache eligibility: Eligible for cache
Edge TTL: 5 minutes
Browser TTL: 0 (no-cache)

Le HTML doit toujours refleter la dernière version déployée. Un TTL edge de 5 minutes est un bon compromis : ca réduit la charge sur l'origin tout en limitant le delai avant qu'un changement soit visible.

Regle 3 : bypass du cache sur l'API

Si: URI path starts with "/api/"
Cache eligibility: Bypass cache

Les réponses d'API sont dynamiques par nature. Ne les cache pas au CDN sauf si tu sais exactement ce que tu fais (et meme la, utilise stale-while-revalidate plutot qu'un TTL fixe).

Cloudflare Workers : du code au edge

Workers, c'est la fonction la plus puissante de Cloudflare. Tu ecris du JavaScript (ou du Wasm) qui s'exécuté sur les 310+ serveurs edge de Cloudflare. Pas sur ton VPS, pas dans le cloud, directement sur le noeud le plus proche de l'utilisateur. Le cold start est inférieur a 5 ms.

Le plan gratuit inclut 100 000 requêtes Workers par jour. Pour un petit site, c'est largement assez.

Un exemple concret que j'utilise : ajouter des headers de sécurité a toutes les réponses.

javascriptexport default {
  async fetch(request) {
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);

    newResponse.headers.set("X-Content-Type-Options", "nosniff");
    newResponse.headers.set("X-Frame-Options", "DENY");
    newResponse.headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
    newResponse.headers.set("Permissions-Policy", "camera=(), microphone=()");

    return newResponse;
  }
};

Six lignes de logique. Deploye sur tous les edge nodes en 30 secondes avec npx wrangler deploy. Pas de modification de ton serveur origin, pas de config Caddy a toucher.

D'autres cas d'usage courants pour les Workers :

Redirection geolocalisee. Tu veux rediriger les visiteurs français vers /fr/ et les anglophones vers /en/ ? Le Worker a acces a request.cf.country.

A/B testing au edge. Tu sers une version A ou B de la page en fonction d'un cookie, sans que l'origin sache quoi que ce soit. Zero latence supplementaire.

API gateway legere. Rate limiting custom, transformation de requêtes, aggregation de plusieurs API backend en un seul appel.

Workers KV est un key-value store global accessible depuis les Workers. Latence de lecture inférieure a 10 ms partout dans le monde. 100 000 lectures par jour gratuites. Pratique pour stocker des feature flags, des redirections, ou des configurations qui changent rarement.

Pour déployer un Worker, installe Wrangler et créé un projet :

bashnpm install -g wrangler
wrangler init mon-worker
# edite src/index.js
wrangler deploy

La compression

On en a parle brievement dans l'article 02, mais approfondissons.

Brotli compresse 15-20% mieux que gzip sur les contenus texte (HTML, CSS, JS, JSON, SVG). Cloudflare le sert automatiquement si le navigateur l'accepte (header Accept-Encoding: br). Tous les navigateurs modernes le supportent depuis 2017.

Un point que beaucoup ignorent : la compression s'applique entre l'edge et le navigateur. Si ton origin envoie deja du contenu compresse en gzip, Cloudflare le decompresse puis le recompresse en Brotli. C'est transparent mais ca consomme du CPU au edge. Pour éviter ce double travail, tu peux envoyer du contenu non compresse depuis l'origin et laisser Cloudflare gerer toute la compression. Avec Caddy, ca veut dire désactiver encode dans le Caddyfile pour le trafic proxifie par Cloudflare.

Early Hints et preloading

Early Hints (103) est un mecanisme HTTP qui permet au serveur d'envoyer des indications au navigateur avant la réponse principale. En pratique, Cloudflare observe les headers Link: <preload> de tes réponses précédentes et les envoie sous forme de 103 a la prochaine requête. Le navigateur commence a telecharger tes CSS et JS critiques pendant qu'il attend encore le HTML.

Sur les sites avec beaucoup de resources, j'ai mesure une réduction du LCP (Largest Contentful Paint) de 200-400 ms grâce à Early Hints. C'est gratuit, c'est automatique une fois active dans le dashboard, il n'y a aucune raison de ne pas l'utiliser.

Combine avec des headers preconnect dans ton HTML :

html<link rel="preconnect" href="https://media.paltemps.fr" crossorigin>
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Le preconnect ouvre la connexion TCP+TLS vers le sous-domaine media avant que le navigateur en ait besoin. Le preload telecharge la font immédiatement. Combine avec Early Hints, ca fait une différence visible.

L'impact sur les Core Web Vitals

Les Core Web Vitals de Google (LCP, INP, CLS) sont directement impactes par la configuration CDN.

LCP (Largest Contentful Paint) : la rapidité a laquelle le plus gros élément visible se charge. Un CDN bien configure avec cache agressif, compression Brotli, preloading et Early Hints peut réduire le LCP de 500 ms a 1 seconde par rapport a un site sans CDN.

INP (Interaction to Next Paint) : la réactivité aux interactions utilisateur. Le CDN aide moins ici, c'est surtout du JavaScript cote client. Mais un Worker qui sert du HTML statique cache plutot que du rendu dynamique peut aider.

CLS (Cumulative Layout Shift) : la stabilité visuelle. Pas directement lie au CDN, sauf si tu utilises l'optimisation d'images Cloudflare qui peut servir des dimensions correctes et éviter les reflows.

Sur paltemps.fr, les scores Lighthouse en production avec Cloudflare actif : Performance 95+, LCP sous 1.2 secondes, CLS a 0. C'est le résultat combine de Caddy (HTTP/2, compression), Cloudflare (cache, Brotli, Early Hints) et un front leger.

Prochain article : Comparatif des CDN.

Navigation : Precedent : 04 - Sécurité CDN | Suivant : 06 - Comparatif des CDN

Sources

• Cloudflare Cache Rules par Cloudflare Docs
• Cloudflare Workers Documentation par Cloudflare Docs
• Early Hints - web.dev par web.dev
• Core Web Vitals par web.dev

Retrouve d'autres articles techniques sur paltemps.fr.