前端网页提速的具体方法

前端网页提速的具体方法先说说目标, 前端优化的目标是什么, 一个字:快. 两个字:更快. 那么下面我们来看看慢的网页将会给我们带来什么:1. 慢的页面可能会网站失去更多的用户.2. 慢500ms 意味

前端网页提速的具体方法

先说说目标, 前端优化的目标是什么, 一个字:快. 两个字:更快. 那么下面我们来看看慢的网页将会给我们带来什么:

1. 慢的页面可能会网站失去更多的用户.

2. 慢500ms 意味着20的用户将放弃访问(google)

3. 慢100ms 意味着1的用户将放弃交易(amazon)

4. 慢 ???ms 意味着??的用户将放弃xx(your site)

所以我们的目标很明确, 就是要网页展现的速度更快. 方法如下:

0. 减少http 请求

我把它排在了第一点, 为啥要在第一点呢, 很简单, 因为它最重要.

如何做呢. 一般来说, 我们从变化性上把数据分成两种类型, 变和不变. 那么不变的数据可以缓存, 变化的数据不能缓存, 这是一个常识, 也就是说要减少我们的http 请求次数这个目标可以转换成把数据分为变化和不变化两个部分. 不变化的数据不需要再次请求, 这样http 请求的次数就减少了, 下面我们分点来描述将数据分类的途径.

1. 合并脚本文件

包括脚本, 样式和图片, 可以有选择的把一些Js 和css 可以合并成一个文件, 一些图片可以使用css sprites 技术. 这样做的原因是什么? 做过web 开发的人都知道,js 和css 基本是不变的, 是静态文件, 图片亦然. 那么不变的文件如果适当的合并在一起, 会有什么效果呢? 请求的次数

,

从多次变成了一次. 这样http 请求的次数就减少了. 当时合并之后, 文件体积变大了, 会影响速度吗? 答:肯定会啊, 不过这里是需要权衡的, 比如我100份静态文件, 合并成10份还是合并成1份这就得看你得具体情况了.

2. 指定Expires 或者Cache-Control

对于静态内容:设置文件头过期时间Expires 的值为“Never expire”(永不过期) 动态页面, 在代码中添加cache-control, 表示多少时间之后过期, 如:

response.setHeader("Cache-Control", "max-age=3600");

如果使用了Expires 文件头,当页面内容改变时就必须改变内容的文件名。通常是在文件内容后加版本号

这一点在企业应用的系统中也时有发生. 比如我们使用extjs 作为前端的技术,400多k 啊, 每打开一个页面都导入, 下载这个js, 够无聊的. 那么童子们可能就要问了, 静态文件为啥不用apache,lighttpd 等呢, 答, 用了又怎么样, 不设expire 或者max-age 不是一样要下载, 最好的方法是写一个filter, 再filter 中判断, 如果url 满足一定的条件(比如符合配置文件中的正则表达式), 那么就设置一个max-age, 这样就ok, 太简单了, 几行代码就可以搞定. 快哉.

3. 缓存Ajax 请求

缓存的方法同动态页面,ajax 请求需要使用get 方式,url 长度为2k(ie)限制(post请求有两个过程,1发送请求headers,2发送请求数据, 根据http 规范,get 请求只会发送一个tcp 包).--------这一段话来自yahoo, 先不管其真假, 我们从另外一个方面来考虑一下为什么最好使用get 方式, 之前有一个项目的ajax 请求使用了post 方式, 后来发现经常出错, 而且抛出了squid 的错误, 因为我们的网站使用了squid, 问题就出在这里了, 从http 协议上可以了解

,

到,method=post是指把数据提交到服务器上去, 那么squid 的一个特性是不会缓存post 请求(事实上它确实不应该缓存, 因为这样会违反http 协议中的语义), 把ajax 请求改成get 方式之后, 一切恢复如常.

4. 移除重复的js

重复的js 导入也有可能导致ie 重新加载该脚本. 没啥好说的, 照做.

5. 避免重定向

有一种经常被网页开发者忽略却往往十分浪费响应时间的跳转现象。这种现象发生在当URL 本该有斜杠(/)却被忽略掉时。这时候会返回一个301的状态码, 然后浏览器重新发起一次请求. 在企业应用里, 重定向是我们在企业应用中常用的技术, 不过用在网站项目上, 您可要小心了, 因为普通的重定向其实是server 在response header 中设置http status=302,浏览器收到之后, 判断出是302, 会重新发送一个请求, 目标地址是前一次返回中指定的地址. 在网站项目中如果可以不用重定向就别用吧. 如果您做企业应用项目,ok, 关系不大, 您就放心的”定”吧.

6. 使用cdn

让内容更靠近用户, 这有啥好说呢, 原理很简单, 就是根据用户浏览器所在机器的ip 来判断哪些服务器离用户最近, 浏览器会再次去请求这些最近的机器. 一般的cdn 服务商是通过开发自己的dns server 来达到这个目的的. 不过这个是通常情况哦, 技术实力比较高, 或者场景比较特殊的公司会开发自己的cdn. 当然不管怎么说, 使用cdn 肯定可以使页面响应更快(也包括音频, 视频, 图片, 文本文件, 等等等等)

,

7. 减小返回数据的体积

(1) 使用gzip 压缩返回数据

Gzip 压缩所有可能的文件类型是减少文件体积增加用户体验的简单方法。比如本来400k 的文件, 压缩一下之后只有50k-100k, 那么网络的流量就立刻下来了, 压缩的代价是服务器端要压缩文件, 需要消耗cpu, 浏览器需要解压文件, 也需要消耗cpu, 不过对于现代这么nb 的pc, 来说, 浏览器解压一下数据带来的cpu 消耗简直不值一提. 所以您就压吧. 不过压的时候要小心哦, 有的浏览器在特定场景下会出去一些小bug, 导致页面不正常. 比如ie6在跨域的时候可能会有些小麻烦, 把这部分数据的gzip 去掉就可以了.

(2) 最小化js 文件和css 文件

压缩js 可以使用JSMin 或者YUI Compressor, 后者同时可以压缩css, 这个也没啥好说的, 照做吧.

(3) 将css 和js 独立成外部文件

其实这一点也可以看成是区分不变数据和变化数据. 很多人喜欢在页面商写很多很多的js 和css, 这些数据其实都是不会变化的数据, 也就是说这些数据也是可以缓存在浏览器上的, 通过把它们独立成外部文件, 可以把这些数据缓存起来. 这样做看上去是增加的请求的次数, 但是由于第一次请求之后该部分数据已经被缓存, 所以第二次就无需再请求后端, 减少了网络带宽的开销.

8. 优化Cookie

(1) 减小cookie 体积

能不放就别放吧, 为啥呀,cookie 就象钥匙串, 只有出门和回家得时候才用, 但是一整天你都要

,

带在身上, 麻烦不.

(2) 合理设置Cookie 域

由于二级域名可以拿到一级域名得cookie, 那么如果, 而二级域名之间确不能相互共享cookie, 所以合理得设置cookie 得域名也可以避免无必要得带宽浪费和响应速度得增加.

(3) 设置合理的cookie 过期时间

该过期就过期, 不要让不必要的数据一直带在身上走来走去.

(4) 使用域分离

为图片或者其他静态资源文件使用子域或者建立新的独立域名(申请新的域名), 避免无必要的cookie 传输, 当然也是要在有必要得情况下, 图片类网站肯定有必要,javaeye 上得图片并没有使用域分离, 所以我们得cookie 其实会带到坛子得图片服务器上去, 每次请求图片都是如此(不过还好, 坛子里没有什么图片, 所以这方面的浪费不大).

(5) 小结

其实cookie 上得问题, 单词请求看上去也不是什么大问题, 好像是无所谓得事情, 就那么几十个byte, 至于吗, 不过大家都听说过水滴石穿, 绳锯木断的故事. 所以该做的, 我们还是要做, 正所谓, 勿以善小而不为, 勿以恶小而为之.

9. 优化浏览器加载

(1)将css 放在页面顶部加载

把样式表放在文档底部的问题是在包括Internet Explorer在内的很多浏览器中这会中止内容的有序呈现。浏览器中止呈现是为了避免样式改变引起的页面元素重绘。用户不得不面对一个空白页面。

HTML 规范清楚指出样式表要放包含在页面的区域内:“和不同,

,

只能出现在文档的区域内,尽管它可以多次使用它”。无论是引起白屏还是出现没有样式化的内容都不值得去尝试。最好的方案就是按照HTML 规范在文 档内加载你的样式表。

(2)将js 放在页面底部加载

脚本带来的问题就是它阻止了页面的平行下载。HTTP/1.1 规范建议,浏览器每个主机名的并行下载内容不超过两个。如果你的图片放在多个主机名上,你可以在每个并行下载中同时下载2个以上的文件。但是当下载脚本时,浏览器就不会同时下载其它文件了,即便是主机名不相同。

Js 放在底部加载其实并不影响浏览器展示页面, 除非用户会在js 加载完成之前就调用某个js 方法, 比如说页面刚展现到一半, 但是恰好这一半里有一部分是调用了还未下载的js, 这个时候就会出问题了, 如果童子们遇到这种情况, 可以把这部分js 先加载.

全文总结

以上这些优化点其实只是前端优化的部分内容, 不过根据80/20原则, 这些优化点已经覆盖了80的情况了, 同时前端优化其实也不是什么复杂的东西, 原理上是很简单的, 更多的是需要我们的实践, 因为我们可能会碰到各种各样的问题, 而很多的这些问题其实一般是预测不到的. 只有遇到过才知道.

说的不对的地方请大家拍砖, 或者童子们也可以把自己的经验在这里和大家分享一下. 代表其他童子表示十分的感谢.

标签: