最理想的方式，无非就是统一使用onload来检测link元素是否加载完毕。但是事不与程序猿人愿~ 但是兼容办法还是有的。

在IE、Opera下，可以直接使用onload、onreadystatechange这两种方式都可以检测link元素是否加载完成，跟检测script一样的原理。

在Chrome、Safari等基于Webkit内核的浏览器下，估计就要监控document.styleSheets.length的变化了。Webkit内核的浏览器在处理document.styleSheets.length的方式是这样的，当加载完了一个link之后，length就会加1，那么这样的话，就可以使用setInterval的方式来检测length的变化了，对于同时检测多个link是否加载完成的方式也可以利用这个，看length增加了多少。《测试用例》示例如下：

[javascript]
var link = document.createElement("link");
var cn = document.styleSheets.length;

var ti = setInterval(function() {
if (document.styleSheets.length > cn) {
alert("CSS loaded");
clearInterval(ti);
}
}, 10);

link.href="http://www.ilovejs.net/lab/css.php";
link.rel = "stylesheet";
document.getElementsByTagName("head")[0].appendChild(link);
[/javascript]

但是在Firefox下，情况就有些恶心了，所使用到的方式跟上面的两类浏览器的处理方式都不太相同。对于document.styleSheets.length的处理也不同于Webkit，它的处理方式是只要link元素一附加到document之后，length就会立即加1，而不管css文件是否加载完毕（测试用例如上面的链接）。为此，对于Firefox的处理方式，使用style标签，而不是link，并且使用传统的@import的方式，通过判断style.sheet.cssRules是否存在来检测css文件是否加载完成，具体如下所示《测试用例》：

[javascript]
var head = document.getElementsByTagName("head")[0];

var style = document.createElement(‘style’);
//加载css.php文件，需要2秒之后才会返回响应内容
style.textContent = ‘@import "http://www.ilovejs.net/lab/css/css.php"’;
style.rel="stylesheet";

var fi = setInterval(function() {
try {
style.sheet.cssRules; // 这句是关键，在css加载完成的时候，style元素就会有这么个对象。

alert("CSS loaded");

clearInterval(fi);

} catch (e){}

}, 10);

head.appendChild(style);
[/javascript]

为此，想要写一个兼容性的检测CSS文件是否加载完成的代码，估计看起来会比较丑陋，差异大，处理的方式各异，期待onload统一的那一天咯~~

起初看到这个标题觉得很惊奇，细看了上面罗列的文章之后，发现也只是利用了解析器的原理（解析器本来就是这么设计的，或许不是bug吧），对<!- – 的处理的不同，来实现将js和css代码混合在一起的方法。从PLT(page load time)来讲，确实将两个HTTP请求减少到一个了，从某种程度上可以减少PLT，但是它所带来的负面的影响和风险也还是比较大的，比如：

1. 增加了代码的复杂度，难以阅读。
2. 增加了代码量。特别是需要在处理CSS代码的时候，每一行都需要添加<!- -，这个无形中增加了文件的代码量。
3. 无法进行代码压缩。
4. 在IE下会出现出错的风险。经过测试发现：如果在body中存在<!- – - ->，或者在body和head标签之间存在这个HTML注释，在IE下就会出错。试试看

所以并不太推荐使用，也不太看好。

query根据CSS规则来查询DOM，提供了基础的CSS选择符：

tag,.class,#id,[attr],tag[attr],tag[attr="value"]...

在测试跟jquery的查询速度比较的时候，再添加了对querySelectorAll（语法是：baseElement.querySelectorAll(selector)，这里的baseElement其实是可以为除了文本节点和空节点之外的任何的DOM节点的，别以为只是document而已）的支持。编写的代码中加入了本人认为不错的编写方式，如果你对阅读代码有兴趣，那就看看吧，欢迎提出更好的方式(如果这里显得难看了，就自己下载来看：query.js)：

[javascript]
;(function(g){
var D = document,
_tag = function(tag,p){
return p.getElementsByTagName(tag || "*");
};
var _queryMethod = {
"#":function(q){
var bits = q.split("#"),
tagName = bits[0],
id = bits[1],
element = D.getElementById(id);
return tagName && element.tagName.toLowerCase() != tagName ? [] : [element];
},
".":function(q,p){
var bits = q.split("."),
tagName = bits[0],
cn=bits[1],
elems = null,
returnEl = [],
index = 0;
for(var i=0,l = p.length;i<l;i++){
elems = _tag(tagName,p[i]);
var tmp = null;
for(var j =0,m = elems.length;j<m;j++){
if(!/\S/.test((tmp = elems[j]).nodeValue)) continue;
if(new RegExp("\\b"+cn+"\\b").test(tmp.className)){
returnEl[index++] = tmp;
}
}
}
return returnEl;
},
"tag":function(q,p){
var found,returnEl = [],index=0;
q = q;
for(var i=0,l=p.length;i<l;i++){
found = _tag(q,p[i]);
for(var j =0,m=found.length;j<m;j++){
returnEl[index++] = found[j];
}
}
return returnEl;
},
"attr":function(operation,tag,attr,attrValue,p){
var found =[],returnEl = [],index=fIndex=0;

for(var i=0,l=p.length;i<l;i++){
var tmp = _tag(tag,p[i]);
for(var j=0,m=tmp.length;j<m;j++){
found[index++]=tmp[j];
}
}

//不错吧？ ^_^
var checkFn = {
‘=’:function(e) { return (e.getAttribute(attr) == attrValue); },
‘~’:function(e) { return (e.getAttribute(attr).match(new RegExp(‘\\b’+attrValue+’\\b’))); },
‘|’:function(e) { return (e.getAttribute(attr).match(new RegExp(‘^’+attrValue+’-?’))); },
‘^’:function(e) { return (e.getAttribute(attr).indexOf(attrValue) == 0); },
‘$’:function(e) { return (e.getAttribute(attr).lastIndexOf(attrValue) == e.getAttribute(attr).length – attrValue.length); },
‘*’:function(e) { return (e.getAttribute(attr).indexOf(attrValue) > -1); },
‘a’:function(e) { return e.getAttribute(attr);}
}[operation];

for(var i=0,l=found.length;i<l;i++){
if(checkFn(found[i])){
returnEl[fIndex++] = found[i];
}
}
return returnEl;
}
}

//处理每一个token
var _querySelector = function(q,p){
var elements = /#/.test(q) ? _queryMethod["#"](q) : /\./.test(q) ? _queryMethod["."](q,p) : [];
if(elements.length) return elements;
if(!elements.length && q.match(/^(\w*)\[(\w+)([=~\|\^\$\*]?)=?"?([^\]"]*)"?\]$/)){
return _queryMethod["attr"](RegExp.$3 || "a",RegExp.$1,RegExp.$2,RegExp.$4,p);
}
if(!elements.length){
return _queryMethod["tag"](q,p);
}
return elements;
}

var _query = function(q){
if(document.querySelectorAll){return document.querySelectorAll(q);}
var tokens = q.split(‘ ‘),token,elems=[D];
for(var i=0,l=tokens.length;i<l;i++){
elems=_querySelector( tokens[i],elems);
}
return elems;
}
g.query=_query || {};
})(this);
[/javascript]
我很经得起批的……《测试示例》

CSS2.1的容错方式总的来说就是：对于出现一些无效的属性、属性值、@-keywords等等，它就会忽视这些样式声明或者整个规则声明。对于无效的属性、属性名会忽视该样式声明，对于@-keywords中keywords无效时，会将整个@-keywords包含的样式声明都忽略掉。

既然CSS2.1有这个容错机制，那么还有其他一些平时比较容易忽略的错误导致的样式失效的问题，下面举例出一些实例，看完下面的实例，基本可以了解CSS解析器解析CSS代码的一些原理了。

1. 不要在CSS每个规则之间插入除空格之外的无效字符或者插入不合CSS语法的注释，否则该无效字符之后的第一个规则无效，例如：

   body{color:green;}.  /*这里不小心多了个点号就杯具了*/
   p.ten{color:red; background-color:green;} /*这个规则是无效的*/
   p.one{color:red;} /*这个有效*/
   

   有一种情况比较特殊，当无效字符等使用大括号“{}”包含的时候，它下面的规则正常应用了，因为浏览器CSS解析器将它当作一条规则来处理。比如：

   body{color:green;}
   {.}
   p.ten{color:red; background-color:green;} /*它可以work啦*/
   

2. 跟上面对应的就是在样式中出现无效字符或者插入不合CSS语法的注释，则当前无效字符之后的第一条样式无效，例如：

   p.one{border-style:solid; . color:#00c; font-weight:bold;}  /*color无效*/
   

   但是有一种情况比较特殊，就是存在分号“;”的时候，前面带有无效字符也没影响。可能浏览器CSS解析器是将样式规则用分号进行拆分成数组，每个分号之前的样式不会影响下一个样式，比如：

   p.one{border-style:solid; . ; color:#00c; font-weight:bold;} /*color有效*/
   

   因此从这里，有可以引申出一个问题：当编写每一个样式的时候最后没有加上分号，当前样式的下一个样式就会无效，因为浏览器把它解析成一整个属性:属性值对了（如果只有一个样式，或者是最后那个样式没有加上分号，则没什么影响。根据数组的split原理，建议是最后那个样式不加分号，这样就减少一个空的数组元素），比如：

   /*下面就杯具了*/
   p.one{
     border-style:solid
     font-weight:bold
   }
   /*这还不错*/
   p.one{
     border-style:solid;
     font-weight:bold
   }
   

3. 不要在颜色值(英文、十六进制等等)上加上双引号，否则该样式规则无效，例如：

   body{color:"red";background-color:"green";}
   

4. 给元素设置border的时候，如果没有设置border-color，则会使用字体的颜色来代替；如果没有设置border-width，则默认是medium。例如:

   p.one{border-style:solid; color:#00c;}
   

5. 在一些连写的CSS规则中，如果其中一个元素的规则声明出现错误，则整个规则无效，比如：

   p.one,em @,strong{border-style:solid; color:#00c;} /*这里em @ 出错，造成整个规则失效*/
   

6. 如果在一个规则中样式进行了重复定义，如果其中一个样式的值无效（或者为空），那么不会覆盖有效的值的样式，因为浏览器会忽略掉无效值的样式声明，比如：

   p.ten{color:red; background-color:green;color:ss;} /*color还是red*/
   

7. 规则声明不可以嵌套：p.ten{color:#00c;p.ten{color:#f00};background:#0c0}
8. 在规则的特殊性方面，对元素声明样式时，将样式定义在它自身上和定义在它父元素上的优先级差别：将样式定义在子元素上，即使是使用标签类型的规则都比父元素使用ID、class、important等这样高优先级的都高，比如：span是p元素的子元素，p带有ID属性为ten

   span{color:red;} /*文本的color样式还是red*/
   body p#ten{color:green !important;}
   

9. 对于无效的属性或者属性值，CSS解析器会直接忽略掉这些属性或者属性值，也就使得这条样式声明无效，比如：

   img { float: left }       /* correct CSS 2.1 */
   img { float: left here }  /* "here" is not a value of 'float' */
   img { background: "red" } /* keywords cannot be quoted */
   img { border-width: 3 }   /* a unit must be specified for length values */
   
   /*解析过后，是：*/
   img { float: left }
   img { }
   img { }
   img { }
   

10. 属性值中双引号和单引号要闭合，否则结果很悲剧，例如：

    p {
       color: green;
       font-family: 'Courier New Times
       color: red;
       color: green;
    }
    解析过后，就成了：
    p{
      color:green;
      color:green;
    }
    

平时是我们太循规蹈矩的去编写CSS代码了，对于一些因为粗心造成的失误而导致样式失效的问题，浏览器又没有很好的提示CSS错误的功能，所以只能是通过肉眼看样式是否生效来测试CSS代码了。其实当你不遵循CSS语法来写的时候，会发现更多的CSS的解析失效问题，或许这就是CSS Hack被发现的源头吧……

详细CSS2.1容错机制可以浏览：http://www.w3.org/TR/CSS21/syndata.html#parsing-errors

话说多了不足为信，看一个简单的测试：《测试js何时开始加载（用firebug查看HTTP瀑布图，或者HTTPWatch、Inspection等等均可）》，代码示例如下

[javascript]
var s = document.createElement("script");
s.setAttribute("src","test.js");

var l =document.createElement("link");
l.setAttribute("href","/wp-content/c/style.css");
l.setAttribute("rel","stylesheet");

var img = new Image();
img.setAttribute("src","/wp-content/uploads/2010/06/performance.png");
//document.body.appendChild(img);
document.body.appendChild(l);
document.body.insertBefore(s,document.body.lastChild);
[/javascript]

通过上面的测试发现：图片先加载，之后是js，最后是css文件。但是看上面的代码，图片并没有插入到文档中，但是它还是加载了；虽然js先于图片声明，但是却在图片之后加载；CSS虽然后于js声明，但是先于js加载。

这就有意思了，通过上面的测试说明：使用new Image声明的图片，在设置它的src属性之后就会开始加载；js和css文件在插入到文档之后才开始加载。通过这个特点，我们在性能优化方面就可以再总结几点想法了：

1. 通过使用Script DOM Element的方式加载js的时候，虽然说是可以同其他资源并行加载和异步执行，但是如果加载的js可以在页面加载完成之后才需要起作用的，可以在</body>前面来声明并插入到页面中，从而可以多让其他资源并行加载，而js最后加载并执行，加快页面的加载速度，这样的话将js插入到head和document.body都一样的效果。
2. 同样使用Link DOM Element的方式加载css文件的时候（如果一定要这样做的话），因为样式表关系到整个页面的布局和样式渲染，所以它需要尽早的被加载进来并开始渲染，以免造成页面内容显示的延迟和IE下“白屏”的问题。
3. 在优化图片加载的需求上，虽然图片加载是并行的，但是浏览器并行加载资源的数目是受到限制的，对于那些不是在浏览器第一屏（打开网页时在浏览器视窗内看到的内容）看到的图片、图片Tab组件、图片列表等等，可是使用上面的方式动态来插入，在页面其他重要的内容和资源都加载完毕的时候，其次的图片动态的插入，使得浏览器开始加载这些的图片。对于加快页面的显示速度，这也是不错的方式。

之前的测试都在页面中直接通过link元素外联css文件，但是动态插入的情况呢？（非常感谢Emu的提醒）

因此，又测试了使用DOM Element的方式来动态插入link元素，并外联css文件，可是问题依旧，《测试示例》。IE、Chrome、Safari照常需要等到全部的样式表都加载下来才开始呈现页面样式；FF、Opera是加载完一个样式表就渲染页面，而不需要等到全部的样式表都加载下来。

之后，测试使用一个定时器(setTimeout)的方式来异步执行动态加载css文件，《测试页面》，这下子就有点意思了：IE出现了无样式内容闪烁，仍然需要等全部的样式表都加载下来之后才呈现页面；Chrome、Safari跟FF、Opera一样了，加载完一个样式表就渲染页面，不需要等到全部的样式表都加载下来。

不过定时器的方式虽然解决了Chrome、Safari的问题，但是使得IE可能会出现无样式内容闪烁，所以也并不是很完美的方案，就看网站的用户群偏向哪些浏览器多一些了，并对这些浏览器做这方面的优化。

——————— 完美的分界线 ———————-

一直存在一个疑问：IE同其他主流浏览器的兼容性差异都涉及到布局、HTML、Javascript、CSS规则等方面，但是对于解析样式表来渲染整个页面呢，是否也存在异同？当看到Steve Souders的博文《Frontend SPOF》，迷惑揭开了，文中对各种浏览器解析样式表的机制做了如下描述：

Browsers are split on how they handle stylesheets. Firefox and Opera charge ahead and render the page, and then flash the user if elements have to be redrawn because their styling changed. Chrome, Internet Explorer, and Safari delay rendering the page until the stylesheets have arrived. (Generally they only delay rendering elements below the stylesheet, but in some cases IE will delay rendering everything in the page.) If rendering is blocked and the stylesheet takes a long time to download, or times out, the user is left staring at a blank page. There’s not a lot of advice on loading stylesheets without blocking page rendering, primarily because it would introduce the flash of unstyled content.

上面说的很明白，对于样式表的加载和渲染的原理，不同的浏览器下有不同的行为，主要是分为Firefox、Opera和IE、Chrome、Safari两类。

Firefox、Opere在加载样式表的时候是边加载边渲染。这样既有利也有弊：利在使得页面可以尽快的开始渲染，而无须等待全部的样式表都加载下来之后再开始渲染，延迟了页面渲染；而弊端在于之前加载并渲染的样式在后面又重新定义或者修改了布局样式，那么将会造成一定程度上的闪烁，闪烁的程度主要看所影响的元素的范围和数目。

而IE、Chrome、Safari则是在全部的样式表完全加载下来之后才开始渲染页面样式。这样做也同样是有利有弊：利在于可以避免Firefox、Opera中出现的闪烁的问题（虽然在IE下闪烁是经常的事情），可以确保样式会统一解析并渲染页面；而弊端在于页面全部样式表的加载延迟了页面渲染的时间，如果样式表加载的时间较长，或者加载错误，将会导致页面一直处于空白状态或者无样式状态，还有可能是“无样式内容的闪烁“的问题的出现。

为了证实上面的说法，进行了一个测试，这个测试的关键是延迟样式表的加载，但是不能延迟了HTML页面的加载和解析，并在页面中添加几个样式表做比较。为此，利用PHP的sleep函数在其中一个样式表中延迟3秒，并放到body的底部来加载，而另外一个样式表放到head里加载：《浏览器解析样式表的测试》。测试结果很明显：FF、Opera是首先解析了第一个样式表，等第二个延迟加载的样式表加载下来的时候，改变了第一个样式表的样式，出现了闪烁；IE、Chrome、Safari则是需要等到第二个样式表也加载下来的时候才开始渲染页面样式，导致了3秒的渲染延迟。

通过上面的测试证实，明白了在页面中Minify CSS、Put CSS at the head的实质理由和重要性：最小化页面渲染延迟时间。并总结出下面几点：

1. 尽量避免将样式表放置到body中来加载，避免IE、Chrome、Safari延迟页面开始渲染的时间，也避免IE下的“空白闪烁”和“无样式内容的闪烁”等问题。
2. 如果页面中有几个样式表，尽量合并为一个样式表文件，避免FF、Opera样式闪烁的问题。既然文件大小总量不变，那就尽量保持HTTP请求数的最小化吧。
3. 在样式表Minify后，再Gzip压缩下，效果更佳，最小化各个浏览器对于加载并解析样式表的差异性而造成不同程度的用户体验的影响。
4. 尽早的让样式表加载，最好是在加载并解析HTML之后就开始加载样式表。但是也要避免样式表后紧跟行内脚本，从而造成对后续资源的阻塞。
5. 对于当前页面使用不到的样式表，就删除掉，避免整个站点的页面都使用同一个样式表，从而节省不必要的宽带和使得页面的渲染时间越早越好。

解析@font-face的机制在不同的浏览器下是不同的。

对于@font-face更多的叙述，在上面提到的那篇博文中有了详细的描述。但是对于它提出的说“IE doesn’t render anything in the page until the font file is done downloading if there is a SCRIPT tag above the @font-face declaration.”，说的是当在声明@font-face的前面如果存在script标签的时候，IE下不会渲染任何东西，页面一片空白，直到@font-face指定的字体加载完为止，这点经过测试，确实如此。

在声明@font-face的标签之前没有script标签的时候IE下并没有出现阻塞页面渲染的情况，但是如果前面有script标签的时候，不管是否是紧跟这script标签，只要在@font-face标签前面有script标签，就阻塞页面渲染：《没有script标签》，《紧跟script标签》，《不紧跟script标签》。

同时，我测试了@font-face是否会阻塞页面其他资源加载，测试发现并没有这个问题：《是否阻塞资源加载的测试》，而且在字体加载下来之前，忙指示器会一直处于等待状态。下面是各种浏览器对@font-face的测试比较结果，结果分为三类：IE，Firefox、Opera，Safari、Chrome。

1. 在Firefox、Opera中，并不会阻塞页面其他资源的加载，也不会影响页面渲染，而且在字体加载下来之前，对想应用该字体的内容会使用默认的字体显示，直到字体加载下来之后再渲染为指定的字体。因此，这两个浏览器测试效果最佳。
2. 在Safari、Chrome中，并不会阻塞页面其他资源加载，也不会影响页面渲染，但是在字体加载下来之前，对应用该字体的内容将会首先空白显示，但是内容尺寸是存在的，直到字体加载完成，才渲染字体样式。
3. 在IE下就分不同的情况了，如上所述，前面是否有script标签的情况。

对于@font-face的杯具的性能问题，如果没有必要，就尽量避免使用。如果一定要使用的话，可以使用使用lazy load的方式来加载，例如博文中给出的例子：

[javascript]
function lazyload() {
var sRule1 =
"@font-face {" +
" font-family: ‘Yanone’;" +
" src: url(‘/bin/resource.cgi?type=font&sleep=6′);" +
" src: local(‘Yanone’), " +
"url(‘/bin/resource.cgi?type=font&sleep=6′) " +
"format(‘truetype’);" +
"}";

var style1 = document.styleSheets[0];
if ( "function" === typeof(style1.insertRule) ) {
// Firefox, Safari, Chrome
style1.insertRule(sRule1, 0);
}else if ( "string" === typeof(style1.cssText) ) {
// IE
style1.cssText = sRule1;
}
}
[/javascript]

将上面的lazyload函数添加到页面的onload事件中去执行，这样就保证了页面的正常渲染并且实现特定字体样式的功能：《lazy load测试》。这个主要是解决IE下@font-face前面有script标签的问题，在其他浏览器下显示的时候，也都还是会在应用该字体的内容中产生空白闪烁、或者是默认字体和指定字体之间的切换闪烁。也都还是在一定程度上影响了用户体验，感觉有些不爽。“Tradeoff is anywhere!!”

上面的三个测试都是使用内联CSS的方式，考虑到使用外联CSS样式表的情况，又对此做了一番测试，发现了不同的状况：

1. 当link放在head时，IE6、8（没有IE7，测试不了）都是死心眼，偏执要阻塞整个页面的加载，在字体下载下来之前整个页面一片空白，其他浏览器跟内联CSS一样的显示：《外联CSS测试（在head内）》。
2. 当link放到body中时，IE8还是阻塞整个页面的渲染，可是IE6就不同了，IE6会阻塞整个页面样式的渲染，但是不会阻塞link前面的内容的显示，而是阻塞了其后面的内容的显示了，直到字体加载下来之后才开始渲染页面样式和显示link后面的内容。其他浏览器跟内联CSS一样的显示：
   《外联CSS测试（在body最底部）》，《外联CSS测试（在body中部）》
3. 当link前面带有script标签的时候，因为外联在head头部的时候在IE各版本都阻塞了，所以这个条件link在页面的任何位置都无所谓，主要测试link前面带有script标签，那就把link放在body中来测试。这下IE6也杯具了，阻塞了整个页面的渲染，IE8照常阻止整个页面渲染，其他浏览器同上。《外联CSS测试（在body中部），前跟script标签》，将link放到body最底部也一样阻塞整个页面的渲染：《外联CSS测试（在body最底部），前跟script标签》，其他浏览器同上。

对于页面中同时有script和link、style标签是很正常的事情，但是当样式中有@font-face的时候，情况就复杂了。更多的测试条件大家可以自行测试。有错误的地方，请不吝留言交流。

之前一直很想做这样的一个导航，可是苦思都不知道良方，还一直认为这需要几个背景图片，着实复杂；还有hover效果，更是会难些，而且有兼容性问题。之后在FF和IE6下测试了下Delicious的兼容性效果，它在ie6下的样式，使用了普通的背景样式，没有上面所看到的折角效果。

之后看了下它的背景图片，一下子豁然开朗了，关键在于使用负margin来实现即可。下面是我实现的样式截图：

而且在兼容性和代码方面都有所改善。在IE6下也可以实现折角的效果，但是没有hover效果。而在Delicious里是在超链接a标签下嵌套了span标签，在a:hover伪类下来处理span的背景变换。而我直接在li标签中使用:hover来处理鼠标hover的背景切换，代码更加简洁了点，并且通过hack来解决ie6下兼容性问题（Updates：因为把:hover写在了li标签上，所以可以直接去掉hack来兼容ie6的css样式，也能做到稳步退化的效果）。

具体的CSS样式和背景图片可以浏览《折角导航栏效果》页面，使用firebug等工具查看页面源码。

Updates:外联js文件的时候，给script标签带上async和defer属性
浏览器正常加载js文件的方式在性能上是比较糟糕的，阻塞了后续资源的加载和渲染，直到js文件加载并执行完毕。而async属性就顾名思义了，它使得js文件的加载和执行是异步的，不会阻塞后续资源的加载：《async加载Javascript测试》。当然了，要支持async的浏览器才行。
defer首先在IE下支持，最新版的FF等浏览器也相继支持了。它的主要作用是让js延迟加载，而不阻塞后续资源的加载和页面的渲染。这对于支持它的浏览器得到了一定程度的优化，而不支持的会忽略掉这个属性。
因此，建议同时加上async和defer属性，对大部分的浏览器都得到了优化，而不支持的浏览器也会按照默认的方式加载，何乐而不为呢。

昨天分享了些关于Web性能优化的几个方面《WEB性能优化系列一》，接下来分享下另外的一些优化方面的心得体会，算是续上一篇博文，欢迎指正~

因为本文的篇幅较小，就不提供链接目录了，提供PDF格式的文档下载：《WEB性能优化系列二》

1. Use efficient CSS selectors：使用高效的CSS选择符
关于高效的CSS选择符的叙述，很多书籍和网站很多博客都有相关的说明，尤其《Writing Efficient CSS for Use in the Mozilla UI》提出了很多的建议以及讲解了CSS引擎解析样式规则的原理。在那本《高性能网站建设进阶指南》中也独立出一章节来讲解高效的CSS选择符。
当浏览器开始下载HTML内容并解析HTML文档的时候，就会生成一个DOM节点树。而CSS选择符的匹配就是在这个节点树中查询符合条件的元素，并添加样式。当浏览器在解析CSS样式表的时候，它会解析样式表中的每一条样式规则，而不管最后样式规则是否会匹配到元素。
并且，CSS引擎是从右往左进行解析规则的，所以这里就有几点建议可以用来优化CSS选择符了：

1. 避免最右端的选择符选择过多的DOM元素。比如全局选择符“*”，标记符（.hide-scrollbars * {…}），这些在CSS引擎解析该规则的时候最开始会匹配DOM节点树中太多的节点，这样再往左匹配的时候，造成匹配所用的时间就更长了。所以，右边的选择符匹配的元素越少越好。
2. 对于子选择符或者说是邻近选择符（child-selector:ul > li > a）为什么低效，Google Page Speed做了如下解释：因为浏览器在解析一个选择符其中一步的时候，比如上面的a，首先它要确认它的父元素中存在li元素，同时还要判断li元素是否是a的直接父元素，这就需要两个判断操作，相比于后代选择符（ul li a）来说，它就多花费了一倍的性能消耗来执行每一步的匹配。
3. 避免一些累赘的选择符。比如在class类中增加了标签（div.sidebar），ID也同样。当然了，如果你想要通过这种方式来增加选择符的权重，这个就另当别论了。
4. 对于:hover选择符的选择。:hover选择符在IE7以上的版本的标准模式中都是良好的，但是一旦回退到怪癖模式，就跟IE6一个样了，只认超链接元素。所以总是声明标准的DOCTYPE，可以避免很多不必要的问题发生（推荐使用HTML5的声明方式）。
5. 从CSS引擎的解析原理出发，选择符越简短越好，越明确越好，确保右边的规则不会选择过多的DOM元素。同时，可以的话选择class来代替后代选择符。

2. Specify a character set early：尽早的声明character
这点在《页面中charset的meta声明将如何影响页面加载性能》这篇文章中有详细的介绍，这里就不多说了。

3. Specify image dimensions：声明图片的尺寸
很多网站页面中对图片都没有明确的声明图片img的尺寸（即：设置img标签的height和width属性为图片的原始大小，或者在CSS中声明，不过最好还是在img标签中直接声明）。明确的在img标签中声明图片的尺寸可以加快浏览器对图片的渲染和布局，从而避免不必要的回流（reflow）和重新渲染（repaint）。
当浏览器布局页面的时候，它需要循环检查那些元素是可以置换的，比如图片。如果浏览器预先知道了一个可以置换的元素（比如图片）的尺寸，那么就可以使得一些不可置换的元素跟这个可置换元素正常的布局，即使图片还没有加载下来，浏览器就可以开始正常的渲染、布局整个页面。
但是，如果没有预先声明的尺寸，或者声明的尺寸跟元素的实际尺寸不符，那么一旦这些元素下载下来的时候，浏览器就需要一次回流（reflow）和重新渲染（repaint）的过程。
因此，为了避免不必要的回流和重新渲染的操作，预先声明图片的宽高，并且这个宽高需要跟图片的实际大小相符，其他可置换元素也一样的原理。

4. Put CSS in the document head：将CSS文件放到head里声明
将行内样式和CSS文件都放到head部位来声明，可以使得页面能及时的渲染，也能避免不必要的“白屏”和“无样式内容的闪烁”的问题的产生。
同时还有一点需要说明的是：当使用@import来加载外部样式表的时候，也可能会出现上面提到的“白屏”和“无样式内容的闪烁”的问题，因为采用@import加载样式表的时候，加载顺序是不定的，它有可能使得样式表在最后才加载进来。还有避免样式表后面紧跟script标签所声明的行内脚本。

5. Put Javascript in the document bottom：将脚本文件放到文档的末尾
这个主要是考虑到正常通过script标签加载Javascript文件的时候，会阻塞后面一切资源的加载。所以尽可能的将Javascript文件都放到文档的末尾来加载，就不会影响页面的渲染进程，但是它仍然对onload事件造成延迟，直到文件下载并执行完毕。《http://www.ilovejs.net/lab/loadjs/》这个页面展示了动态加载Javascript文件的方式，可以有效的解决这个延迟问题。
同时，Javascript文件和样式表文件要按照合理的顺序来加载，避免阻塞样式表加载的问题。

6. Avoid CSS expressions：避免使用CSS expression
关于css的expression，应用的是比较少的，但是不能说它没有被使用。Css的expression会明显的降低页面渲染的性能，避免使用它会改善IE用户的体验。
CSS expression是在IE5的时候加进IE中的，使用它可以使得Javascript可以通过一些事件动态的操作CSS中的某些属性，从而来改变document的某些属性。它在IE5到IE7版本之间受支持，IE8声称不再受支持，同时其他浏览器都不支持。
但是使用CSS expression会造成非常糟糕的性能问题。因为在一些普通细小的操作都可能使得expression重复执行，比如：窗口缩放、鼠标移动等等，反正是触发了reflow的因素都会触发expression，这对IE用户来说，是很恶心的性能问题，严重的阻碍用户跟页面的交互操作，恐怖的就是使得IE崩溃了。

7. Combine external Javascript and CSS：合并外部的Javascript和CSS文件
这个主要是从最小化HTTP请求这个优化准则来说的，将几个Javascript文件或者几个CSS文件合并成一个文件，再结合Gzip压缩，来优化资源的加载时间。可以浏览这篇文章的说明：《Javascript,CSS Minify》。

8. Avoid bad requests：避免请求无效的链接
当我们点击了一个超链接，而这里链接的目的地却是无效的，这个不仅造成了恶心的404状态吗，而且还严重影响了用户体验。通过返回404状态的时候都是比较消耗时间的，因为服务器需要查询整个站点是否有这个链接所执行的资源，到最终重定向到一个404页面。而用户等待了些时间最后得来的，却是一个404 Not Found页面，很恶心的事情。
因此，当一个站点越来越大，更新快的时候，适时的检查页面的链接是否失效并及时的修正这些无效的链接，这对提高用户体验以及避免页面加载一些无用的字节都是有用的。

9. Minimize redirects：最少化重定向的数量
重定向在某些情况下是必须的，将用户从一个页面重定向到另外一个页面。但是重定向会触发额外的HTTP请求和响应的操作，并且增加了往返时间的延迟，而这个额外的HTTP请求和响应就是301和302状态码了。从重定向的时候服务器会返回一个301或者302状态码来确定此次请求是重定向，之后再发送请求到服务器请求另外一个页面来加载页面内容和资源。
这里我需要说明一点的是我们平时都可能不太在意的细节—URL，我们知道有些URL中有斜杠“/”，而有些URL中不包含，比如：http://www.example.com/sport和http://www.example.com/sport/ ，这两个URL中的区别仅仅是最末尾的一个斜杠，但是请求这两个URL时，第一个链接会产生一个重定向，因为服务器不知道请求的这个是文件还是目录，当判断是目录的时候，就会在URL的末尾加上一个斜杠（这就造成重定向），之后就会查询该目录下的index文件名的文件来响应请求；而第二个链接就会使得服务器直接省略重定向的操作，请求该目录下的index类型的文件。
通过，还可以几点说明：如果需要重定向几个页面的话，比如A—B—C，但是如果能直接A—C重定向就能实现功能的话，就尽量减少重定向的次数。
通常我们从跟一个页面重定向到另外一个页面的方式是采用Javascript的localtion或者在head里通过meta的方式来实现，但是这样都会因重定向造成的性能问题。对于上面提到的URL方面不注意造成的重定向，有时候可以通过在服务器端rewrite的方式来解决。这就可以使得从一个URL映射到另外一个URL，这个操作是服务器自动完成的，不会出发重定向的问题。

2010-6-8 Updates:在其他牛人的PPT中收集的一些优化技巧

1. 预加载资源。如果能预知用户下一步将会浏览哪个页面，就可以利用浏览器在当前页面的onload事件之后一点“空暇”时间来预加载一些资源（比如：图片、样式表、脚本等等），以期在下一个页面中会使用到。但是有一点必须要谨慎：预加载的资源不能影响当前页面的功能和效果，或者至少不能让用户察觉到。
2. 避免把样式表的加载放置到body中。例如：如果head部分已经加载了一个样式表，这个样式表会解析并且渲染页面样式，如果body中又加载了样式表，这个样式表又重新渲染了页面的一些模块的样式，或者重定义了一些样式规则，就显得累赘了。如果把页面中所有的样式表都放到body中加载，则延迟了页面的加载时间。
3. 加载外部脚本会阻塞页面的后续资源的加载，即使是不同域下的脚本也都是。
4. 避免将cookie设置到最高级域下。比如将cookie设置到example.com下，这样子域也会在HTTP请求头中带有主域的cookie。
5. 给永久的静态资源（图片、flash、样式、脚本）等添加Expires、Etag、Control-cache头来使得浏览器长久的缓存资源。使得重复浏览页面的时候从浏览器缓存读取资源。
6. 优化DOM的一系列操作。DOM、HTMLCollection对象的操作在Javascript中是非常低效的。优化DOM中循环操作对性能提高最甚，比如使用利用局部变量、转HTMLCollection为数组、定时器、事件委托、文档碎片（document fragment）等等方式。
7. 使用data:URL来链接base64编码的文件。这个方法尤其是在sprites图片背景或者其他一些下载文件的时候用到，但是由于IE6、7不支持data:URL，所以需对它们做特殊处理。本博客的sprites背景也使用了这种方式，具体的用法可以浏览《优化试试玩》一文。
   通过这样的方式，可以减少HTTP请求，但是又得保证它的可缓存性。
8. 在HTML中始终闭合标签，而不要依赖浏览器多出一个步骤来自动渲染闭合标签，况且IE下在缺失的闭合标签可能会导致布局错乱。

[html]
.bgimage { background-image: url("/images/button1.gif"); }
[/html]

1. 想象一下，当页面中没有元素使用了这个class的时候，背景图片是否会被下载？
2. 当页面中有元素使用了它，但是该元素又设置了display:none和visibility:hidden的时候，图片是否会被下载？

3. 当规则出现覆盖的时候，比如在接下来一个外联的css文件中重新定义了bgimage类，并且使用了不同的背景图片的时候，前面那张背景图片是否会被下载？比如：

   [html]
   .bgimage { background-image: url("/images/button2.gif"); }
   [/html]

对于上面的三个问题，Steve Souders已经在他的博文《5e speculative background images》里做了详细的叙述，在这里也先做一个原文意思的翻译：

1. 对于第一种情况，没有元素应用bgimage类的时候，图片不会被下载，这在所有浏览器都是一致的。

2. 当元素同时定义了display:none和visibility:hidden之后，不同的浏览器出现了不同的现象，Firefox3.6和Opera10.10不会下载背景图片，而IE8，Chrome，Safari却下载了，他还提供了一个测试页面《hidden background images》。

   但是，经过我的测试发现，全部的浏览器对元素设置了visibility:hidden时，也是会下载背景图片（为此还跟番茄来打赌，结果输了，只能承认是我人品有问题了，-_-）。在此提供两个测试页面，供大家自行测试：《display》，《visibility》。

3. 对于第三个问题，Steve Souders解释说也是“depends on the browser”，不同浏览器有不同的现象。Chrome和Safari下载了两个背景图片，IE、Firefox、Opera只下载了第二个图片button2.gif。《测试页面》

上面对于CSS中对背景图片的加载问题的三种情况的测试，是比较有意思滴。可以根据这几种情况来提高编写CSS的质量，避免不必要的背景图片在Chrome，Safari，IE下被加载了，造成了性能问题，尤其是第三种情况。但是，根据Steve Souders的一番调查，用他的博文上说：

I went on a search and couldn’t find any popular web site that overwrote the background-image style. Not one. I’m not saying pages like this don’t exist, I’m just saying it’s very atypical.

出现这种情况是比较少见的，但肯定还是会有。

说了那么多，上面的叙述只是个引子，接下来才是题目中说的两种编写规则的测试，但是这个测试也是从上面的几种情况中想到的。为此，我有一个疑问：当CSS代码中很多标签都引用了同一个背景图片，如果把这些标签都独立起来写规则（比如下面代码所示），页面是否会跟服务器进行了相应多的次数交互呢？

[html]
<!– 是否会跟服务器进行了三次的交互呢？即使第一个后面的请求都是从缓存中读取的，但是也必须会跟服务器交互一次来确认吧？ –>
#test1{background:url(test.gif) no-repeat;}
#test2{background:url(test.gif) no-repeat;}
#test3{background:url(test.gif) no-repeat;}
…
[/html]

假设我的疑问是正确的，那么让我们来进行下面的测试：

第一种、把所有都使用同一个背景图片的标签都定义在一起，这样就只有一个CSS规则：
[html]
#test1,#test2,#test3…{
background:url(test.gif) no-repeat;
}
[/html]
第二种、把所有都使用同一个背景图片的标签根据具体情况都分开定义：
[html]
#test1{background:url(test.gif) no-repeat;}
#test2{background:url(test.gif) no-repeat;}
#test3{background:url(test.gif) no-repeat;}
…
[/html]
先不从表面来说这两种写法的孰好孰坏，下面提供了两个测试页面，测试条件是：

1. 在页面中有2000个div元素，分别有不同的id属性
2. 为了尽量保持页面的大小，CSS规则都使用外联link的形式引入
3. 因为这两个测试主要是为了测试两种方式的渲染速度，所以尽量保持了两个CSS文件都是大小相同的（86多K）
4. 使用相同的背景图片，但是文件名不同，以防造成在测试的时候受缓存的影响。

基本条件都差不多了，现在来测试吧：《拆分的方式》，《结合的方式》。测试结果我就不说了，大家可以自行测试，毕竟相信浏览器，相信自己的眼睛和判断。

其实对于上面使用结合的方式来归类一些具有相同CSS规则的写法，是我之前在口碑实习期间，跟师傅乌龙茶学来的，刚开始还以为会增加一连串的CSS规则，给CSS文件页面的大小增加了不少的字节，但是当你整合好整体的CSS样式之后，你会发现，其实页面会有一个很好的架构，维护起来非常的方便（关于维护这点，有一个经验让我印象非常深刻，就是在今年4月20号的时候，公司要求口碑整站首页要变灰，当开始知道这事的时候，纳闷起来了，那么多首页，在一个下午的时间都要变灰，包括背景、链接、文字。但是，当我在修改灰色版本首页的时候，因为师傅之前是使用了结合的方式，背景、链接等等颜色样式都整合在了一起，所以整个CSS文件，只需要改动几处，问题就解决了，Fuck，还真省事）。所以，把具有相同CSS规则的标签的样式都写在一起，一个维护上也都是非常方便的。

今天去口碑网逛的时候，看到自己最后切的二级城市的页面改版的项目上线了。欣慰啊~，所以共享下本人在编写页面期间写的CSS文件，供指正：《http://www.ilovejs.net//lab/default-css/koubei.html》

各种浏览器之间对HTML元素默认的样式的不统一性，正是YUI reset css、HTML5 Reset Stylesheet以及Eric Meyer’s CSS reset被提出来的必要性。

更多参考：《踏上寻找webkit内核渲染HTML的默认样式之路》，《HTML默认样式和浏览器默认样式》，《Reset CSS研究（八卦篇）》，《Really Undoing html.css》，《SUNThink》，《CSS Compatibility and Internet Explorer》，《Cascading Style Sheet Compatibility in Internet Explorer 7》，《HTML5 Boilerplates》，《Eric Meyer’s CSS reset》，《YUI reset css》，《Mozilla all default Stylesheets》，《Webkit WebCore》

相信大家都熟悉那本《高性能网站建设指南》，而作为姊妹篇的《高性能网站建设进阶指南》也绝不会逊色于前者。通过校验该书的机会，也学习到了非常多关于web前端优化的具体的最佳实践，包括图片优化、Load Javascript without block，编写高效的Javascript、css代码，后加载（Initial Payload），拆分window.onload代码等等最佳实践，还介绍了众多的前端开发工具。可以总的来说：《高性能网站建设指南》是一本理论的书，而《高性能网站建设进阶指南》则是实践篇。

它确实是一本值得去反复阅读的好书！！

对于”Transfer-Encoding:chunked”HTTP响应头，虽然说它可以使得服务器可以以小块数据包的形式连续的发送HTML内容回来，或许有些人会认为：为什么不让他应用于Js，CSS呢，这样使得JS，CSS可以边加载边解析。理论上是可以的，但是实际是会崩溃的，在JS，CSS的响应头中应用它的时候，会造成JS，CSS加载失败，很悲剧的事情……

2010-6-2 Update:

今天捣鼓了下设置HTTP文档的响应头Transfer-Encoding:chunked。对于Transfer-Encoding的作用，在《高性能网站建设指南》中所说的就是“块编码”，它是HTTP/1.1引入的，使用它HTML文档可以被分成多个数据块立即返回，而不需要浏览器知道数据的大小和确定响应的结束时间，这就允许浏览器在下载数据包后马上进行解析，使得页面的加载速度更快。而HTTP/1.0是通过Content-Length头来发送的，而且还是将HTML一整块的发送，所以浏览器在响应结束之前，不会开始渲染页面和下载资源。

可是经过一上午的折腾，给页面加上了这个HTTP头之后，出错了，Chrome下返回错误“ERR_INVALID_CHUNKED_ENCODING”。郁闷了很久，之后在HTTPWatch官方博客上看到关于这个的文章《Content Length & Transfer Encoding》，在文章的Example中提到了一句话提醒了我：“if you are accessing this page through a proxy it may remove the chunked encoding”。想一下，还真是我设置了浏览器的代理，把Transfer-Encoding给删除了，同时经过测试，发现代理还会删除Trailer头。因此出错的原因就是跟代理冲突了。

但是代理不会删除HTTP响应头Content-transfer-encoding，不过在本站代理下测试，效果不明显，就没运用了，因为本站在未设置代理的情况下，是支持Transfer-Encoding的。下面是Transfer-Encoding有无情况的HTTP瀑布图，可以更直观的说明。

有Transfer-Encoding头的时候，HTML页面边下载边解析：


没有Transfer-Encoding头的时候，需要HTML页面全部下载完之后才开始解析：

2010-5-31 Update:

这次的优化是针对“最大化HTTP请求”这个需求来提升页面加载速度。之前注意到可以使用Data:URI的形式来连接图片，将图片通过base64编码过后直接写在页面上，但是如果使用这样方式将图片写在了HTML页面上了，这就会无疑增加了HTML页面的大小，而且Data:URI的大小跟图片的大小是直接相关的。所以在Nicholas C. Zakas的这篇博文中《Data URIs explained》提到了这么一段话：

Inline images use the data: URI scheme to embed the image data in the actual page. This can increase the size of your HTML document. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages. Inline images are not yet supported across all major browsers.

就是将Data:URI联入的图片写到CSS文件里面，当然这样的图片是起修饰作用的（比如背景图片），这样可以利用CSS文件可缓存的特点，将图片的信息也缓存了，减少了HTTP的请求数目，达到了一定程度上的优化。本站也使用了这样的方式，但是由于IE6、7对Data:URI还不支持，所以只能通过hack的方式对IE6、7进行特殊的处理：

[html]
#body-bg{
background:url("image/png;base64,…….") no-repeat;
*background:url("image/icons.gif.php") no-repeat;
}
[/html]

对本站的具体情况来说，将背景图片base64编码之后的大小跟原本图片的大小相差无几，所以使用data:URI之后，并且将CSS文件Gzip压缩，给CSS文件增加的大小也不会有太大的影响，而对于连接数有限的虚拟主机来说，减少一个HTTP请求，优化效果会占优势，所以权衡过后，使用了这样方式，同时测试成功~

2010-5-28 Update:

刚才看了Steve Souders的这篇关于优化CSS选择符的文章《Simplifying CSS Selectors》，觉得十分在理。按照《Writing Efficient CSS for use in the Mozilla UI》这篇指出的：

The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.

浏览器渲染系统是从右到左的形式来查询CSS选择符中指定的页面元素的。所以，精简CSS选择符就尤其显得重要。Steve Souders将CSS选择符中最右边的选择符称为“关键选择符”，比如：A.class0007 * {}。这个选择符是非常耗性能的，首先它会查询页面中全部的元素，再往上查询带有class0007类的超链接。

因此，将你的CSS选择符尽量保持简洁，并且避免那些消耗性能高的选择符，比如：全局选择符；还有避免那些累赘的选择符，比如：div#test,div.test等等；尽量避免关键选择符不要查询过多的元素。

同时在这里引用David Hyatt (architect for Safari and WebKit, also worked on Mozilla, Camino, and Firefox)对于CSS3的一段描述：

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.

按照他的话说，CSS3选择符也是比较消耗性能的，尤其在一些动画、阴影方面等等，都需要消耗比较大的CPU和内存来渲染。

更多阅读：《Performance Impact of CSS Selectors》，《CSS Qualified Selectors》

2010-5-13 Update:

优化了整站超链接的URL，将”http://www.ilovejs.net”替换为”/”，减少页面大小。这对于tag cloud来说尤其有优化作用。

/////////////////////////////////////////////////////////////////////////////////////

2010-5-4 Update:

1.对内容栏和边栏使用了ob_flush();flush();这两个方法，使得内容首先显示，边栏后显示的效果。毕竟内容为主，边栏就类似于“后加载”的情形吧。
2.通过修改主题css文件，发现当前编写css代码时，仍有非常多的低效的代码。
3.再离谱点，把javascript和css都各自合并到一个文件里了，删除了wordpress默认的并且已经没用的javascript文件，并且通过Google的Page Speed插件的建议，删除了无用的css样式规则，也获得了不少的优化效果。这主要是考虑到减少HTTP请求，毕竟虚拟主机对连接数的限制等等原因，还有就是可缓存，可以加快页面的加载速度。下面是首页在Page Speed和ySlow插件下的优化效果图以及firebug下的“网络”的HTTP瀑布图：

Update:

终于将“Catagroies”、“Links”、“Favorite Tags”，还有头部导航等HTML都压缩了，欣慰一下……

/////////////////////////////////////////////////////////////////////////////////////

这个礼拜总算有点时间来搞搞网站了，之前一直都很想整整网站的代码，优化一下(平时自己嘴边总说会优化，实践才出真知啊)。经过一天的捣鼓之后，发现访问速度也确实有些提高了。甚感欣慰啊……

优化的地方主要有以下几点：

1. 因为网站内安装了syntaxhighlighter代码高亮插件，这个插件虽然强大，但是也很纠结：它会在页面内插入几个css文件以及js文件（跟高亮代码的种类成正比）。这点本人非常不满意，所以，优化的主要目标，就是这个。本来打算将几个css文件和js文件先在服务端通过php的fopen、fwrite、fclose几个方法整合为一个文件，再用link和script来链接这个整合的文件，可是发现优化失败（具体可以参见《Javascript,CSS Minify》）。所以暂时的解决方案是手动去整合那些css和js文件，再将整合的文件链入页面内。达到较少HTTP请求的优化。并且将inline的css和js代码进行了压缩。
2. 网站内同时也安装了wordpress-thread-comment插件，它的问题跟syntaxhighlighter插件一样，动态插入了两个js文件（如果在登陆的情况下，否则插入一个js文件）。并且在head部动态插入了一段inline样式代码。因为逻辑和关联的比较复杂，所以就只能是压缩css和js代码了，将inline的css代码压缩掉，并且将插件将要用到的js文件也压缩掉。
3. 将头部和脚部的html都压缩掉，去掉每一个多余的字符，本来想将头部一连串的link元素给帅选掉一些，但是毕竟wp对搜索引擎优化比较良好，而且也只是元素而已，不用链接外部文件，所以就暂时留住了。删除了一些无用的meta元素，并且将DOCTYPE改为html5的声明方式，更加精简。
4. 将wp主题的php文件都进行了压缩，将html代码结构都压缩。本来想对“Categories”和“Favorite Tags”的HTML结构也压缩掉，可是在查看wp的PHP源码的时候，尝试暂时失败了，有待进一步疯狂的压缩。
5. 去掉了link、style元素中的type属性，去掉了script中的type和language属性。
6. 优化PNG图片，使用PNGOUTWin这个优化PNG图片的工具，确实不错，可以优化减少png图片20%的大小。
7. 使用PHP的flush()方法，尽快的输出缓冲区的内容。
8. 插入页面内的图片使用原始大小，并且显示声明width和height。
9. 优化了主题style.css文件中粗糙而且耗时的代码，并且对它进行简写优化，减小文件大小。比如将全部声明border-radius的元素都放在一起来声明。圆角效果都是用CSS3的border-radius来渲染。
10. 同时去掉了wp系统默认的很多没用的css class类
11. 经过firebug发现，网友头像的加载会导致“忙指示器”持续很久，用户体验效果低。所以就去掉网友评论中头像动态加载显示的功能(一般都是来自：www.gravatar.com)，将动态的头像图片修改为站内的一张静态图片。
12. 合并css和js文件并压缩（高亮插件和评论插件）

由于不是托管主机，gzip压缩、Etag、Expires等等依赖于服务器的优化无法测试，可惜了。

经过这几部的优化，效果果然有变化，页面加载速度确实有了提高。下面是首页(http://www.ilovejs.net)空缓存和有缓存的两种HTTP瀑布图和加载时间。

空缓存的情况

有缓存的情况

PNGOUTWin优化PNG软件

YSlow测试首页的结果（关于“Reduce the DOM Elements“这一条是由于代码高亮插件引起的）

修改网友评论的头像为站内的静态头像

参考文章：《All About Floats》，《How To Clear Floats Without Structural Markup》

tab在切换的时候如上面图片所示，左右一个像素的border，上面2像素，下面一个白色像素来覆盖边框。这个在FF等非IE内核的浏览器下显示没有问题，可是在IE浏览器下《问题页面》:

在IE下，激活tab右下角总是多出了一像素高度，为着这个IE下的一像素问题，快崩溃了。最初还以为是IE bug，测试来测试去，最后发现是IE渲染border的方式跟FF等浏览器不同。按原理来说，应该是top、bottom覆盖left、right的border颜色（FF等浏览器正是这么做的），可是IE却不是，它是按照逆时针，类似于是拼接似的来渲染border。这个问题只有在一个像素宽的border的时候才会出现，当大于一像素的时候，问题不存在。

《更新的测试页面》

在公司同事中学到了不少的经验，也总结出来了自己的一套开发步骤：

• 整体分析页面布局
• 归纳统一、分类，切图（CSS Sprites）
• 拆分模块、规划HTML结构、规划并编写CSS
• 组合成页面（得益于YUI的页面布局生成器组件）

第一步：整体分析页面布局。
当拿到视觉稿的时候，不是着手去想怎么编写HTML、CSS代码，而是先从整体上分析页面的布局，观察页面各个模块的间距差别、划分header，body，footer、CSS Sprites、切图事宜、页面色调、背景如何设置等等，之后再细化到每个模块的布局，从外到内，逐步细化。可以说，这一步是非常关键的，它给了下面将要进行的代码编写一个整体的框架布局。

第二步：归纳统一、分类，切图（CSS Sprites）
整体分析过后，就是归类、组合模块的时候了。这一步还是的需要从整体来看，分析页面哪些模块的样式相似（常见的就是ul列表，以及一些图文编排），包括颜色、样式、修饰、背景、宽度、padding、margin、border等等。将相似的模块的样式归类，这为接下来编写CSS代码大有好处，可以最大化的精简CSS代码。

第三步：拆分模块、规划HTML结构、规划并编写CSS
在前期工作都做了之后，这步就改到了动手写代码的时候了，我喜欢将每个模块或者列拆分开来编写，这样做的好处是我可以先不管整体布局，从HTML语意化的角度架构HTML结构，此时HTML代码较少，在编写CSS以及查看HTML代码的时候不用花费太多时间了（痛恨HTML代码多了，上下拉滚动条，累人！）

第四步：组合成页面。
在每个模块都编写好之后，借助页面布局生成器（幸亏有了它，效率第一啊！缺点是HTML结构复杂，-_-），将每个拆分的模块整合起来，同时也清理CSS文件的代码，整合CSS代码也有一些些技巧的：在CSS Sprites里设置HTML元素的背景的时候，把全部的元素都写在一处：

/* background url */
.rhs-bd,.business-join h1,.yk-mod-content .business-join p a,.business-open-flow ul,.business-case-list ul li,
.kb-bank-toolbar ul,.kba-consumer h1,.kba-consumer h1,.kba-consumer ul li,.kba-new-join ul li,
.recommend-shop-list,.hot-sign,.search-merchant-bd{background:url(ka_bg.png) no-repeat;}

这样相应的元素只需要设置background-position就OK了，代码整洁，结构清晰，重构维护成本小。还有一点就是慎用margin，在IE6、7下margin会引发很多问题，所以在编写CSS和规划HTML布局的时候，需要考虑到需要使用margin还是使用padding，各有各的好处，margin能保持HTML结构比较简洁，而padding原理是在当前HTML元素的子元素中设置padding来实现布局（当然也可以在当前元素下，但是它会改变宽度和高度，需要重新调整宽高）。所以我的经验是：在模块的HTML和CSS编写方面，都会尽量使用padding，特别是涉及到float的时候，使用padding会避免很多问题。有句话说的好：既然明知道这样做会引发bug，那就尽量不这样做。

上面的开发步骤因人而已，偶是喜欢并且习惯这样的一个思索开发过程，正在体验它的乐趣。《页面DEMO请点击》

不测不知道，一测还真学了一套。

第一种情况是：如果文本只是单行的话，这个就简单，直接设置元素的line-height css规则的高度跟height一样就ok了。下面的测试code在每个浏览器都显示正常。

[html]
<style type="text/css">
div{
width:400px;
height:200px;
line-height:200px;
border:1px solid #ccc;
}
</style>

<div>only one line at here.</div>
[/html]

接下来的第二种情况是多行文本垂直局中的问题，但是这里又有一个区分En文跟中文的问题。垂直局中的话只要自适应高度，并且设置上下padding为一个相同的值就能够实现，这个简单。有点小问题就是En文跟中文的断行问题，如果En文内容的长度过长的话，就会撑破原来定的width，每个浏览器的显示都基本类似，除了IE6，它会忽视你定义的width。比如下面的代码：

[html]
<style type="text/css">
div {
width:300px;
border:1px solid #ccc;
padding:30px 0;
}
</style>

<div><p>sdfsjdlfjalsdjfalsdjflasdjkljfkladjfkljsdffffffffffffffffffffffffffffffffffffff 我被推出来啦 </p></div>
[/html]

效果：

中文是完全没有问题滴:
[html]
<div>
<p>上了飞机数量大幅减少芬兰首都基辅联手打击对方手机的法律我没有被推出来
</p>
</div>
[/html]

对于En文的这个问题，就需要通过css的word-wrap来“强制”换行了，把word-wrap设置为break-word，哟，好了。

[html]
<style type="text/css">
div {
width:300px;
border:1px solid #ccc;
padding:30px 0;
word-wrap:break-word;
}
</style>
<div>
<p>sdfsjdlfjalsdjfalsdjflasdjkljfkladjfkljsdffffffffffffffffffffffffffffffffffffff 推我不出来了
</p>
</div>
[/html]

效果：

关于为啥En文不会自动断行的原因不明，或许这就是有word-wrap的原因吧。更多的关于word-wrap的相关的说明，可以浏览：《word-wrap同word-break的区别》，《CSS WORD-WRAP》。

因为HTML、CSS这方面功力不足，所以一方面要求乌龙茶师傅多分配这样的一些作业或者多接一些日常任务来提高这方面的能力。N个月没有写HTML了，对HTML语意化、创建良好的HTML结构都比较模糊，经过观察内网（http: //www.koubei.com)的HTML结构，也开始使用Firefox的Firebug来查看淘宝网等等一些知名网站的HTML各模块的 HTML结构编写方式，从中也开始悟出了一些门道。

关于HTML的良好的结构性的说法网上都有很多论述，总结一点就是：根据你要展现内容的特点来使用跟内容语意相符的HTML标签。这个总结或许是片面点了吧，不过基本思路还是这样滴。:)

页面上比较常用到的模块有：导航、图文并排、列表、图文列表、列表里又细分为图文并排等等，这些都是经常需要使用到的。我在入职后刚开始写页面的时候也是碰到了很多这样的模块的HTML的编写。按照我现在的习惯方式的话，当接到一个页面的需求的时候，首先不是入手开始编写HTML，而是先从整个页面上、结构语意化的角度考虑去如何规划结构，将每个模块细分出来，在细分的过程中去归纳哪些模块或者哪些样式是可以整合为使用一个css类来编写的，细分和归纳好之后，开始入手编写每个版块的HTML结构。所以，刚开始做任务的时候，我都会在这方面花费一点点时间来审视和规划页面，这些基本工作准备好了之后，就开始编写HTMl结构啦。这样一个过程的好处在于使得我编写的HTML的结构会尽量的保持精简而又能完成视觉效果，而且还有一个好处就是可以精简你的css的编写，使得你的css代码将会非常的清晰。

关于上面提及的精简css代码的一点点技巧就是：使用好css类！！这点再夸大也不为过。归纳整个页面哪些元素的样式可以通过一个通用的类来是实现视觉效果，再根据每个模块的不同点来额外添加css类或者通过元素的id来额外添加独立的样式，比如：

[html]
<div class="common hotsport">
<ul>
<li><a href="#">…</a></li>
<li><a href="#">…</a></li>
…
</ul>
</div>

<div class="common hotfood">
<ul>
<li><a href="#">…</a></li>
<li><a href="#">…</a></li>
…
</ul>
</div>
[/html]

假如上面的两个列表有非常多相似的地方，不如margin，padding，background等等，但是在颜色方面有一些不同的话，相同的可以在 common类里定义css样式，不同的可以独自写多个不同的类来编写。通过这种方式，就可以使得你的css代码精简多了，不会出现重复累赘的样式规则。

其他的一些收获是用好inline-block和overflow属性，inline-block的详细的说明可以在口碑的UED里乌龙茶师傅的一篇文章里得到详细的论述：《inline-block从入门到精通》。

推荐阅读：《Object Oriented CSS (OOCSS): The Lowdown》

我的方式是使用div将每个label和input分组，比如：
[html]
<form method="post" action="#">
<div>
<label for="username">User Name:</label><input type="text" id="username" class="txt" />
</div>
<div>
<label for="email">E-mail:</label><input type="text" id="email" class="txt" />
</div>
<div>
<label for="pwd">E-mail:</label><input type="password" id="pwd" class="txt" />
</div>
<div>
<input type="button" value="Submit Now" id="btn" />
</div>
</form>
[/html]
HTML结构已经定义了，接下来就是css的技巧问题了，首先给每个div设置样式：
[css]
div{
clear:left;
margin-bottom:6px;
}
[/css]
之后就是技巧的关键label样式：
[css]
label{
float:left;
width:150px;
}
[/css]

通过设置了label的float样式，再加上设置一下它的width，使得每一个label内的文本都能在一行内显示，这样就使得他们后面的input都能对齐了。浏览效果

即时更新:

经过测试，也可以不使用float的方式来实现上面的效果，关键的还是在label的css样式设置上，设置label的display属性为inline-block，再加上一个合适的width属性，也就实现了简单的对齐效果，在IE6以上版本，FF，Chrome，Opera，Safari测试通过：
[css]
div{
margin-bottom:6px;
}
label{
display:inline-block;
width:150px;
}
[/css]
预览inline-block版的form效果。

• <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
• <?xml version=”1.0″ encoding=”utf-8″?><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>
• <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
• 还有一个就是目前HTML5的声明模式

设置DOCTYPE的好处就在于促使浏览器使用标准模式下去解析HTML文档，这使得浏览器之间的兼容性更好，比如IE的框模型Hack都不会存在等等，跟其他的浏览器使用同一种模式来解析。但是如果不声明DOCTYPE的话，浏览器就会使用怪癖模式去解析文档，这就使得很多兼容性的问题都会出现，特别是IE浏览器下的怪癖模式。所以应该避免不声明DOCTYPE的写法。当然，有时候为了特意的去促发浏览器使用怪癖模式去解析 ，那就另当别论了，比如Google，百度的首页就没有声明DOCTYPE。

同时还有一点问题大家需要知道的是，IE8下有一个兼容模式，就是会默认使用IE7的兼容模式去解析文档，而不是使用IE8本身。这个细节问题可以通过设置meta来实现：<meta content=”IE=8″ http-equiv=”X-UA-Compatible” />

推荐阅读：《用doctype激活浏览器模式》，《HTML和XHTML的不同》，《XHTML1.1标签列表、属性和嵌套规则》，《HTML文档中小meta的大作用》。