Un aspect primordial du développement est la mise en cache des ressources statiques qui sont utilisées par votre application web. De nos jours, cette pratique devient essentielle en raison du poids sans cesse augmenté des applications web. Il est donc essentiel d’évaluer ce qu’est un contenu dynamique et ce qui peut être mis en stockage permanent côté client.
Des applications plus lourdes à exécuter et des librairies CSS et JavaScript qui font de l’obésité. C’est un peu cela le web moderne.
À petite échelle, l’effort de s’assurer qu’un navigateur télécharge qu’une seule fois un fichier afin d’éviter de le réutiliser à travers vos différentes visites peut sembler exagéré. Cependant, lorsque votre application a un peu d’affluence, l’idée du caching a beaucoup de sens. Si vous payez pour votre bande passante, vous apprécierez tous les kilobits économisés.
Dans le même genre d’économies d’échelle, chaque requête que votre serveur web n’a pas à faire c’est des cycles de CPU qui peuvent être utilisés à faire d’autres traitements ou même vous permettre d’utiliser un serveur de plus petite capacité pour vos besoins. Considérant les coûts de certains hébergements dans le cloud, ce n’est pas si bête comme idée.
Mise en cache
Avec IIS (et les autres serveurs web), tout commence par l’activation de la cache des contenus statiques dans la configuration de votre application. Cela aura pour effet d’envoyer l’instruction aux navigateurs web n’éviter de télécharger inutilement les éléments image, CSS et JavaScript.
À ceci, j’ajouterais qu’en réalité, la configuration de la mise en cache des contenus est un peu plus complexe que cela. Ce que j’ai affirmé au paragraphe précédent va fonctionner pour une majorité de cas. Il s’agit uniquement d’une recette de base. Par exemple, il faut savoir quand et comment utiliser le etag, connaitre les différences entre les entêtes cache-control et expires.
Le web, c’est compliqué quand on s’attarde aux détails!
Fingerprint
Une fois que votre contenu est mis en cache pour les jours ou même les semaines à venir, que faire si vous venez de mettre à jour une partie de ceux-ci et désirez vous assurer qu’ils sont téléchargés par vos visiteurs?
Le meilleur et le plus simple mécanisme que je connaisse est d’introduire un paramètre d’URL indiquant un identifiant de version à vos fichiers statiques. Cet identifiant doit être incrémenté à chaque nouvelle révision de vos fichiers afin que le navigateur le télécharge à nouveau lorsqu’il sera modifié.
Ce que j’utilise depuis déjà un bon moment est l’utilitaire développé par Mads Kristensen nommé Fingerprint. Ce que cette classe fait est très simple. Elle permet la création d’URL convertissant la date de modification des fichiers désirés en un identifiant de version unique. Par exemple, la ressource /content/site.css devient /content/v-634933238684083941/site.css.
Cool, n’est-ce pas? En plus, c’est super simple à utiliser. Avec ASP.NET MVC, il suffit d’invoquer la classe Fingerprint de cette façon pour obtenir l’URL @Fingerprint.Tag(« /content/site.css »). Magie, magie.
La dernière chose à mentionner est l’ajout de cet élément de configuration dans votre web.config.
<rewrite>
<rules>
<rule name="fingerprint">
<match url="([\S]+)(/v-[0-9]+/)([\S]+)" />
<action type="Rewrite" url="{R:1}/{R:3}" />
</rule>
</rules>
</rewrite>
Parlant d’URL Rewrite, la seule vraie mise en garde est la configuration sur vos environnements de développement et de production. Fingerprint requiert l’installation de l’extension URL Rewrite sur vos serveurs IIS. Donc, si vous allez de l’avant avec ceci (je vous le conseille fortement), installez URL Rewrite avant tout. Sinon, votre site web sera simplement kaput à son démarrage.
French Coding 