Toujours à l’affût des dernières possibilités dans le monde de l’optimisation des sites web, nous utilisons depuis peu le concept d’Edge Side Include pour quelques-uns de nos clients qui disposent de sites à forte charge.
La norme ESI maintenue par le consortium W3C (à l’origine des normes HTML et XHTML) décrit un langage de balises de bases qui permettent à un serveur mandataire (reverse-proxy), situé en frontal d’un ou plusieurs serveurs web, de reconstruire une page web à partir de plusieurs éléments distincts.
Ainsi, si une page web contient une partie « statique », non dépendante d’un compte connecté ou du temps qui passe, et une partie « mobile » qui dépend par exemple de l’état de connexion d’un utilisateur ou du temps qu’il fait, ESI permettra au serveur proxy de garder en cache différemment chacune des parties de la page et reconstruira la page entière avant de l’envoyer à l’internaute.
ESI permet typiquement d’effectuer des conditions (if) simples et des inclusions de blocs de page (include).
Exemple et documents de référence :
On peut donc construire une page non plus dans son intégralité sur le serveur d’application, mais en partie uniquement, et laisser à d’autres parties de l’application le soin de calculer le reste de la page, grâce à une syntaxe du type :
<esi:include src="/userbloc" onerror="continue"/>
Le langage ESI est décrit dans sa version 1.0 sur le site du W3C
Il est donc possible, typiquement, de structurer une page web de contenu comme ceci :
<html> <body> Mettez ici le code de votre page web, code commun à tous les internautes (connectés ou non) lorsque vous avez besoin, par exemple de la boîte décrivant le compte de l'utilisateur connecté, mettez : <esi:include src="/userbox" /> Continuez avec votre code html commun comme si de rien n'était. Si vous avez besoin à nouveau d'un bloc spécifique (par exemple pour ajouter des éléments de menu), utilisez à nouveau esi include : <esi:include src="/usermenu" /> et finissez votre page </body> </html>
Les pages /userbox et /usermenu étant, quant à elles, totalement dynamiques et dépendantes de l’utilisateur connecté (donc sûrement de son cookie d’authentification, etc.)
Ainsi, votre reverse-proxy pourra garder en cache très longtemps la page principale, et ne mettre à jour que les blocs spécifiques, voire les mettre en cache aussi, mais moins longtemps, conformément à sa configuration…
Dans un prochain article, nous mettrons en oeuvre ce principe dans Varnish, excellent reverse-proxy en logiciel libre, qui écrase joyeusement Apache-mod-proxy ou squid dans ce domaine…
Portfolio
