Web前端性能测试及优化技巧
Web前端性能测试及优化技巧
　　1、前端性能的意义　　对于访问一个网站，最花费时间的并不是后端应用程序处理以及数据库等消耗的时间，而是前端花费的时间（包括请求、网络传输、页面加载、渲染等）。根据web优化的黄金法则：　　80%的最终用户响应时间花在前端程序上，而其大部分时间则花在各种页面元素，如图像、样式表、脚本和Flash等，的下载上。减少页面元素将会减少HTTP请求次数。这是快速显示页面的关键所在。　　根据著名的“2-5-8原则”，用户访问一个页面：　　当用户能够在2秒以内得到响应时，会感觉系统的响应很快；　　当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；　　当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；　　而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。　　对于一个网站如果希望抓住用户，网站的速度以及稳定性是首当其冲的。目前性能已经被列入google的网站的排名规则中。　　相关文章Web Performance Optimization (WPO) – As Business Critical as SEO　　2、前端性能关注的重点　　2.1 加载时间指标，主要包括三个时间断　　a. Time to First Impression　　表示从用户在浏览器键入url按下回车键一刻开始到页面开始有反应（用户可以在页面中看见一点点内容）为止。经常能感觉到的一个信号就是网页开始显示title。　　b.Time to onLoad Event　　表示从页面开始显示内容，到浏览器开始触发OnLoad函数这一时间段。只有当初始的文本和所引用的对象加载完成，浏览器才开始触发OnLoad函数　　c.Time to Fully Loaded　　表示从上一时间段末到整个网页完全加载完成（所有OnLoad函数以及相关的动态资源加载完成）。在网页中含有timeout或定时刷新之类处理时较为难判断结束点。　　2.2 资源情况指标　　网页由初始的html文本中嵌入图片以及通过XHR或者修改dom树动态加载的内容组成，css负责样式，js负责行为。所以当网页资源过多为了下载资源，客户端和服务器的网络来回就更多。下面是资源方面相关的指标。　　a. Total Number of Requests　　包括html网页请求，css、js资源下载及其它网络请求。优化的目标之一是要尽量减少请求数。　　b. Total Number of HTTP 300s/400s/500s　　表示返回状态为300（重定向）、400（客户端错误）、500（服务器端错误）的http请求。尽量避免这些请求，以提高页面load的时间。造成这些状态的原因经常是服务器的实施、配置和部署问题。　　c. Total Size of Web Site　　构成网页元素总的大小。图片或者js库的增加都会对下载时间造成重要的影响。　　d. Total Size of Images/CSS/JS　　image、css、js在网页元素大小中占主要比例。　　e. Total Number of XHR(XMLHttpRequest) Requests　　通过js异步从服务器端获得数据的请求数。一些js框架提供了跟服务器端的更新机器，就是XHR请求。通过配置可以减少XHR请求的数目　　2.3 网络连接指标　　浏览器底层的网络连接对资源的下载速度有很大影响。资源的下载过程分为很多阶段。下面介绍这些阶段以及浏览器、网络、请求如何影响这些阶段的时间　　a. DNS Time　　dns 查询的时间。网页请求会产生一次寻找该网页资源所在主机的dns查询。在同个域名进行网页切换不会造成新的dns查询。　　b. Connect Time　　指浏览器和服务器之间建立tcp/ip连接的时间，对于ssl连接包括握手的时间。网络连接过慢、使用ssl、使用短连接而非常连接都是造成connect time较多的原因。　　c. Server Time　　指收到请求后服务器逻辑处理的时间，　　d. Transfer Time　　这一指标与浏览器和服务器之间的连接速度相一致，通过减小传输内容或使用cdn来降低Transfer Time。　　e. Wait Time　　等待时间和同一个域中服务资源的数量直接相关。每个域的浏览器的物理网络的限制，导致资源等待可用的连接。减少资源的数量，或将资源散布在不同的域，能将这一时间降低。平均等待时间的大小更能反映等待时间是否需要注意。　　f. Number of Domains / Single Resource Domains　　部署网站资源的域主机数量是很重要的，因为它影响的DNS，连接和等待时间。　　专门用户资源下载的域是必要的，他将直接减少等待时间。应避免单一的资源域，否则你将为dns查询以及资源下载付出昂贵的代价。　　参考：关于前端的关键性能指标Key Performance Indicators.....投稿请联系：阅读全文内容，请点击左下角“阅读原文”吧！
发表评论：
TA的最新馆藏[转]&[转]&[转]&[转]&[转]&[转]&项目经验积累（35）
沧海遗珠（19）
转自：/kf/725.html
& & & & &网站的划分一般为二：前端和后台。我们可以理解成后台是用来实现网站的功能的，比如：实现用户注册，用户能够为文章发表评论等等。而前端呢？其实应该是属于功能的表现。并且影响用户访问体验的绝大部分来自前端页面。
& & & & 而我们建设网站的目的是什么呢？不就是为了让目标人群来访问吗？所以我们可以理解成前端才是真正和用户接触的。除了后台需要在性能上做优化外，其实前端的页面更需要在性能优化上下功夫，只有这样才能给我们的用户带来更好的用户体验。就好像，好多人问，男人在找女朋友的时候是不是只看外表，一些智慧的男人给出了这样的回答：脸蛋和身材决定了我是否想去了解她的思想，思想决定了我是否会一票否决她的脸蛋和身材。同理，网站也是这样，网站前端的用户体验决定了用户是否想要去使用网站的功能，而网站的功能决定了用户是否会一票否决前端体验。
& & & & 不仅仅如此，如果前端优化得好，他不仅可以为企业节约成本，他还能给用户带来更多的用户，因为增强的用户体验。说了这么多，那么我们应该如何对我们前端的页面进行性能优化呢？
& & & & 一般说来，web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有浏览器访问、使用反向代理才、CDN等。
浏览器访问优化
浏览器请求处理流程如下图：
<span style="color:#、减少http请求，合理设置 HTTP缓存
& & & & http协议是无状态的应用层协议，意味着每次http请求都需要建立通信链路、进行数据传输，而在服务器端，每个http都需要启动独立的线程去处理。这些通信和服务的开销都很昂贵，减少http请求的数目可有效提高访问性能。
& & & & 减少http的主要手段是合并CSS、合并javascript、合并图片。将浏览器一次访问需要的javascript和CSS合并成一个文件，这样浏览器就只需要一次请求。图片也可以合并，多张图片合并成一张，如果每张图片都有不同的超链接，可通过CSS偏移响应鼠标点击操作，构造不同的URL。
& & & & &缓存的力量是强大的，恰当的缓存设置可以大大的减少 HTTP请求。假设某网站首页，当浏览器没有缓存的时候访问一共会发出 78个请求，共 600多 K数据，而当第二次访问即浏览器已缓存之后访问则仅有 10个请求，共 20多 K数据。 (这里需要说明的是，如果直接 F5刷新页面的话效果是不一样的，这种情况下请求数还是一样，不过被缓存资源的请求服务器是 304响应，只有 Header没有Body，可以节省带宽 )
& & & & 怎样才算合理设置 ?原则很简单，能缓存越多越好，能缓存越久越好。例如，很少变化的图片资源可以直接通过 HTTP Header中的Expires设置一个很长的过期头 ;变化不频繁而又可能会变的资源可以使用 Last-Modifed来做请求验证。尽可能的让资源能够在缓存中待得更久。关于 HTTP缓存的具体设置和原理此处就不再详述了。
<span style="color:#、使用浏览器缓存
& & & & 对一个网站而言，CSS、javascript、logo、图标这些静态资源文件更新的频率都比较低，而这些文件又几乎是每次http请求都需要的，如果将这些文件缓存在浏览器中，可以极好的改善性能。通过设置http头中的cache-control和expires的属性，可设定浏览器缓存，缓存时间可以是数天，甚至是几个月。
& & & & 在某些时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况，可通过改变文件名实现，即更新javascript文件并不是更新javascript文件内容，而是生成一个新的JS文件并更新HTML文件中的引用。
& & & & 使用浏览器缓存策略的网站在更新静态资源时，应采用逐量更新的方法，比如需要更新10个图标文件，不宜把10个文件一次全部更新，而是应该一个文件一个文件逐步更新，并有一定的间隔时间，以免用户浏览器忽然大量缓存失效，集中更新缓存，造成服务器负载骤增、网络堵塞的情况。
<span style="color:#、启用压缩
& & & & 在服务器端对文件进行压缩，在浏览器端对文件解压缩，可有效减少通信传输的数据量。如果可以的话，尽可能的将外部的脚本、样式进行合并，多个合为一个。文本文件的压缩效率可达到80%以上，因此HTML、CSS、javascript文件启用GZip压缩可达到较好的效果。但是压缩对服务器和浏览器产生一定的压力，在通信带宽良好，而服务器资源不足的情况下要权衡考虑。
<span style="color:#、CSS Sprites
合并 CSS图片，减少请求数的又一个好办法。
<span style="color:#、LazyLoad Images
& & & & 这条策略实际上并不一定能减少 HTTP请求数，但是却能在某些条件下或者页面刚加载时减少 HTTP请求数。对于图片而言，在页面刚加载的时候可以只加载第一屏，当用户继续往后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。
<span style="color:#、CSS放在页面最上部，javascript放在页面最下面
& & & &浏览器会在下载完成全部CSS之后才对整个页面进行渲染，因此最好的做法是将CSS放在页面最上面，让浏览器尽快下载CSS。如果将 CSS放在其他地方比如 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了，这就导致页面由无 CSS状态跳转到 CSS状态，用户体验比较糟糕，所以可以考虑将CSS放在HEAD中。
& & & & Javascript则相反，浏览器在加载javascript后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此javascript最好放在页面最下面。但如果页面解析时就需要用到javascript，这时放到底部就不合适了。
& & & & Lazy Load Javascript（只有在需要加载的时候加载，在一般情况下并不加载信息内容。）随着 Javascript框架的流行，越来越多的站点也使用起了框架。不过，一个框架往往包括了很多的功能实现，这些功能并不是每一个页面都需要的，如果下载了不需要的脚本则算得上是一种资源浪费
-既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的 mini版框架，另一种则是 Lazy Load。
<span style="color:#、异步请求Callback（就是将一些行为样式提取出来，慢慢的加载信息的内容）
在某些页面中可能存在这样一种需求，需要使用 script标签来异步的请求数据。类&#20284;：
&span style=&font-size:14&&/*Callback 函数*/
function myCallback(info){
//do something here
　　Callback返回的内容 :
myCallback(&#39;Hello world!&#39;);
像以上这种方式直接在页面上写&&script&&对页面的性能也是有影响的，即增加了页面首次加载的负担，推迟了 DOMLoaded和window.onload 事件的触发时机。如果时效性允许的话，可以考虑在 DOMLoaded事件触发的时候加载，或者使用 setTimeout方式来灵活的控制加载的时机。
<span style="color:#、减少cookie传输
& & & & 一方面，cookie包含在每次请求和响应中，太大的cookie会严重影响数据传输，因此哪些数据需要写入cookie需要慎重考虑，尽量减少cookie中传输的数据量。另一方面，对于某些静态资源的访问，如CSS、script等，发送cookie没有意义，可以考虑静态资源使用独立域名访问，避免请求静态资源时发送cookie，减少cookie传输次数。
<span style="color:#、Javascript代码优化
(1). DOM　　
a.HTML Collection（HTML收集器，返回的是一个数组内容信息）&
　　在脚本中 document.images、document.forms、getElementsByTagName()返回的都是HTMLCollection类型的集合，在平时使用的时候大多将它作为数组来使用，因为它有 length属性，也可以使用索引访问每一个元素。不过在访问性能上则比数组要差很多，原因是这个集合并不是一个静态的结果，它表示的仅仅是一个特定的查询，每次访问该集合时都会重新执行这个查询从而更新查询结果。所谓的“访问集合” 包括读取集合的 length属性、访问集合中的元素。&
　　因此，当你需要遍历 HTML Collection的时候，尽量将它转为数组后再访问，以提高性能。即使不转换为数组，也请尽可能少的访问它，例如在遍历的时候可以将 length属性、成员保存到局部变量后再使用局部变量。　　&
b. Reflow & Repaint　　&
　　除了上面一点之外， DOM操作还需要考虑浏览器的Reflow和Repaint ，因为这些都是需要消耗资源的。
(2). 慎用 with　
with(obj){ p = 1};
代码块的行为实际上是修改了代码块中的执行环境 ，将obj放在了其作用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，如果没有再依次按作用域链向上查找，因此使用 with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的，过长的作用域链会导致查找性能下降。&
　　因此，除非你能肯定在 with代码中只访问 obj中的属性，否则慎用 with，替代的可以使用局部变量缓存需要访问的属性。
(3). 避免使用 eval和 Function
或Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。&
　　eval 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。&
　　Function 构造函数比 eval略好，因为使用此代码不会影响周围代码 ;但其速度仍很慢。&
　　此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。
(4). 减少作用域链查找
前文谈到了作用域链查找问题，这一点在循环中是尤其需要注意的问题。如果在循环中需要访问非本作用域下的变量时请在遍历之前用局部变量缓存该变量，并在遍历结束后再重写那个变量，这一点对全局变量尤其重要，因为全局变量处于作用域链的最顶端，访问时的查找次数是最多的。&
低效率的写法：
&span style=&font-size:14&&// 全局变量
var globalVar = 1;
function myCallback(info){
for( var i = 100000; i--;){
//每次访问 globalVar 都需要查找到作用域链最顶端，本例中需要访问 100000 次
globalVar +=
更高效的写法：
&span style=&font-size:14&&// 全局变量
var globalVar = 1;
function myCallback(info){
//局部变量缓存全局变量
var localVar = globalV
for( var i = 100000; i--;){
//访问局部变量是最快的
localVar +=
//本例中只需要访问 2次全局变量
在函数中只需要将 globalVar中内容的值赋给localVar 中
globalVar = localV
此外，要减少作用域链查找还应该减少闭包的使用。
(5). 数据访问
　　Javascript中的数据访问包括直接量 (字符串、正则表达式 )、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问需要更大的开销。当出现以下情况时，建议将数据放入局部变量：&
　　a. 对任何对象属性的访问超过 1次&
　　b. 对任何数组成员的访问次数超过 1次&
　　另外，还应当尽可能的减少对对象以及数组深度查找。
(6). 字符串拼接
在 Javascript中使用”&#43;”号来拼接字符串效率是比较低的，因为每次运行都会开辟新的内存并生成新的字符串变量，然后将拼接结果赋&#20540;给新变量。与之相比更为高效的做法是使用数组的 join方法，即将需要拼接的字符串放在数组中最后调用其 join方法得到结果。不过由于使用数组也有一定的开销，因此当需要拼接的字符串较多的时候可以考虑用此方法。
<span style="color:#、CSS选择符优化
在大多数人的观念中，都觉得浏览器对 CSS选择符的解析式从左往右进行的，例如&
#toc A { color: #444; }这样一个选择符，如果是从右往左解析则效率会很高，因为第一个 ID选择基本上就把查找的范围限定了，但实际上浏览器对选择符的解析是从右往左进行的。如上面的选择符，浏览器必须遍历查找每一个 A标签的祖先节点，效率并不像之前想象的那样高。根据浏览器的这一行为特点，在写选择符的时候需要注意很多事项，有兴趣的童鞋可以去了解一下。
CDN（contentdistribute network，内容分发网络）的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户以最快速度获取数据，即所谓网络访问第一跳，如下图。
由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商，因此用户请求路由的第一跳就到达了CDN服务器，当CDN中存在浏览器请求的资源时，从CDN直接返回给浏览器，最短路径返回响应，加快用户访问速度，减少数据中心负载压力。&
CDN缓存的一般是静态资源，如图片、文件、CSS、script脚本、静态网页等，但是这些文件访问频度很高，将其缓存在CDN可极大改善网页的打开速度。
传统代理服务器位于浏览器一侧，代理浏览器将http请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站web服务器接收http请求。如下图所示：
论坛网站，把热门词条、帖子、博客缓存在反向代理服务器上加速用户访问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新的动态内容再次缓存起来。
此外，反向代理也可以实现负载均衡的功能，而通过负载均衡构建的应用集群可以提高系统总体处理能力，进而改善网站高并发情况下的性能。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：120004次
积分：2519
积分：2519
排名：第11398名
原创：125篇
转载：16篇
评论：22条
It's not what you do once in a while, it's what you do day in and day out that makes the difference.
阅读：3287
阅读：3563
文章：12篇
阅读：14420
文章：12篇
阅读：9505
阅读：6557
阅读：7908
(1)(1)(2)(2)(2)(4)(5)(1)(2)(1)(2)(4)(2)(1)(2)(2)(4)(4)(4)(4)(4)(9)(9)(12)(4)(6)(10)(5)(9)(8)(9)(5)(1)网站前后端性能优化的34条经验方法（上）_网站前端交流吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：3贴子：
网站前后端性能优化的34条经验方法（上）
1 、减少HTTP请求数量 (Minimize HTTP Requests)tag:content80%的用户响应时间被花费在前端，而这其中的绝大多数时间是用于下载页面中的图片、样式表、脚本以及Flash这些组件。减少这些组件的数量就可以减少展示页面所需的请求数，而这是提高网页响应速度的关键。朴素的页面设计当然是减少组件的一种途径，但有没有能兼顾丰富的页面内容和快速的响应速度的方法呢？下面就是一些不错的技巧，能在提供丰富的页面展现的同时，减少Http请求数量：合并文件，通过把所有脚本置于一个脚本文件里或者把所有样式表放于一个样式表文件中，从而减少Http请求的数量。当不同页面需要应用不同的脚本或样式时，合并这些文件会是一个很大的挑战，不过在发布网站时进行这种合并，将是提高网站响应速度的重要一步。CSS Sprites是减少图片请求的首选方案。把所有的背景图片合并到一张图中，使用CSS的background-image 和background-position 属性去控制展现恰当的图片区域。Image maps把多张图片组合成为一张图片。图片的总大小是不变的，但减少Http请求数会提高页面的响应速度。Image maps只能用于图片在网页中相邻的情况，比如导航条。制定image maps中的图片坐标是个很麻烦的过程，而且容易出错。同时给导航使用image maps也并不易读，所以并不推荐使用。内联图片使用data: URL scheme 把图片数据嵌入页面，但这会增加Html文档的大小。把内联图片合并到你被缓存的的样式表中是一个能既减少HTTP请求数又不会增加页面大小的方法。但目前并不是所有的主流浏览器都支持内联图片。减少页面的Http请求数量是第一步，而且对于提高用户初次访问体验是最重要的一步。正如在 Tenni Theurer的blog中的Browser Cache Usage – Exposed!里描述的，每天，有 40%-60%的访客并没有你的网站的缓存文件。提高这些初次访客的访问速度是提高用户体验的关键。 2 、使用内容分布式网络 (Use a Content Delivery Network)tag:server用户连接你的网站服务器的速度影响响应的快慢。把你的网站布置在多台分布于不同地域的服务器上，会让用户觉得你的页面加载速度更快。那么我们应该从哪里开始呢？不要一开始就把重新设计你的网站使其能够适应分布式结构作为实现网站地域分布的第一步。根据你的网站的复杂程度不同，更新网站结构的过程也许会包含诸如同步会话状态、在服务器间复制数据库等一系列复杂的步骤。这样你提高用户访问速度的目的反而会被更新网站架构的工作耽误。记住，用户80-90%的访问时间被花费在下载页面中的图片、样式表、脚本、Flash这些组件上。这是网站展示的黄金法则。那么与其重新设计网站的结构，不如先实现这些静态组件的分布。这不仅仅可以大幅减少响应时间，而且由于内容分布式网络（content delivery networks）的存在，这将是个很简单的工作。内容分布式网络（CDN）是一系列分布在不同地域的服务器的集合，能够更有效的给用户发送信息。它会根据一种衡量网域距离的方法，选取为某个用户发送数据的服务器。比如，到达用户最少跳或者最快相应速度的服务器会被选中。一些大型Internet公司拥有他们自己的CDN，但使用公用的CDN服务提供商更为划算，比如 Akamai Technologies, Mirror Image Internet, 或者Limelight Networks。对于刚起步的公司和个人网站来说，CDN服务的花费也许会偏高。但当你的目标用户越来越多而且趋于国际化，用CDN来降低响应时间就很必要了。在Yahoo!，把静态的内容从自己的网络服务器移到CDN提高了用户20%甚至更多的访问速度。转向CDN会是一个只需要相对简单的代码更新的工作，而且那将会显著的提高你的网站访问速度。 3 、给头部添加一个失效期或者Cache-Control (Add an Expires or a Cache-Control Header)tag:server这条法则包含两方面：* 对于静态组件：把头部的缓存期设为某个遥远的未来，使其能够“永不过期”。* 对于动态组件：使用适当的Cache-Control头部帮助浏览器执行特定的请求。网页设计越来越丰富，页面里包含了越来越多的脚本、样式表、图片和Flash。页面的初次访问者也许会发送多个HTTP请求，但通过给头部添加失效期，你可以使那些组件被缓存。这会避免下次浏览页面时的不必要的HTTP请求。给图片文件的头部设置失效时间更为常用，但包括脚本文件、样式表和 Flash之类的所有组件的头部都应该被设置失效时间。浏览器（还有代理服务器）使用缓存以减少HTTP请求的数量和大小，提高网页的加载速度。服务器在HTTP相应中通过头部中的过期时间告知客户端一个组件可以被缓存多久。下面是一个far future的过期头部，告诉浏览器这个响应直到日才会过期：Expires: Thu, 15 Apr :00 GMT如果你使用的是Apache服务器，使用ExpiresDefault 指令会设置一个相对于当前时间的过期时间。这里有一个通过ExpiresDefault 指令把过期时间设为请求时间之后10年的例子：ExpiresDefault “access plus 10 years”记住，如果你使用了far future过期头部，你必须在组件更新时更换它的名字。在Yahoo!我们通常在建设网站的过程中执行这样的步骤：组件的名字里包含了它的版本，比如：yahoo_2.0.6.js。使用一个far future过期头部只会在用户已经访问你的网站之后起作用。它不会影响一个没有缓存的初次访问者的HTTP请求数量。所以这一切的效果取决于多少用户访问页面时有一份预缓存（一份”预缓存”中已经包含了页面的所有组件）。我们对此在Yahoo！做过测试，发现拥有预缓存的用户在 75-85%。给头部添加far future失效期，可以增加浏览器缓存的组件数量并重复用于随后的页面浏览而不需要通过用户的网络发送哪怕一个字节。 4、 Gzip压缩组件(Gzip Components)tag:server前台工程师的决策能够显著的减少在网络上传输 HTTP请求和响应花费的时间。确实，终端用户的带宽速度、Internet服务提供商和连接交换机的服务器这些因素都是开发小组所不能控制的。但还有一些其它因素会影响响应的时间，比如压缩文件，就会减少HTTP响应的大小从而减少响应的时间。从HTTP/1.1开始，Web客户端就被设定为支持HTTP请求的头部中Accept-Encoding指定的压缩格式：Accept-Encoding: gzip, deflate当服务器检测到请求头部中的这一代吗，它就会使用客户端提供的方法列表中的一个来压缩响应内容。而服务器通过响应头部中的Content- Encoding来告知客户端它所使用的压缩方式：Content-Encoding: gzipGzip是当前最常用也是最有效的压缩方式，GNU项目开发了这一方法并且符合RFC 1952标准。另外一种你可能见过的压缩格式是deflate，但它没有那么有效和常用。使用gzip压缩通常会减少70%的响应大小。当前浏览器中大约90%的Internet通讯传输声明支持gzip。如果你使用Apache服务器，配置gzip的模块取决于服务器的版本：Apache 1.3 使用mod_gzip ，而Apache 2.x 使用mod_deflate。浏览器和代理会有一些已知的问题，可能导致浏览器的预期内容和获得的实际压缩内容不匹配。幸运的是，这种情况随着旧浏览器的使用者减少而减少。 Apache的模块可以通过自动添加适当的变化响应文件头来解决这些问题。服务器会根据文件类型选择gzip压缩的内容，但一般情况下，服务器选择压缩的内容会过于局限。大部分网站会压缩它们的Html文档，而压缩脚本和样式表也是值得一做的，但很多网站并没有这样做，事实上，压缩在包括 XML和JSON在内的任何文本响应都是值得的。图片和PDF文件不应该被gzip压缩，因为它们已经是被压缩了的文件，gzip它们不仅浪费CPU甚至还有增大文件大小的可能。Gzip尽可能多的文件类型是减少页面大小从而提高用户体验的一个简单的方法。 5、 把样式表放在前面(Put Stylesheets at the Top)tag:css在研究Yahoo！的性能时，我们发现把样式表挪到文档的头部可以让页面的加载显得更快。因为把样式表放在头部可以让页面逐步呈现。关心网站性能的前台工程师通常希望页面能够逐步加载；即，我们希望浏览器能够把已经获得的内容尽快展现。这对于内容很多的页面以及网络连接较慢的用户尤为重要。给予用户视觉上的反馈（比如进度提示）的重要性，已经经过了很详尽的论证。而对于我们来说，Html 页面本身就可以作为进度提示！当浏览器逐步加载页面时，头部、导航条、顶部的logo等等这些都可以作为对正在等待页面的用户的可视的反馈。而这会从整体上提高用户体验。把样式表放在文档的最后，会导致包括IE在内的大部分浏览器不进行逐步呈现。浏览器为了避免当样式改变时重绘元素而中止呈现。用户会十分无聊的看到一个空白的页面。Html规范明确规定样式表应该被包含在页面的HEAD中：“和A不同，LINK只能在文档的HEAD部位出现，但它可以出现多次。”空白的屏幕或者由于没有应用样式而引起的内容的闪现都不值得去尝试。最好的方法是遵循HTML规范，把样式表放在文档的HEAD部位。 6、 把脚本放在最后(Put Scripts at the Bottom)tag:javascript脚本可能会堵塞并发的下载。HTTP/1.1规范建议浏览器在每个域名下只进行两个并发下载。如果你把图片放在多个域名下，可以实现多于两个的并发下载。当脚本被下载时，即使使用不同的域名。浏览器也不会进行任何其它的下载。有些情况下把脚本放到底部并不太容易。比如，脚本使用了document.write 来添加部分页面中的内容，就不能放到页面中更后面的位置。还可能有作用域的问题。很多情况下，还有一些变通的方法。通常的建议是使用延迟脚本。DEFER属性表明脚本不包含document.write，而且提示浏览器继续展现。不幸的是，Firefox不支持DEFER属性。IE中，脚本可以被延迟，但并不如你期望的那么久。如果一个脚本可以被延迟，那么它也可以被放在页面的底部。这会让你的页面加载的更快。 7、 不使用CSS表达式 (Avoid CSS Expressions)tag:cssCSS表达式是一种有力的（同时也很危险的）动态设置CSS属性的方法。从IE5开始支持CSS表达式。比如，使用CSS表达式可以实现背景颜色每小时变换的效果。background-color: expression_r( (new Date()).getHours()%2 ? “F08A00〃 );如上所示，表达式方法采用了 Javascript的表达。CSS属性则被设为Javascript表达式的结果。其它的浏览器会忽略CSS表达式，所以对于设置专属IE的属性以便在不同浏览器间能有一致的体验是有用的。、而CSS表达式的问题是它比大多数人期望的执行次数更频繁。表达式不仅仅在页面展现和重新设置大小的时候执行，在页面滚动，甚至用户在页面上挪动鼠标时都会执行。给CSS表达式添加一个计数器可以跟踪CSS在什么时候和怎样执行。在页面上移动鼠标可以轻易的产生一万次以上的执行。使用一次性的表达式是减少CSS表达式的执行次数的一个方法，当表达式第一次执行时，CSS表达式会被一个确定的值代替。如果在页面生命周期中，样式属性必须动态的设定，使用事件处理替代CSS表达式是一个可选的方法。如果必须使用CSS表达式，要记得它们会执行上千次并影响页面的性能。 8、 使用外部的JavaScript和CSS (Make JavaScript and CSS External)tag:javascript,css很多性能规则都是解决怎样处理独立的组件的问题的。但是，考虑这些之前，你应该先考虑一个更基本的问题：JavaScript和CSS应该被放于外部的文件，还是内联在页面里？在实际应用中使用外部的文件往往产生更快的页面，因为浏览器会缓存JavaScript和CSS文件。而内联在页面里的JavaScript和CSS会在每次请求页面时下载。这会减少所需的HTTP请求数，但增大HTML文档的体积。而另一方面，如果放在外部文件里的JavaScript和CSS被浏览器缓存，则既不用增加HTTP请求的数量，HTML文档的体积也会减少。关键的问题是，外部的JavaScript和CSS的组件被缓存的频率和HTML文档被请求的次数相关。虽然很难去量化，但可以被用很多指标衡量。如果你的网站的用户在每个会话中浏览了很多网页而且很多页面重用了相同的JavaSctipt和样式表，缓存外部文件是有很大潜在的好处的。很多网站都符合这样的指标。对于这些网站来说，最好的解决方案是把JavaScript和CSS发布为单独的文件。唯一的例外，对于主页，内联的文件更好一些，例如 Yahoo!’s front page 和 My Yahoo!。主页在每个会话中只有很少浏览（也许只有一次），你会发现内联的 JavaScript和CSS会让终端用户的响应更快。对于有很多页面浏览量的首页来说，有很多能平衡内联文件所提供的HTTP请求减少的效果与外部文件缓存获得的好处的技巧。一种这样的技巧就是把JavaScript和CSS内联在说夜里，但在页面完成加载时动态下载外部文件。随后的页面会调用浏览器中已经缓存的外部文件。 9、 减少DNS的查询 (Reduce DNS Lookups)tag:content正如电话簿使人名和他们的电话号码相对应，域名系统（DNS）能够使域名和IP地址相对应。当你在浏览器中键入，浏览器链接的DNS解析器会返回服务器的 IP地址。域名解析会耗费一些时间，DNS查找给定域名的IP地址一般会耗费20-120毫秒。在DNS查找结束前，浏览器不会从目标域名那里下载任何东西。DNS查询会被缓存以便优化性能。会有一个专门的缓存服务器进行缓存，用户的ISP或者本地网络会维护它，但独立用户的电脑里也会有缓存。DNS信息存在于操作系统的DNS缓存里（微软Windows操作系统里的“DNS客户服务”）。大部分浏览器有它们自己的缓存，与操作系统的缓存相独立。当浏览器在自己的缓存里保存了DNS的记录，它不会向操作系统发出请求记录的要求。IE默认缓存DNS查询30分钟，在注册表的DnsCacheTimeout的键值中设定。Firefox则缓存DNS查询一分钟，在配置network.dnsCacheExpiration 中设定。（Fasterfox 将它变为一小时。）当客户端的DNS缓存被清空（包括浏览器和操作系统的缓存），DNS查询的数量等同于网页中单独的域名的数量。包括页面中的链接，图片，脚本文件，样式表，Flash对象等。减少不同域名的数量则会减少DNS查询的数量。减少不同域名的数量可能减少页面并行的下载数量。减少 DNS查询缩短了响应时间，但减少了并行下载数也许会增加响应时间。我的建议是将组件分布在两到四个域名之间。这能很好的折中减少DNS查询提高的速度和维持较高水平的并行下载的效果。 10、 缩小JavaScript和CSS (Minify JavaScript and CSS)tag:javascript,css缩小是指从代码中删除不必要的字母，减少文件体积从而提高加载速度。缩减代码时需要移除所有的注释，以及不需要的空白（空格，新行和tab）。这样处理JavaScript之后，会由于下载文件的体积被减少而提高响应的性能。两个常用的缩减JavaScript代码的工具是JSMin 和YUI Compressor。YUI compressor也可以压缩CSS。代码混淆是另一个可用于源代码的优化方案。它比压缩更为复杂，而且在混淆的过程中更容易产生 Bug。纵观U.S.的前十大网站，压缩获得了21%的体积减小而代码混淆达到了25%。虽然代码混淆的压缩程度更高，但压缩JavaScript的风险更小。不仅仅要压缩外部的脚本和样式表，内敛的&script&和&style&部分也可以而且应当被压缩。即使你gzip了你的脚本和样式，压缩它们仍然能减少5%以上的体积。随着JavaScript和CSS的应用和体积的增加，压缩你的代码获得的收益也会越来越多。 11 、避免重定向 (Avoid Redirects)tag:content重定向结束于 301或302状态码。这里有一个301响应的HTTP头的例子：HTTP/1.1 301 Moved PermanentlyLocation: Content-Type: text/html浏览器会自动把用户转向Location域中指明的Url地址。HTTP头里包含了重定向所需的所有信息。响应的主体一般是空的。301或者302响应都不会被实际缓存，除非添加额外的头部，比如 Expires或者Cache- Control指明了它应该被缓存。meta refresh标签和JavaScript也可以将用户重定向到不同的URL，但如果你必须执行重定向，最好的方法是使用标准的3XX HTTP状态代码，以便使后退按钮工作正常。需要谨记的是，重定向降低了用户体验。在用户和HTML文档之间插入的重定向延误了页面的呈现和组件下载，因为它们都不可能在获得HTML文档之前开始。一种最浪费性能的重定向频繁发生而网络开发者们却往往没有意识到，那就是当地址中应当有一个左斜线（/）却没有的时候。比如，访问/astrology会导致一个301效应并重定向到/astrology/（注意这里加了一个左斜线）。在Apache中，这可以使用mod_rewrite,或者在Apache事件处理中使用DirectorySlash指令来修补。使用重定向的另一个常见场景是连接旧网站和新网站。还包括连接网站的不同部分，或者在不同情况下（比如依据浏览器的类型，用户的类型等）重定向用户。使用重定向来连接两个网站很简单而且需要很少的额外代码。虽然在这些情况下使用重定向减少了开发者的麻烦，但却降低了用户体验。如果两部分在同一个服务器上，可以使用Alias 和rewrite来替代重定向。如果域名变更引起了重定向，可以创建一个CNAME（一种可以创建一个别名使一个域名指向另一个的DNS记录）结合 Alias 或者mod_rewrite来替代重定向。 12、 移除重复的脚本 (Remove Duplicate Scripts)tag:javascript在同一个页面中包含两个相同的脚本文件降低了性能。这并不如你想象的那么罕见。在对美国十大网站中的检查中，发现它们中的两个包含了重复的脚本。有两个主要因素增加了一个页面包含两个相同脚本的几率——团队的大小和脚本的数量。当脚本被重复包含时，由于增加了不必要的HTTP请求和JavaScript的执行，影响了性能。不必要的HTTP请求在IE中存在，而Firefox终没有。在IE中，如果一个外部脚本被包含了两次而且没有被缓存，在页面加载的过程中会产生两次HTTP请求。即使脚本被缓存了，当用户重载页面时，多余的HTTP请求也会发生。产生多余的HTTP请求的同时，多次执行脚本也会浪费时间。在Firefox和IE中，无论是否被缓存，脚本都会被重复执行。避免脚本被意外加载两次的一个方法是在你的模板系统中执行一个脚本管理模块。通常的方式是在HTML页面中使用SCRIPT标签来添加一个脚本：&script type=”text/javascript” src=”menu_1.0.17.js”&&/script&HP 中，可以选择创建一个叫做insertScript的方法：&?php insertScript(“menu.js”) ?&这个函数不仅仅能防止脚本被重复加载多次，还可以解决脚本的其他问题，比如独立性检测以及为脚本添加版本号码以应对far future Expires头部。 13 、设定ETags (Configure ETags)tag:server实体标签（ETags）是服务器和浏览器用于确定浏览器中缓存的组件和服务器中的是否对应的一种机制。（”entity”是组件的另一种说法：图片、脚本、样式表等等）添加 ETags用于辨别组件提供了比单纯利用“最后修改时间”更为灵活的机制。ETag是一个唯一标识组件的特定版本的字符串。它的唯一格式规范是字符串必须被引号引用。来源服务器使用ETag响应头来设定一个组件的ETag：HTTP/1.1 200 OKLast-Modified: Tue, 12 Dec :59 GMTETag: “10c24bc-4ab-457e1c1f”Content-Length: 12195当浏览器晚些时候需要检测一个组件时，它使用If-None-Match 头部把ETag传回来源服务器。如果ETag匹配了，会返回一个304状态码，在这个例子里它会减少12195个字节的响应：GET /i/yahoo.gif HTTP/1.1Host: If-Modified-Since: Tue, 12 Dec :59 GMTIf-None-Match: “10c24bc-4ab-457e1c1f”HTTP/1.1 304 Not ModifiedETag的问题是它们往往在网站的一个服务器中被设为唯一的，当浏览器从一个服务器得到了组件并在稍后试图到另一个服务器验证时，ETag会不匹配，而这在使用多个服务器来处理请求的网站中是很常见的。默认情况下，Apache和IIS在ETag中嵌入的数据戏剧性的减少了应用多台服务器的网站的ETag验证成功几率。Apache1.3和2.新版本的ETag格式是inode-size- timestamp。虽然一个给定的文件在多台服务器中处于同一个目录，而且有同样的大小，权限，时间戳，但它的inode在不同服务器中是不同的。IIS5.0和6.0有同样的问题。IIS中ETag的格式是Filetimestamp:ChangeNumber。 ChangeNumber用来跟踪IIS配置的改变次数。一个网站的所有IIS不可能有相同的ChangeNumber。这导致的结果是，Apache和IIS对完全相同的组件产生的ETag在不同服务器间不能匹配。如果ETags不匹配，用户不会得到小而快的304响应，而是一个普通的200响应和组件的所有数据。如果你把你的网站放在了一个服务器里，这不会是一个问题。但如果你的网站有多台服务器，而且你使用了Apache和IIS 默认的ETag配置，你的用户会访问页面的速度会变慢，你的服务器加载的程度更高，消耗了更大的带宽，代理服务器不能有效的缓存你的内容。即使你的组件有一个ar future Expires头部，当用户重载或者刷新页面时，依然会发送一个GET请求。如果你不打算利用ETags提供的灵活的验证模式，你最好把ETag统统移除。Last-Modified头部的验证方式给予组件的时间戳。移除ETag 同时减少响应和随后的请求中的HTTP头部大小。这篇微软的支持文档描述了怎样在IIS中移除 ETags。在Apache中，你只要在Apache配置文件中添加如下一行：FileETag none 14 、让Ajax可以缓存 (Make Ajax Cacheable)tag:contentAjax 的好处之一是它能给用户提供瞬间的响应，因为它从服务端异步请求数据。但Ajax不能保证用户在等候那些异步的JavaScript和XML响应返回时什么都不做。在应用程序中，用户是否继续等待取决于Ajax怎样应用。比如，在一个基于Web的Email客户端用户会等候Ajax返回他们所搜索的邮件信息。记住异步并不代表“即刻”。为了提高性能，优化Ajax响应很重要。提高Ajax性能最重要的方式是使响应缓存，正如“添加一个过期期限和缓存控制头”这一节讨论的。这些原则同样适用于Ajax。* Gzip组件* 减少DNS查询* 压缩JavaScript* 避免重定向* 设定ETag我们看一个例子。一个Web2，0的邮件客户端可能会用Ajax自动下载用户地址簿。如果用户从上次使用邮件网站以来没有修改她的地址簿，那么如果Ajax响应使用了长期失效时间或者缓存控制头部，地址簿就可以从缓存中读取出来。浏览器必须被告知“使用之前的缓存地址簿”而不是“请求一个新的地址簿”。可以在地址簿Ajax的URL中添加一个标识用户最后一次修改地址簿的时间戳，比如，&t=。如果地址簿从最后一次下载后没有被更改，时间戳将相同而地址簿将会从浏览器的缓存中得到来替代额外的HTTP传输。如果用户更改了她的地址簿，时间戳会保证新的URL不会和缓存中的匹配，而且浏览器会请求会请求更新的地址簿记录。即使你的Ajax响应时动态创建的，而且只适用于一个用户，它们依然会被缓存。这样做会让你的Web2.0应用程序更快。 15 、更早的刷新缓冲区 (Flush the Buffer Early)tag:server当用户请求一个页面，服务端会花费200至500毫秒的时间组合HTML页面。在这期间，浏览器会静静等待数据到来。PHP中有flush（）函数，它允许你向浏览器发送部分就绪的HTML响应，这样浏览器可以在服务器处理余下的HTML页面时去获取组件。这样的好处主要在忙碌的后台和轻松的前台间可以看到。在HEAD后面是放置刷新操作的好地方，因为头部的HTML代码更容易产生，而且可以让你放置任何CSS和JavaScript文件，以便浏览器在后台工作依然进行时并行开始获取组件。例子：… &!– css, js –&&/head&&?php flush(); ?&&body&… &!– content –&Yahoo! search先行研究并且进行了真人测试证明了使用这项技术的好处。 16、 在Ajax请求中使用GET方法 (Use GET for AJAX Requests)tag:serverYahoo! Mail 团队发现进行XMLHttpRequest的时候，POST方法在浏览器中分两步执行：先发送头部，然后发送数据。所以最好使用只发送一个TCP包（除非你有很多的cookie）的GET方法。IE中URL的最大长度是2000，所以如果你发送超过 2000的数据就不能使用GET方法。一个有趣的现象是，POST方法并不像GET那样实际发送数据（而Get则名副其实）。基于 HTTP规范，GET方法意味着取回数据，所以当你只是请求数据时使用GET方法更为有意义（从语义上来说），而在发送需要储存在服务器端的数据时则相反使用POST。 17 、后加载组件 (Post-load Components)tag:content你可以仔细端详下你的页面然后自问：“什么是在页面初始化时必须的？”那么其余的内容和组件可以放在后面。JavaScript是理想的用来分割onload事件之前和之后的选择。例如你有执行拖放、下拉和动画的JavaScript代码和菜单，它们可以稍后加载，因为用户在初始呈现之后才会在页面上拖动元素。其他的可以被后加载的地方包括隐藏的内容（当用户做某项操作才会展现的内容）和被折叠的图片。可以帮助你的工具有： YUI Image Loader能帮助你延缓加载折叠的图片，而且YUI Get utility 能够很简单的包装运行中的JS和CSS。比如，打开Firebug的网络选项卡去查看Yahoo! Home Page。当性能指标和其它网站开发的好的实践一致时是不错的。渐进增强的观念告诉我们当支持JavaScript时，会提高用户体验，但你必须确保在没有JavaScript时页面也能工作。所以当你确保页面工作正常时，你会通过延后加载的那些更花哨的脚本比如拖放和动画，来增强你的页面。
贴吧热议榜
使用签名档&&
保存至快速回贴