Optimisations IIS 7.5 pour un site ne servant que du contenu statique

21

Je cherche à configurer un domaine sans cookie destiné à servir du contenu statique pour une application Web, similaire au site http://sstatic.net/ que les sites d'échange de pile utilisent.

Ma question est, quelles optimisations puis-je apporter à ma configuration IIS 7.5 pour un tel domaine? Par exemple, il ne sera jamais responsable d'autre chose que de servir du contenu statique, donc la désactivation de l'intégration ASP.NET serait-elle une bonne décision pour ce site?

Toutes suggestions ou références sur la configuration d'un tel site avec IIS 7.5 seraient les bienvenues.

modifier

Juste pour clarifier, ce n'est pas le SEUL site sur le serveur, donc les optimisations suggérées devraient cibler le niveau du site, et non la configuration au niveau du serveur.

iis iis-7 web-server optimization yslow DanP
la source

Réponses:

18

Il y a plusieurs considérations à cela, certaines qui sont gérées sur IIS (compression HTTP, mise en cache des en-têtes fx), et certaines qui sont gérées pendant le processus de construction / avant le déploiement (comme la concaténation de fichiers Javascript et CSS et la minification des espaces blancs).

En tant que tel, il est un peu difficile de vous donner un aperçu complet en une seule réponse, car certaines dépendront de vos méthodes de génération et de publication. Par étapes de haut niveau:

  • Le site est "sans cookies" du fait que vous utilisez un nouveau domaine, qui n'est pas lié à votre application web. Étant donné que vous ne définissez aucun cookie pour le domaine (à l'aide du code d'application fx .NET), il est alors "sans cookie".

  • Vous devez absolument activer la compression HTTP pour le contenu de texte statique tel que Javascript et CSS.

  • Je ne suis pas le meilleur administrateur IIS, mais pour autant que je sache, vous n'avez besoin que des composants IIS par défaut associés au rôle de serveur de base "Web Server (IIS)" .

  • Vous devez absolument activer les en-têtes de mise en cache longs pour le contenu statique . La recommandation générale est de 31 jours, mais vous pouvez la régler plus haut ou plus bas. N'oubliez pas que si vous diffusez du contenu statique avec de longs en-têtes de cache, vous devez modifier l'URL si vous modifiez le fichier, pour éviter que l'ancien contenu mis en cache soit réutilisé par les clients.

  • Vous devez activer keep-alive HTTP (mêmes documents que la mise en cache des en- têtes).

En plus de cela, il y a des tâches de pré-déploiement, telles que la compression des espaces en Javascript et CSS , et idéalement la compression de PNG , etc. Ce sont vos outils de développement et votre cycle de construction qui aident à décider comment procéder.

Lorsque vous avez terminé, essayez de télécharger quelques fichiers à partir de vos serveurs statiques avec YSlow activé . Je trouve que le jeu de règles "Classic V2" donne le plus grand impact pour l'effort, donc je suggère de vérifier votre score par rapport à ce jeu de règles YSlow.

De l'ensemble de règles "Classic V2", ces règles s'appliquent proprement aux instances et au contenu IIS de votre serveur statique:

3. Add an Expires or a Cache-Control Header
4. Gzip Components
10. Minify JavaScript and CSS
11. Avoid Redirects
13. Configure ETags
19. Use Cookie-Free Domains for Components
22. Make favicon.ico Small and Cacheable
Jesper M
la source
Merci pour vos commentaires: j'ai déjà pris soin des considérations de pré-production que vous avez notées. Ce que je recherche vraiment, c'est le détail de la configuration IIS. Puisqu'il n'y a que du contenu statique, je suppose que je peux supprimer beaucoup de choses du pipeline http, etc.
DanP
1
@DanP: Il n'y a vraiment pas beaucoup de travail pour configurer IIS. Microsoft réussit à expédier des configurations minimales «sécurisées par défaut». L'optimisation des performances en supprimant les composants IIS qui font partie du rôle serveur de base est l'optimisation prématurée à mon humble avis. Je peux presque garantir que le gain de performances n'en vaudra pas la peine, car le service de fichiers statiques a généralement une charge de serveur très faible. Pour les performances de l'utilisateur final, la partie importante consiste à obtenir la bonne sémantique HTTP - en-tête de mise en cache, compression, keepalive, selon les documents ci-dessus.
Jesper M
Les valeurs par défaut sont conçues pour le service de fichiers statiques - si vous ajoutez simplement le rôle de serveur Web, vous êtes configuré avec un pipeline minimal pour le service de fichiers statiques. Donc, pour minimiser le pipeline - n'installez rien d'autre!
TristanK
@TristanK: Je suppose que je devrais être plus précis ... ce n'est pas le SEUL site sur le serveur IIS, donc je dois faire mes optimisations au niveau du site, pas au niveau du serveur.
DanP
Oui, c'est une information clé. Si vous avez décidé que c'est le chemin que vous avez choisi, je pense a) en installer un nouveau pour le comparer, b) marquer tous les modules / gestionnaires que vous souhaitez supprimer (qui ne font pas partie de l'installation par défaut) avec precondition = " AppPoolName! = StaticPool "(la syntaxe peut être inversée). C'est à peu près tout, d'inclure / exclure des modules dans un pool d'applications donné.
TristanK
9

Il y a une écriture très intéressante ici où quelqu'un utilise IIS pour servir des fichiers statiques. Il se concentre principalement sur l'ajustement des paramètres de mise en cache des fichiers IIS pour limiter l'activité du disque (ce qui était son goulot d'étranglement). Il dit qu'il a vu une augmentation de 20 fois ses performances.

Jusqu'à la crique
la source