La personnalisation des pages web pour le spectateur peut nécessiter la réécriture du code HTML récupéré d'une autre source. Par exemple, il nous faut adresser une requête à un service appartenant à une autre équipe et nous devons modifier sélectivement certaines parties de la réponse. Ou bien, nous voulons mettre en cache les parties statiques de la page en périphérie, plus proches des utilisateurs, et effectuer la personnalisation à un emplacement physique qui minimise la latence des requêtes. Désormais, le SDK JavaScript de Fastly Compute est accompagné d'une réécriture HTML en streaming qui permet d'atteindre ces objectifs avec une API ergonomique qui s'intègre dans les standards web existants et qui surpasse les solutions de manipulation DOM côté serveur à usage général.
La réécriture HTML est disponible dans la version 3.35.0 du SDK JS, et la documentation est disponible dans les docs @fastly/js-compute.
Comment fonctionne l'API HTMLRewritingStream
Le SDK JS fournit un type HTMLRewritingStream qui vous permet d’enregistrer des fonctions de rappel de réécriture sur des sélecteurs CSS. Lorsque l'outil de réécriture rencontre un élément correspondant au sélecteur, il appelle la fonction de rappel enregistrée. Cette fonction de rappel peut manipuler les attributs de l’élément et ajouter ou supprimer du contenu dans le contexte immédiat. Après avoir créé une instance de ce type, vous pouvez y faire transiter un flux HTML. Par exemple, si nous voulons ajouter le texte « Header : » à tous les tags h1 et ajouter un attribut aux tags div, nous pourrions écrire ceci :
/// <reference types="@fastly/js-compute" />
import { HTMLRewritingStream } from 'fastly/html-rewriter';
async function handleRequest(event) {
let transformer = new HTMLRewritingStream()
.onElement("h1", e => e.prepend("Header: "))
.onElement("div", e => e.setAttribute("special-attribute", "top-secret"));
let body = (await fetch("https://example.com/")).body.pipeThrough(transformer);
return new Response(body, {
status: 200,
headers: new Headers({
"content-type": "text/html"
})
})
}
addEventListener("fetch", (event) => event.respondWith(handleRequest(event)));Pour construire le HTMLRewritingStream, il existe deux fonctions de rappel : une pour les tags h1 et une pour les divs. Commencez par effectuer une requête HTTP pour récupérer une page HTML, puis faites passer la réponse dans l'outil de réécriture. Enfin, renvoyez une réponse contenant le corps réécrit.
HTMLRewritingStream est un type de TransformStream, qui fait partie de la norme Streams API. Cela présente deux avantages principaux. Premièrement, le HTML est traité en streaming : le document est reçu, transformé et envoyé au client par fragments, sans attendre la transmission et la transformation complètes. Deuxièmement, l'outil de réécriture s'intègre aux pipelines existants basés sur TransformStream. Ainsi, si vous avez des transformations personnalisées à effectuer avant ou après la réécriture HTML, il vous suffit d'enchaîner un autre appel pipeThrough, comme suit :
body.pipeThrough(aCustomTransformer)
.pipeThrough(htmlRewriter)
.pipeThrough(anotherCustomTransformer);L'API suit l'interface html-rewriter d'Akamai, à l'exception de l'option insert_implicit_close, qui n'est pas prise en charge, et de l'ajout d'une option escapeHTML, qui permet l’insertion de HTML en tant que texte dans les éléments réécrits. L'implémentation utilise la crate Rust lol-html de Cloudflare pour effectuer du parsing et des réécritures à la volée.
Tests de performance : Fastly HTMLRewritingStream vs LinkeDOM
En raison de l'infrastructure sous-jacente de parsing et de réécriture à faible latence basée sur le streaming, le HTMLRewritingStream surpasse largement les bibliothèques JS pures telles que LinkeDOM. Le graphique ci-dessous illustre le temps de traitement en millisecondes nécessaire à la réécriture d'un certain nombre de tags d'image, ainsi que de leurs étiquettes et descriptions :
Notez les axes logarithmiques. Cela montre que le temps de traitement pour HTMLRewritingStream est environ 20 fois plus rapide que celui de LinkedDOM. Les mesures ont été effectuées avec une exécution locale sur un MacBook Pro M3, moyennées sur 20 exécutions.
Vous pouvez voir la différence en action dans cette petite démo, qui réécrit des images avec une photo de Nicholas Cage (notez que sélectionner un nombre d'images plus élevé pour l'implémentation de LinkeDOM peut entraîner des dépassements de temps CPU).
Conclusion : Réécriture HTML haute performance en périphérie avec Fastly Compute
La fonctionnalité de réécriture HTML du SDK JavaScript de Fastly est maintenant disponible dans la version 3.35.0. Elle vous offre une méthode ergonomique et performante pour réécrire du HTML qui respecte les normes web existantes. N'hésitez pas à l'essayer et à nous faire part de l'aide qu'elle apporte à vos charges de travail Compute.