Compression IIS6 pour un site 100% HTTPS

La compression statique n'est utilisée qu'une seule fois et est ensuite mise en cache pour une utilisation ultérieure. Il s'agit donc rarement d'un problème.

Mais comme vous avez un site MVC, vous devrez également utiliser la compression dynamique. Cela représente un coût pour le processeur à chaque requête, mais cela en vaut généralement la peine. La plupart du temps, vous disposez de cycles CPU supplémentaires mais d'une bande passante limitée sur votre client. La plupart du temps, la compression est donc une bonne idée. Mais si le serveur passe la plupart de son temps à une certaine charge élevée, la question de savoir si elle est utile ou nuisible varie.

Vous pouvez ajuster le niveau de compression en fonction de vos besoins, ce qui est conseillé car chaque scénario d'utilisation générale varie selon le site, le serveur et la bande passante. Voir Compression IIS dans IIS6.0 o Compression IIS 7. Bonne ? Mauvaise ? Combien ? (qui porte sur IIS7, techniquement, mais la discussion sur les limites est plus approfondie).

(Je ne sais plus si IIS6 fait cela, mais sachez que IIS7 arrête la compression dynamique lorsque le serveur atteint une certaine charge et ne la réactive pas avant que la charge ne soit beaucoup plus faible. Je n'arrive pas à trouver la référence de cette information pour l'instant - donc ne prenez pas cela comme parole d'évangile).

Je dirais que 99% du temps, activer la compression est une bonne chose. Mais comme pour toute modification des performances, assurez-vous de tester et d'ajuster pour répondre à vos besoins spécifiques.

Si vous livrez/téléchargez de grandes quantités de données textuelles dans l'application, il est très facile pour le développeur d'activer Gzip/Deflate dans le code, et cela fonctionne indépendamment d'IIS. Dans ce cas, il se peut qu'il soit déjà activé, mais que vous ne le sachiez pas.

Voici un extrait pertinent du livre Pro ASP.Net MVC de Steven Sanderson :

"N'oubliez pas que la compression HTTP n'est vraiment utile que pour les données textuelles. Les données binaires, comme les graphiques, sont généralement déjà compressées. Vous ne tirerez aucun avantage à envelopper la compression gzip autour de la compression JPEG existante. autour de la compression JPEG existante ; vous ne ferez que brûler des cycles CPU pour rien.

"Remarque : IIS 6 et les versions ultérieures peuvent être configurés pour compresser les réponses HTTP, que ce soit pour le contenu statique (c'est-à-dire les fichiers servis directement depuis le disque) ou pour le contenu dynamique (par exemple, la sortie de votre application ASP.NET MVC). Malheureusement, elle est assez difficile à configurer (sur IIS 6, vous devez modifier directement la métabase, ce qui peut ne pas être une option dans certains scénarios de déploiement), et bien sûr, elle ne vous donne pas la possibilité de l'activer ou de la désactiver pour des méthodes d'action individuelles. "