Je suis looking to setup a cookie-free domain intended to serve static content for a web application, similaire to le [http://sstatic.net/](http://sstatic.net/) site that le stack exchange sites use.
My question is, what optimizations can I make to mon IIS 7.5 setup for such a domain? Par exemple, it will jamais be responsible for anything mais serving static content, so would disabling ASP.NET integration be a good move for this site?
Any suggestions ou references on setting up such a site avec IIS 7.5 would be le plus welcome.
**Edit**
Just to clarify, this n'est pas le ONLY site on le server, so suggested optimizations should target le site level, et pas le server-level config.
Optimisations IIS 7.5 pour un site ne servant que du contenu statique
Re: Optimisations IIS 7.5 pour un site ne servant que du contenu statique
Il y a plusieurs considerations in this, certains qui are handled on IIS (HTTP compression, caching headers fx), et certains qui are handled pendant le build process / avant deployment (such as Javascript et CSS file concatenation & whitespace minification).
As such, c'est a bit hard to give you a complete rundown in one answer, as certains of it will depend on votre build & release methods. In high level steps:
-
The site is "cookieless" by virtue of you using a nouveau domain, one that is pas tied to votre webapplication. Since you're pas setting tout cookies for le domain (using f.x. .NET application code), c'est alors "cookieless".
-
Vous devriez *absolutely* [enable HTTP compression for static text content](http://www.iis.net/ConfigReference/system.webServer/httpCompression) such as Javascript et CSS.
-
Je suis pas le greatest IIS administrator, mais as far as I can tell, you seulement need le par défaut IIS components associated avec le [basic "Web Server (IIS)" server role](http://technet.microsoft.com/en-us/library/cc753473.aspx).
-
Vous devriez *absolutely* enable [long caching headers for the static content](http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache). The general recommendation is 31 days, mais you can set it higher ou lower. Remember, si you serve static content avec long cache headers, alors you must changez le URL si you changez le file, to avoid old cached content being re-used by le clients.
-
You *should* enable HTTP keep-alive (same docs as caching headers).
De plus to this, there are pre-deployement tasks, such as [whitespace compressing the Javascript and CSS](http://coderjournal.com/2010/01/yahoo-yui-compressor-vs-microsoft-ajax-minifier-vs-google-closure-compiler/), et [ideally compress PNG's better](http://www.smushit.com/ysmush.it/), etc. Ceci est were votre development tools et build cycle helps decide how to proceed.
When you're done, try downloading a peu de files depuis votre [static servers with YSlow enabled](http://developer.yahoo.com/yslow/). I find that le ["Classic V2" ruleset](http://developer.yahoo.com/yslow/help/#guidelines) gives le biggest impact for le effort, so Je suggérerais check votre score against this YSlow ruleset.
Of le "Classic V2" ruleset, these rules apply cleanly to votre static server IIS instances & content:
```
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
```
As such, c'est a bit hard to give you a complete rundown in one answer, as certains of it will depend on votre build & release methods. In high level steps:
-
The site is "cookieless" by virtue of you using a nouveau domain, one that is pas tied to votre webapplication. Since you're pas setting tout cookies for le domain (using f.x. .NET application code), c'est alors "cookieless".
-
Vous devriez *absolutely* [enable HTTP compression for static text content](http://www.iis.net/ConfigReference/system.webServer/httpCompression) such as Javascript et CSS.
-
Je suis pas le greatest IIS administrator, mais as far as I can tell, you seulement need le par défaut IIS components associated avec le [basic "Web Server (IIS)" server role](http://technet.microsoft.com/en-us/library/cc753473.aspx).
-
Vous devriez *absolutely* enable [long caching headers for the static content](http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache). The general recommendation is 31 days, mais you can set it higher ou lower. Remember, si you serve static content avec long cache headers, alors you must changez le URL si you changez le file, to avoid old cached content being re-used by le clients.
-
You *should* enable HTTP keep-alive (same docs as caching headers).
De plus to this, there are pre-deployement tasks, such as [whitespace compressing the Javascript and CSS](http://coderjournal.com/2010/01/yahoo-yui-compressor-vs-microsoft-ajax-minifier-vs-google-closure-compiler/), et [ideally compress PNG's better](http://www.smushit.com/ysmush.it/), etc. Ceci est were votre development tools et build cycle helps decide how to proceed.
When you're done, try downloading a peu de files depuis votre [static servers with YSlow enabled](http://developer.yahoo.com/yslow/). I find that le ["Classic V2" ruleset](http://developer.yahoo.com/yslow/help/#guidelines) gives le biggest impact for le effort, so Je suggérerais check votre score against this YSlow ruleset.
Of le "Classic V2" ruleset, these rules apply cleanly to votre static server IIS instances & content:
```
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
```