“喂？雅虎军规，我能在前端优化中做什么？”

一直闻 雅虎军规 之大名，虽然种种原因，以前一直没看，但是近日阅读时发现，受前辈们的影响，我一直在潜意识中使用这些“军规”。

曾经有位老师告诉我说：虽然现在随着各种框架、插件的兴起，有些军规已经不再完美，但是，雅虎军规的意义和它透漏出来的关于性能优化的思想，仍然是需要我们借鉴的。

基于此，我想根据自己写项目的经验，来谈谈这著名的 “雅虎军规”：

1、图片压缩

这个不必多说，见标题思意，压缩图片，在前端页面上用处巨大。这里推荐一个压缩图片的网站，格式的话推荐ps就好。

2、优化css雪碧图

不能否认，雪碧图的出现曾经震撼了前端技术圈，但是现在来说，雪碧图的使用可谓是越来越少（但在某些图片大而且多的网站里还发挥着余热）。
使用雪碧图只有一个优点：减少请求次数，这和它不可避免的缺点：高清屏会失真、图片变化极不方便相比，可谓不值一提。
相比雪碧图，我倒是更推荐使用icon字符集，或者预加载和懒加载。

3、禁止缩放图片在HTML文档里

不要在HTML中缩放图片！
永远不要在img标签里的width和height中改变图片的大小。这对性能是有损伤的。一位老师告诉我说，img里的width和height只是为了告诉计算机，你的图片究竟有多大，而不是为了告诉你，这里的图片你想放多大。
改变图片大小的事情还是要交给css（静态改变）或js（动态改变）来做
比如你又一张100X100的图片，你在标签里就应该这样写：

<img width="100" height="100" src="路径" alt="替代文字"></img>

4、关于css

能在css里写的就不要在js里写！
因为css写在head里一般不会去阻塞程序执行（好像说是异步线程，同时加载），而js会。
但是这也带来了问题：
HTML规范明确表明：样式（css）一定要放在head标签里！
研究雅虎网页性能时发现把样式表移到 里会让页面更快。这是因为把样式表移到 里允许页面逐步渲染。
关注性能的前端工程师希望页面被逐步渲染，这是因为，我们希望浏览器尽早渲染获取到的任何内容。这对大页面和网速慢的用户很重要。给用户视觉反馈，比如进度条的重要性已经被大量研究和记录。在我们的情况中，HTML 页面就是进度条。当浏览器逐步加载页面头部，导航条，logo 等等，这些都是给等待页面的用户的视觉反馈。这优化了整体用户体验。
把样式表放在文档底部的问题是它阻止了许多浏览器的逐步渲染，包括 IE。这些浏览器阻止渲染来避免在样式更改时需要重绘页面元素。所以用户会卡在白屏。

一定注意：这里放在head里的css是指通过<style>包裹的，而不是通过<link>外链引入的（事实上，这并没有太大作用）

避免css表达式

我知道，css表达式是强大的，但也是危险的。
就拿IE来说，从IE5开始支持css表达式，到IE8不赞成使用。css表达式可能比我们知道的更麻烦：它们不仅在页面载入和调整大小时重新计算，也在滚动页面甚至是用户在页面上移动鼠标时计算。比如在页面中移动鼠标可能轻易超过10000次，那么，页面由于css的改变就要重新渲染10000+次。
比如这个：

background-color:expression((new Date()).getHours()%2?"#B8D4FF":"#F08A00");

我们要避免这样。或者避免表达式计算太多次，如果非要用，可以在它第一次计算后替换成确切值。

采用gzip压缩文件

http 请求或响应的传输时间可以被前端工程师显著减少。终端用户的带宽，ISP，接近对等交换点等等没法被开发团队控制，但是，压缩可以通过减少 http 响应的大小减少响应时间。
从 HTTP/1.1 开始，客户端通过http请求中的 Accept-Encoding 头部来提示支持的压缩：

Accept-Encoding: gzip, deflate

如果服务器看到这个头部，它可能会选用列表中的某个方法压缩响应。服务器通过Content-Encoding 头部提示客户端：

Content-Encoding: gzip

gzip 一般可减小响应的 70%。尽可能去gzip更多（文本）类型的文件。html，脚本（js），样式（css），xml 和json 等等都应该被gzip，而图片，pdf等等不应该被gzip，因为它们本身已被压缩过，gzip 它们只是浪费 cpu，甚至增加文件大小。

把脚本放在最下面

脚本引起的问题是它们阻塞了并行下载。HTTP1.1 规范建议浏览器每个域名下不要并行下载超过2个组件。如果你的图片分散在不同服务器，那么你能并行下载多个图片。但当脚本在下载的时候，浏览器不会再下载其它文件，即使在不同域名下。
有些情况下把脚本移动到底部并不简单。比如，脚本中用了 document.write 来插入内容，它就不能被移动到底部。另外有可能有作用域问题。但大多数情况，有方法可以解决这些问题。
一个替代建议是使用异步脚本。defer 属性表明脚本不包含 document.write，是提示浏览器继续渲染的线索。不幸的是，Firefox 不支持。如果脚本能异步，那么也就可以移动到底部，这样可以大大加快网页运行速度。
并且，我们可以多使用外部的js

开发聪明的事件处理

有时候页面看起来不那么响应（响应速度慢），是因为绑定到不同元素的大量事件处理函数执行太多次。这是为什么使用事件委托是一种更好的解决方法。
另外，你不必等到 onload 事件来开始处理 DOM 树，DOMContentLoaded 更快。大多时候你需要的只是想访问的元素已在 DOM 树中，所以你不必等到所有图片也被下载。

我曾经在本专栏中说过：
onLoad是的在页面所有文件加载完成后执行
DomContentLoad是Dom加载完成后执行，不必等待样式脚本和图片加载

最小化http请求

到终端用户的响应时间 80% 花在前端：大部分用于下载组件 js/css/image/flash 等等。减少组件数就是减少渲染页面所需的 http 请求数。这是更快页面的关键。
减少组件数的一个方法就是简化页面设计。保持富内容的页面且能减少 http 请求，有以下几个技术：
Combined files (合并文件)，如合并 js，合并 css 都能减少请求数。如果页面间脚本和样式差异很大，合并会更具挑战性,同时也这样也可以减少发布所需要的时间。
CSS Sprites。雪碧图可以合并多个背景图片，通过 background-image 和 background-position 来显示不同部分。
Image maps (雪碧图)。合并多个图片到一个图片，一般用于如导航条。由于定义坐标的枯燥和易错，一般不推荐。
Inline images (内联图片)。使用 data:url scheme 来内联图片，将内嵌图像组合到（缓存的）样式表中同样也是一种减少 HTTP 请求并避免增加页面大小的方法。
减少请求数是为第一次访问页面的用户提高性能的最重要的指导。

雅虎军规中有人提出：Inline images 这里我们一些矢量图标转换为base64编码，然后直接内嵌到HTML文件或者CSS文件当中，减少http请求。

但我认为这实非明智之举：base64巨大巨长的编码型字符让计算机眼中的css文件变得“似乎苦涩难懂”，这使得css因为体积倍增的缘故，也能影响到渲染（回流和重绘）。

No 404

这里有一句闻名已久的话：http 请求是昂贵的。
所以发出 http 请求但获得没用的响应（如404）是完全不必要的，并且会降低用户体验。
一些网站会有特别的 404 页面提高用户体验，但这仍然会浪费服务器资源。特别坏的是当链接指向外部 js 但却得到 404 结果。这样首先会降低（占用）并行下载数，其次浏览器可能会把 404 响应体当作 js 来解析，试图从里面找出可用的东西。