本文將探討瀏覽器渲染的loading過(guò)程，主要有2個(gè)目的：
了解瀏覽器在loading過(guò)程中的實(shí)現(xiàn)細(xì)節(jié)，具體都做了什么
研究如何根據(jù)瀏覽器的實(shí)現(xiàn)原理進(jìn)行優(yōu)化，提升頁(yè)面響應(yīng)速度
由于loading和parsing是相互交織、錯(cuò)綜復(fù)雜的，這里面有大量的知識(shí)點(diǎn)，為了避免過(guò)于發(fā)散本文將不會(huì)對(duì)每個(gè)細(xì)節(jié)都深入研究，而是將重點(diǎn)放在開發(fā)中容易控制的部分（Web前端和Web Server），同時(shí)由于瀏覽器種類繁多且不同版本間差距很大，本文將側(cè)重一些較新的瀏覽器特性
現(xiàn)有知識(shí)提升頁(yè)面性能方面已經(jīng)有很多前人的優(yōu)秀經(jīng)驗(yàn)了，如
Best Practices for Speeding Up Your Web Site和
Web Performance Best Practices本文主要專注其中加載部分的優(yōu)化，總結(jié)起來(lái)主要有以下幾點(diǎn)：
帶寬 使用CDN
壓縮js、css，圖片優(yōu)化
HTTP優(yōu)化 減少轉(zhuǎn)向
減少請(qǐng)求數(shù)
緩存
盡早Flush
使用gzip
減少cookie
使用GET
DNS優(yōu)化
減少域名解析時(shí)間
增多域名提高并發(fā)
JavaScript 放頁(yè)面底部
defer/async
CSS 放頁(yè)面頭部
避免@import
其它 預(yù)加載
接下來(lái)就從瀏覽器各個(gè)部分的實(shí)現(xiàn)來(lái)梳理性能優(yōu)化方法network首先是網(wǎng)絡(luò)層部分，這方面的實(shí)現(xiàn)大部分是通過(guò)調(diào)用操作系統(tǒng)或gui框架提供的api
DNS為了應(yīng)對(duì)DNS查詢的延遲問(wèn)題，一些新的瀏覽器會(huì)緩存或預(yù)解析DNS，如當(dāng)Chrome訪問(wèn)google頁(yè)面的搜索結(jié)果時(shí)，它會(huì)取出鏈接中的域名進(jìn)行預(yù)解析
當(dāng)然，Chrome并不是每次都將頁(yè)面中的所有鏈接的域名都拿來(lái)預(yù)解析，為了既提升用戶體驗(yàn)又不會(huì)對(duì)DNS造成太大負(fù)擔(dān)，Chrome做了很多細(xì)節(jié)的優(yōu)化，如通過(guò)學(xué)習(xí)用戶之前的行為來(lái)進(jìn)行判斷
Chrome在啟動(dòng)時(shí)還會(huì)預(yù)先解析用戶常去的網(wǎng)站，具體可以參考DNS Prefetching，當(dāng)前Chrome中的DNS緩存情況可以通過(guò)net-internals頁(yè)面來(lái)察看
為了幫助瀏覽器更好地進(jìn)行DNS的預(yù)解析，可以在html中加上以下這句標(biāo)簽來(lái)提示瀏覽器
<link rel="dns-prefetch" >
除此之外還可以使用HTTP header中的X-DNS-Prefetch-Control來(lái)控制瀏覽器是否進(jìn)行預(yù)解析，它有on和off兩個(gè)值，更詳細(xì)的信息請(qǐng)參考Controlling DNS prefetching
CDN本文不打算詳細(xì)討論這個(gè)話題，感興趣的讀者可以閱讀Content delivery network
在性能方面與此相關(guān)的一個(gè)問(wèn)題是用戶可能使用自定義的DNS，如OpenDNS或Google的8.8.8.8，需要注意對(duì)這種情況進(jìn)行處理
link prefetch由于Web頁(yè)面加載是同步模型，這意味著瀏覽器在執(zhí)行js操作時(shí)需要將后續(xù)html的加載和解析暫停，因?yàn)閖s中有可能會(huì)調(diào)用document.write來(lái)改變dom節(jié)點(diǎn)，很多瀏覽器除了html之外還會(huì)將css的加載暫停，因?yàn)閖s可能會(huì)獲取dom節(jié)點(diǎn)的樣式信息，這個(gè)暫停會(huì)導(dǎo)致頁(yè)面展現(xiàn)速度變慢，為了應(yīng)對(duì)這個(gè)問(wèn)題，Mozilla等瀏覽器會(huì)在執(zhí)行js的同時(shí)簡(jiǎn)單解析后面的html，提取出鏈接地址提前下載，注意這里僅是先下載內(nèi)容，并不會(huì)開始解析和執(zhí)行
這一行為還可以通過(guò)在頁(yè)面中加入以下標(biāo)簽來(lái)提示瀏覽器
<link rel="prefetch" href="
http://">
但這種寫法目前并沒(méi)有成為正式的標(biāo)準(zhǔn)，也只有Mozilla真正實(shí)現(xiàn)了該功能，可以看看Link prefetching FAQ
WebKit也在嘗試該功能，具體實(shí)現(xiàn)是在HTMLLinkElement的process成員函數(shù)中，它會(huì)調(diào)用ResourceHandle::prepareForURL()函數(shù)，目前從實(shí)現(xiàn)看它是僅僅用做DNS預(yù)解析的，和Mozilla對(duì)這個(gè)屬性的處理不一致
對(duì)于不在當(dāng)前頁(yè)面中的鏈接，如果需要預(yù)下載后續(xù)內(nèi)容可以用js來(lái)實(shí)現(xiàn)，請(qǐng)參考這篇文章Preload CSS/JavaScript without execution
預(yù)下載后續(xù)內(nèi)容還能做很多細(xì)致的優(yōu)化，如在Velocity China
2010中，來(lái)自騰訊的黃希彤介紹了騰訊產(chǎn)品中使用的交叉預(yù)下載方案，利用空閑時(shí)間段的流量來(lái)預(yù)加載，這樣即提升了用戶訪問(wèn)后續(xù)頁(yè)面的速度，又不會(huì)影響到高峰期的流量，值得借鑒
預(yù)渲染預(yù)渲染比預(yù)下載更進(jìn)一步，不僅僅下載頁(yè)面，而且還會(huì)預(yù)先將它渲染出來(lái)，目前在Chrome（9.0.597.0）中有實(shí)現(xiàn)，不過(guò)需要在about:flags中將’Web Page Prerendering’開啟
不得不說(shuō)Chrome的性能優(yōu)化做得很細(xì)致，各方面都考慮到了，也難怪Chrome的速度很快
http在網(wǎng)絡(luò)層之上我們主要關(guān)注的是HTTP協(xié)議，這里將主要討論1.1版本，如果需要了解1.0和1.1的區(qū)別請(qǐng)參考Key Differences between HTTP/1.0 and HTTP/1.1
header首先來(lái)看http中的header部分
header大小header的大小一般會(huì)有500 多字節(jié)，cookie內(nèi)容較多的情況下甚至可以達(dá)到1k以上，而目前一般寬帶都是上傳速度慢過(guò)下載速度，所以如果小文件多時(shí)，甚至?xí)霈F(xiàn)頁(yè)面性能瓶頸出在用戶上傳速度上的情況，所以縮小header體積是很有必要的，尤其是對(duì)不需要cookie的靜態(tài)文件上，最好將這些靜態(tài)文件放到另一個(gè)域名上
將靜態(tài)文件放到另一個(gè)域名上會(huì)出現(xiàn)的現(xiàn)象是，一旦靜態(tài)文件的域名出現(xiàn)問(wèn)題就會(huì)對(duì)頁(yè)面加載造成嚴(yán)重影響，尤其是放到頂部的js，如果它的加載受阻會(huì)導(dǎo)致頁(yè)面展現(xiàn)長(zhǎng)時(shí)間空白，所以對(duì)于流量大且內(nèi)容簡(jiǎn)單的首頁(yè)，最好使用內(nèi)嵌的js和css
header的擴(kuò)展屬性header中有些擴(kuò)展屬性可以用來(lái)保護(hù)站點(diǎn)，了解它們是有益處的
X-Frame-Options
這個(gè)屬性可以避免網(wǎng)站被使用frame、iframe的方式嵌入，解決使用js判斷會(huì)被var location;破解的問(wèn)題，IE8、Firefox3.6、Chrome4以上的版本都支持
X-XSS-Protection
這是IE8引入的擴(kuò)展header，在默認(rèn)情況下IE8會(huì)自動(dòng)攔截明顯的XSS攻擊，如query中寫script標(biāo)簽并在返回的內(nèi)容中包含這項(xiàng)標(biāo)簽，如果需要禁止可以將它的值設(shè)為0，因?yàn)檫@個(gè)XSS過(guò)濾有可能導(dǎo)致問(wèn)題，如IE8 XSS Filter Bug
X-Requested-With
用來(lái)標(biāo)識(shí)Ajax請(qǐng)求，大部分js框架都會(huì)加入這個(gè)header
X-Content-Type-Options
如果是html內(nèi)容的文件，即使用Content-Type: text/plain;的header，IE仍然會(huì)識(shí)別成html來(lái)顯示，為了避免它所帶來(lái)的安全隱患，在IE8中可以通過(guò)在header中設(shè)置X-Content-Type-Options: nosniff來(lái)關(guān)閉它的自動(dòng)識(shí)別功能
使用get請(qǐng)求來(lái)提高性能首先性能因素不應(yīng)該是考慮使用get還是post的主要原因，首先關(guān)注的應(yīng)該是否符合HTTP中標(biāo)準(zhǔn)中的約定，get應(yīng)該用做數(shù)據(jù)的獲取而不是提交
之所以用get性能更好的原因是有測(cè)試表明，即使數(shù)據(jù)很小，大部分瀏覽器（除了Firefox）在使用post時(shí)也會(huì)發(fā)送兩個(gè)TCP的packet，所以性能上會(huì)有損失
連接數(shù)在HTTP/1.1協(xié)議下，單個(gè)域名的最大連接數(shù)在IE6中是2個(gè)，而在其它瀏覽器中一般4-8個(gè)，而整體最大鏈接數(shù)在30左右
而在HTTP/1.0協(xié)議下，IE6、7單個(gè)域名的最大鏈接數(shù)可以達(dá)到4個(gè)，在Even Faster Web Sites一書中的11章還推薦了對(duì)靜態(tài)文件服務(wù)使用HTTP/1.0協(xié)議來(lái)提高IE6、7瀏覽器的速度
瀏覽器鏈接數(shù)的詳細(xì)信息可以在Browserscope上查到
使用多個(gè)域名可以提高并發(fā)，但前提是每個(gè)域名速度都是同樣很快的，否則就會(huì)出現(xiàn)某個(gè)域名很慢會(huì)成為性能瓶頸的問(wèn)題
cache主流瀏覽器都遵循h(huán)ttp規(guī)范中的Caching in HTTP來(lái)實(shí)現(xiàn)的
從HTTP cache的角度來(lái)看，瀏覽器的請(qǐng)求分為2種類型：conditional requests 和 unconditional requests
unconditional請(qǐng)求是當(dāng)本地沒(méi)有緩存或強(qiáng)制刷新時(shí)發(fā)的請(qǐng)求，web server返回200的heder，并將內(nèi)容發(fā)送給瀏覽器
而conditional則是當(dāng)本地有緩存時(shí)的請(qǐng)求，它有兩種：
使用了Expires或Cache-Control，如果本地版本沒(méi)有過(guò)期，瀏覽器不會(huì)發(fā)出請(qǐng)求
如果過(guò)期了且使用了ETag或Last-Modified，瀏覽器會(huì)發(fā)起conditional請(qǐng)求，附上If-Modified-Since或If-None-Match的header，web server根據(jù)它來(lái)判斷文件是否過(guò)期，如果沒(méi)有過(guò)期就返回304的header（不返回內(nèi)容），瀏覽器見到304后會(huì)直接使用本地緩存中的文件
以下是IE發(fā)送conditional requests的條件，從MSDN上抄來(lái)
The cached item is no longer fresh according to Cache-Control or Expires
The cached item was delivered with a VARY header
The containing page was navigated to via META REFRESH
JavaScript in the page called reload on the location object, passing TRUE
The request was for a cross-host HTTPS resource on browser startup
The user refreshed the page
簡(jiǎn)單的來(lái)說(shuō)，點(diǎn)擊刷新按鈕或按下F5時(shí)會(huì)發(fā)出conditional請(qǐng)求,而按下ctrl的同時(shí)點(diǎn)擊刷新按鈕或按下F5時(shí)會(huì)發(fā)出unconditional請(qǐng)求
需要進(jìn)一步學(xué)習(xí)請(qǐng)閱讀：
Caching Tutorial
Caching Improvements in Internet Explorer 9
前進(jìn)后退的處理瀏覽器會(huì)盡可能地優(yōu)化前進(jìn)后退，使得在前進(jìn)后退時(shí)不需要重新渲染頁(yè)面，就好像將當(dāng)前頁(yè)面先“暫停”了，后退時(shí)再重新運(yùn)行這個(gè)“暫停”的頁(yè)面
不過(guò)并不是所有頁(yè)面都能“暫停”的，如當(dāng)頁(yè)面中有函數(shù)監(jiān)聽unload事件時(shí)，所以如果頁(yè)面中的鏈接是原窗口打開的，對(duì)于unload事件的監(jiān)聽會(huì)影響頁(yè)面在前進(jìn)后時(shí)的性能
在新版的WebKit里，在事件的對(duì)象中新增了一個(gè)persisted屬性，可以用它來(lái)區(qū)分首次載入和通過(guò)后退鍵載入這兩種不同的情況，而在Firefox中可以使用pageshow和pagehide這兩個(gè)事件
unload事件在瀏覽器的實(shí)現(xiàn)中有很多不確定性因素，所以不應(yīng)該用它來(lái)記錄重要的事情，而是應(yīng)該通過(guò)定期更新cookie或定期保存副本（如用戶備份編輯文章到草稿中）等方式來(lái)解決問(wèn)題
具體細(xì)節(jié)可以參考WebKit上的這2篇文章：
cookie瀏覽器中對(duì)cookie的支持一般是網(wǎng)絡(luò)層庫(kù)來(lái)實(shí)現(xiàn)的，瀏覽器不需要關(guān)心，如IE使用的是WinINET
需要注意IE對(duì)cookie的支持是基于pre-RFC Netscape draft spec for cookies的，和標(biāo)準(zhǔn)有些不同，在設(shè)定cookie時(shí)會(huì)出現(xiàn)轉(zhuǎn)義不全導(dǎo)致的問(wèn)題，如在ie和webkit中會(huì)忽略“=”，不過(guò)大部分web開發(fā)程序（如php語(yǔ)言）都會(huì)處理好，自行編寫http交互時(shí)則需要注意
p3p問(wèn)題在IE中默認(rèn)情況下iframe中的頁(yè)面如果域名和當(dāng)前頁(yè)面不同，iframe中的頁(yè)面是不會(huì)收到cookie的，這時(shí)需要通過(guò)設(shè)置p3p來(lái)解決，具體可以察看微軟官方的文檔，加上如下header即可
P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
這對(duì)于用iframe嵌入到其它網(wǎng)站中的第三方應(yīng)用很重要
編碼識(shí)別頁(yè)面的編碼可以在http header或meta標(biāo)簽中指明，對(duì)于沒(méi)有指明編碼的頁(yè)面，瀏覽器會(huì)根據(jù)是否設(shè)置了auto detect來(lái)進(jìn)行編碼識(shí)別（如在chrome中的View-Encoding菜單）
關(guān)于編碼識(shí)別，Mozilla開源了其中的Mozilla Charset Detectors模塊，感興趣的可以對(duì)其進(jìn)行學(xué)習(xí)
建議在http
header中指定編碼，如果是在meta中指定，瀏覽器在得到html頁(yè)面后會(huì)首先讀取一部分內(nèi)容，進(jìn)行簡(jiǎn)單的meta標(biāo)簽解析來(lái)獲得頁(yè)面編碼，如WebKit代碼中的HTMLMetaCharsetParser.cpp，可以看出它的實(shí)現(xiàn)是查找charset屬性的值，除了WebKit以外的其它瀏覽器也是類似的做法，這就是為何HTML5中直接使用如下的寫法瀏覽器都支持
需要注意不設(shè)定編碼會(huì)導(dǎo)致不可預(yù)測(cè)的問(wèn)題，應(yīng)盡可能做到明確指定
chunked瀏覽器在加載html時(shí)，只要網(wǎng)絡(luò)層返回一部分?jǐn)?shù)據(jù)后就會(huì)開始解析，并下載其中的js、圖片，而不需要等到所有html都下載完成才開始，這就意味著如果可以分段將數(shù)據(jù)發(fā)送給瀏覽器，就能提高頁(yè)面的性能，這就是chunked的作用，具體協(xié)議細(xì)節(jié)請(qǐng)參考Chunked Transfer Coding
在具體實(shí)現(xiàn)上，php中可以通過(guò)flush函數(shù)來(lái)實(shí)現(xiàn)，不過(guò)其中有不少需要注意的問(wèn)題，如php的配置、web server、某些IE版本的問(wèn)題等，具體請(qǐng)參考php文檔及評(píng)論
注意這種方式只適用于html頁(yè)面，對(duì)于xml類型的頁(yè)面，由于xml的嚴(yán)格語(yǔ)法要求，瀏覽器只能等到xml全部下載完成后才會(huì)開始解析，這就意味著同等情況下，xml類型的頁(yè)面展現(xiàn)速度必然比html慢，所以不推薦使用xml
即使不使用這種http傳輸方式，瀏覽器中html加載也是邊下載邊解析的，而不需等待所有html內(nèi)容都下載完才開始，所以實(shí)際上chunked主要節(jié)省的是等待服務(wù)器響應(yīng)的時(shí)間，因?yàn)檫@樣可以做到服務(wù)器計(jì)算完一部分頁(yè)面內(nèi)容后就立刻返回，而不是等到所有頁(yè)面都計(jì)算都完成才返回，將操作并行
另外Facebook所使用的BigPipe實(shí)際上是在應(yīng)用層將頁(yè)面分為了多個(gè)部分，從而做到了服務(wù)端和瀏覽器計(jì)算的并行
keepaliveeepalive使得在完成一個(gè)請(qǐng)求后可以不關(guān)閉socket連接，后續(xù)可以重復(fù)使用該連接發(fā)送請(qǐng)求，在HTTP/1.0和HTTP/1.1中都有支持，在HTTP/1.1中默認(rèn)是打開的
keepalive在瀏覽器中都會(huì)有超時(shí)時(shí)間，避免長(zhǎng)期和服務(wù)器保持連接，如IE是60秒
另外需要注意的是如果使用阻塞IO（如apache），開啟keepalive保持連接會(huì)很消耗資源，可以考慮使用nginx、lighttpd等其它web server，具體請(qǐng)參考相關(guān)文檔，這里就不展開描述
pipeliningipelining是HTTP/1.1協(xié)議中的一個(gè)技術(shù)，能讓多個(gè)HTTP請(qǐng)求同時(shí)通過(guò)一個(gè)socket傳輸，注意它和keepalive的區(qū)別，keepalive能在一個(gè)socket中傳輸多個(gè)HTTP，但這些HTTP請(qǐng)求都是串行的，而pipelining則是并行的
可惜目前絕大部分瀏覽器在默認(rèn)情況下都不支持，已知目前只有opera是默認(rèn)支持的，加上很多網(wǎng)絡(luò)代理對(duì)其支持不好導(dǎo)致容易出現(xiàn)各種問(wèn)題，所以并沒(méi)有廣泛應(yīng)用
SPDYSPDY是google提出的對(duì)HTTP協(xié)議的改進(jìn)，主要是目的是提高加載速度，主要有幾點(diǎn)：
Mutiplexed streams
可以在一個(gè)TCP中傳輸各種數(shù)據(jù)，減少鏈接的耗時(shí)
Request prioritization
請(qǐng)求分級(jí)，便于發(fā)送方定義哪些請(qǐng)求是重要的
HTTP header compression
header壓縮，減少數(shù)據(jù)量
frame從實(shí)現(xiàn)上看，frame類（包括iframe和frameset）的標(biāo)簽是最耗時(shí)的，而且會(huì)導(dǎo)致多一個(gè)請(qǐng)求，所以最好減少frame數(shù)量
b]
resticted[/b]
如果要嵌入不信任的網(wǎng)站，可以使用這個(gè)屬性值來(lái)禁止頁(yè)面中js、ActiveX的執(zhí)行，可以參考msdn的文檔
<iframe security="restricted" src=""></iframe>
b]
加載[/b]
對(duì)于html的script標(biāo)簽，如果是外鏈的情況，如:
<script src="a.js"></script>
瀏覽器對(duì)它的處理主要有2部分：下載和執(zhí)行
下載在有些瀏覽器中是并行的，有些瀏覽器中是串行的，如IE8、Firefox3、Chrome2都是串行下載的
執(zhí)行在所有瀏覽器中默認(rèn)都是阻塞的，當(dāng)js在執(zhí)行時(shí)不會(huì)進(jìn)行html解析等其它操作，所以頁(yè)面頂部的js不宜過(guò)大，因?yàn)槟菢訉?dǎo)致頁(yè)面長(zhǎng)時(shí)間空白，對(duì)于這些外鏈js，有2個(gè)屬性可以減少它們對(duì)頁(yè)面加載的影響，分別是：
async
標(biāo)識(shí)js是否異步執(zhí)行，當(dāng)有這個(gè)屬性時(shí)則不阻塞當(dāng)前頁(yè)面的加載，并在js下載完后立刻執(zhí)行
不能保證多個(gè)script標(biāo)簽的執(zhí)行順序
defer
標(biāo)示js是否延遲執(zhí)行，當(dāng)有這個(gè)屬性時(shí)js的執(zhí)行會(huì)推遲到頁(yè)面解析完成之后
可以保證多個(gè)script標(biāo)簽的執(zhí)行順序
下圖來(lái)自Asynchronous and deferred JavaScript execution explained，清晰地解釋了普通情況和這2種情況下的區(qū)別
需要注意的是這兩個(gè)屬性目前對(duì)于內(nèi)嵌的js是無(wú)效的
而對(duì)于dom中創(chuàng)建的script標(biāo)簽在瀏覽器中則是異步的，如下所示：
ar script = document.createElement('script');
script.src = 'a.js';
document.getElementsByTagName('head')[0].appendChild(script);
為了解決js阻塞頁(yè)面的問(wèn)題，可以利用瀏覽器不認(rèn)識(shí)的屬性來(lái)先下載js后再執(zhí)行，如ControlJS就是這樣做的，它能提高頁(yè)面的相應(yīng)速度，不過(guò)需要注意處理在js未加載完時(shí)的顯示效果
document.writedocument.write是不推薦的api，對(duì)于標(biāo)示有async或defer屬性的script標(biāo)簽，使用它會(huì)導(dǎo)致不可預(yù)料的結(jié)果，除此之外還有以下場(chǎng)景是不應(yīng)該使用它的：
使用document.createElement創(chuàng)建的script
事件觸發(fā)的函數(shù)中，如onclick
setTimeout/setInterval
簡(jiǎn)單來(lái)說(shuō)，document.write只適合用在外鏈的script標(biāo)簽中，它最常見的場(chǎng)景是在廣告中，由于廣告可能包含大量html，這時(shí)需要注意標(biāo)簽的閉合，如果寫入的內(nèi)容很多，為了避免受到頁(yè)面的影響，可以使用類似Google AdSense的方式，通過(guò)創(chuàng)建iframe來(lái)放置廣告，這樣做還能減少?gòu)V告中的js執(zhí)行對(duì)當(dāng)前頁(yè)面性能的影響
另外，可以使用ADsafe等方案來(lái)保證嵌入第三方廣告的安全，請(qǐng)參考如何安全地嵌入第三方j(luò)s – FBML/caja/sandbox/ADsafe簡(jiǎn)介
script標(biāo)簽放底部將script標(biāo)簽放底部可以提高頁(yè)面展現(xiàn)給用戶的速度，然而很多時(shí)候事情并沒(méi)那么簡(jiǎn)單，如頁(yè)面中的有些功能是依賴js的，所以更多的還需要根據(jù)實(shí)際需求進(jìn)行調(diào)整
嘗試用Doloto分析出哪些JS和初始展現(xiàn)是無(wú)關(guān)的，將那些不必要的js延遲加載
手工進(jìn)行分離，如可以先顯示出按鈕，但狀態(tài)是不可點(diǎn)，等JS加載完成后再改成可點(diǎn)的
傳輸js壓縮可以使用YUI Compressor或Closure Compiler
gwt中的js壓縮還針對(duì)gzip進(jìn)行了優(yōu)化，進(jìn)一步減小傳輸?shù)捏w積，具體請(qǐng)閱讀On Reducing the Size of Compressed Javascript
CSS比起js放底部，css放頁(yè)面頂部就比較容易做到
@import使用@import在IE下會(huì)由于css加載延后而導(dǎo)致頁(yè)面展現(xiàn)比使用link標(biāo)簽慢，不過(guò)目前幾乎沒(méi)有人使用@import，所以問(wèn)題不大，具體細(xì)節(jié)請(qǐng)參考don’t use @import
selector的優(yōu)化瀏覽器在構(gòu)建DOM樹的過(guò)程中會(huì)同時(shí)構(gòu)建Render樹，我們可以簡(jiǎn)單的認(rèn)為瀏覽器在遇到每一個(gè)DOM節(jié)點(diǎn)時(shí)，都會(huì)遍歷所有selector來(lái)判斷這個(gè)節(jié)點(diǎn)會(huì)被哪些selector影響到
不過(guò)實(shí)際上瀏覽器一般是從右至左來(lái)判斷selector是否命中的，對(duì)于ID、Class、Tag、Universal和Page的規(guī)則是通過(guò)hashmap的方式來(lái)查找的，它們并不會(huì)遍歷所有selector，所以selector越精確越好，google page-speed中的一篇文檔Use efficient CSS selectors詳細(xì)說(shuō)明了如何優(yōu)化selector的寫法
另一個(gè)比較好的方法是從架構(gòu)層面進(jìn)行優(yōu)化，將頁(yè)面不同部分的模塊和樣式綁定，通過(guò)不同組合的方式來(lái)生成頁(yè)面，避免后續(xù)頁(yè)面頂部的css只增不減，越來(lái)越復(fù)雜和混亂的問(wèn)題，可以參考
Facebook的靜態(tài)文件管理工具以下整理一些性能優(yōu)化相關(guān)的工具及方法
Browserscope之前提到的
http://www.browserscope.org收集了各種瀏覽器參數(shù)的對(duì)比，如最大鏈接數(shù)等信息，方便參考
Navigation TimingNavigation Timing是還在草案中的獲取頁(yè)面性能數(shù)據(jù)api，能方便頁(yè)面進(jìn)行性能優(yōu)化的分析
傳統(tǒng)的頁(yè)面分析方法是通過(guò)javascript的時(shí)間來(lái)計(jì)算，無(wú)法獲取頁(yè)面在網(wǎng)絡(luò)及渲染上所花的時(shí)間，使用Navigation Timing就能很好地解決這個(gè)問(wèn)題，具體它能取到哪些數(shù)據(jù)可以通過(guò)下圖了解（來(lái)自w3c）
目前這個(gè)api較新，目前只在一些比較新的瀏覽器上有支持，如Chrome、IE9，但也占用一定的市場(chǎng)份額了，可以現(xiàn)在就用起來(lái)
boomerangyahoo開源的一個(gè)頁(yè)面性能檢測(cè)工具，它的原理是通過(guò)監(jiān)聽頁(yè)面的onbeforeunload事件，然后設(shè)置一個(gè)cookie，并在另一個(gè)頁(yè)面中設(shè)置onload事件，如果cookie中有設(shè)置且和頁(yè)面的refer保持一致，則通過(guò)這兩個(gè)事件的事件來(lái)衡量當(dāng)前頁(yè)面的加載時(shí)間
另外就是通過(guò)靜態(tài)圖片來(lái)衡量帶寬和網(wǎng)絡(luò)延遲，具體可以看
boomerang檢測(cè)工具Speed TracerYahoo! YSlowPage SpeeddynaTrace AJAXreferenceBrowser Performance Wishlist
HTML5
Testing Page Load Speed
Technically speaking, what makes Google Chrome fast?
Optimizing Page Load Time
An Engineer’s Guide to Bandwidth
An Engineer’s Guide to DNS
EricLaw’s IEInternals
Internet Explorer Platform for Privacy Preferences (P3P) Standards Support Document
COMET Streaming in Internet Explorer
Internet Explorer Cookie Internals (FAQ)
Fiddler PowerToy – Part 2: HTTP Performance
Frontend SPOF
XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?
WebKit Page Cache I – The Basics
WebKit Page Cache II – The unload Event
原文地址：
http://www.baiduux.com/blog/2011/02/15/browser-loading/#more-987
