提高IIS 5.0网站服务器的执行效率的八种方法【提高iis 5.0网站服务器的执行效率的八种方法有哪些】
IIS实现反向代理
反向代理可以启用先进的URL 策略和管理技术，使不同Web 服务器系统中的网页同时存在于同一URL 空间中。
通过IIS安装反向代理可以让IIS和Apache等服务器在同一台机器上运行。 IIS和Apache都可以通过80端口访问，使网站兼容性更强。
在IIS中实现反向代理有两种方法。 IIS6通过第三方工具ISAPI Rewrite来实现反向代理。 IIS7及以后的版本可以使用微软自己的URL Rewrite和Application Request Routing来实现反向代理。
IIS6首先安装ISAPI_Rewrite3_0082.msi。安装完成后，安装Apache服务器。 Apache安装完成后，将HTTP端口设置为8080，HTTPS端口4433，IIS的HTTP端口设置为80，HTTPS端口443。IIS和Apache的端口不能冲突。
在IIS中新建一个网站，并在网站根目录下创建一个名为.htaccess的文件。内容如下。请将域名更改为您自己的域名：
重写引擎
重写兼容性2 开启
重复次数限制200
重写库
RewriteCond %{HTTP:Host} ^www.williamlong.info$
RewriteProxy (.*) http://www.williamlong.info:8080$1 [NC、P、H]
之后IIS6+Win2003成功配置了Apache的反向代理。指定的域名可以通过IIS的80端口访问，但实际网站是在Apache的8080端口，用户看不到该端口。
IIS7IIS7不需要安装第三方软件。 Microsoft 提供了自己的反向代理软件。我们可以使用微软自己的URL Rewrite和Application Request Routing来实现反向代理。
安装完以上两个插件后，重新启动IIS管理器，然后点击当前主机，你会发现两个新的图标。
单击“应用程序请求路由”图标，选择“服务器代理设置”，选中“启用代理”，然后单击右侧的“应用”。
选择需要反向代理的站点，然后选择“URL重写”，点击添加规则，选择一条空白规则，在“条件输入”中填写“{HTTP_HOST}”，模式为^www.williamlong.info$，入站规则的操作类型为“重写”，重写URL为“http://www.williamlong.info:8080{R:1}”。填写并保存后即可完成IIS7的反向代理配置。
Web性能优化
最终用户80%的响应时间用于下载各种内容。这部分时间包括下载页面中的图片、样式表、脚本、Flash等。通过减少页面中的元素数量来减少HTTP 请求数量是提高网页速度的关键步骤。
减少页面组件的方式实际上就是简化页面设计。那么有没有办法既能保持页面内容的丰富性，又能加快响应时间呢？以下是一些可以减少HTTP 请求数量同时保持页面内容丰富的技术。
1. 合并文件：合并文件是一种通过将所有脚本放入一个文件来减少HTTP 请求的方法。例如，您可以简单地将所有CSS 文件放入一个样式表中。当脚本或样式表在不同页面使用时需要进行不同的修改时，这可能会比较麻烦，但即便如此，这种方法也应该被视为提高页面性能的重要一步；
2. CSS Sprites：CSS Sprites是减少图像请求的有效方法。将所有背景图片放入一个图片文件中，然后通过CSS的background-image和background-position属性来显示图片的不同部分；
3、图片地图：图片地图将多张图片整合为一张图片。虽然文件的整体大小不会改变，但HTTP 请求的数量会减少。仅当图像的所有组件在页面上靠近在一起时（例如导航栏）才能使用图像地图。确定图像的坐标和总和可能繁琐且容易出错，并且使用图像地图导航不可读，因此不推荐这种方法；
4.内联图像：内联图像使用data:URL方案将图像数据加载到页面中，这可能会增加页面的大小。将内联图像放入样式表（可缓存）中可以减少HTTP 请求，同时避免增加页面文件大小，但主流浏览器尚不支持内联图像。
减少页面的HTTP 请求数量是优化网站性能的第一步。这是改善首次用户等待时间的最重要方法。正如Tenni Theurer 的博文《Browser Cahe Usage Exposed》 中提到的，在没有缓存的情况下，HTTP 请求占用了40% 到60% 的响应时间。改进HTTP 请求将为首次访问您网站的用户提供更快的体验。
域名系统（DNS）提供了域名和IP之间的对应关系，就像电话簿中人名和电话号码的对应关系一样。当您在浏览器地址栏中输入www.52maomao.info时，DNS解析服务器将返回该域名对应的IP地址。 DNS解析的过程也需要时间。一般情况下，返回给定域名对应的IP地址需要20到120毫秒的时间，在这个过程中，浏览器不会做任何事情，直到DNS搜索完成。
缓存DNS 查找可以提高页面性能。这种缓存需要特定的缓存服务器，该服务器一般由用户的ISP提供商或局域网控制，但它也会在用户使用的计算机上生成缓存。 DNS 信息将保留在操作系统的DNS 缓存中（Microsoft Windows 系统中的DNS 客户端服务）。大多数浏览器都有自己的缓存，独立于操作系统。由于浏览器有自己的缓存记录，因此在请求期间不受操作系统的影响。
Internet Explorer 默认缓存DNS 查找记录30 分钟，其注册表中的键值为DnsCacheTimeout。 Firefox的DNS查找记录缓存时间为1分钟，其配置文件中的选项为network.dnsCacheExpiration（Fasterfox将此选项更改为1小时）。
跳转是使用301和302代码实现的。以下是响应代码为301 的HTTP 标头：
HTTP/1.1 301 永久移动
位置： http://52maomao.info/demo
内容类型： 文本/html
浏览器会将用户指向位置中指定的URL。跳转时需要头文件中的所有信息，内容部分可以为空。尽管名称如此，但301 和302 响应不会被缓存，除非添加额外的标头选项（例如Expires 或Cache-Control）来指定对其进行缓存。
肉/元素的刷新标签和JavaScript也可以实现URL跳转，但如果一定要跳转，最好的办法是使用标准的3XX HTTP状态码。这主要是为了保证“后退”按钮能够正确使用。
但请记住，重定向会降低用户体验。在用户和HTML 文档之间添加跳转会延迟页面中所有元素的显示，因为在加载HTML 文件之前不会下载任何文件（图像、Flash 等）。
有一种跳转现象常常被Web开发者忽视，却常常浪费响应时间。当URL 应该有斜杠(/) 但被忽略时，就会出现这种现象。例如，当我们要访问http: //astrology.yahoo.com/astrology时，实际返回的是一个包含301代码的跳转，它指向http://astrology.yahoo.com/astrology/（注意最后的斜杠）。在Apache服务器中，可以使用Alias或mod_rewrite或DirectorySlash来避免这种情况。
将新网站连接到旧网站是另一种经常使用跳转功能的情况。这种情况下，往往需要将网站的不同内容连接起来，然后根据不同类型的用户（如浏览器类型、用户账户类型）进行跳转。使用跳转在两个网站之间进行切换非常简单，所需的代码量也不多。虽然使用这种方法降低了开发人员的复杂性，但也降低了用户体验。
另一种方法是使用Alias 和mod_rewrite（如果两者位于同一服务器上）。如果由于域名不同而导致重定向，可以使用Alias 或mod_rewirte 创建CNAME（保存一个域名与另一个域名之间关系的DNS 记录）来代替。
Ajax 经常提到的好处之一是，由于其从后端服务器传输信息的异步特性，它可以为用户带来即时反馈。然而，使用Ajax 并不能保证用户不会花时间等待异步javascript 和XML 响应。
在许多应用程序中，用户是否需要等待响应取决于如何使用Ajax。例如，在基于Web 的电子邮件客户端中，用户必须等待Ajax 返回符合其条件的电子邮件查询结果。重要的是要记住“异步”并不意味着“立即”。
为了提高性能，优化Ajax 响应非常重要。提高Ajxa 性能最重要的方法是使响应可缓存。有关详细讨论，请参阅《Add an Expires or a Cache-Control Header》。其他一些规则也适用于Ajax：
1.gizp压缩文件；
2.减少DNS查找次数；
3. 简化JavaScript；
4、避免跳跃；
5. 配置ETag。
让我们看一个例子：Web 2.0 电子邮件客户端将使用Ajax 自动下载用户的地址簿。如果用户自上次使用电子邮件Web 应用程序以来没有对地址簿进行任何更改，并且Ajax 响应通过Expire 或Cacke-Control 标头进行缓存，则可以直接从上次缓存中读取地址簿。必须告知浏览器是使用缓存的地址簿还是发送新请求。这可以通过在读取地址簿的Ajax URL 中添加包含上次编辑时间的时间戳来实现，例如t=11900241612 等。如果地址簿自上次下载后尚未编辑过，则时间戳保持不变并从浏览器的缓存中加载，从而消除一次HTTP 请求。如果用户修改了地址簿，则使用时间戳来确定新的URL 与缓存的响应不匹配，浏览器将请求更新地址簿。
即使您的Ajxa 响应是动态生成的，即使它仅适用于一个用户，也应该对其进行缓存。这样做将使您的Web 2.0 应用程序更快。
您可以仔细查看您的网页并问自己：“页面渲染必须首先加载哪些内容？可以稍后加载哪些内容和结构？”
要根据onload 事件将整个过程分为两部分，JavaScript 是一个理想的选择。例如，如果您有实现拖放和动画的JavaScript，它将等待稍后加载，因为页面上的拖放元素是在初始渲染之后发生的。其他内容，例如隐藏部分（仅在用户操作后出现的内容）和折叠部分中的图像也可以推迟。
工具可以节省你的工作：YUI Image Loader 可以帮助你延迟加载折叠部分的图像，YUI Get 实用程序是包含js 和CSS 的便捷方法。例如，您可以打开Firebug 的Net 选项卡来查看Yahoo 的主页。
性能目标和其他网站开发实践保持一致时可以相互补充。这种情况下，通过程序提升网站性能的方法告诉我们，如果支持JavaScript，可以先去掉用户体验，但这必须保证你的网站在没有JavaScript的情况下也能正常运行。确保页面运行正常后，加载脚本即可实现拖放、动画等更多奇特效果。
预加载和后加载可能看起来完全相反，但实际上预加载是用来实现另一个目标的。预加载是在浏览器空闲时，请求将来可能使用的页面内容（例如图像、样式表和脚本）。使用这种方法，当用户要访问下一个页面时，页面中的大部分内容已经加载到缓存中，因此可以大大提高访问速度。
下面提供了几种预加载方法：
无条件加载：当触发onload事件时，直接加载额外的页面内容。以Google.com为例，可以看看onload中它的spirit image是如何加载的。 google.com 主页上不需要此精神图像，但可以在搜索结果页面上使用它。
条件加载：根据用户的操作，基本确定用户接下来可能会进入的页面，并相应地预加载页面内容。在search.yahoo.com 中，您可以看到在您键入时如何加载其他页面内容。
预期加载：加载重新设计的页面时使用预加载。这种情况经常发生在用户抱怨页面重新设计后“新页面看起来很酷，但速度比以前慢”时。问题可能是用户对旧网站有完整的缓存，但对新网站没有缓存内容。因此，您可以通过在访问新站点之前加载一段内容来避免这种结果。在旧站点中，利用浏览器的空闲时间加载新站点中使用的图像和脚本，以提高访问速度。
复杂的页面意味着需要下载更多的数据，这也意味着JavaScript 遍历DOM 的速度会更慢。例如，当您添加事件处理程序时，循环遍历500 个和5000 个DOM 元素的效果肯定会有所不同。
大量DOM 元素的存在意味着页面的某些部分可以精简，而无需删除内容并简单地替换元素标签。您在页面布局中使用表格吗？您是否曾为了布局而引入更多的div 元素？可能有一个标签适合您使用或者在语义上更适合您使用。
YUI CSS实用程序可以给你的布局带来很大的帮助：grids.css可以帮助你实现整体布局，而font.css和reset.css可以帮助你去除浏览器默认格式。它提供了重新访问页面中标签的机会，例如仅在语义上有意义时才使用div，而不是因为它具有断行效果而使用它。
DOM元素的数量很容易计算，只需在Firebug控制台中输入：
document.getElementsByTagName('*').length
那么多少个DOM 元素就太多了呢？这可以与具有良好标记使用的类似页面进行比较。例如，雅虎！首页是一个内容很多的页面，但是它只使用了700个元素（HTML标签）。
将页面内容划分为多个部分可以让您最大限度地提高并行下载速度。由于DNS查找的影响，您首先需要确保您使用的域名数量在2到4之间。例如，您可以将www.52maomao.info上使用的HTML内容和动态内容放在statics1.52maomao.info和statics.52maomao.info上，并将页面的各种组件（图像，脚本，CSS）分别存储在statics1.52maomao.info和statics.52maomao.info上。
ifrmae 元素将新的HTML 文档插入到父文档中。了解iframe 的工作原理非常重要，这样您才能更有效地使用它们。
iframe 优点：
1.解决图标、广告等第三方内容加载缓慢的问题；
2、安全沙箱；
3. 并行加载脚本。
iframe的缺点：
1、即时内容为空，加载需要时间；
2. 会阻止页面加载；
3.没有语义意义。
HTTP请求时间消耗非常大，因此使用HTTP请求得到无用的响应（例如404 Page Not Found）是完全没有必要的。只会降低用户体验，没有任何好处。
有些网站将404错误响应页面更改为“您正在寻找***吗？”这样虽然提高了用户体验，但是也浪费了服务器资源（比如数据库等）。最坏的情况是外部JavaScript 的链接出现故障并返回404 代码。首先，这种加载会破坏并行加载；其次，浏览器会尝试在返回的404 响应内容中寻找潜在有用的部分作为JavaScript 代码来执行。
用户与网站服务器的距离会影响响应时间。将您的网站内容分布在不同地理位置的多个服务器上可以加快下载速度。但我们首先应该做什么呢？
在地理位置上安排网站内容的第一步不是尝试重新构建网站以使它们在分发服务器上正常运行。根据应用程序的需要更改网站结构，这可能包括一些更复杂的任务，例如同步服务器之间的会话状态和合并数据库更新。为了缩短用户和内容服务器之间的距离，这些架构步骤可能是不可避免的。
请记住，80% 到90% 的最终用户响应时间用于下载页面内容，例如图像、样式表、脚本、Flash 等。这是网站性能的黄金法则。与其承担重新构建应用程序的更困难的任务，不如先分发静态内容。这不仅可以缩短响应时间，而且还可以更轻松地在内容交付网络中实施。
内容分发网络（CDN）由一系列分散在不同地理位置的Web服务器组成。它提高了网站内容的传输速度。用于向用户传送内容的服务器主要是根据它们在网络上与用户的距离来指定的。例如，将选择网络跳数最少且响应时间最快的服务器。
一些大型互联网公司拥有自己的CDN，但使用Akamai Technologies、Mirror Image Internet 或Limelight Networks 等CDN 服务非常昂贵。对于刚刚起步的企业和个人网站来说，他们可能没有使用CDN的成本预算，但随着目标用户群不断扩大并变得更加全球化，CDN对于实现快速响应是必要的。以雅虎为例，他们将网站程序的静态内容转移到CDN上，节省了最终用户20%以上的响应时间。使用CDN是一种比较简单的方法，只需修改代码即可显着提高网站访问速度。
这段代码包括两个方面：
对于静态内容：将文件头过期时间Expires值设置为“Never expire”（永不过期）；
对于动态内容：使用适当的Cache-Control 标头来帮助浏览器发出条件请求。
网页内容设计越来越丰富，这意味着页面必须包含更多的脚本、样式表、图片和Flash。用户第一次访问您的页面意味着发出多个HTTP 请求，但您可以使用Expires 文件标头使该内容可缓存。它避免了后续页面访问时不必要的HTTP 请求。 Expires 标头通常用于图像文件，但它应该用于所有内容，包括脚本、样式表、Flash 等。
浏览器（和代理）使用缓存来减少HTTP 请求的大小和数量，以加快页面访问速度。 Web 服务器使用HTTP 响应中的Expires 标头来告诉客户端内容需要缓存多长时间。下面的示例是一个较长的Expires 文件头，它告诉浏览器此响应直到2010 年4 月15 日才会过期。
过期日期：2010 年4 月15 日，星期四： 20:00:00 GMT
如果您使用的是Apache 服务器，则可以使用ExpiresDefault 设置相对于当前日期的过期时间。
以下示例使用ExpiresDefault 设置在请求时间10 年后过期的文件标头：
过期默认“访问权限加10 年”
请记住，如果使用Expires 文件头，则必须在页面内容更改时更改内容的文件名。嘿，对于Yahoo!我们经常使用这一步：将版本号yahoo_2.0.6.js 添加到内容的文件名中。
仅当用户已经访问过您的网站时，使用Expires 标头才有效。当用户第一次访问您的网站时，这对于减少HTTP 请求数量是无效的，因为浏览器的缓存是空的。因此，使用此方法对网站性能的提高取决于页面“预缓存”存在时（“预缓存”已包含页面上的所有内容）时的点击频率。雅虎！建立了一套测量方法，我们发现所有页面浏览量的75% 到85% 都是“预缓存”的。通过使用Expires 标头，您可以增加浏览器中缓存的内容量，并且可以在用户的后续请求中重用，甚至无需通过用户发送请求的单个字节。
通过前端机制可以显着改善网络传输中的HTTP 请求和响应时间。事实上，最终用户的带宽、互联网提供商、与对等交换点的接近程度等都不是网站开发人员可以确定的。但还有其他因素会影响响应时间。通过减小HTTP 响应的大小可以节省HTTP 响应时间。
从HTTP/1.1开始，Web客户端默认支持HTTP请求中带Accept-Encoding头的压缩格式：
Accept-Encoding: gzip、deflate
如果Web服务器在请求头中检测到上述代码，它将按照客户端列出的方式压缩响应内容。 Web服务器通过响应文件头中的Content-Encoding将压缩方式返回给浏览器。
内容编码： gzip
Gzip是目前最流行、最有效的压缩方法。这是由GNU Project 开发的，并通过RFC 1952 进行标准化。唯一的另一种压缩格式是deflate，但其使用范围有限，效果稍差。
Gzip 可以将响应大小减少大约70%。目前大约90%通过浏览器传输的互联网交换都支持gzip格式。如果您使用Apache，gzip 模块配置取决于您的版本：Apache 1.3 使用mod_zip，Apache 2.x 使用moflate。
浏览器和代理都存在这个问题：浏览器期望接收的内容与实际接收的内容之间会不匹配。幸运的是，随着旧版浏览器使用量的减少，这种特殊情况正在减少。 Apache 模块将通过自动添加适当的Vary 响应文件头来避免这种情况。
服务器根据文件类型选择需要gzip压缩的文件，但这过度限制了可以压缩的文件。大多数Web 服务器都会压缩HTML 文档。压缩脚本和样式表也值得做，但许多Web 服务器没有此功能。事实上，压缩任何文本类型的响应都是值得的，包括XML 和JSON。图像和PDF 文件无法进行gzip 压缩，因为它们已经被压缩。尝试对这些文件进行gizp 不仅会浪费CPU 资源，还会增加文件大小。
对所有可能的文件类型进行Gzip 压缩是减小文件大小和提高用户体验的简单方法。
更详细的GZIP压缩信息可以参考我的另外两篇文章：《GZIP页面压缩原理》和《WEB性能优化之GZIP压缩》
实体标签（ETag）是Web服务器和浏览器用来判断浏览器缓存中的内容是否与服务器中的原始内容相匹配的机制（“实体”就是所谓的“内容”，包括图片、脚本、样式表等）。添加ETag 为实体验证提供了比使用“上次修改日期”更灵活的机制。 Etag是标识内容版本号的唯一字符串。唯一的格式限制是它必须用双引号引起来。源服务器通过包含ETag文件头的响应来指定页面内容的ETag。
HTTP/1.1 200 好
最后修改时间： 2006 年12 月12 日星期二03:03:59 GMT
ETag:“10c24bc-4ab-457e1c1f”
内容长度： 12195
稍后，如果浏览器想要验证文件，它将使用If-None-Match 文件头将ETag 传回源服务器。在此示例中，如果ETag 匹配，将返回304 状态代码，从而节省12195 字节的响应。
获取/i/yahoo.gif HTTP/1.1
主机： love.52maomao.info
If-Modified-Since: 2006 年12 月12 日星期二03:03:59 GMT
如果-无-Match:“10c24bc-4ab-457e1c1f”
HTTP/1.1 304 未修改
ETag 的问题在于它是根据标识网站所在服务器的唯一属性生成的。当浏览器从一台服务器获取页面内容并在另一台服务器上验证时，ETag将不匹配。对于使用服务器组合来处理请求的网站来说，这种情况很常见。默认情况下，Apache和IIS都将数据嵌入到ETag中，这将显着减少多个服务器之间的文件验证冲突。
Apache 1.3 和2.x 中的ETag 格式为inode-size-timestamp。即使文件位于不同服务器上的同一目录中，文件大小、权限、时间
间戳等都完全相同，但是在不同服务器上他们的内码也是不同的。 IIS 5.0和IIS 6.0处理ETag的机制相似。IIS中的ETag格式为Filetimestamp:ChangeNumber。用ChangeNumber来跟踪 IIS配置的改变。网站所用的不同IIS服务器间ChangeNumber也不相同。 不同的服务器上的Apache和IIS即使对于完全相同的内容产生的ETag在也不相同，用户并不会接收到一个小而快的304响应；相反他们会接收一个正 常的200响应并下载全部内容。 如果你的网站只放在一台服务器上，就不会存在这个问题。但是如果你的网站是架设在多个服务器上，并且使用Apache和IIS产生默认的ETag配 置，你的用户获得页面就会相对慢一点，服务器会传输更多的内容，占用更多的带宽，代理也不会有效地缓存你的网站内容。即使你的内容拥有Expires文件 头，无论用户什么时候点击“刷新”或者“重载”按钮都会发送相应的GET请求。 如果你没有使用ETag提供的灵活的验证模式，那么干脆把所有的ETag都去掉会更好。Last-Modified文件头验证是基于内容的时间戳 的。去掉 ETag文件头会减少响应和下次请求中文件的大小。微软的这篇支持文稿讲述了如何去掉ETag。在Apache中，只需要在配置文件中简单添加下面一行代 码就可以了：FileETag none。 当用户请求一个页面时，无论如何都会花费200到500毫秒用于后台组织HTML文件。在这期间，浏览器会一直空闲等待数据返回。在PHP中，你可 以使用flush()方法，它允许你把已经编译得好的部分HTML响应文件先发送给浏览器，这时浏览器就会可以下载文件中的内容（脚本等）而后台同时处理 剩余的 HTML页面。这样做的效果会在后台烦恼或者前台较空闲时更加明显。 输出缓冲应用最好的一个地方就是紧跟在<head />之后，因为HTML的头部分容易生成而且头部往往包含CSS和JavaScript文件，这样浏览器就可以在后台编译剩余HTML的同时并行下载它们。 例子： … <!– css, js –> </head> <body> … <!– content –> 当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。因此使用 GET最为恰当，因为它只需发送一个TCP包（除非你有很多cookie）。IE中URL的最大长度为2K，因此如果你要发送一个超过2K的数据时就不能 使用GET了。 一个有趣的不同就是POST并不像GET那样实际发送数据。根据HTTP规范，GET意味着“获取”数据，因此当你仅仅获取数据时使用GET更加有意义（从语意上讲也是如此），相反，发送并在服务端保存数据时使用POST。 在研究性能表现时，我们发现把样式表放到文档的<head />内部似乎会加快页面的下载速度。这是因为把样式表放到<head />内会使页面有步骤的加载显示。 注重性能的前端服务器往往希望页面有秩序地加载。同时，我们也希望浏览器把已经接收到内容尽可能显示出来。这对于拥有较多内容的页面和网速较慢的用户来说 特别重要。向用户返回可视化的反馈，比如进程指针，已经有了较好的研究并形成了正式文档。在我们的研究中HTML页面就是进程指针。当浏览器有序地加载文 件头、导航栏、顶部的logo等对于等待页面加载的用户来说都可以作为可视化的反馈。这从整体上改善了用户体验。 把样式表放在文档底部的问题是在包括Internet Explorer在内的很多浏览器中这会终止内容的有序呈现。浏览器中止呈现是为了避免样式改变引起的页面元素重绘，用户不得不面对一个空白页面。 HTML规范清楚指出样式表要放包含在页面的<head />区域内：“和<a />不同，<link />只能出现在文档的<head />区域内，尽管它可以多次使用它”。无论是引起白屏还是出现没有样式化的内容都不值得去尝试。最好的方案就是按照HTML规范在文 档<head />内加载你的样式表。 CSS表达式是动态设置CSS属性的强大（但危险）方法。Internet Explorer从第5个版本开始支持CSS表达式。下面的例子中，使用CSS表达式可以实现隔一个小时切换一次背景颜色： background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00″ ); 如上所示，expression中使用了JavaScript表达式。CSS属性根据JavaScript表达式的计算结果来设置。 expression方法在其它浏览器中不起作用，因此在跨浏览器的设计中单独针对Internet Explorer设置时会比较有用。 表达式的问题就在于它的计算频率要比我们想象得多。不仅仅是在页面显示和缩放时，就是在页面滚动、乃至移动鼠标时都会要重新计算一次。给CSS表达式增加一个计数器可以跟踪表达式的计算频率。在页面中随便移动鼠标都可以轻松达到10000次以上的计算量。 一个减少CSS表达式计算次数的方法就是使用一次性的表达式，它在第一次运行时将结果赋给指定的样式属性，并用这个属性来代替CSS表达式。如果样 式属性必须在页面周期内动态地改变，使用事件句柄来代替CSS表达式是一个可行办法。如果必须使用CSS表达式，一定要记住它们要计算成千上万次并且可能 会对你页面的性能产生影响。 很多性能规则都是关于如何处理外部文件的。但是，在你采取这些措施前你可能会问到一个更基本的问题：JavaScript和CSS是应该放在外部文件中呢还是把它们放在页面本身之内呢？ 在实际应用中使用外部文件可以提高页面速度，因为JavaScript和CSS文件都能在浏览器中产生缓存。内置在HTML文档中的 JavaScript和CSS则会在每次请求中随HTML文档重新下载。这虽然减少了HTTP请求的次数，却增加了HTML文档的大小。从另一方面来说， 如果外部文件中的JavaScript和CSS被浏览器缓存，在没有增加HTTP请求次数的同时可以减少HTML文档的大小。 关键问题是，外部JavaScript和CSS文件缓存的频率和请求HTML文档的次数有关。虽然有一定的难度，但是仍然有一些指标可以一测量它。 如果一个会话中用户会浏览你网站中的多个页面，并且这些页面中会重复使用相同的脚本和样式表，缓存外部文件就会带来更大的益处。 许多网站没有功能建立这些指标。对于这些网站来说，最好的解决方法就是把JavaScript和CSS作为外部文件引用。比较适合使用内置代码的例 这就是网站的主页，如Yahoo!主页和My Yahoo!。主页在一次会话中拥有较少（可能只有一次）的浏览量，你可以发现内置JavaScript和CSS对于终端用户来说会加快响应时间。 对于拥有较大浏览量的首页来说，有一种技术可以平衡内置代码带来的HTTP请求减少与通过使用外部文件进行缓存带来的好处。其中一个就是在首页中内 致 JavaScript和CSS，但是在页面下载完成后动态下载外部文件，在子页面中使用到这些文件时，它们已经缓存到浏览器了。 精简是指从去除代码不必要的字符减少文件大小从而节省下载时间。消减代码时，所有的注释、不需要的空白字符（空格、换行、tab缩进）等都要去掉。 在 JavaScript中，由于需要下载的文件体积变小了从而节省了响应时间。精简JavaScript中目前用到的最广泛的两个工具是JSMin和YUI Compressor。YUI Compressor还可用于精简CSS。 混淆是另外一种可用于源代码优化的方法。这种方法要比精简复杂一些并且在混淆的过程更易产生问题。在对美国前10大网站的调查中发现，精简也可以缩 小原来代码体积的21%，而混淆可以达到25%。尽管混淆法可以更好地缩减代码，但是对于JavaScript来说精简的风险更小。 除消减外部的脚本和样式表文件外，<script>和<style>代码块也可以并且应该进行消减。即使你用Gzip压缩 过脚本和样式表，精简这些文件仍然可以节省5%以上的空间。由于JavaScript和CSS的功能和体积的增加，消减代码将会获得益处。 前面的最佳实现中提到CSS应该放置在顶端以利于有序加载呈现。 在IE中，页面底部@import和使用<link>作用是一样的，因此最好不要使用它。 IE独有属性AlphaImageLoader用于修正7.0以下版本中显示PNG图片的半透明效果。这个滤镜的问题在于浏览器加载图片时它会终止内容的呈现并且冻结浏览器。在每一个元素（不仅仅是图片）它都会运算一次，增加了内存开支，因此它的问题是多方面的。 完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替，这种格式能在IE中很好地工作。如果你确实需要使用 AlphaImageLoader，请使用下划线_filter又使之对IE7以上版本的用户无效。 脚本带来的问题就是它阻止了页面的平行下载。HTTP/1.1 规范建议，浏览器每个主机名的并行下载内容不超过两个。如果你的图片放在多个主机名上，你可以在每个并行下载中同时下载2个以上的文件。但是当下载脚本 时，浏览器就不会同时下载其它文件了，即便是主机名不相同。 在某些情况下把脚本移到页面底部可能不太容易。比如说，如果脚本中使用了document.write来插入页面内容，它就不能被往下移动了。这里可能还会有作用域的问题。很多情况下，都会遇到这方面的问题。 一个经常用到的替代方法就是使用延迟脚本。DEFER属性表明脚本中没有包含document.write，它告诉浏览器继续显示。不幸的 是，Firefox并不支持DEFER属性。在Internet Explorer中，脚本可能会被延迟但效果也不会像我们所期望的那样。如果脚本可以被延迟，那么它就可以移到页面的底部，这会让你的页面加载的快一点。 在同一个页面中重复引用JavaScript文件会影响页面的性能。你可能会认为这种情况并不多见。对于美国前10大网站的调查显示其中有两家存在 重复引用脚本的情况。有两种主要因素导致一个脚本被重复引用的奇怪现象发生：团队规模和脚本数量。如果真的存在这种情况，重复脚本会引起不必要的HTTP 请求和无用的JavaScript运算，这降低了网站性能。 在Internet Explorer中会产生不必要的HTTP请求，而在Firefox却不会。在Internet Explorer中，如果一个脚本被引用两次而且它又不可缓存，它就会在页面加载过程中产生两次HTTP请求。即时脚本可以缓存，当用户重载页面时也会产 生额外的HTTP请求。 除增加额外的HTTP请求外，多次运算脚本也会浪费时间。在Internet Explorer和Firefox中不管脚本是否可缓存，它们都存在重复运算JavaScript的问题。 一个避免偶尔发生的两次引用同一脚本的方法是在模板中使用脚本管理模块引用脚本。在HTML页面中使用<script />标签引用脚本的最常见方法就是： <script type=”text/javascript” src=”menu_1.0.17.js”></script> 在php中可以通过创建名为insertScript的方法来替代：
用户评论
我一直用 IIS 5.0，这篇文章真的太对味了！尤其是说预热、使用缓存和调整应用程序池配置这两点，我以前经常会忽略这些细节，学习起来很实用！
有15位网友表示赞同！
IIS 5.0的网站服务器效率确实比较低，之前一直想解决这个问题但是找不到好方法，现在看到这篇文章八种方法介绍，感觉很有希望了！马上试试看。
有15位网友表示赞同！
我记得IIS 6.0的时候，优化策略有很多更便捷的方法，比如使用Windows服务组件管理工具。现在用5.0还要自己手动的调整这么多配置是不是太麻烦了？
有17位网友表示赞同！
文章写的很详细，图解也很清晰！以前一直没发现 IIS 5.0 的性能瓶颈在哪里，现在看明白了，感觉很多问题都可以解决，谢谢分享!
有9位网友表示赞同！
我目前运行的网站用IIS 5.0，有时候确实会遇到用户反馈页面加载较慢的情况。希望能通过这八种方法优化，提升网站运行速度，提高用户体验。
有15位网友表示赞同！
提高IIS 5.0 的执行效率真是个宝贵的经验！ 我现在有个项目用到IIS 5.0，感觉有点卡顿，学习这篇文章或许能帮到我!
有13位网友表示赞同！
看到一篇关于 IIS 5.0 文章，想看看有没有解决性能问题的方法。文章说要开启预热机制，我之前也做了这个操作，但效果似乎并不明显，不知道是不是我的配置不对？
有15位网友表示赞同！
还是老方法管用啊！IIS 5.0 优化虽然麻烦点，但是只要掌握八种方法的技巧，就能有效提升网站性能。以后遇到类似问题就知道该怎么处理了。
有14位网友表示赞同！
这篇文章真是太有用了！我以前尝试过一些方法来提高 IIS 5.0 的速度，却一直没找到合适的方案。现在有了文章的指导，相信我能解决这个问题，让我的网站跑得更快!
有12位网友表示赞同！
文章里提到的“调整应用程序池配置”和 “优化数据库连接”， 我不太理解具体的含义，希望以后作者能详细解释一下这些方法的具体操作步骤。
有19位网友表示赞同！
现在很多公司还在使用IIS 5.0，这篇文章的经验非常值得借鉴。如果可以针对不同情况分别提出解决方案那更完美了，比如对于并发访问比较高的网站...
有9位网友表示赞同！
其实IIS 5.0 的优化方法还是有很多的可研究的空间， 这八种方法只是基础入门级的操作， 如果想要进一步提升性能，还需要结合实际情况进行细化的调整和监控。
有9位网友表示赞同！
文章说的没错！预热机制确实很有效， 但要考虑网站访问模式， 预热时机也要合理调整， 否则可能会带来反效果。
有12位网友表示赞同！
IIS 5.0 的缺点很多，而且微软已经不维护了这个老版本… 建议大家直接升级到新版本，这样能摆脱这些兼容性的烦恼，同时也避免很多安全漏洞的风险！
有11位网友表示赞同！
这八种方法确实对IIS 5.0网站服务器的执行效率是有帮助， 但是想要真正达到最佳效果还需要根据实际情况进行调整， 每个站点的需求都不一样。
有14位网友表示赞同！
虽然 IIS 5.0 的性能比新的版本差很多， 但仍然有一些企业因为业务场景特殊而还在使用旧版。 希望这种类型的优化文章能能给这些企业带来一些帮助。
有14位网友表示赞同！
对于IIS 5.0网站服务器的执行效率来说， 我觉得这篇文章仅仅触及了表面， 真正的提升还需要关注代码优化、数据库性能、网络带宽等多方面因素。
有12位网友表示赞同！