Edge SEO 2026 : HTMLRewriter Cloudflare sous le capot

Pourquoi un parser HTML qui ne charge jamais le DOM en mémoire peut réécrire vingt mille redirections en streaming sans casser le TTFB ? Parce qu'il est écrit en Rust, qu'il fonctionne en zero-copy, et qu'il tourne sur les 330+ villes du réseau Cloudflare. C'est exactement ce que fait HTMLRewriter, et c'est la pièce la plus intéressante du puzzle Edge SEO en 2026.

Si vous avez déjà ouvert un Worker pour injecter une balise hreflang à la volée, vous savez que la promesse "modifier le HTML à l'edge" cache une vraie complexité technique. Cet article décortique le runtime, le pricing, les limites réelles, et pourquoi les concurrents (Akamai EdgeWorkers, Fastly Compute) peinent à offrir la même expérience développeur.

Sous le capot : pourquoi HTMLRewriter n'est pas un parser comme les autres#

La doc officielle Cloudflare le résume en une phrase : "Cloudflare performs zero-copy streaming parsing". Traduction pour les devs dans la salle : pas de chargement DOM en mémoire, pas de buffer entier en RAM, pas de copie inutile des bytes du response body. Le parser, écrit en Rust, lit le flux HTML et émet des événements à mesure que les balises arrivent.

C'est la différence clé avec un cheerio.load(html) que vous feriez côté Node : là, vous chargez tout en mémoire, vous parsez, vous serialize. Ici, vous attachez des handlers à des sélecteurs CSS et le parser les déclenche au fil de l'eau.

L'API ressemble à du jQuery moderne, et c'est volontaire :

class CanonicalInjector {
	element(element) {
		element.append('<link rel="canonical" href="https://www.example.com/page" />', {
			html: true,
		})
	}
}

export default {
	async fetch(request) {
		const response = await fetch(request)
		return new HTMLRewriter().on('head', new CanonicalInjector()).transform(response)
	},
}

Les méthodes disponibles sur un Element couvrent à peu près tout ce dont un dev SEO a besoin : getAttribute, setAttribute, hasAttribute, removeAttribute, before, after, prepend, append, replace, setInnerContent, remove, removeAndKeepContent, onEndTag. Deux types de handlers : .on(selector, handler) pour cibler des éléments via sélecteurs CSS, et .onDocument(handler) pour réagir au niveau document (doctype, fin de doc, etc.).

Le détail qui change tout : les handlers peuvent être async. Vous pouvez donc, dans un handler, faire un appel à Workers KV, à un Durable Object, ou même à une API tierce, avant de décider ce que vous injectez dans le HTML. C'est la feature qui distingue Cloudflare de la concurrence, on y revient plus bas.

Le piège des text chunks#

Petit caveat technique pas évident à la première lecture : quand vous attachez un handler text à un sélecteur, les text chunks que vous recevez ne correspondent pas aux text nodes du DOM. La doc le dit clairement : "text chunks are not the same thing as text nodes". Un seul nœud texte peut arriver en plusieurs chunks selon la taille du buffer de streaming.

Concrètement, si vous voulez remplacer une chaîne dans du texte, vous ne pouvez pas faire un simple .replace() sur un chunk parce que la chaîne peut être coupée à cheval entre deux chunks. Il faut soit accumuler, soit travailler sur des balises englobantes. C'est typiquement le genre de bug qu'on découvre en prod après deux semaines de fonctionnement nominal. Honnêtement, j'ai mis du temps à comprendre pourquoi mon regex sautait un mot sur cinq.

Autre point : si un handler throw, le parsing s'arrête immédiatement, le response body est en erreur, et la response originale est annulée. Pas de mode dégradé "on injecte rien et on laisse passer". Vous devez wrapper vos handlers dans des try/catch si vous ne voulez pas planter la page entière à cause d'un appel KV qui timeout.

Les vrais cas d'usage SEO (avec les chiffres de Cloudflare)#

L'article de référence sur le sujet, c'est le post Cloudflare "Diving into Technical SEO with Cloudflare Workers" (2021). Les benchmarks publiés là-bas restent la meilleure source publique pour qui veut chiffrer sérieusement ce que coûte un rewrite à l'edge.

Redirections en masse. Le cas d'école : vous avez 20 000 anciennes URLs à rediriger après une refonte. Au lieu de 20 000 lignes dans un fichier nginx ou un plugin WordPress qui ramene la base, vous packez tout dans un Cuckoo Filter. Cloudflare a documenté un setup qui fait tenir 20 000 redirections dans 128 KB, splittées sur 2 clés KV, avec un taux de faux positifs de 0,5 à 1 %. Le faux positif déclenche une vérification KV pleine, donc rien de cassé, juste un coût subrequest occasionnel.

Hreflang dynamique. Injection des balises <link rel="alternate" hreflang="..." /> dans le <head> selon l'URL ou le domaine. Le benchmark Cloudflare est instructif sur les algos de matching :

Implémentation	Débit (ops/sec)
Boyer-Moore-Horspool précompilé (1024B)	424 948
Rust WASM (1024B)	348 197
UTF-8 decode + indexOf()	91 685

Le constat : un algo de string matching bien choisi multiplie le débit par presque cinq. Et surtout, en production, le filter hreflang n'a pas montré de "statistically significant change in latency" comparé à un Worker sans filtre. C'est la phrase à garder en tête quand on vous parle de "TTFB overhead" sans source.

Canonicals, JSON-LD, robots.txt. Tous les classiques du SEO technique passent par le même moteur. Injecter un JSON-LD Article dans le <head> sans toucher au backend ? Trois lignes. Modifier le robots.txt selon le user-agent ou la geo ? Pareil.

class JsonLdInjector {
	constructor(article) {
		this.article = article
	}
	element(element) {
		const ld = {
			'@context': 'https://schema.org',
			'@type': 'Article',
			headline: this.article.title,
			datePublished: this.article.date,
		}
		element.append(`<script type="application/ld+json">${JSON.stringify(ld)}</script>`, {
			html: true,
		})
	}
}

À noter : Cloudflare prévient explicitement qu'Edge SEO peut créer du duplicate content si on sert un HTML différent à Googlebot et aux utilisateurs. C'est une des erreurs classiques qu'on voit régulièrement, et ça vaut un rappel dans toute revue de SEO technique sérieuse.

Pricing et limites réelles#

Le truc qui surprend beaucoup de monde quand ils découvrent Workers, c'est le rapport prix/performance. Voici les chiffres officiels Cloudflare 2026 :

Tier	Free	Paid
Prix	0 $	5 $/mois minimum
Requêtes	100 000/jour	10 millions/mois inclus, +0,30 $/M
CPU time	10 ms par invocation	30 millions ms/mois inclus, +0,02 $/M
CPU max	10 ms	5 minutes (défaut 30 secondes)
Subrequests	50 par invocation	10 000 par invocation (jusqu'à 10 M)
Mémoire isolate	128 MB	128 MB
Script size	64 MB pré-compression	10 MB compressé (gzip), 64 MB avant gzip

Le tier gratuit est largement suffisant pour tester, prototyper, ou faire tourner un blog avec quelques milliers de visites par jour. Le passage à Paid à 5 $/mois minimum est pertinent dès que vous dépassez 100 000 requêtes/jour ou que vous voulez plus de subrequests.

Les 128 MB de mémoire par isolate, c'est la vraie limite à connaître. Pour de l'injection HTML c'est confortable. Pour du processing lourd (un parseur PDF en WASM, par exemple), c'est serré. Mais le streaming zero-copy de HTMLRewriter est précisément conçu pour ne pas saturer cette mémoire, même sur une page de 5 MB.

Petit changement réglementaire à noter : depuis le 7 janvier 2026, Durable Objects Storage est facturé (avant : gratuit). Si votre stack SEO repose sur des DO pour stocker des sessions ou des compteurs, le coût n'est plus zéro.

Latence ajoutée à l'edge#

Sujet sensible et souvent mal traité. Search Engine Journal cite environ 10 millisecondes en moyenne sur des sites réels. C'est la seule estimation publique sérieuse. Cloudflare lui-même n'a pas publié de benchmark TTFB précis sur HTMLRewriter, et les chiffres qu'on lit parfois sur des contenus marketing ("60-80 % TTFB reduction" et autres) ne viennent d'aucune source primaire vérifiable. À 1,8 secondes de LCP, 10 ms d'overhead edge, c'est statistiquement invisible. Pour aller plus loin sur les seuils, je vous renvoie au guide Core Web Vitals 2026.

Akamai et Fastly : pourquoi la DX décide#

Cloudflare a deux concurrents directs sur l'edge compute : Akamai EdgeWorkers et Fastly Compute. Sur le papier, ils font la même chose. En pratique, l'expérience développeur creuse l'écart.

Akamai EdgeWorkers. A publié son module html-rewriter en avril 2023, soit quatre ans après Cloudflare. La limite qui change tout : pas de support async/await dans les handlers. Vous ne pouvez donc pas, depuis un handler, appeler un KV, une API, ou même un cache. Vous devez tout pré-charger avant le rewrite. Pour 90 % des cas SEO sérieux (redirects en masse, hreflang dynamique avec lookup), c'est rédhibitoire.

Deuxième point : "The HtmlRewritingStream does not escape inserted text". L'échappement XSS est à la charge du dev. Une ligne de doc qu'on a tendance à survoler, jusqu'au jour où une injection passe en prod parce qu'un attribut user-supplied n'a pas été nettoyé.

Fastly Compute. Runtime WebAssembly (Rust, AssemblyScript, JavaScript), TTFB annoncé "jusqu'à 32 % plus rapide que les autres CDNs" (chiffre auto-déclaré dans leur brief commercial, à prendre avec des pincettes). Purge instantanée à 150 ms en moyenne, ça c'est solide. Mais 3 à 7x plus cher que Cloudflare pour des workloads similaires selon la comparaison Taloflow 2024. Pas de grille tarifaire publique précise, négociation custom, trial à 50 $ de crédits.

Le verdict de Taloflow est sec : Cloudflare est "the only contender" pour une app serverless self-contained, et la DX d'Akamai est "currently not up to par". J'ajoute une nuance personnelle : Akamai reste pertinent si vous êtes déjà client enterprise pour le CDN et que vous voulez consolider. Sinon, le ticket d'entrée Cloudflare à 5 $ est imbattable.

La règle qui sauve : KV lu une fois par seconde#

Détail de perf rarement mentionné mais critique. La doc Cloudflare précise que les clés KV doivent idéalement être lues "on the order of once-per-second in any given data center" pour une perf optimale. KV est un eventually consistent store, optimisé pour des reads massifs et des writes peu fréquents.

Si vous lisez la même clé 10 000 fois par seconde, ça marche, mais vous payez en latence et en cohérence. Le pattern correct pour de l'edge SEO, c'est : KV pour les données peu volatiles (mappings de redirects, configs hreflang), Durable Objects pour ce qui doit être consistent et fréquent (compteurs, sessions). La distinction est moins évidente qu'elle n'en a l'air, et c'est typiquement le genre de choix qui se paie en facture six mois plus tard.

Pour qui, concrètement#

Trois profils tirent vraiment parti d'HTMLRewriter en 2026 :

Sites en migration / refonte avec des milliers de redirects à gérer sans toucher au backend. Le combo KV + Cuckoo Filter + Workers règle ça en quelques heures. Voir aussi le guide redirection 301 vs 302 pour les bonnes pratiques.
Sites multi-locale qui doivent injecter du hreflang dynamique selon le domaine ou l'URL, sans modifier le CMS.
Stacks headless où le SEO technique (canonicals, JSON-LD, robots.txt) est piloté à l'edge plutôt que dans le framework front.

Pour qui ça ne vaut pas le coup ? Un blog WordPress avec un plugin Yoast qui fait déjà 90 % du job, et 5 000 visites/mois. Inutile de complexifier la stack pour économiser trois millisecondes. Le critère de bascule, c'est généralement le volume de redirects à gérer ou le besoin de logique conditionnelle (geo, user-agent, A/B test SEO).