改善 Web 2.0 应用程序的性能

探秘不同的浏览器端缓存机制

随着 Web 2.0 应用程序的出现和流行,人们使用 Internet 的方式已经悄然改变。现在,这些 Web 2.0 应用程序拥有许多典型的特征,包括拥有富客户端、大页面、包含许多小项目的页面、大量的 JavaScript 编码等等。鉴于目前的浏览器技术,大部分这些特征都会导致浏览器端性能问题,特别是在长距离网络中。本文将分析典型 Web 2.0 应用程序的关键方面,并介绍它们如何影响浏览器端性能。本文还将检查浏览器端性能的一个非常重要的部分 —— 浏览器端缓存。

Jian Qiao Sun, 软件工程师, WSO2 Inc

//www.ibm.com/developerworks/i/p-jqsun.jpgJian Qiao Sun 是一位 WPLC 性能工程师。



Hua Pin Shen, 顾问软件工程师, WSO2 Inc

//www.ibm.com/developerworks/i/p-hpshen.jpgHua Pin Shen 是一位 WPLC 高级性能工程师。



2010 年 2 月 25 日

简介

随着 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 表明在不同的情形下,浏览器是将请求重新发送到服务器还是使用缓存的内容。

表 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 秒后,浏览器重新发送请求到服务器

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. 当用户打开一个新的浏览器窗口时的失效操作
Firefox 3.5IE 8Chrome 3Safari 4
内容没有失效浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 200浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面
内容失效浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200
表 4. 当用户在原始浏览器窗口中单击 Enter 按钮时的失效操作
Firefox 3.5IE 8Chrome 3Safari 4
内容没有失效浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304
内容失效浏览器重新发送请求到服务器。返回代码是 200浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200
表 5. 当用户按 F5 键刷新页面时的失效操作
Firefox 3.5IE 8Chrome 3Safari 4
内容没有失效浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304
内容失效浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200
表 6. 当用户单击 Back 或 Forward 按钮时的失效操作
Firefox 3.5IE 8Chrome 3Safari 4
内容没有失效浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面
内容失效浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 200

注意:所有浏览器都假定为使用默认设置运行。

Last-Modified/E-Tag

Last-Modified 实体头部字段值通常用作一个缓存验证器。简单来说,如果实体值在 Last-Modified 值之后没有被更改,则认为该缓存条目有效。ETag 响应头部字段值是一个实体标记,它提供一个 “不透明” 的缓存验证器。这可能在以下几种情况下提供更可靠的验证:不方便存储修改日期;HTTP 日期值的 one-second 解决方案不够用;或者原始服务器希望避免由于使用修改日期而导致的某些冲突。

不同的浏览器有不同的配置行为。表 7-10 表明针对不同用户操作的不同浏览器的行为。

表 7. 当用户打开一个新的浏览器窗口时的 Last-Modified E-Tag 操作
Firefox 3.5IE 8Chrome 3Safari 4
内容自上次访问以来没有被修改浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200
表 8. 当用户在原始浏览器窗口中单击 Enter 按钮时的 Last-Modified E-Tag 操作
Firefox 3.5IE 8Chrome 3Safari 4
内容自上次访问以来没有被修改浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改浏览器重新发送请求到服务器。返回代码是 200浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200
表 9. 当用户按 F5 键刷新页面时的 Last-Modified E-Tag 操作
Firefox 3.5IE 8Chrome 3Safari 4
内容自上次访问以来没有被修改浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200
表 10. 没有缓存设置且用户单击 Back 或 Forward 按钮
Firefox 3.5IE 8Chrome 3Safari 4
内容自上次访问以来没有被修改浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面
内容自上次访问以来已经被修改浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器重新发送请求到服务器。返回代码是 200

注意:所有浏览器都假定使用默认设置运行。

不进行任何缓存相关设置

如果您不定义任何缓存相关设置,则不同的浏览器有不同的行为。有时,同一个浏览器在相同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外,有些不该缓存的内容如果被缓存,将会导致安全问题。

不同的浏览器有不同的行为。表 11 展示了不同的浏览器行为。

表 11. 没有缓存设置且用户打开一个新的浏览器窗口
Firefox 3.5IE 8Chrome 3Safari 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
有两行用红色标识:'Last-Modified Tue, 13 Oct 2009 05:48:08 GMT' 和 'Cache-Control public, must-revalidate, max-age=5'

首先,Cache-Control 覆盖 Last-Modified 设置,因此页面可以在本地缓存 5 秒钟,但如果内容失效将重新验证。当用户访问这个页面时,浏览器首先检查本地缓存,以确定本地文件是否已经失效。如果内容失效,浏览器将发送一个请求到服务器以比较 Last-Modified 时间戳。如果响应文件拥有相同的 Last-Modified 时间戳,则服务器将返回代码 304 到浏览器,告知浏览器响应文件相同。

图 3. My developerWorks 博客主页 Response Header 2
来自 My developerWorks Blog 页面的细节,以下内容用红色标识:'Cache-Control no-cache, max-age=0'

这个 Cache-Control 设置表明:这个响应不能被缓存。从业务角度看,这个请求用于检查用户验证和授权,不应该被缓存。

图 4. My developerWorks 博客主页 Response Header 3
以下行用红色标识:'Cache-Control public, max-age=86400' 和 'Last-Modified Sun, 15 Feb 2009 21:48:46 GMT'

这个响应文件是一个很少修改的 JavaScript 库,因此它的 max-age 等于 1 天。

Mashup Center

Mashup Center 设计用于提供一个易于使用的 mashup 解决方案,支持将多个动态情景应用程序集合到一个业务范围中,并提供 IT 所需的安全和治理功能。Mashup Center 包含 Lotus Mashups 和 InfoSphere MashupHub。图 5 展示了正在运行的 Lotus Mashups 的快照。

图 5. Mashup 主页
一个页面的 Lotus Mashup 分析,顶部是一个公园信息数据查看器,下面是 3 个并排显示的示例图表

图 6 和图 7 展示了选中的 HTTP 头部。

图 6. Mashup 主页 Response Header 1
来自 Mashup Home Response Header 1 的反馈,其中 'Expires Wed, 14 Oct 2009 07:56:36 GMT' 和 'Cache-Control public, max-age=86400' 以红色标识

这个请求检索可以从服务器缓存的主题信息。

图 7. Mashup 主页 Response Header 2
'Set-Cookie JSESSIONID=0000Fqxf-SY3wIX3UbLOD-Mv0_7:~1; Path=/' 'Expires Thu, 01 Dec 1994 16:00:00 GMT' 和 'Cache-Control no-cache=set-cookie, set-cookie2'

这是一个个人主页,不应该被缓存。注意,Expires 日期值设置为一个很久以前的日期,以便这个页面总是能够刷新。

结束语

由于不同浏览器的复杂性,适当的缓存设置非常重要。在本文中,我们介绍了以下最佳实践:

  • 尽可能多地缓存文件,以便减少加载次数并改善性能。
  • 尽可能使用 cache-control 定义缓存行为,尤其是对 IE。这降低了不同浏览器之间的差别,是改善性能的最佳方法。
  • 不要使用 “no settings related with cache”。
  • 使用默认设置初次打开 IE 时,IE 浏览器几乎总是发送一个请求到服务器端以检索数据。
  • 如果某个页面不应该被缓存,则使用 “cache-control: no-cache, no-store” 来确保该页面不会被缓存,尤其是当数据涉及安全或敏感信息时。
  • 除非必要,不要使用 post 请求,因为它不能被缓存。

参考资料

学习

获得产品和技术

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Web development
ArticleID=469710
ArticleTitle=改善 Web 2.0 应用程序的性能
publish-date=02252010