web前端性能优化9大方向

最新推荐文章于 2024-02-27 09:33:31 发布

置顶 Kongkong_nana

最新推荐文章于 2024-02-27 09:33:31 发布

阅读量2.9k

点赞数

分类专栏： web开发文章标签： web 前端性能优化

web开发专栏收录该内容

11 篇文章 0 订阅

订阅专栏

摘自《高性能网站建设》

一、减少HTTP请求

通过减少组件的数量来减少HTTP请求的数量

1、图片地图

它允许在一个图片上关联多个URL，目标URL的选择取决于用户单击了图片上的哪个位置。

当使用N个分开的图片，每个图片对应一个超链接，这样就会产生N个HTTP请求，当把N张图片合并为一张的时候，然后以位置信息定位超链接，这样就只剩下一个HTTP请求，同时保证功能的准确实现。例如：

<img usemap="#map1" border=0 src="">
<map name="map1">
    <area shape="rect" coords="0,0,31,31" href="javascript:alert('Home')" title="Home">
    <area shape="rect" coords="36,0,66,31" href="javascript:alert('Gifts')" title="Gifts">
    <area shape="rect" coords="71,0,101,31" href="javascript:alert('Cart')" title="Cart">
    <area shape="rect" coords="106,0,136,31" href="javascript:alert('Settings')" title="Settings">
    <area shape="rect" coords="141,0,171,31" href="javascript:alert('Help')" title="Help">
</map>

2、CSS Sprites

简单的来讲，就是通过使用合并图片，用css中的background-image和background-position来显示元素。

在background-position中，background-position:x y;x和y可以为负可以为正。图片的左上方为(0,0)，以(0,0)坐标向右是为负数的x轴，以(0,0)坐标向下是为负数的y轴。正值的情况则以图片左下方为(0,0)，向右是为正数的x轴，向上是为正数的y轴。

例如：

<html>
<head>
    <title></title>
    <style type="text/css">
        .left{ background-image:url(2.png); background-position:0px 0px; width:18px; height:18px; }
        .right{ background-image:url(2.png); background-position:-18px 0px; width:18px; height:18px; }
        .left:hover{ background-position:0px -18px; }
        .right:hover{ background-position:-18px -18px; }
    </style>
</head>
<body>
    <div>
        <div class="left"></div>
        <div class="right"></div>
    </div>
</body>
</html>

这里推荐css sprite generator小工具，可以合并图片，可以生成图片的css样式。

综上两个：图片地图依赖于html实现，css sprite依赖css实现。

3、合并脚本和样式表

把js合并为一个文件，把css也合并为一个样式表

二、使用内容分发网络

服务器离用户越近，HTTP请求的响应时间就会更短。

CNAME：别名记录，当多个域名需要指向同一服务器IP，可以使用一个域名做A记录指向该服务器IP，然后让多个域名指向该A记录。

ICP：Internet Content Providor

DNS：Domain Name System

内容分发网络CDN：CDN是一组分布在多个不同地理位置的web服务器，通过将网站的资源发布到最接近用户的网络“边缘”，供用户就近取得所需内容。CDN可以看做是一种缓存代理，主要用于对静态资源（如image，css，js等）的缓存。

CDN网络架构：

CDN的网络架构主要分为中心和边缘两个部分，中心服务器主要负责DNS解析和全局负载均衡；而边缘服务器指异地节点，作为CDN分发的载体，包括负载均衡和高速缓存。边缘服务器的负载均衡负责缓存内容的负载均衡，保证节点的工作效率，同时还负责与中心服务器通信，实现整个系统的负载均衡。边缘服务器的高速缓存负责存储从客户源服务器获取的资源，并提供给本地用户访问。

CDN的工作原理：

除了一些大型互联网公司拥有自己的CDN，其他公司基本都会选择CDN运营商合作。
所以作为ICP，需要把域名解释权交给CDN运营商，操作时ICP修改自己的域名解析部分，一般用CNAME的方式，将自己的静态资源域名指向一个CDN提供的CNAME。
而作为CDN运营商，需要对CNAME提供专用DNS解析，同时需要维护客户服务器的域名和IP地址映射列表。

CDN工作流程：

1、浏览器获得需要访问的资源的域名；

2、通过域名解析得到该域名指向CDN的一个CNAME；

3、为了获得IP地址，需要对CNAME进行域名解析，这时请求就会被发送到CDN的中心服务器，全局负载均衡通过预先设定的规则，同时根据用户访问的地理位置，把最合适的边缘服务器IP地址返回；

4、浏览器获得IP地址后，就向边缘服务器发出请求；

5、边缘服务器根据访问域名，首先搜索缓存，查看资源是否存在，存在则直接返回资源给浏览器，直接完成整个资源请求过程，否则就根据缓存内部的DNS解析得到资源实际IP地址（即客户的服务器IP地址），向该IP地址发起资源请求；

6、边缘服务器向客户服务器请求资源成功后，就把该资源加入本身的高速缓存中，并把资源发送给用户。

CDN的简单应用

其实CDN的使用并没有和我们想象中那么遥远，JQuery应该是当今Web开发领域使用最为广泛的js框架之一，很多时候我们的网站都需要引用一个jquery.min.js的引用，我们可以将这个js文件存储在自己的服务器，或者更好的选择：使用大公司的CDN服务提供的jquery.min.js. 微软和google都提供了jquery的CDN免费服务，你只需做的事情就是在项目中引用它们，就能享受CDN带来的便利。

延伸：http://www.chinaz.com/web/2015/0309/388408.shtml

http://www.chinaz.com/web/2015/0414/398330.shtml

http://www.chinaz.com/web/2014/1112/373825.shtml

三、添加Expires头

什么是Expires头？

Expires存储的是一个用来控制缓存失效的日期。当浏览器看到响应中有一个Expires头时，它会和相应的组件一起保存到其缓存中，只要组件没有过期，浏览器就会使用缓存版本而不会进行任何的HTTP请求。Expires设置的日期格式必须为GMT。

HTTP1.1协议中缓存的另一种选择

Expires存在着明显的不足。
首先，Expires头使用的是一个特定的时间，要求客户端和服务器端的时钟严格同步。何为严格同步？我们知道客户端的时间是可以修改的，如果服务器和客户端的时间不统一，这就导致有可能出现缓存提前失效的情况，存在不稳定性。其次，假如Expires的日期到来了，那么还需要在服务器配置中提供一个新的日期。
面对这种情况，HTTP1.1引入了Cache-Control头来克服Expires头的限制。Cache-Control使用max-age制定组件被缓存多久，使用秒为单位，例如Cache-Control：max-age=3600；表示组件将被缓存60分钟。如果max-age和Expires同时出现，则max-age有更高的优先级，浏览器会根据max-age的时间来确认缓存过期时间。

Cache-Control除了可以设置max-age之外，还可以同时设置其他标签。如下图所示常用标签：

no-cache：实际上是可以存储在本地缓存中，只是在与服务器进行新鲜度再验证之前，不能提供缓存给客户端使用

no-store：表示资源既不能被放入缓存，也不能被放入磁盘中，比no-chche指令更加严格

private：默认值，表示代理服务器将不能缓存资源，只有客户端能缓存

public：表示资源任何服务器都可以缓存

max-age：确定资源的缓存时间

如何配置过期缓存？
在ASP.NET下，可以通过web.config文件来配置缓存。

<!--单独配置Expires-->
<system.webServer>
    <staticContent>
        <clientCache cacheControlMode="UseExpires" httpExpires="Sun, 29 Mar 2020 00:00:00 GMT"/><!--表示过期时间为2020年3月29号-->
    </staticContent>
</system.webServer>
<!--单独配置max-age-->
<system.webServer>
    <staticContent>
        <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:01:00"/><!--表示过期时间为（30*24*60*60+60）s后-->
    </staticContent>
</system.webServer>

四、压缩组件

gzip编码：gzip是GUNzip的缩写，是使用无损压缩算法的一种，最早是用于Unix系统的文件压缩，凭借着良好的压缩效率，现在已经成为Web上使用最为普遍的数据压缩格式。

压缩是如何工作的？

客户端请求报文中包含Accept-Encoding表示客户端能识别的压缩方法，如果客户端请求报文没有包含Accept-Encoding首部，服务器就会假设客户端能够接受任何编码格式；服务器响应报文中包含Content-Encoding表示采用的压缩方法。（然而，一个统计表明，大约有15%的客户端请求是没有Accept-Encoding请求的，因为客户端的一些web代理和PC安全软件会移除浏览器发出的Accept-Encoding，因为监听未经压缩的响应会占用更少的CPU资源，但却无疑增加了网络传输的时间。）

应该对什么资源使用压缩？

基于文本的资源如html，js，css，xml都适用于压缩。然而对于图片而言，却不应该对图片进行压缩，因为图片本身是已经被压缩过了，如果再进行gzip压缩，有可能得到的结果是和图片本身大小相差不大或更大，这样就浪费了服务器的CPU资源来做无用功了。

压缩的优缺点

优点：压缩组件可以减少HTTP响应时间，提升传输效率。

缺点：服务器要通过花费额外的CPU周期来完成压缩，客户端要对压缩文件进行解压缩。

总体来说，使用压缩还是利大于弊的，不过需要合理地使用压缩，通过选择对一定范围大小的组件进行压缩和选择要压缩组件的类型，能使得收益最大化。

考虑代理缓存的情况

代理缓存服务器是一个中间层，位于客户端和服务器之间。使用代理缓存的情况下，浏览器将不直接与服务器通信，而是通过代理发送请求。这种情况下，压缩就要考虑额外的东西了。
首先，假设到达代理的是一个来自不支持gzip的浏览器的请求，代理会将请求转发到web服务器，此时web服务器的响应是未经过压缩的，这个响应会把代理服务器缓存起来并发给浏览器。现在，假设到达代理的第二个请求来自一个支持gzip浏览器，请求的是与之前相同的URL，代理会直接使用未经压缩的缓存响应，那么久失去了进行压缩的机会了。考虑更糟糕的情况，第一个请求来自支持gzip的浏览器，第二个请求来自不支持gzip的浏览器，这样第二个请求得到的缓存响应将无法被解码，导致出错。
解决这一问题的方法就是在Web服务器的响应中添加Vary头，Vary:Accept-Encoding，表示web服务器告诉缓存服务器分别为每一个Accpet-Encoding请求头缓存。在前面的例子中，代理通过识别Vary头，对响应缓存不同的版本，避免出错。

五、网站样式和脚本

1、将样式表放在头部

可视性回馈的重要性
进度指示器有三个主要优势——它们让用户知道系统没有崩溃，只是正在为他或她解决问题；它们指出了用户大概还需要等多久，以便用户能够在漫长的等待中做些其他事情；最后，它们能给用户提供一些可以看的东西，使得等待不再是那么无聊。最后一点优势不可低估，这也是为什么推荐使用图形进度条而不是仅仅以数字形式显示预期的剩余时间。在Web的世界里，Html页面的逐步呈现就是很好的进度指示器。
将没有立即使用的css放在底部是错误的做法
通常组件的下载是按照文档中出现的顺序下载的，所以将不需要立即使用到的组件css(比如需要用户点击登录弹出框需要用到的样式)放在底部，可以得到一个加载很快的页面。然而这个推论其实是错误的，IE8以下(包括IE8)的工作方式是如果css表仍在加载，构建呈现树就是一种浪费，因为在所有样式表加载并解析完毕之前无需绘制任何东西，这时整个浏览器显示都是空白，直到css加载完毕，这就失去了提供可视化回馈的机会，让用户感觉到缓慢。
不过，更高级版本的IE和其他浏览器已经克服了“白屏”问题，所以这种情况已经不复存在。
无样式内容的闪烁
这里将讨论另外一种出现的情况，当我们将css放在底部，页面可以正常逐步呈现，但在css下载并解析完毕之后，已经呈现的文字和图片就要用新的样式重绘了，这就是“无样式内容的闪烁”，这将是一种不好的用户体验。
CSS的最佳摆放位置
使用LINK标签将样式表放在文档HEAD中。

二、将脚本放在底部

并行下载
浏览器下载组件的时候并不是每次只下载一个组件，而是实现了并行下载的机制。HTTP规范1.1建议浏览器从每个主机名并行地下载两个组件。既假如页面的所有组件都来自于一个主机名，则每次只能同时下载两个组件。如果组件使用了两个主机名，而且组件的主机名分配均匀，则每次并行下载的数量变成了2*2=4。不过，当代的浏览器普遍实现都超过了2个并行下载，不同的浏览器设置都有所不同。
脚本阻塞下载
并行下载组件能加快页面的加载速度，然而，在下载脚本的时候并行下载实际上是被禁用的，即使其他组件使用了不同的主机名，浏览器也不会启动其他的下载。原因如下：1. 脚本可能使用了document.write来修改页面内容，因此浏览器会等待，以确保能够恰当地布局；2. 为了保证脚本能够按照正确的顺序执行，如果并行下载多个组件，就无法保证响应是按照特定顺序到达浏览器的。
所以，脚本放在越靠近顶部的地方将越延迟用户的可视化反馈，这不是一种良好的用户体验，会让用户感觉到缓慢。
最佳做法
放置脚本的最好地方是页面的底部，这不会阻止页面内容的呈现，而且页面的可视化组件可以尽早下载。以博客园为例，博客园就把google流量分析的js放在底部，同时把下载Blog新闻和Blog侧边栏的js执行函数放在了底部。

3、使用外部javascript和css

基础知识
页面浏览量(PV)：用户对页面请求访问次数总和。
内联 VS 外置
对于两个相同大小的页面，一个使用了内联，只有html需要下载，一个使用了外置，包括一个js和一个css，在用户不带缓存访问页面的时候，内联所有的js和css的效率更快，原因是外置js和css带来额外的http请求开销，1个http请求相对于3个http请求要更快一些。尽管如此，现实中还是使用外部文件会产生较快的访问速度，这是由于外部js和css有机会被浏览器缓存起来，当再次请求相同的js或css的时候，浏览器将不会发出http请求，而是使用缓存的组件，减少了总体需要下载文件的大小。
综合来讲，我们一般推荐使用外置的js和css，不过这也要根据自身web的访问场景以及PV做出最优选择。
如何划分组件？
当我们决定使用外置js和css的时候，这时怎样划分js和css并打包到外部文件中成为一个首要考虑的问题。在典型情况下，页面之间的js和css的重用既不可能100%重叠，也不可能100%无关。

一种极端的做法是创建一个单独的，联合了所有js的文件，再创建一个包含了所有css的文件。这只要求用户生成一个Http请求，但它增加了用户不带缓存访问的情况下的数据量，同时我们必须清楚：缓存有时会失效，这将带来更多额外的开销。而且，在任何一块独立的js或css改变后，都需要更新文件，并发布新的版本号，这将使所有客户端的旧版本缓存失效。
另一种极端的做法是为每个页面提供一组分离的外部文件，这种方式真正做到按需下载，但缺点在于每个页面都产生令响应时间变慢的HTTP请求。
对于大多数web应用来说，我们需要一种折中的方案！将页面划分为几种页面类型，然后为每种类型创建单独的js和css。以css为例，我们可以创建一个所有页面都通用的global.css，再针对不同类型的页面，创建对应的css。

六、减少DNS查找、避免重定向

1、减少DNS查找

基础知识
DNS(Domain Name System)：负责将域名URL转化为服务器主机IP。
DNS查找流程：首先查看浏览器缓存是否存在，不存在则访问本机DNS缓存，再不存在则访问本地DNS服务器。所以DNS也是开销，通常浏览器查找一个给定URL的IP地址要花费20-120ms，在DNS查找完成前，浏览器不能从host那里下载任何东西。
TTL(Time To Live)：表示查找返回的DNS记录包含的一个存活时间，过期则这个DNS记录将被抛弃。
影响DNS缓存的因素
（1）. 服务器可以设置TTL值表示DNS记录的存活时间。本机DNS缓存将根据这个TTL值判断DNS记录什么时候被抛弃，这个TTL值一般都不会设置很大，主要是考虑到快速故障转移的问题。
（2）.浏览器DNS缓存也有自己的过期时间，这个时间是独立于本机DNS缓存的，相对也比较短，例如chrome只有1分钟左右。
（3）. 浏览器DNS记录的数量也有限制，如果短时间内访问了大量不同域名的网站，则较早的DNS记录将被抛弃，必须重新查找。不过即使浏览器丢弃了DNS记录，操作系统的DNS缓存也有很大机率保留着该记录，这样可以避免通过网络查询而带来的延迟。

最佳实践
当客户端的DNS缓存为空时，DNS查找的数量与Web页面中唯一主机名的数量相等。所以减少唯一主机名的数量就可以减少DNS查找的数量。
然而减少唯一主机名的数量会潜在地减少页面中并行下载的数量，避免DNS查找降低了响应时间，但减少并行下载可能会增加响应时间。当页面的组件量比较多的时候，可以考虑将组件分别放到至少2-4个主机名，已获得最大收益。

延伸：

http://www.chinaz.com/web/2015/0318/390930.shtml

http://www.chinaz.com/web/2015/0316/390234.shtml

http://www.chinaz.com/web/2015/0122/380042.shtml

http://www.chinaz.com/web/2015/0122/380039.shtml

2、避免重定向

什么是重定向？
重定向用于将用户从一个URL重新路由到另一个URL。
常用重定向的类型
301：永久重定向，主要用于当网站的域名发生变更之后，告诉搜索引擎域名已经变更了，应该把旧域名的的数据和链接数转移到新域名下，从而不会让网站的排名因域名变更而受到影响。
302：临时重定向，主要实现post请求后告知浏览器转移到新的URL。
304：Not Modified，主要用于当浏览器在其缓存中保留了组件的一个副本，同时组件已经过期了，这是浏览器就会生成一个条件GET请求，如果服务器的组件并没有修改过，则会返回304状态码，同时不携带主体，告知浏览器可以重用这个副本，减少响应大小。
重定向如何损伤性能?
当页面发生了重定向，就会延迟整个HTML文档的传输。在HTML文档到达之前，页面中不会呈现任何东西，也没有任何组件会被下载。
来看一个实际例子：对于ASP.NET webform开发来说，对于新手很容易犯一个错误，就是把页面的连接写成服务器控件后台代码里，例如用一个Button控件，在它的后台click事件中写上：Response.Redirect("")；然而这个Button的作用只是转移URL，这是非常低效的做法，因为点击Button后，先发送一个Post请求给服务器，服务器处理Response.Redirect("")后就发送一个302响应给浏览器，浏览器再根据响应的URL发送GET请求。正确的做法应该是在html页面直接使用a标签做链接，这样就避免了多余的post和重定向。

重定向的应用场景
（1). 跟踪内部流量
当拥有一个门户主页的时候，同时想对用户离开主页后的流量进行跟踪，这时可以使用重定向。以yahoo.com为例，主页新闻的链接主机名是http://hsrd.yahoo.com/，后面跟着识别的参数，点击后再产生一个301重定向，这样就记录了离开门户主页后的流量去向。　　
我们知道重定向是如何损伤性能的，为了实现更好的效率，可以使用Referer日志来跟踪内部流量去向。每个HTTP请求都有一个Referer表示原始请求页(除了从书签打开或直接键入URL等操作)，记录下每个请求的Referer，就避免了向用户发送重定向，从而改善了响应时间。

(2). 跟踪出站流量
有时链接可能将用户带离你的网站，在这种情况下，使用Referer就不太现实了。
同样也可以使用重定向来解决跟踪出站流量问题。以百度搜索为例，百度通过将每个链接包装到一个302重定向来解决跟踪的问题，例如搜索关键字“跟踪出站流量”，搜索结果的第一个URL为http://www.baidu.com/link?url=后面跟着一连串字符，即使搜索结果并没有变，但这个字符串是动态改变的，我认为这里的搜索连接URL好像没有改变的需要，不知道这里起到怎样的作用？
除了重定向外，我们还可以选择使用信标(beacon)——一个HTTP请求，其URL中包含有跟踪信息。跟踪信息可以从信标Web服务器的访问日记中提取出来，信标通常是一个1px*1px的透明图片，不过204响应更优秀，因为它更小，从来不被缓存，而且绝不会改变浏览器的状态。

延伸：http://www.chinaz.com/web/2014/1029/372287.shtml

http://www.chinaz.com/web/2013/1212/330808.shtml

http://www.chinaz.com/web/2015/0409/397350.shtml

七、精简js移除重复脚本

基础知识
精简：从javascript代码中移除所有的注释以及不必要的空白字符(空格，换行和制表符)，减少javascript文件的大小。
混淆：和精简一样，会从javascript代码中移除注释和空白，另外也会改写代码。作为改写的一部分，函数和变量的名字将被转换为更短的字符串，所以进一步减少了javascript文件的大小。

混淆的缺点：

1. 缺陷：混淆过程本身很有可能引入错误。
2. 维护：由于混淆会改变javascript符号，因此需要对任何不能改变的符号进行标记，防止混淆器修改它们。
3. 调试：经过混淆的代码很难阅读，这使得在产品环境中更加难以调试。

相对而言，精简出错的概率会少很多。

一个精简和混淆的示例

使用JSMin进行精简，使用yuicompressor进行混淆，原始js如下：

//anthor:teroy/*
This is for test.
*/
function show(name, day) {
    alert(name);
    alert(day);
}
function test(name, day) {
    var variable = name;
    show(name, day);
}

JSMin精简后的代码：

function show(name,day){alert(name);alert(day);}
function test(name,day){var variable=name;show(name,day);}

混淆后的代码：

function show(b,a){alert(b);alert(a)}function test(c,a){var b=c;show(c,a)};

对精简和混淆进行抉择

我们知道启用gzip压缩能减少组件的传送大小，压缩后精简和混淆的差别会进一步减少，综合考虑混淆可能带来的额外的风险，所以优先考虑使用精简。不过，如果对于性能的极致追求，可以使用混淆，但要做足测试，确保混淆不会带来其他的问题。

JQuery作为非常流行的前端框架，除了有开发版外，也提供了一个min版本，供实际部署web使用，这个min版本就使用了混淆，最大化地减少代码总量。
2、移除重复脚本

出现重复脚本的原因
导致一个脚本的重复又两个主要因素：团队大小和脚本数量。开发一个网站需要极大数量的资源，不同的团队需要构建一个大型web的不同部分，当团队整合和沟通工作没有做足，则容易出现重复脚本的情况。当然脚本数量也是重要的一环，脚本数量越多越容易出现重复脚本的情况。

重复脚本如何损伤性能
在没有缓存的情况下，如果在html中重复链接了相同的脚本，IE7以下(包括IE7)将会产生两次HTTP请求，IE8以上则不会。
除了产生不必要的HTTP请求外，对脚本进行重复执行也会浪费时间，脚本的重复执行在浏览器中都存在。
如何避免重复脚本
（1）. 形成良好的脚本组织。重复脚本有可能出现在不同的脚本包含同一段脚本的情况，有些是必要的，但有些却不是必要的，所以需要对脚本进行一个良好的组织。
（2）. 实现脚本管理器函数。

八、配置ETag

什么是ETag？
实体标签(EntityTag)是唯一标识了一个组件的一个特定版本的字符串，是web服务器用于确认缓存组件的有效性的一种机制，通常可以使用组件的某些属性来构造它。
条件GET请求
浏览器下载组件的时候，会将它们存储到浏览器缓存中。如果需要再次获取相同的组件，浏览器将检查组件的缓存时间，假如已经过期，那么浏览器将发送一个条件GET请求到服务器，服务器判断缓存还有效，则发送一个304响应，告诉浏览器可以重用缓存组件。
那么服务器是根据什么判断缓存是否还有效呢?答案有两种方式，一种是前面提到的ETag，另一种是根据最新修改时间。先来看看最新修改时间。
最新修改时间
原始服务器通过Last-Modified响应头来返回组件的最新修改时间。
以一个实际例子来说明，当我们不带缓存访问www.google.com.hk的时候，我们需要下载google的logo，这时会发送这样一个HTTP请求：

Request：
GET /logo.png HTTP 1.1
Host: www.google.com.hk
Response:
HTTP 1.1 200 OK
Last-Modified:Wed, 09 Oct 2013 01:35:39 GMT

当需要再次访问相同组件的时候，同时缓存已经过期，浏览器会发送如下条件GET请求：

REQUEST：

GET /logo.png HTTP 1.1
If-Modified-Since:Wed, 09 Oct 2013 01:35:39 GMT
Host: www.google.com.hk

Response：

HTTP 1.1 304 Not Modified

实体标签

ETag提供了另外一种方式，用于检测浏览器缓存中的组件与原始服务器上的组件是否匹配。

不带缓存的请求：

Request：

GET /i/yahoo/gif HTTP 1.1
Host: us.yimg.com

Response：

HTTP 1.1 200 OK
Last-Modified:Tue,12 Dec 200603:03:59 GMT
ETag:”10c24bc-4ab-457elc1f“

再次请求相同组件：

Request：

GET /i/yahoo/gif HTTP 1.1
Host: us.yimg.com
If-Modified-Since:Tue,12 Dec 200603:03:59 GMT
If-None-Match:”10c24bc-4ab-457elc1f“

Response：

HTTP 1.1 304 Not Midified

当ETag和Modified-Time都出现了，则原始服务器禁止返回304除非请求中的条件头字段全部一致。

为什么要引入ETag？

ETag主要是为了解决Last-Modified无法解决的一些问题：

1. 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET;

2. 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记

录MTIME只能精确到秒);

3. 某些服务器不能精确的得到文件的最后修改时间。

ETag带来的问题

ETag的问题在于通常使用某些属性来构造它，有些属性对于特定的部署了网站的服务器来说是唯一的。当使用集群服务器的时候，浏览器从一台服务器上获取了原始

组件，之后又向另外一台不同的服务器发起条件GET请求，ETag就会出现不匹配的状况。

最佳实践

1. 如果使用Last-Modified不会出现任何问题，可以直接移除ETag，google的搜索首页则没有使用ETag。

2. 确定要使用ETag，在配置ETag的值的时候，移除可能影响到组件集群服务器验证的属性，例如只包含组件大小和时间戳。

九、图像和Cookie优化

1、图像优化

图像基础知识

gif: 适用于动画效果，例如提示的滚动条图案 Web前端性能优化教程 Web前端性能优化 Web优化图像优化

jpg: 是一种使用有损压缩的图片格式，它将图片的每个像素分解成8*8的栅格，然后对每个栅格的数据进行压缩处理，通过特殊的算法用附近的颜色填充栅格，隐藏细

节。用户可以设置质量级别，从0到100，数字越少图片质量就越差。

png：是一种使用无损压缩的图片格式，它将图片上出现的颜色进行索引，保留在“调色板”上，PNG在显示图像的时候就会调用调色板的颜色去填充相应的位置。png

又分为png8，png24和png32；png8表示支持2^8个种颜色，通常情况下png8是最通用的web图片格式。

选择jpg还是png

对比jpg和png的特点，不同的图像使用不同的格式能得到最佳压缩效果。对于层次丰富颜色较多的图像，使用jpg更好，因为为了很好的显示这种图像，png将使用调

色板颜色更为丰富的png24，这样图片大小会比jpg大。而对于颜色简单对比强烈的图像，使用png更好，因为png使用较少的调色板颜色就可以满足显示效果，而且得

到的图片相对也比较小，而jpg是有损的，在清晰的颜色过渡周围会有大色块，影响显示效果。

将png24|32转化为png8

png图片的优化的很重要的一步：有些png24|32图片本身颜色较为简单，将其转变为png8得到的显示效果很类似，但却能极大地减少图片的大小。这一步可以通过使

用工具pngGo来完成，这是一个完全免费的工具，而且可以根据需要设置png所需要的调色板颜色数，得到最大的压缩效果。

使用smushit.it在线无损化压缩

png格式将图像信息保存在“块”中，对于web显示来说，大部分的“块”都并非必要，所以优化策略可以将它们安全地删除。雅虎的YSlow提供了一个在线的无损化压缩

工具smushit.it，不过基本上假如已经将图片转变为png8，使用smushit.it能压缩的空间已经很小了，不过对于追求极致性能的web来说，还是值得一试的。

2、优化Cookie

什么是Cookie

Cookie是存储在客户端的一小段文本信息，伴随着用户请求在浏览器和服务器之间传递。Cookie除了核心对象key-value外，还有max-age，path，domain和httponly

属性。httponly属性标识一个客户端javascript能否操作这个Cookie；max-age表示缓存时间，单位为秒；domain代表域名，例如设置为.cnblog.com，则

i.cnblogs.com也可以访问这个Cookie，如果设置为i.cnblogs.com，则image.cnblogs.com这个域名下的资源将不能访问这个Cookie；path代表文件路径，默认为/，表

示可以该domain下的所有资源可以访问这个Cookie。浏览器对单个Cookie大小限制不超过4KB；对于同一域名下Cookie的数量也有限制，一般不允许超过50个。

非持久Cookie和持久Cookie

假如Http请求响应头部Set-Cookie的时候没有给Cookie添加一个过期时间，则它的默认过期时间为当前浏览会话结束，既退出浏览器这个Cookie就无效了，这个

Cookie就叫做非持久Cookie，因为是存储在浏览器进程的内存中的。

而如果给Cookie添加了一个过期时间，则Cookie信息将存储到硬盘上，即使浏览器退出这个Cookie还是存在的。只要Cookie未被清除且还在过期时间以内，这个

Cookie就会在访问对应域名的时候发送给服务器。

减少Cookie的体积

由于Cookie在访问对应域名下的资源的时候都会通过Http请求发送到服务器，所以通过合理地设计Cookie，减少Cookie的体积，能够减少Http请求报文的大小，提高

响应速度。

通过使用不同的主机减少Cookie的使用

Cookie在访问对应域名下的资源的时候都会通过Http请求发送到服务器，但是在访问一些资源（例如js脚本，css和图片）的时候，大多数情况下这些Cookie是多余

的，所以我们可以通过使用不同的主机来存储一些静态资源，例如用专门的主机来存储图片，这样访问这些资源的时候就不会发送多余的Cookie，从而提高响应速

度。

Kongkong_nana

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
web前端性能优化9大方向

摘自《高性能网站建设》一、减少HTTP请求通过减少组件的数量来减少HTTP请求的数量1、图片地图它允许在一个图片上关联多个URL，目标URL的选择取决于用户单击了图片上的哪个位置。当使用N个分开的图片，每个图片对应一个超链接，这样就会产生N个HTTP请求，当把N张图片合并为一张的时候，然后以位置信息定位超链接，这样就只剩下一个HTTP请求，同时保证功能的准确实现。例如：
复制链接

扫一扫