深入探讨Web Page性能优化-web性能基础

 

深入探讨 Web Page 的性能提升

【 摘要 】 Web 性能在 Web 开发中占有非常重要的地位，一个快速的网页对于提升用户体验，提高用户黏性，具有非常重要的意义。要开发出高性能的 Web page, 需要深入了解 Web 端的原理 , 在本文中作者深入探讨了 Web Page 的性能优化技巧，本文不仅介绍了技巧，并深入了研究了使用这些技巧的原因以及机理，本文凝结互联网上众多高手的智慧和劳动 , 尤其是 Yahoo 团队在 Web page 端所做的理论分析 , 给作者以非常大的启示 , 本文有部分转载，其中也加入了大量本人的理解和实例，本文对于 Web 端性能提升具有非常重大的参考意义，是不可多得的好材料。本文可以广泛地推介给 Web 端开发人员，易于理解，并能够加强基础，一个快速如飞的网页，对开发人员来说，是非常有成就感的一件事情 , 本文首先简单介绍了 Web 基础，然后列举了多种方法进行 Web 性能优化的方法，最后列举实例，通过这些优化方法，很好地完成了 Innova Center 的性能优化。阅读完本文，并能够深刻理解，你会成为 Web 性能方面的专家。

 

【主要内容】

深入探讨Web Page 的性能提升 . 1

1 Web端性能基础 . 4

1.1 Web端性能的重要性 . 4

1.1.1 跟踪Web 页面的性能 . 4

1.1.2 Web Page的时间消耗分析 . 5

1.1.3 性能的黄金法则 . 5

1.2 HTTP基础 . 6

1.2.1 压缩 . 6

1.2.2 Keep-Alive 7

2 常用的Web Page 优化技巧以及原理 . 7

2.1 减少HTTP 请求 . 7

实例1: 在InnovaCenter 的主页采用CSS Sprites 进行图片合并 . 9

2 .2 添加Expires 头 . 12

实例 2 ： INNOVACenter 添加 Expire 头的请求和没有添加 Expires 头请求的差别 . 13

2 .3 压缩组件 . 14

实例3 INNOVA Center 采用 GZIP 压缩完成对 HTML 文档， CSS ， JavaScript 的压缩 . 15

2.4 将CSS 放在顶部 . 16

2.5 将JS 文件放在Page 的底部 . 17

2.5.1 脚本带来的问题 . 17

2.5.2 并行下载 . 17

2.5.3 脚本阻塞下载 . 19

2.6 使用外部的JavaScript 和CSS 20

2.7 减少 DNS 查询 . 21

2.8 尽早 flush 缓冲区 . 22

2.9 在集群环境中避免使用 ETag 23

2.9.1 ETag是什么 ？ . 23

2.9.2 Expires头 . 23

2.9.3条件Get 请求 . 24

2.9.4 服务如何检测缓存中的组件 . 24

2.9.5 ETag 带来的问题 . 25

2.10 使用 get 方法进行 AJAX 请求 . 25

2.11 延迟加载组件 . 26

2.12 预加载组件 . 26

2.13 减少 DOM 元素的数量 . 28

2.14 跨域分割组件 . 28

2.15 尽量减少 Iframe 的数量 . 29

2.16 在页面尽量避免组件 404 的响应 . 29

2.17 尽量减少 Cookie 的大小 . 30

2.18 尽量减少 DOM 的访问 . 30

3.    总结 . 30

 

1 Web 端性能基础

1.1 Web 端性能的重要性

在 Web 应用程序中，通常的后端优化包括 - 数据库优化设计，和内存管理。但实际上，只有 10%-20% 的最终用户响应时间是花在从 Web 服务器获取 HTML 文档并传达到浏览器中。如果希望能够有效地减少页面的响应时间，就必须关注剩余 80%-90% 的最终用户体验。

这 80%-90% 的时间花在哪里了？如何减少它？

1.1.1 跟踪 Web 页面的性能

为了知道能够改进哪些地方，我们需要了解用户的时间都花在等待哪些东西，以 公司首页 为例， IE 浏览器的 HTTPWatch 工具来查看，下载 INNOVA Center 首页时所产生的流量。每个横条都是一个 HTTP 请求 , 第一个横条 , 标有 HTML, 是对 HTML 文档的初始请求 . 浏览器解析 HTML 并开始下载页面中的组件。这里的页面中的组件，指的是页面的 img 元素， flash ， JavaScript 文件和 CSS 文件。由于第一次加载页面时，浏览器中的缓存是空的，因此所有的组件，都需要从 WEB 服务器中下载。 HTML 文档只占总响应的 5% 。用户需要花费其实的 95% 的时间中的大部分来等待组件的下载。还有一小部分时间花在解析 HTML 、脚本和 CSS 上面 :

1.1.2 Web Page 的时间消耗分析

如上图所示：整个 INNOVA Center 的主页耗时 605ms ，从发送请求到从服务器端响应，组装 HTML 到下载 HTML 文档的时间只有 61ms ，其余的时间都花在下载 js ， CSS 和图片上，还有少量的时间花在了 js 的解析上。

总的来说，一个页面从用户请求开始，到完整的页面呈现在用户面前，包含以下几个过程：

1.DNS 查找，寻址，找到目标服务器的 IP

2. 建立 HTTP 连接

3. 发送请求

4. 服务器响应，组装 HTML

5. 浏览器下载服务器端响应组装的 HTML 文档

6. 浏览器下载组件（ js ， css ， flash 和图片等）

通过刚才举出的实例，可以看出大部分的时间都花在了第 6 步：下载 js ，图片，和 css 上面了。

1.1.3 性能的黄金法则

从一个页面请求发送给服务器到服务器响应组装 HTML ，到客户端下载 HTML 所花的时间大概占用所有时间的 10%-20% 的时间，这个现象不只是出现在 Yahoo ！， Google 的主页上。而且这一统计数据适用于绝大多数网站。下面的列表得到的美国前十个网站，除了 AOL 之外，这些网站都名列美国的前十名。

Site	无缓存	完整缓存
AOL	6%	14%
Amazon	18%	14%
CNN	19%	8%
eBay	2%	8%
Google	14%	36%
MSN	3%	5%
MySpace	4%	14%
Wikipedia	20%	12%
Yahoo!	5%	12%
YouTube	3%	5%

 

所有的这些网站在获取 HTML 文档是，花费的时间都不到总响应时间的 20% 。在进行网站的性能优化时，关键是剖析当前的性能，找到哪里可以获得最大的改进。很明显，在这种情况下我们应该关注前端性能：

1. 首先，关注前端性能可以很好地提高整体性能。 如果我们可以将后端响应时间缩短一半，整体响应时间确只能 5%-10% 。而如果关注前端性能，同样是将其响应时间减少一半，则整体响应时间可以减少 40%-50%.

2. 其次，改进前端通常只需要较少的时间和资源。 而改动后端，很可能需要修改程序的架构，添加或者改动硬件，对数据库进行分布化等。

3. 前端性能调整已经被证明是可行的。 Yahoo ！有超过 50 个团队使用了这里介绍的性能优化方案并降低了最终用户的响应时间，降低幅度通常为 25% 或更高。一般来说，只需要遵循这些优化方案就能节省 25% 或更多的时间。

根据上面的三点理由，性能黄金法则 可以总结如下：

只有 10%~20% 的最终用户响应时间花在了下载 HTML 文档上。其余的 80%~90% 时间花在了下载页面中的所有组件上。

1.2 HTTP 基础

HTTP 是一种客户端 / 服务器协议，由请求和响应组成。浏览器向一个特定的 URL 发送 HTTP 请求， URL 对应的宿主服务器发回 HTTP 响应。和很多的 Internet 服务一样，该协议使用简单的纯文本形式。请求的类型有 GET,POST,HEAD,PUT,DELETE,OPTIONS 和 TRACE 。 HTTP 协议从开始 1.0 版本到现在最常用的 1.1 在性能上得到了很大的改进。下面列出几个 HTTP 的最基本知识点，这对于理解 Web Page 的优化有很大的好处：

1.2.1 压缩

目前主流的浏览器和服务器都支持压缩，也就是说 HTTP 发送到服务端的请求，服务器响应给浏览器的 HTML 文本，由服务器端先压缩好，再传输给客户端，客户端再进行解压缩。

这样 HTML 文本在网络传输过程中，大大减少了其大小，目前如 Apache 服务器，可以支持 HTML 文本的压缩率可达到 80% ，这个基本知识点为 WEB Page 的优化提供了一个最基本的优化点。

1.2.2 Keep-Alive

HTTP 协议构建在 TCP 之上。在 HTTP 的早期实现中，每个 HTTP 都打开一个 Socket 连接。这样做效率很低，因为一个 Web 页面中的 HTTP 请求都指向同一个服务器。例如，很多为 Web 页面中的图片发起的请求都指向同一个图片服务器。持久连接的引入解决了多对以请求服务器导致的 Socket 连接低效性的问题。它是浏览器可以在一个单独的连接上进行请求。浏览器服务器使用 Connection 头来指出对 Keep - Alive 的支持。在服务器的响应中 Connection 头看起来是一样的。

浏览器或服务器可以通过发送一个 Connection : close 头来关系连接。从技术上讲： Connection ： keep - alive 并不是 HTTP1 .1 中必需的，但是很多浏览器和服务器都包含它。

HTTP1 .1 中定义的管到可以在一个单独的 socket 上发送多个请求而无须等待响应。管道的性能要优于持久连接。但不幸的是 IE 都不支持管道，而 Firefox 自从版本 2 开始默认也是关闭该功能的。在管道被广泛应用之前， Keep-Alive 依然是浏览器和服务器使用 HTTP 的 socket 连接最有效的方式。这对于 HTTPS 来说甚至更重要，因为建立新的安全 socket 连接要消耗更多的时间。