改善 Web 2.0 应用程序的性能
2010-03-02 17:09
363 查看
http://www.ibm.com/developerworks/cn/web/wa-aj-cache/
简介
随着 Web 2.0 应用程序的出现和流行,Internet 的使用方式已经发生改变,出现了一种新趋势:针对内容管理、信息共享、通信、团队合作等创建一种更加以用户为中心的方法。从技术角度看,Web 2.0 应用程序并没有带来很多新的技术突破。但是,这些应用程序的确带来了一种新的 Internet 使用模式。现在,Web 2.0 应用程序拥有许多典型特征,包括拥有富客户端、大页面、包含许多小项目的页面、大量的 JavaScript 编码等等。这些特征会导致浏览器端性能问题,特别是在长距离网络中。这些性能问题会对用户体验造成不利影响,但您甚至不会意识到这些问题的存在。由于开发人员拥有很好的网络条件,因此这些性能问题很难完全暴露出来。
本文将首先分析典型的 Web 2.0 应用程序的关键方面,解释它们如何影响浏览器端性能。然后,本文介绍浏览器端性能的一个非常重要的部分 —— 浏览器缓存。通过使用适当的缓存设置,您可以向用户提供较好的应用程序体验。如果您没有一个整体缓存策略设计,那么您的缓存策略不仅会导致低劣的性能,还会引发一些功能缺陷。
有许多影响浏览器缓存的规则,其中的部分规则包括 Cache-Control、Etag、Expires、Last-Modified 和 Vary。所有这些设置拥有不同的含义和最适用的情形。困难之处在于对于相同的设置,并不是所有流行浏览器都拥有相同的行为。因此,在您决定使用这些设置之前,您应该准确了解这些浏览器是如何工作的。本文将检查目前市面上最流行的浏览器的行为:Internet Explorer、Firefox、Chrome 和 Safari。
在本文中,我们还使用 IBM® Mashups 和开源 “Roller Weblogger” 来提供一些示例,展示如何应用不同的指令以最好地使用浏览器缓存。
背景
在当今的 Internet 环境中,Web 2.0 应用程序正在变得越来越流行。许多 Web 站点都使用 Web 2.0 构建,比如 Facebook、Youtube 等。IBM 也有 Web 2.0 应用程序,比如 Lotus Connections 和 Lotus Mashups。
以下是一种用于计算浏览器响应时间的基本方法:
浏览器响应时间 = 服务器端时间 + 页面加载时间 + 浏览器呈现时间
页面加载时间 = (请求数 / 并发数)* 延迟时间 + 页面总大小 / 带宽
在上述等式中:
“服务器端时间” 是指服务器端处理所花费的时间,比如通过 LDAP 验证和从数据库检索信息。
“浏览器呈现时间” 是指浏览器呈现页面所花费的时间,包括执行 JavaScript 和解析 DOM 树的时间。
“请求数” 是指 HTTP 请求的数量。
“并发数” 是指浏览器与服务器之间的并行连接的数量。
“页面总大小” 是指一个页面的完整大小。
“延迟时间” 和 “带宽” 是网络状态指标。在常见的长距离网络环境中,带宽大约为 1M,延迟时间大约为 100 毫秒。因此,减少到 100KB 或减少为一个请求能够节约 0.1 秒响应时间。
请注意一点,鉴于真实环境的复杂性,这个等式可能不能涵盖所有情形。
在一个典型的 Web 2.0 富 Internet 应用程序(例如 Lotus Mashup Maker)中,浏览器首先发送格式定义请求到服务器。接收到定义响应数据后,浏览器向服务器发送数据请求。然后,浏览器对用户呈现页面。在这种模式中,有大量的小项目请求,比如 JavaScript 文件、CSS 文件等。在长距离网络环境中,这会导致严重影响用户体验的客户端性能问题。大多数文件是可以被缓存的静态文件,因此,如果您添加适当的缓存控件、expiry 头部以及其他影响浏览器缓存的头部元数据,就可以明显改善用户体验。
浏览器缓存机制
有几个影响浏览器缓存的规则,这个小节将分别讨论它们。
Cache-Control
Cache-Control 是最重要的规则。这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通常覆盖默认缓存算法。缓存指令是单向的,即请求中存在一个指令并不意味着响应中将存在同一个指令。
cache-control 定义是:Cache-Control = "Cache-Control" ":" cache-directive。表 1 展示了适用的值。
表 1. 常用 cache-directive 值
表 2 表明在不同的情形下,浏览器是将请求重新发送到服务器还是使用缓存的内容。
表 2. 对 cache-directive 值的浏览器响应
Cache-Control 是关于浏览器缓存的最重要的设置,因为它覆盖其他设置,比如 Expires 和 Last-Modified。另外,由于浏览器的行为基本相同,这个属性是处理跨浏览器缓存问题的最有效的方法。
失效
Expires 头部字段提供一个日期和时间,响应在该日期和时间后被认为失效。失效的缓存条目通常不会被缓存(无论是代理缓存还是用户代理缓存)返回,除非首先通过原始服务器(或者拥有该实体的最新副本的中介缓存)验证。(注意:cache-control max-age 和 s-maxage 将覆盖 Expires 头部。)
Expires 字段接收以下格式的值:“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看内容时的日期在给定的日期之前,则认为该内容没有失效并从缓存中提取出来。反之,则认为该内容失效,缓存将采取一些措施。表 3-6 表明针对不同用户操作的不同浏览器的行为。
表 3. 当用户打开一个新的浏览器窗口时的失效操作
表 4. 当用户在原始浏览器窗口中单击 Enter 按钮时的失效操作
表 5. 当用户按 F5 键刷新页面时的失效操作
表 6. 当用户单击 Back 或 Forward 按钮时的失效操作
注意:所有浏览器都假定为使用默认设置运行。
Last-Modified/E-Tag
Last-Modified 实体头部字段值通常用作一个缓存验证器。简单来说,如果实体值在 Last-Modified 值之后没有被更改,则认为该缓存条目有效。ETag 响应头部字段值是一个实体标记,它提供一个 “不透明” 的缓存验证器。这可能在以下几种情况下提供更可靠的验证:不方便存储修改日期;HTTP 日期值的 one-second 解决方案不够用;或者原始服务器希望避免由于使用修改日期而导致的某些冲突。
不同的浏览器有不同的配置行为。表 7-10 表明针对不同用户操作的不同浏览器的行为。
表 7. 当用户打开一个新的浏览器窗口时的 Last-Modified E-Tag 操作
表 8. 当用户在原始浏览器窗口中单击 Enter 按钮时的 Last-Modified E-Tag 操作
表 9. 当用户按 F5 键刷新页面时的 Last-Modified E-Tag 操作
表 10. 没有缓存设置且用户单击 Back 或 Forward 按钮
注意:所有浏览器都假定使用默认设置运行。
不进行任何缓存相关设置
如果您不定义任何缓存相关设置,则不同的浏览器有不同的行为。有时,同一个浏览器在相同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外,有些不该缓存的内容如果被缓存,将会导致安全问题。
不同的浏览器有不同的行为。表 11 展示了不同的浏览器行为。
表 11. 没有缓存设置且用户打开一个新的浏览器窗口
注意:所有浏览器都假定使用默认设置运行。
应用示例
本小节提供几个 Web 站点分析示例,展示如何使用 IBM 商业和开源工具确定正确的缓存行为。
Apache Roller Weblogger
Apache Roller Weblogger 是一个开源 Web 2.0 Web 应用程序,它是驱动 blogs.sun.com、blog.usa.gov、IBM Lotus Connections、IBM Developer Works 博客等大量博客的开源 Java™ 博客服务器,
在本文中,我们选择 IBM My developerWorks 博客作为一个示例,详细解释缓存设置。图 1 展示了 My developerWorks 博客页面的一个屏幕截图。
图 1. My developerWorks 博客页面
这个页面有 62 个请求,多数是 png、gif、js 或其他静态文件类型。当用户首次访问这个页面时,将花费约 16 秒时间来在浏览器中显示整个页面。如果您定义正确的缓存设置,多数资源将被缓存到浏览器端。因此,当用户再次访问这个页面时,这个页面的请求数量将减少到 22,只需约 6 秒钟就可以加载。用户体验得到极大地改善。
现在,我们将分析一些重要的请求缓存设置。相关的 Weblogger 输出如图 2 所示。
图 2. My developerWorks 博客主页 Response Header 1
首先,Cache-Control 覆盖 Last-Modified 设置,因此页面可以在本地缓存 5 秒钟,但如果内容失效将重新验证。当用户访问这个页面时,浏览器首先检查本地缓存,以确定本地文件是否已经失效。如果内容失效,浏览器将发送一个请求到服务器以比较 Last-Modified 时间戳。如果响应文件拥有相同的 Last-Modified 时间戳,则服务器将返回代码 304 到浏览器,告知浏览器响应文件相同。
图 3. My developerWorks 博客主页 Response Header 2
这个 Cache-Control 设置表明:这个响应不能被缓存。从业务角度看,这个请求用于检查用户验证和授权,不应该被缓存。
图 4. My developerWorks 博客主页 Response Header 3
这个响应文件是一个很少修改的 JavaScript 库,因此它的 max-age 等于 1 天。
Mashup Center
Mashup Center 设计用于提供一个易于使用的 mashup 解决方案,支持将多个动态情景应用程序集合到一个业务范围中,并提供 IT 所需的安全和治理功能。Mashup Center 包含 Lotus Mashups 和 InfoSphere MashupHub。图 5 展示了正在运行的 Lotus Mashups 的快照。
图 5. Mashup 主页
图 6 和图 7 展示了选中的 HTTP 头部。
图 6. Mashup 主页 Response Header 1
这个请求检索可以从服务器缓存的主题信息。
图 7. Mashup 主页 Response Header 2
这是一个个人主页,不应该被缓存。注意,Expires 日期值设置为一个很久以前的日期,以便这个页面总是能够刷新。
结束语
由于不同浏览器的复杂性,适当的缓存设置非常重要。在本文中,我们介绍了以下最佳实践:
尽可能多地缓存文件,以便减少加载次数并改善性能。
尽可能使用 cache-control 定义缓存行为,尤其是对 IE。这降低了不同浏览器之间的差别,是改善性能的最佳方法。
不要使用 “no settings related with cache”。
使用默认设置初次打开 IE 时,IE 浏览器几乎总是发送一个请求到服务器端以检索数据。
如果某个页面不应该被缓存,则使用 “cache-control: no-cache, no-store” 来确保该页面不会被缓存,尤其是当数据涉及安全或敏感信息时。
除非必要,不要使用 post 请求,因为它不能被缓存。
参考资料
学习
查看 HTTP Protocol Definition,了解基础知识。
阅读 IBM developerWorks Blogs 并加入讨论。
“Notes.net 揭秘:改善 Web 站点的性能”介绍了 Web 性能改进。
developerWorks 技术活动和网络广播:随时关注 developerWorks 技术活动和网络广播。
developerWorks Web development 专区:通过专门关于 Web 技术的文章和教程,扩展您在网站开发方面的技能。
获得产品和技术
开始使用 Apache Roller Weblogger 构建自己的博客项目。
了解关于 IBM Mashup Center 的更多信息并下载免费试用版。
简介
随着 Web 2.0 应用程序的出现和流行,Internet 的使用方式已经发生改变,出现了一种新趋势:针对内容管理、信息共享、通信、团队合作等创建一种更加以用户为中心的方法。从技术角度看,Web 2.0 应用程序并没有带来很多新的技术突破。但是,这些应用程序的确带来了一种新的 Internet 使用模式。现在,Web 2.0 应用程序拥有许多典型特征,包括拥有富客户端、大页面、包含许多小项目的页面、大量的 JavaScript 编码等等。这些特征会导致浏览器端性能问题,特别是在长距离网络中。这些性能问题会对用户体验造成不利影响,但您甚至不会意识到这些问题的存在。由于开发人员拥有很好的网络条件,因此这些性能问题很难完全暴露出来。
本文将首先分析典型的 Web 2.0 应用程序的关键方面,解释它们如何影响浏览器端性能。然后,本文介绍浏览器端性能的一个非常重要的部分 —— 浏览器缓存。通过使用适当的缓存设置,您可以向用户提供较好的应用程序体验。如果您没有一个整体缓存策略设计,那么您的缓存策略不仅会导致低劣的性能,还会引发一些功能缺陷。
有许多影响浏览器缓存的规则,其中的部分规则包括 Cache-Control、Etag、Expires、Last-Modified 和 Vary。所有这些设置拥有不同的含义和最适用的情形。困难之处在于对于相同的设置,并不是所有流行浏览器都拥有相同的行为。因此,在您决定使用这些设置之前,您应该准确了解这些浏览器是如何工作的。本文将检查目前市面上最流行的浏览器的行为:Internet Explorer、Firefox、Chrome 和 Safari。
在本文中,我们还使用 IBM® Mashups 和开源 “Roller Weblogger” 来提供一些示例,展示如何应用不同的指令以最好地使用浏览器缓存。
背景
在当今的 Internet 环境中,Web 2.0 应用程序正在变得越来越流行。许多 Web 站点都使用 Web 2.0 构建,比如 Facebook、Youtube 等。IBM 也有 Web 2.0 应用程序,比如 Lotus Connections 和 Lotus Mashups。
以下是一种用于计算浏览器响应时间的基本方法:
浏览器响应时间 = 服务器端时间 + 页面加载时间 + 浏览器呈现时间
页面加载时间 = (请求数 / 并发数)* 延迟时间 + 页面总大小 / 带宽
在上述等式中:
“服务器端时间” 是指服务器端处理所花费的时间,比如通过 LDAP 验证和从数据库检索信息。
“浏览器呈现时间” 是指浏览器呈现页面所花费的时间,包括执行 JavaScript 和解析 DOM 树的时间。
“请求数” 是指 HTTP 请求的数量。
“并发数” 是指浏览器与服务器之间的并行连接的数量。
“页面总大小” 是指一个页面的完整大小。
“延迟时间” 和 “带宽” 是网络状态指标。在常见的长距离网络环境中,带宽大约为 1M,延迟时间大约为 100 毫秒。因此,减少到 100KB 或减少为一个请求能够节约 0.1 秒响应时间。
请注意一点,鉴于真实环境的复杂性,这个等式可能不能涵盖所有情形。
在一个典型的 Web 2.0 富 Internet 应用程序(例如 Lotus Mashup Maker)中,浏览器首先发送格式定义请求到服务器。接收到定义响应数据后,浏览器向服务器发送数据请求。然后,浏览器对用户呈现页面。在这种模式中,有大量的小项目请求,比如 JavaScript 文件、CSS 文件等。在长距离网络环境中,这会导致严重影响用户体验的客户端性能问题。大多数文件是可以被缓存的静态文件,因此,如果您添加适当的缓存控件、expiry 头部以及其他影响浏览器缓存的头部元数据,就可以明显改善用户体验。
浏览器缓存机制
有几个影响浏览器缓存的规则,这个小节将分别讨论它们。
Cache-Control
Cache-Control 是最重要的规则。这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通常覆盖默认缓存算法。缓存指令是单向的,即请求中存在一个指令并不意味着响应中将存在同一个指令。
cache-control 定义是:Cache-Control = "Cache-Control" ":" cache-directive。表 1 展示了适用的值。
表 1. 常用 cache-directive 值
Cache-directive | 说明 |
---|---|
public | 所有内容都将被缓存 |
private | 内容只缓存到私有缓存中 |
no-cache | 所有内容都不会被缓存 |
no-store | 所有内容都不会被缓存到缓存或 Internet 临时文件中 |
must-revalidation/proxy-revalidation | 如果缓存的内容失效,请求必须发送到服务器/代理以进行重新验证 |
max-age=xxx (xxx is numeric) | 缓存的内容将在 xxx 秒后失效 |
表 2. 对 cache-directive 值的浏览器响应
Cache-directive | 打开一个新的浏览器窗口 | 在原窗口中单击 Enter 按钮 | 刷新 | 单击 Back 按钮 |
---|---|---|---|---|
public | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器 | 浏览器呈现来自缓存的页面 |
private | 浏览器重新发送请求到服务器 | 第一次,浏览器重新发送请求到服务器;此后,浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器 | 浏览器呈现来自缓存的页面 |
no-cache/no-store | 浏览器重新发送请求到服务器 | 浏览器重新发送请求到服务器 | 浏览器重新发送请求到服务器 | 浏览器重新发送请求到服务器 |
must-revalidation/proxy-revalidation | 浏览器重新发送请求到服务器 | 第一次,浏览器重新发送请求到服务器;此后,浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器 | 浏览器呈现来自缓存的页面 |
max-age=xxx (xxx is numeric) | 在 xxx 秒后,浏览器重新发送请求到服务器 | 在 xxx 秒后,浏览器重新发送请求到服务器 | 浏览器重新发送请求到服务器 | 在 xxx 秒后,浏览器重新发送请求到服务器 |
失效
Expires 头部字段提供一个日期和时间,响应在该日期和时间后被认为失效。失效的缓存条目通常不会被缓存(无论是代理缓存还是用户代理缓存)返回,除非首先通过原始服务器(或者拥有该实体的最新副本的中介缓存)验证。(注意:cache-control max-age 和 s-maxage 将覆盖 Expires 头部。)
Expires 字段接收以下格式的值:“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看内容时的日期在给定的日期之前,则认为该内容没有失效并从缓存中提取出来。反之,则认为该内容失效,缓存将采取一些措施。表 3-6 表明针对不同用户操作的不同浏览器的行为。
表 3. 当用户打开一个新的浏览器窗口时的失效操作
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容没有失效 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 |
内容失效 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容没有失效 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 |
内容失效 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容没有失效 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 |
内容失效 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容没有失效 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 |
内容失效 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 200 |
Last-Modified/E-Tag
Last-Modified 实体头部字段值通常用作一个缓存验证器。简单来说,如果实体值在 Last-Modified 值之后没有被更改,则认为该缓存条目有效。ETag 响应头部字段值是一个实体标记,它提供一个 “不透明” 的缓存验证器。这可能在以下几种情况下提供更可靠的验证:不方便存储修改日期;HTTP 日期值的 one-second 解决方案不够用;或者原始服务器希望避免由于使用修改日期而导致的某些冲突。
不同的浏览器有不同的配置行为。表 7-10 表明针对不同用户操作的不同浏览器的行为。
表 7. 当用户打开一个新的浏览器窗口时的 Last-Modified E-Tag 操作
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容自上次访问以来没有被修改 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 |
内容自上次访问以来已经被修改 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容自上次访问以来没有被修改 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 |
内容自上次访问以来已经被修改 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容自上次访问以来没有被修改 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 | 浏览器重新发送请求到服务器。返回代码是 304 |
内容自上次访问以来已经被修改 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
内容自上次访问以来没有被修改 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 |
内容自上次访问以来已经被修改 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器呈现来自缓存的页面 | 浏览器重新发送请求到服务器。返回代码是 200 |
不进行任何缓存相关设置
如果您不定义任何缓存相关设置,则不同的浏览器有不同的行为。有时,同一个浏览器在相同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外,有些不该缓存的内容如果被缓存,将会导致安全问题。
不同的浏览器有不同的行为。表 11 展示了不同的浏览器行为。
表 11. 没有缓存设置且用户打开一个新的浏览器窗口
Firefox 3.5 | IE 8 | Chrome 3 | Safari 4 | |
---|---|---|---|---|
打开一个新页面 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
在原始窗口中单击 Enter 按钮 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器呈现来自缓存的页面。 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
按 F5 键刷新 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
单击 Back 或 Forward 按钮 | 浏览器呈现来自缓存的页面。 | 浏览器呈现来自缓存的页面。 | 浏览器重新发送请求到服务器。返回代码是 200 | 浏览器重新发送请求到服务器。返回代码是 200 |
应用示例
本小节提供几个 Web 站点分析示例,展示如何使用 IBM 商业和开源工具确定正确的缓存行为。
Apache Roller Weblogger
Apache Roller Weblogger 是一个开源 Web 2.0 Web 应用程序,它是驱动 blogs.sun.com、blog.usa.gov、IBM Lotus Connections、IBM Developer Works 博客等大量博客的开源 Java™ 博客服务器,
在本文中,我们选择 IBM My developerWorks 博客作为一个示例,详细解释缓存设置。图 1 展示了 My developerWorks 博客页面的一个屏幕截图。
图 1. My developerWorks 博客页面
这个页面有 62 个请求,多数是 png、gif、js 或其他静态文件类型。当用户首次访问这个页面时,将花费约 16 秒时间来在浏览器中显示整个页面。如果您定义正确的缓存设置,多数资源将被缓存到浏览器端。因此,当用户再次访问这个页面时,这个页面的请求数量将减少到 22,只需约 6 秒钟就可以加载。用户体验得到极大地改善。
现在,我们将分析一些重要的请求缓存设置。相关的 Weblogger 输出如图 2 所示。
图 2. My developerWorks 博客主页 Response Header 1
首先,Cache-Control 覆盖 Last-Modified 设置,因此页面可以在本地缓存 5 秒钟,但如果内容失效将重新验证。当用户访问这个页面时,浏览器首先检查本地缓存,以确定本地文件是否已经失效。如果内容失效,浏览器将发送一个请求到服务器以比较 Last-Modified 时间戳。如果响应文件拥有相同的 Last-Modified 时间戳,则服务器将返回代码 304 到浏览器,告知浏览器响应文件相同。
图 3. My developerWorks 博客主页 Response Header 2
这个 Cache-Control 设置表明:这个响应不能被缓存。从业务角度看,这个请求用于检查用户验证和授权,不应该被缓存。
图 4. My developerWorks 博客主页 Response Header 3
这个响应文件是一个很少修改的 JavaScript 库,因此它的 max-age 等于 1 天。
Mashup Center
Mashup Center 设计用于提供一个易于使用的 mashup 解决方案,支持将多个动态情景应用程序集合到一个业务范围中,并提供 IT 所需的安全和治理功能。Mashup Center 包含 Lotus Mashups 和 InfoSphere MashupHub。图 5 展示了正在运行的 Lotus Mashups 的快照。
图 5. Mashup 主页
图 6 和图 7 展示了选中的 HTTP 头部。
图 6. Mashup 主页 Response Header 1
这个请求检索可以从服务器缓存的主题信息。
图 7. Mashup 主页 Response Header 2
这是一个个人主页,不应该被缓存。注意,Expires 日期值设置为一个很久以前的日期,以便这个页面总是能够刷新。
结束语
由于不同浏览器的复杂性,适当的缓存设置非常重要。在本文中,我们介绍了以下最佳实践:
尽可能多地缓存文件,以便减少加载次数并改善性能。
尽可能使用 cache-control 定义缓存行为,尤其是对 IE。这降低了不同浏览器之间的差别,是改善性能的最佳方法。
不要使用 “no settings related with cache”。
使用默认设置初次打开 IE 时,IE 浏览器几乎总是发送一个请求到服务器端以检索数据。
如果某个页面不应该被缓存,则使用 “cache-control: no-cache, no-store” 来确保该页面不会被缓存,尤其是当数据涉及安全或敏感信息时。
除非必要,不要使用 post 请求,因为它不能被缓存。
参考资料
学习
查看 HTTP Protocol Definition,了解基础知识。
阅读 IBM developerWorks Blogs 并加入讨论。
“Notes.net 揭秘:改善 Web 站点的性能”介绍了 Web 性能改进。
developerWorks 技术活动和网络广播:随时关注 developerWorks 技术活动和网络广播。
developerWorks Web development 专区:通过专门关于 Web 技术的文章和教程,扩展您在网站开发方面的技能。
获得产品和技术
开始使用 Apache Roller Weblogger 构建自己的博客项目。
了解关于 IBM Mashup Center 的更多信息并下载免费试用版。
相关文章推荐
- 改善 Web 2.0 应用程序的性能
- 全面提升 Web 2.0 应用程序的性能,第 1 部分: Web 2.0 应用的性能分析概述和新的挑战
- 提高基于 Dojo 的 Web 2.0 应用程序的性能
- 全面提升 Web 2.0 应用程序的性能,第 2 部分: 页面下载时间分析
- 提高基于 Dojo 的 Web 2.0 应用程序的性能
- 全面提升 Web 2.0 应用程序的性能,第 2 部分: 页面下载时间分析
- 通过改善代码布局提高应用程序性能
- JSF 和 Ajax:使用 Rational Application Developer V7 轻松实现 Web 2.0 应用程序
- 基于ASP.NET AJAX低级动画技术开发Web 2.0应用程序
- asp.net 2.0中通过压缩ViewState改善性能
- 改善WPF应用程序性能的10大方法(转)
- Web 应用程序性能优化
- 提升 web 应用程序的性能(二)
- asp.net 2.0中通过压缩ViewState改善性能
- Web 2.0应用客户端性能问题十大根源《转载》
- ASP.NET 2.0 本地化功能:本地化 Web 应用程序的新方法
- 易于开发Web 2.0应用程序的5个PHP框架
- 细数改善WPF应用程序性能的10大方法
- 解析如何改善和优化 Web 服务器性能
- 应用程序性能的监控与改善——性能设计