[{"data":1,"prerenderedAt":158},["ShallowReactive",2],{"blog:\u002Fblog\u002F2015\u002F10\u002F29\u002Fyahoo-14\u002F":3},{"id":4,"title":5,"body":6,"categories":142,"comments":144,"date":145,"description":146,"draft":147,"extension":148,"legacySlug":149,"meta":150,"navigation":144,"path":151,"seo":152,"stem":153,"tags":154,"updated":156,"__hash__":157},"blog\u002Fblog\u002F2015\u002F10\u002F29\u002FYaHoo-14.md","YaHoo  14条(Web 应用性能优化黄金法则)",{"type":7,"value":8,"toc":138},"minimark",[9,13,18,21,25,28,31,35,38,42,45,48,52,55,59,62,66,69,73,76,80,83,87,90,94,114,118,121,125,128,131,135],[10,11,12],"p",{},"Web 应用性能优化黄金法则：先优化前端程序 (front-end) 的性能，由于这是80% 或以上的最终用户响应时间的花费所在。javascript",[14,15,17],"h5",{"id":16},"法则1-减小http请求次数","法则1： 减小HTTP请求次数",[10,19,20],{},"80%的最终用户响应时间花在前端程序上，而其大部分时间则花在各类页面元素， 如图像、 样式表、 脚本和 Flash 等的下载上。 减小页面元素将会减小 HTTP 请求 次数。这是快速显示页面的关键所在。一种减小页面元素个数的方法是简化页面设计。 可是否存在其余方式，能作到既有丰富内容，又能得到快速响应时间呢？如下是这样一些技术：image maps 组合，多个图片到一张图片中。总文件大小变化不大，但减小了HTTP 请求次数从而加快了页面显示速度。 该方式只适合图片连续的状况；同时坐标的定义是烦人又容易出错的工做。 CSS Sprites 是更好的方法。它能够组合页面中的图片到单个文件中，并使用 CSS 的 background-image 和 background-position 属性来现实所需的部分图片。 inline images 使用 data: URL scheme 来在页面中内嵌图片。这将增大HTML文件的大小。组合 inline images 到你的（缓存）样式表是既能较少HTTP请求，又能避免加大HTML文件大小的方法。 Combined files 经过组合多个脚本文件到单一文件来减小 HTTP 请求次数。样式 表也可采用相似方法处理。 这个方法虽然简单，但没有获得大规模的使用。美国网站每页平均有7个脚本文件和2个样式表。当页面之间脚本和样式表变化很大时，该方式将遇到很大的挑战，但若是作到的话，将能加快响应时间。 减小HTTP请求次数是性能优化的起点。这最提升首次访问的效率起到很重要的做用。 Tenni Theurer 的文章 Browser Cache Usage ? Exposed!描述，40-60% 据的平常访问是首次访问，所以为首次访问者加快页面访问速度是用户体验的关键。css",[14,22,24],{"id":23},"法则2-使用-cdncontent-delivery-network-内容分发网络-html","法则2： 使用 CDN(Content Delivery Network, 内容分发网络 )html",[10,26,27],{},"用户离 web server 的远近对响应时间也有很大影响。从用户角度看，把内容部署到多个地理位置分散的服务器上将有效提升页面装载速度。 可是该从哪里开始呢？前端",[10,29,30],{},"做为实现内容地理分布的第一步，不要试图重构 web 应用以适应分布架构。 改变 架构将致使多个周期性任务，如同步session状态，在多个server之间复制数据库交易。 这样缩短用户与内容距离的尝试可能被应用架构改版所延迟，或阻止。 咱们还记得 80-90%的最终用户响应时间花在下载页面中的各类元素上，如图像文件、 样式表、 脚本和Flash等。 与其花在重构系统这个困难的任务上，还不如先分布静态内容。 这不只能大大减小响应时间，并且因为CDN的存在，分布静态内容很是容易实现。 CDN是地理上分布的web server的集合，用于更高效地发布内容。 一般基于网络远近来选择给具体用户服务的 web server。 一些大型网站拥有本身的CDN，可是使用如 Akamai Technologies, Mirror Image Internet, 或 Limelight Networks 等 CDN 服务提供商的服务将是划算的。 在Yahoo!把静态内容分布到 CDN减小了用户影响时间 20%或更多。切换到CDN的代码修改工做是很容易的，但能达到提升网站的速度。java",[14,32,34],{"id":33},"法则3增长-expires-header","法则3：增长 Expires Header",[10,36,37],{},"网页内容正变得愈来愈丰富，这意味着更多的脚本文件、样式表、图像文件和 Flash。首次访问者将不得不面临屡次HTTP请求，但经过使用Expires header， 您能够在客户端缓存这些元素。这在后续访问中避免了没必要要的HTTP请求。 Expires header 最经常使用于图像文件，可是它也应该用于脚本文件、样式表和 Flash。 浏览器（和代理）使用缓存来减小 HTTP 请求的次数和大小，使得网页加速装载。 Web server 经过 Expires header 告诉客户端一个元素能够缓存的时间长度。 若是服务器是Apache 的话，您可使用 ExpiresDefault 基于当期日期来设置过时日期，如： ExpiresDefault “access plus 10 years” 设置过时时间为从请求时间开始计算的10 年。请记住，若是使用超长的过时时间，则当内容改变时，您必须修改文件名称。 在 Yahoo!咱们常常把更名做为release 的一个步骤：版本号内嵌在文件名中，如 yahoo_2.0.6.js。node",[14,39,41],{"id":40},"法则4压缩页面元素","法则4：压缩页面元素",[10,43,44],{},"经过压缩HTTP响应内容可减小页面响应时间。从 HTTP\u002F1.1 开始，web客户端在 HTTP请求中经过 Accept-Encoding 头来代表支持的压缩类型，如：web",[10,46,47],{},"Accept-Encoding: gzip, deflate. 若是 Web server 检查到 Accept-Encoding 头，它会使用客户端支持的方法来压 缩 HTTP 响应，会设置 Content-Encoding 头，如：Content-Encoding: gzip。 Gzip 是目前最流行及有效的压缩方法。 其余的方式如deflate，但它效果较差，也不够流行。经过 Gzip，内容通常可减小 70%。若是是Apache，在 1.3 版本下需 使用 mod_gzip 模块，而在 2.x 版本下，则需使用mod_deflate。 Web server 根据文件类型来决定是否压缩。 大部分网站对 HTML 文件进行压缩。 但 对脚本文件和样式表进行压缩也是值得的。实际上，对包括 XML 和JSON 在内的任务文本信息进行压缩都是值得的。 图像文件和 PDF 文件不该该被压缩，由于它 们原本就是压缩格式保存的。对它们进行压缩，不但浪费 CPU，并且还可能增长 文件的大小。 所以，对尽可能多的文件类型进行压缩是一种减小页面大小和提升用户体验的简 便方法。数据库",[14,49,51],{"id":50},"法则5-把样式表放在头上","法则5： 把样式表放在头上",[10,53,54],{},"咱们发现把样式表移到HEAD部分能够提升界面加载速度，所以这使得页面元素能够顺序显示。 在不少浏览器下，如 IE，把样式表放在 document 的底部的问题在于它禁止了网页内容的顺序显示。 浏览器阻止显示以避免重画页面元素，那用户只能看到空白页了。Firefox 不会阻止显示，但这意味着当样式表下载后，有些页面元素可能须要重画，这致使闪烁问题。 HTML 规范明确要求样式表被定义在HEAD 中，所以，为避免空白屏幕或闪烁问题， 最好的办法是遵循HTML规范，把样式表放在HEAD中。express",[14,56,58],{"id":57},"法则6把脚本文件放在底部","法则6：把脚本文件放在底部",[10,60,61],{},"与样式文件同样，咱们须要注意脚本文件的位置。 咱们需尽可能把它们放在页面的底部，这样一方面能顺序显示，另方面可达到最大的并行下载。 浏览器会阻塞显示直到样式表下载完毕，所以咱们须要把样式表放在 HEAD部分。 而对于脚原本说，脚本后面内容的顺序显示将被阻塞，所以把脚本尽可能放在底部意味着更多内容能被快速显示。脚本引发的第二个问题是它阻塞并行下载数量。HTTP\u002F1.1 规范建议浏览器每一个主机的并行下载数不超过2 个。 所以若是您把图像文件分布到多台机器的话，您能够达到超过2个的并行下载。 可是当脚本文件下载时，浏览器不会启动其余的并行下载，甚至其余主机的下载也不启动。 在某些状况下，不是很容易就能把脚本移到底部的。如，脚本使用 document.write 方法来插入页面内容。 同时可能还存在域的问题。 不过在不少状况下，仍是有一些方法的。 一个备选方法是使用延迟脚本（deferred script）。DEFER属性代表脚本未包含 document.write，指示浏览器刻继续显示。不幸的是，Firefox 不支持 DEFER 属性。 IE中，脚本可能被延迟执行，但不必定获得须要的长时间延迟。在不过从另外角度来讲，若是脚本能被延迟执行，那它就能够被放在底部了。windows",[14,63,65],{"id":64},"法则7避免-css-表达式","法则7：避免 CSS 表达式",[10,67,68],{},"CSS 表达式是功能强大的(同时也是危险的)用于动态设置CSS属性的方式。IE从版本5开始支持 CSS 表达式，如 backgourd-color: expression((new Date()).getHours()%2?”#B8D4FF”:”#F08A00”)，即背景色每一个小时切换一次。 CSS表达式的问题是其执行次数超过大部分人的指望。 不只页面显示和 resize 时计算表达式，并且当页面滚屏，甚至当鼠标在页面上移动时都会从新计算表达式。 一种减小CSS表达式执行次数的方法是一次性表达式，即当第一次执行时就以明确的数值代替表达式。若是必须动态设置的话，可以使用事件处理函数代替。若是您必须使用CSS表达式的话，请记住它们可能被执行上千次，从而影响页面性能。",[14,70,72],{"id":71},"法则8把javascript和css放到外部文件中","法则8：把JavaScript和CSS放到外部文件中",[10,74,75],{},"上述不少性能优化法则都基于外部文件进行优化。如今，咱们必须问一个问题：JavaScript 和CSS应该包括在外部文件，仍是在页面文件中？在现实世界中，使用外部文件会加快页面显示速度，由于外部文件会被浏览器缓存。若是内置JavaScript 和CSS 在页面中虽然会减小HTTP请求次数，但增大了页面的大小。 另一方面，使用外部文件，会被浏览器缓存，则页面大小会减少，同时又不增长 HTTP 请求次数。 所以，通常来讲，外部文件是更可行的方式。 惟一的例外是内嵌方式对主页更有效，如Yahoo!和My Yahoo!都使用内嵌方式。通常来讲，在一个 session中，主页访问此时较少，所以内嵌方式能够取得更快的用户响应时间。",[14,77,79],{"id":78},"法则9减小dns查询次数","法则9：减小DNS查询次数",[10,81,82],{},"DNS用于映射主机名和IP地址，通常一次解析须要 20～120 毫秒。 为达到更高的性能，DNS解析一般被多级别地缓存，如由ISP或局域网维护的caching server，本地机器操做系统的缓存（如 windows 上的 DNS Client Service）浏览器的缺省 DNS 缓存时间为30分钟，Firefox的缺省缓冲时间是1分钟。 IE减小主机名可减小DNS 查询的次数，但可能形成并行下载数的减小。避免DNS查询可减小响应时间，而减小并行下载数可能增长响应时间。 一个可行的折中是把内容分布到至少2 个，最多4个不一样的主机名上。",[14,84,86],{"id":85},"法则10最小化javascript代码","法则10：最小化JavaScript代码",[10,88,89],{},"最小化JavaScript代码指在JS代码中删除没必要要的字符，从而下降下载时间。 两个流行的工具是JSMin 和YUI Compressor。 混淆是最小化于源码的备选方式。 象最小化同样，它经过删除注释和空格来减小源码大小，同时它还能够对代码进行混淆处理。 做为混淆的一部分，函数名和变量名被替换成短的字符串，这使得代码更紧凑，同时也更难读，使得难于被反向工程。Dojo Compressor (ShrinkSafe)是最多见的混淆工具。 最小化是安全的、直白的过程，而混淆则更复杂，并且容易产生问题。从对美国10大网站的调查来看，经过最小化，文件可减小 21%，而混淆则可减小25%。 除了最小化外部脚本文件外，内嵌的脚本代码也应该被最小化。 即便脚本根据法则4被压缩后传输，最小化脚本刻减小文件大小 5%或更高。",[14,91,93],{"id":92},"法则11-避免重定向","法则11： 避免重定向",[10,95,96,97,103,104,108,109,113],{},"重定向功能是经过301和302这两个HTTP状态码完成的，如：HTTP\u002F1.1 301 Moved Permanently Location: ",[98,99,100],"a",{"href":100,"rel":101},"http:\u002F\u002Fexample.com\u002Fnewuri",[102],"nofollow"," Content-Type: text\u002Fhtml 浏览器自动重定向请求到 Location 指定的 URL 上，重定向的主要问题是下降了 用户体验。 一种最耗费资源、常常发生而很容易被忽视的重定向是URL的最后缺乏，如访 问",[98,105,106],{"href":106,"rel":107},"http:\u002F\u002Fastrology.yahoo.com\u002Fastrology",[102]," 将被重定向到 ",[98,110,111],{"href":111,"rel":112},"http:\u002F\u002Fastrology.yahoo.com\u002Fastrology\u002F",[102],"  。在 Apache 下，能够经过Alias，mod_rewrite或 DirectorySlash 等方式来解决该问题。",[14,115,117],{"id":116},"法则12删除重复的脚本文件","法则12：删除重复的脚本文件",[10,119,120],{},"在一个页面中包含重复的JS脚本文件会影响性能，即它会创建没必要要的HTTP请求和额外的JS执行。 没必要要的HTTP请求发生在IE 下，而 Firefox 不会产生多余的HTTP请求。 额外的JS执行，无论在IE下，仍是在Firefox下，都会发生。 一个避免重复的脚本文件的方式是使用模板系统来创建脚本管理模块。 除了防止 重复的脚本文件外，该模块还能够实现依赖性检查和增长版本号到脚本文件名中，从而实现超长的过时时间。",[14,122,124],{"id":123},"法则13配置-etags","法则13：配置 ETags",[10,126,127],{},"ETags 是用于肯定浏览器缓存中元素是否与 Web server 中的元素相匹配的机制， 它是比 last-modified date 更灵活的元素验证机制。ETag 是用于惟一表示元素版本的字符串，它需被包括在引号中。Web server 首先在 response 中指定 ETag： HTTP\u002F1.1 200 OK \u003C 03:03:59 2006 Dec 12> 10c24bc-4ab-457e1c1f” Content-Length: 12195后来，若是浏览器须要验证某元素，它使用 If-None-Match 头回传 ETag 给 Web server，若是 ETag 匹配，则服务器返回304代码，从而节省了下载时间：GET \u002Fi\u002Fyahoo.gif HTTP\u002F1.1 Host: us.yimg.com \u003C 03:03:59 2006 Dec 12> 10c24bc-4ab-457e1c1f” HTTP\u002F1.1 304 Not Modified ETags 的问题在于它们是基于服务器惟一性的某些属性构造的，如 Apache1.3 和 2.x，其格式是 inode-size-timestamp，而在 IIS5.0和 6.0 下，其格式是 Filetimestamp:ChangeNumber。这样同一个元素在不一样的 web server 上，其 ETag 是不同的。这样在多 Web server 的环境下，浏览器先从server1 请求某 元素，后来向 server2 验证该元素，因为 ETag 不一样，因此缓存失效，必须从新 下载。",[10,129,130],{},"所以，若是您未用到 ETags 系统提供的灵活的验证机制，最好删除 ETag。删除 ETag会减小 http response 及后续请求的 HTTP 头的大小。微软支持文章描述了 如何删除ETags，而在 Apache 下，只要在配置文件中设置 FileETag none 便可。",[14,132,134],{"id":133},"法则14缓存-ajax","法则14：缓存 Ajax",[10,136,137],{},"性能优化法则一样适用于web 2.0 应用。提升Ajax的性能最重要的方式是使得其response 可缓存，就像“法则3”增长 Expires Header”讨论的那样。如下其余法则一样适用于 Ajax，固然“法则3”是最有效的方式。",{"title":139,"searchDepth":140,"depth":140,"links":141},"",2,[],[143],"web开发",true,"2015-10-29 11:53:58","Web 应用性能优化黄金法则：先优化前端程序 (front-end) 的性能，由于这是80% 或以上的最终用户响应时间的花费所在。javascript 法则1： 减小HTTP请求次数 80%的最终用户响应时间花在前端程序上，而其大部分时间则花在各类页面元素， 如图像、 样式表、 脚本和 Flash ",false,"md","YaHoo-14",{},"\u002Fblog\u002F2015\u002F10\u002F29\u002Fyahoo-14",{"title":5,"description":146},"blog\u002F2015\u002F10\u002F29\u002FYaHoo-14",[155],"网站优化",null,"Bk-jEisOJjjiIrSk1hZrK-YFquvkDE8Bn0puGbVpw6c",1783807996125]