web前端性能

由于web前端性能測(cè)試包含的知識(shí)點(diǎn)很多：瀏覽器工作原理、瀏覽器緩存、相關(guān)的http頭信息、http狀態(tài)碼、完整的一個(gè)http請(qǐng)求及響應(yīng)過(guò)程、響應(yīng)時(shí)間、web前端性能測(cè)試工具以及優(yōu)化方法等等，所以決定分兩篇文章來(lái)總結(jié)，這一篇主要介紹一些跟web前端性能有關(guān)的一些概念，最近也在收集閱讀相關(guān)文檔，一邊學(xué)習(xí)一邊理解消化一邊總結(jié)，有什么不對(duì)

的希望指出。

瀏覽器的主要構(gòu)成：

1>.用戶界面－包括地址欄、后退/前進(jìn)按鈕、書簽?zāi)夸浀�，也就是你所看到的除了用�?lái)

顯示你所請(qǐng)求頁(yè)面的主窗口之外的其他部分。2>.瀏覽器引擎－用來(lái)查詢及操作渲染引擎的接口。

3>.渲染引擎－用來(lái)顯示請(qǐng)求的內(nèi)容，例如，如果請(qǐng)求內(nèi)容為html，它負(fù)責(zé)解析html

及css，并將解析后的結(jié)果顯示出來(lái)。

4>.網(wǎng)絡(luò)－用來(lái)完成網(wǎng)絡(luò)調(diào)用，例如http請(qǐng)求，它具有平臺(tái)無(wú)關(guān)的接口，可以在不同

平臺(tái)上工作。

5>.UI后端－用來(lái)繪制類似組合選擇框及對(duì)話框等基本組件，具有不特定于某個(gè)平臺(tái)

的通用接口，底層使用操作系統(tǒng)的用戶接口。

6>.JS解釋器－用來(lái)解釋執(zhí)行JS代碼。

7>.數(shù)據(jù)存儲(chǔ)－屬于持久層，瀏覽器需要在硬盤中保存類似cookie的各種數(shù)據(jù)，HTML5定義了webdatabase技術(shù)，這是一種輕量級(jí)完整的客戶端存儲(chǔ)技術(shù)

雖然不同瀏覽器的工作方式不完全一樣，但是基本上都包括以上各組件，瀏覽器的核心是瀏覽器引擎（BrowserEngine），目前市場(chǎng)占有率最高的幾種瀏覽器幾乎使用了不同的瀏覽器引擎：IE使用的是Trident，F(xiàn)irefox使用的是Gecko，Safari和Chrome使用的是Webkit。

一個(gè)完整的頁(yè)面請(qǐng)求及響應(yīng)過(guò)程：

1、瀏覽器的url請(qǐng)求2、遞歸尋找DNS服務(wù)器3、連接目標(biāo)IP并建立TCP連接4、向目標(biāo)服務(wù)器發(fā)送http請(qǐng)求

5、web服務(wù)器接收請(qǐng)求后處理

6、web服務(wù)器返回相應(yīng)的結(jié)果【無(wú)效、重定向、正確頁(yè)面等】7、瀏覽器接收返回的http內(nèi)容

=========================================前端解析分割線==============================================8、開(kāi)始解析html文件，當(dāng)然是自上而下，先是頭部，后是body

9、當(dāng)解析到頭部css外部鏈接時(shí)，同步去下載，如果遇到外部js鏈接也是下載【不過(guò)js鏈接不建議放在頭部，因?yàn)榈⒄`頁(yè)面第一展現(xiàn)時(shí)間】

10、接著解析body部分，邊解析邊開(kāi)始生成對(duì)應(yīng)的DOM樹(shù)，同時(shí)等待css文件下載11、一旦css文件下載完畢，那么就同步去用已經(jīng)生成的DOM節(jié)點(diǎn)+CSS去生成渲染樹(shù)12、渲染樹(shù)一旦有結(jié)構(gòu)模型了，接著就會(huì)同步去計(jì)算渲染樹(shù)節(jié)點(diǎn)的布局位置13、一旦計(jì)算出來(lái)渲染的坐標(biāo)后，又同步去開(kāi)始渲染

14、10-13步進(jìn)行過(guò)程中如果遇到圖片則跳過(guò)去渲染下面內(nèi)容，等待圖片下載成功后會(huì)返回來(lái)在渲染原來(lái)圖片的位置

15、同14步，如果渲染過(guò)程中出現(xiàn)js代碼調(diào)整DOM樹(shù)機(jī)構(gòu)的情況，也會(huì)再次重新來(lái)過(guò)，從修改DOM那步開(kāi)始

16、最終所有節(jié)點(diǎn)和資源都會(huì)渲染完成

=========================================分析結(jié)束分割線==============================================17、渲染完成后開(kāi)始page的onload事件18、整個(gè)頁(yè)面load完成

整個(gè)過(guò)程中會(huì)有很多的分別請(qǐng)求，所以TCP連接會(huì)很多，并且每一個(gè)用完都會(huì)自己關(guān)了，除非是keep-live類型的可以請(qǐng)求多次才關(guān)閉。對(duì)web應(yīng)用前端性能的研究并不是為了準(zhǔn)確的得到一個(gè)響應(yīng)時(shí)間數(shù)據(jù)，實(shí)際上，web性能一部分取決于web服務(wù)器和應(yīng)用服務(wù)器（建立連接、下載資源文件），另一部分取決于瀏覽器的實(shí)現(xiàn)機(jī)制、web頁(yè)面上的js文件的執(zhí)行等（分割線以內(nèi)的步驟過(guò)程），我們并不僅僅關(guān)注頁(yè)面資源的解析和展示響應(yīng)時(shí)間，而是要關(guān)注總時(shí)間；我們進(jìn)行web前端性能測(cè)試的目的是計(jì)算出包含頁(yè)面渲染、網(wǎng)絡(luò)傳輸以及

服務(wù)器端解析等綜合因素在內(nèi)的加載時(shí)間等指標(biāo)，對(duì)該頁(yè)面性能進(jìn)行評(píng)估分析，找出影響性能的主要因素和瓶頸，并在此結(jié)果的基礎(chǔ)上，給出一定的優(yōu)化建議和解決方案，從而提升用

戶體驗(yàn)。

Web前端響應(yīng)時(shí)間與緩存有很大關(guān)聯(lián)，而緩存也取決于http請(qǐng)求和響應(yīng)頭的某些信息。下面介紹下與前端性能相關(guān)的http頭信息：先來(lái)說(shuō)說(shuō)為什么要緩存：1>減少網(wǎng)絡(luò)帶寬消耗2>降低服務(wù)器壓力

3>減少網(wǎng)絡(luò)延遲，加快頁(yè)面加載

Web緩存的工作原理是基于一套規(guī)則（http協(xié)議頭定義或HTML頁(yè)面的Meta標(biāo)簽中定義）來(lái)幫助他們決定什么時(shí)候使用緩存中的保存的副本提高服務(wù)。分別從新鮮度和校驗(yàn)值兩個(gè)維度來(lái)決定是使用緩存中的副本還是直接去源服務(wù)器中獲取資源。

新鮮度（過(guò)期機(jī)制）：也就是緩存副本有效期。一個(gè)緩存副本必須滿足以下條件，瀏覽器會(huì)

認(rèn)為它是有效的，足夠新的：

1.含有完整的過(guò)期時(shí)間控制頭信息（HTTP協(xié)議報(bào)頭），并且仍在有效期內(nèi)；2.瀏覽器已經(jīng)使用過(guò)這個(gè)緩存副本，并且在一個(gè)會(huì)話中已經(jīng)檢查過(guò)新鮮度；

滿足以上兩個(gè)情況的一種，瀏覽器會(huì)直接從緩存中獲取副本并渲染。

校驗(yàn)值（驗(yàn)證機(jī)制）：服務(wù)器返回資源的時(shí)候有時(shí)在控制頭信息帶上這個(gè)資源的實(shí)體標(biāo)簽Etag（EntityTag），它可以用來(lái)作為瀏覽器再次請(qǐng)求過(guò)程的校驗(yàn)標(biāo)識(shí)。如過(guò)發(fā)現(xiàn)校驗(yàn)標(biāo)識(shí)

不匹配，說(shuō)明資源已經(jīng)被修改或過(guò)期，瀏覽器需求重新獲取資源內(nèi)容。

看看瀏覽器的一些工作原理：

在先前至少有過(guò)一次有效訪問(wèn)后，在以后對(duì)同一URI資源的請(qǐng)求中，瀏覽器只進(jìn)行兩種動(dòng)

作：

(1)直接在緩存中去獲取內(nèi)容。如果先前有效訪問(wèn)的響應(yīng)頭包含Expires,max-age的話，“打開(kāi)新窗口”、“輸入U(xiǎn)RI回車”、“前一頁(yè)”、“后一頁(yè)”這些瀏覽器行為不會(huì)使瀏覽器在Expires,

max-age設(shè)置的有效期時(shí)間內(nèi)去訪問(wèn)服務(wù)器，而是在緩存中去獲取內(nèi)容，但是""刷新""或"

重載"例外。

(2)訪問(wèn)服務(wù)器，根據(jù)服務(wù)器響應(yīng)來(lái)獲取內(nèi)容。這種情況發(fā)生在設(shè)置no-cache等頭標(biāo)要求不

緩存，或者是設(shè)置了Expires,max-age但瀏覽器行為是“刷新”或“重載”時(shí)候。"Last-Modified"、"ETag"、"must-revalidate"等有些特殊，不直接受瀏覽器行為影響，它們必須訪問(wèn)服務(wù)器后，再由服務(wù)器判斷是直接發(fā)送新的資源，還是發(fā)送一個(gè)304NotModfied

讓瀏覽器使用緩存中的資源。用戶操作的行為也會(huì)影響緩存的使用。

需要注意的一點(diǎn)是瀏覽器的緩存是根據(jù)URI進(jìn)行的，當(dāng)瀏覽器需要從某個(gè)URI獲取資源時(shí)，會(huì)首先查看緩存中是否存在針對(duì)該URI的緩存內(nèi)容，判斷是直接使用還是去數(shù)據(jù)庫(kù)重新去資源，因此需要改變web上顯示的資源時(shí)，只需要在發(fā)布時(shí)使用一個(gè)與以前不同的URI即

可。

關(guān)于瀏覽器并發(fā)數(shù)：

瀏覽器默認(rèn)對(duì)同一域下的資源，只保持一定的連接數(shù)，會(huì)阻塞過(guò)多的連接，即規(guī)定了每個(gè)客戶端只能與每個(gè)服務(wù)器建立的連接數(shù)。rfc2616建議不超過(guò)2個(gè)，但是隨著家庭帶寬和網(wǎng)速的增加，各個(gè)瀏覽器并沒(méi)有保持rfc建議的2個(gè)連接數(shù)，不同瀏覽器的默認(rèn)值是不一樣的，

對(duì)于不同的HTTP協(xié)議，其值也是不一樣的，下面的表格是早期統(tǒng)計(jì)的一些值：

瀏覽器HTTP1.1HTTP1.0IE6,724IE866Firefox228Firefox366Safari3,444Chrome1,26?

瀏覽器HTTP1.1HTTP1.0Chrome344Opera9.644總的來(lái)看，HTTP1.0下允許的連接數(shù)普遍大于HTTP1.1協(xié)議下的，是因?yàn)镠TTP1.1是保持連接的，本身對(duì)同域下資源的獲取就是優(yōu)化的，且對(duì)資源的消耗要大于HTTP1.0。在rfc2616中說(shuō)到，限制連接數(shù)的目的在于提高響應(yīng)速度和避免擁塞。當(dāng)然對(duì)于瀏覽器的連接數(shù)也是可以修改的。使用httpwatch時(shí)頁(yè)面響應(yīng)時(shí)間劃分中的Block這個(gè)時(shí)間段主要就是瀏覽器并發(fā)

數(shù)限制影響的。

HTTP狀態(tài)碼（HTTPStatusCode）是由RFC2616規(guī)范定義，用于表示W(wǎng)eb服務(wù)器HTTP

響應(yīng)狀態(tài)的3位數(shù)字代碼。

所有狀態(tài)碼的第一個(gè)數(shù)字代表了響應(yīng)的5種狀態(tài)之一，這5種狀態(tài)分別如下。

1xx消息：這一類型的狀態(tài)碼，代表請(qǐng)求已被接受，需要繼續(xù)處理。2xx成功：這一類型的狀態(tài)碼，代表請(qǐng)求已成功被服務(wù)器接收、理解并接收。3xx重定向：這類狀態(tài)碼代表需要客戶端采取進(jìn)一步的操作才能完成請(qǐng)求。

4xx請(qǐng)求錯(cuò)誤：這類的狀態(tài)碼代表了客戶端看起來(lái)可能發(fā)生了錯(cuò)誤，妨礙了服務(wù)器的處理。

5xx服務(wù)器錯(cuò)誤：這類狀態(tài)碼代表了服務(wù)器在處理請(qǐng)求的過(guò)程中有錯(cuò)誤或者異常狀態(tài)如使用httpwatch錄制一個(gè)http請(qǐng)求，會(huì)返回200http狀態(tài)碼，表示請(qǐng)求已成功，請(qǐng)求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回；返回302表示請(qǐng)求的資源現(xiàn)在臨時(shí)從不同的URI響應(yīng)請(qǐng)求，由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請(qǐng)求。

只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存

的。；返回304時(shí)需要與其他頭信息綜合查看。

其它的頭信息：1>1.Accept-Encoding

Accept-Encoding是瀏覽器發(fā)出的請(qǐng)求頭中包含的頭信息域之一，用于告訴服務(wù)器所接受

的頁(yè)面文件的編碼方式

比如：Accept-Encoding:gzip,deflate就是告訴服務(wù)器，瀏覽器能夠接受不壓縮和使用gzip壓縮兩種方式的頁(yè)面內(nèi)容。頁(yè)面壓縮和不壓縮之間的下載時(shí)間相差很大，直接影響web前端相應(yīng)時(shí)間。對(duì)比以下兩張圖（使用的是ApacheHTTPServer自帶的ab加壓工具，測(cè)

試對(duì)象是我實(shí)際測(cè)試項(xiàng)目）

2>

2.2.Connection

http協(xié)議是一種非面向連接的、無(wú)狀態(tài)的協(xié)議。每一個(gè)http請(qǐng)求與其他http請(qǐng)求都是完全獨(dú)立的。從理論上講，每個(gè)一個(gè)http請(qǐng)求都會(huì)經(jīng)歷一個(gè)“建立連接-請(qǐng)求頁(yè)面或資源-獲得頁(yè)面或資源-斷開(kāi)連接”的過(guò)程。但是建立和斷開(kāi)連接需要一定的時(shí)間和資源開(kāi)銷，對(duì)于非常小的頁(yè)面和資源文件來(lái)說(shuō)，很可能建立連接所消耗的時(shí)間甚至大于頁(yè)面或資源的處理時(shí)間。為了讓響應(yīng)時(shí)間盡可能縮短，http協(xié)議引入了持久連接。用于控制持久連接的http請(qǐng)求頭就是Connection.當(dāng)Connection的值設(shè)為keep-live時(shí)，瀏覽器與服務(wù)器之間約定使用持久連接。Httpwatch工具下Headers下headersents中可以查看Connection的Value。

擴(kuò)展閱讀：Web前端性能優(yōu)化全攻略

網(wǎng)頁(yè)制作Webjx文章簡(jiǎn)介：Web前端性能優(yōu)化是個(gè)大話題，是個(gè)值得運(yùn)維人員持續(xù)跟蹤的話題，是被很多網(wǎng)站無(wú)情忽視的技術(shù)。

Web前端性能優(yōu)化是個(gè)大話題，是個(gè)值得運(yùn)維人員持續(xù)跟蹤的話題，是被很多網(wǎng)站無(wú)情忽視的技術(shù)。

Web前端優(yōu)化最佳實(shí)踐之內(nèi)容篇Web前端優(yōu)化最佳實(shí)踐之Server篇Web前端優(yōu)化最佳實(shí)踐之Cookie篇Web前端優(yōu)化最佳實(shí)踐之CSS篇

Web前端優(yōu)化最佳實(shí)踐之JavaScript篇Web前端優(yōu)化最佳實(shí)踐之圖象篇

Web前端優(yōu)化最佳實(shí)踐之Mobile(iPhone)篇

Yahoo!的ExceptionalPerformanceteam在Web前端方面作出了卓越的貢獻(xiàn)。廣為人知的優(yōu)化規(guī)則也由13條到14條，再到20條，乃至現(xiàn)在的34條--真是與時(shí)俱進(jìn)啊。最新的34條也針對(duì)不同的角度做了分類。面向內(nèi)容的優(yōu)化規(guī)則目前有10條。

1.盡量減少HTTP請(qǐng)求(MakeFewerHTTPRequests)

作為第一條，可能也是最重要的一條。根據(jù)Yahoo!研究團(tuán)隊(duì)的數(shù)據(jù)分析，有很大一部分用戶訪問(wèn)會(huì)因?yàn)檫@一條而取得最大受益。有幾種常見(jiàn)的方法能切實(shí)減少HTTP請(qǐng)求：

1)合并文件，比如把多個(gè)CSS文件合成一個(gè)；

2)CSSSprites利用CSSbackground相關(guān)元素進(jìn)行背景圖絕對(duì)定位；參見(jiàn)：CSSSprites:ImageSlicing"sKissofDeath3)圖像地圖

4)內(nèi)聯(lián)圖象使用data:URLscheme在實(shí)際的頁(yè)面嵌入圖像數(shù)據(jù).

2.減少DNS查找(ReduceDNSLookups)

必須明確的一點(diǎn)，DNS查找的開(kāi)銷是很大的。另外，我倒是覺(jué)得這是Yahoo!所有站點(diǎn)的通病，Yahoo！主站點(diǎn)可能還不夠明顯，一些分站點(diǎn)，存在明顯的類似問(wèn)題。對(duì)于國(guó)內(nèi)站點(diǎn)來(lái)說(shuō)，如果過(guò)多的使用了站外的Widget，也很容易引起過(guò)多的DNS查找問(wèn)題。

3.避免重定向(AvoidRedirects)

不是絕對(duì)的避免，盡量減少。另外，應(yīng)該注意一些不必要的重定向。比如對(duì)Web站點(diǎn)子目錄的后面添加個(gè)/(Slash)，就能有效避免一次重定向。

與二者之間是有差異的。如果是Apache服務(wù)器，通過(guò)配置Alias或mod_rewrite或是DirectorySlash能夠消除這個(gè)問(wèn)題。

4.使得Ajax可緩存(MakeAjaxCacheable)

響應(yīng)時(shí)間對(duì)Ajax來(lái)說(shuō)至關(guān)重要，否則用戶體驗(yàn)絕對(duì)好不到哪里去。提高響應(yīng)時(shí)間的有效手段就是Cache。其它的一些優(yōu)化規(guī)則對(duì)這一條也是有效的。5.延遲載入組件(Post-loadComponents)6.預(yù)載入組件(PreloadComponents)

上面兩條嚴(yán)格說(shuō)來(lái)，都是屬于異步這個(gè)思想靈活運(yùn)用的事兒。7.減少DOM元素?cái)?shù)量(ReducetheNumberofDOMElements)8.切分組件到多個(gè)域(SplitComponentsAcrossDomains)

主要的目的是提高頁(yè)面組件并行下載能力。但不要跨太多域名，否則就和第二條有些沖突了。

9.最小化iframe的數(shù)量(MinimizetheNumberofiframes)

熟悉SEO的朋友知道iframe是SEO的大忌。針對(duì)前端優(yōu)化來(lái)說(shuō)iframe有其好處，也有其弊端，一分為二看問(wèn)題吧。10.杜絕http404錯(cuò)誤(No404s)

對(duì)頁(yè)面鏈接的充分測(cè)試加上對(duì)Web服務(wù)器error日志的不斷跟蹤能有效減少404錯(cuò)誤，亦能提升用戶體驗(yàn)。值得一提的是，CSS與JavaScript引起的404錯(cuò)誤因?yàn)槎ㄎ簧陨?難"一點(diǎn)而往往容易被忽略。

這是內(nèi)容篇的10條。應(yīng)該說(shuō)具體引導(dǎo)性的內(nèi)容還不夠詳細(xì)。逐漸會(huì)根據(jù)自己的理解補(bǔ)充上來(lái)

Web前端優(yōu)化最佳實(shí)踐第二部分面向Server。目前共計(jì)有6條實(shí)踐規(guī)則�！咀�，這最多算技術(shù)筆記，查看最原始內(nèi)容，還請(qǐng)?jiān)L問(wèn)：ExceptionalPerformance:BestPracticesforSpeedingUpYourWebSite】1.使用CDN(UseaContentDeliveryNetwork)

國(guó)內(nèi)CDN的普及還不夠。不過(guò)我們有獨(dú)特的電信、網(wǎng)通之間的問(wèn)題，如果針對(duì)這個(gè)作優(yōu)化，基本上也算能收到CDN或類似的效果吧(假裝如此)�！綯in說(shuō)國(guó)內(nèi)CDN用的挺多，看看CDN廠商的市場(chǎng)就知道了，還沒(méi)走入尋常百姓家】2.添加Expires或Cache-Control信息頭(AddanExpiresoraCache-ControlHeader)

各個(gè)瀏覽器都有針對(duì)的方案,Apache例子【注意：下面的說(shuō)明例子還不夠精細(xì)，具體的環(huán)境上還要加一些調(diào)整】:

ExpiresActiveOn

ExpiresByTypeimage/gif"modificationplus1weeks"Lighttpd啟用mod_expire模塊后：

$HTTP["url"]=~"\\.(jpg|gif|png)___FCKpd___1quot;{expire.url=(""=>"access1years")}

Nginx例子參考:

location~*\\.(jpg|gif|png)${if(-f$request_filename){expiresmax;break;}}

3.壓縮內(nèi)容(GzipComponents)

對(duì)于絕大多數(shù)站點(diǎn)，這都是必要的一步，能有效減輕網(wǎng)絡(luò)流量壓力�；蛟S有人擔(dān)心對(duì)CPU壓縮對(duì)于CPU的影響，放心大膽的整吧，沒(méi)事兒。Nginx例子：gzipon;

gzip_typestext/plaintext/htmltext/cssext/javascript;另外參見(jiàn)：

IIS如何啟用Gzip壓縮?4.設(shè)置Etags(ConfigureETags)

對(duì)于Etag，可能是多數(shù)網(wǎng)站維護(hù)者都會(huì)忽略的地方。在這一系列優(yōu)化規(guī)則出現(xiàn)之前，可能互聯(lián)網(wǎng)上絕大多數(shù)站點(diǎn)都對(duì)這個(gè)問(wèn)題忽略了。當(dāng)然，Etag對(duì)多數(shù)站點(diǎn)性能的影響并不是很大。除非是面向RSS的網(wǎng)站�！究吹接信笥雅�評(píng)說(shuō)寫的簡(jiǎn)略，并且說(shuō)IE不支持ETag。明確說(shuō)一下：IE支持ETag，倒是使用IIS要注意相關(guān)EtagBug�！�

補(bǔ)充：我的意思是"很多網(wǎng)站在不注意的情況下都是打開(kāi)Etag的，而沒(méi)有網(wǎng)站關(guān)心如何用，消耗資源而不知。并不是說(shuō)Etag不好，合理利用Etag，絕對(duì)能取得很好的收益.

5.盡早刷新Buffer(FlushtheBufferEarly)

對(duì)這一條，琢磨了半天，貌似還是異步的思路。能更好的提升用戶體驗(yàn)?6.對(duì)AJAX請(qǐng)求使用GET方法(UseGETforAJAXRequests)

XMLHttpRequestPOST要兩步，而GET只需要一步。但要注意的是在IE上GET最大能處理的URL長(zhǎng)度是2K。

Web前端優(yōu)化最佳實(shí)踐第三部分面向Cookie。目前只有2條實(shí)踐規(guī)則。1.縮小Cookie(ReduceCookieSize)

Cookie是個(gè)很有趣的話題。根據(jù)RFC2109的描述，每個(gè)客戶端最多保持300個(gè)Cookie，針對(duì)每個(gè)域名最多20個(gè)Cookie(實(shí)際上多數(shù)瀏覽器現(xiàn)在都比這個(gè)多，比如Firefox是50個(gè))，每個(gè)Cookie最多4K，注意這里的4K根據(jù)不同的瀏覽器可能不是嚴(yán)格的4096。別扯遠(yuǎn)了，對(duì)于Cookie最重要的就是，盡量控制Cookie的大小，不要塞入一些無(wú)用的信息。

2.針對(duì)Web組件使用域名無(wú)關(guān)性的Cookie(UseCookie-freeDomainsforComponents)

這個(gè)話題在此前針對(duì)Web圖片服務(wù)器的討論中曾經(jīng)提及。這里說(shuō)的Web組件(Component)，多指靜態(tài)文件，比如圖片CSS等，Yahoo!的靜態(tài)文件都在yimg.com上，客戶端請(qǐng)求靜態(tài)文件的時(shí)候，減少了Cookie的反復(fù)傳輸對(duì)主域名(yahoo.com)的影響。

從這篇WhentheCookieCrumbles能看出，MySpace和eBay的Cookie都不小的，想必是對(duì)用戶行為比較關(guān)心。eBay前不久構(gòu)造了PersonalizationPlatform，就是從Cookie的限制中跳出來(lái)。

Web前端優(yōu)化最佳實(shí)踐第四部分面向CSS。目前共計(jì)有6條實(shí)踐規(guī)則。另請(qǐng)參見(jiàn)Mozilla開(kāi)發(fā)者中心的文章：WritingEfficientCSS1.把CSS放到代碼頁(yè)上端(PutStylesheetsattheTop)

官方的解釋我覺(jué)得多少有點(diǎn)語(yǔ)焉不詳。這一條其實(shí)和用戶訪問(wèn)期望有關(guān)。CSS放到最頂部，瀏覽器能夠有針對(duì)性的對(duì)HTML頁(yè)面從頂?shù)较逻M(jìn)行解析和渲染。沒(méi)有人喜歡等待，而瀏覽器已經(jīng)考慮到了這一點(diǎn)。2.避免CSS表達(dá)式(AvoidCSSExpressions)

個(gè)人認(rèn)為通過(guò)CSS表達(dá)式能做到的事情，通過(guò)其它手段也同樣能做到而且風(fēng)險(xiǎn)更小一些。

3.從頁(yè)面中剝離JavaScript與CSS(MakeJavaScriptandCSSExternal)剝離后，能夠有針對(duì)性的對(duì)其進(jìn)行單獨(dú)的處理策略，比如壓縮或者緩存策略。4.精簡(jiǎn)JavaScript與CSS(MinifyJavaScriptandCSS)

如果沒(méi)有JavaScript與CSS可能更好。但，這是不可能的，SO，盡量小點(diǎn)吧。語(yǔ)法能簡(jiǎn)寫的簡(jiǎn)寫。

5.使用而不是@importChooseover@import

在IE中@import指令等同于把link標(biāo)記寫在HTML的底部。而這與第一條相違背。

6.避免使用Filter(AvoidFilters)

Web前端優(yōu)化最佳實(shí)踐之JavaScript篇，這部分有6條規(guī)則，和CSS篇重復(fù)的有幾條。前端優(yōu)化最佳實(shí)踐，最重要的還是"實(shí)踐"，要理解這東西容易得很，關(guān)鍵是要去"實(shí)踐"，去"執(zhí)行"，去"反饋"，去獲取受益。1.腳本放到HTML代碼頁(yè)底部(PutScriptsattheBottom)

當(dāng)一個(gè)腳本在下載的時(shí)候，瀏覽器干不了其它的事兒(串行了)。所以，把它扔到最后面去處理。對(duì)于一些功能性的腳本，可能實(shí)現(xiàn)起來(lái)有些兩難。不過(guò)對(duì)于國(guó)內(nèi)網(wǎng)站來(lái)說(shuō)，有很多使用GoogleAnalytics服務(wù)進(jìn)行網(wǎng)站數(shù)據(jù)分析的。這這一點(diǎn)來(lái)說(shuō)，絕對(duì)可行的建議，放到頁(yè)面最底下。2.MakeJavaScriptandCSSExternal參見(jiàn)CSS篇的描述

3.精簡(jiǎn)JavaScript與CSS(MinifyJavaScriptandCSS)參見(jiàn)CSS篇的描述

4.移除重復(fù)腳本(RemoveDuplicateScripts)

對(duì)于一些歷史遺留站點(diǎn)或是論壇類的網(wǎng)站來(lái)說(shuō)，這倒是比較常見(jiàn)的。接手維護(hù)人前后變化過(guò)多，每個(gè)人都有自己的一套。這就會(huì)帶來(lái)一些潛在的麻煩。5.減少DOM訪問(wèn)(MinimizeDOMAccess)有三條指導(dǎo)建議:

緩存已經(jīng)訪問(wèn)過(guò)的元素(Cachereferencestoaccessedelements)"離線"更新節(jié)點(diǎn),再將它們添加到樹(shù)中(Updatenodes"offline"andthenaddthemtothetree)

避免使用JavaScript輸出頁(yè)面布局--應(yīng)該是CSS的事兒(AvoidfixinglayoutwithJavaScript)

6.DevelopSmartEventHandlers

除了英文解釋外，這里也提醒一下注意關(guān)于JavaScript內(nèi)存泄漏的問(wèn)題。另外推薦一篇《如何優(yōu)化JavaScript腳本的性能》，關(guān)于Ajax優(yōu)化指導(dǎo)原則，可以參見(jiàn)提高Ajax應(yīng)用程序性能，避開(kāi)Web服務(wù)漏洞。

后記1)：整理得差不多之后，發(fā)現(xiàn)網(wǎng)絡(luò)上已經(jīng)有一篇《Yahoo!網(wǎng)站性能最佳體驗(yàn)的34條黃金守則》，是翻譯稿�？磥�(lái)我做了一部分重復(fù)勞動(dòng)。

后記2)：CSS/JavaScript都有優(yōu)化規(guī)則。但似乎缺少了對(duì)Flash的優(yōu)化實(shí)踐。

Web前端優(yōu)化最佳實(shí)踐第六部分面向圖片(Image)，這部分目前有4條規(guī)則。在最近的Velocity201*技術(shù)大會(huì)上，Yahoo!的StoyanStefanov做的ImageOptimization:HowManyofThese7MistakesAreYouMaking也非常有參考價(jià)值。結(jié)合一起說(shuō)一下。1.優(yōu)化圖片(OptimizeImages)

使用GIF、JPG還是PNG格式的圖片?盡可能的使用PNG格式的圖片，更多的功能，更小的尺寸(與GIF相比)。

對(duì)于PNG圖片，考慮用Pngcrush或類似的工具進(jìn)行優(yōu)化。常見(jiàn)的工具如下表:pngcrush

pngrewrite~jason1/pngrewrite/

OptiPNG~cosmin/pngtech/optipng/(refer:教程)

PNGOut

另請(qǐng)參見(jiàn):FiveTipsFortheEffectiveUseofPNGImages對(duì)JPEG圖片的優(yōu)化工具：

jpegtran()必需要強(qiáng)調(diào)的是，圖片設(shè)計(jì)的同學(xué)啊，請(qǐng)考慮設(shè)計(jì)面向Web的圖片，不要?jiǎng)硬粍?dòng)就設(shè)計(jì)超過(guò)可接受尺寸之外大家伙，這應(yīng)該是一種習(xí)慣，而不是什么高超的技能，只需要記住就成了。

2.使用CSSSprites技巧對(duì)圖片優(yōu)化(OptimizeCSSSprites)

之前提到過(guò)，簡(jiǎn)單的說(shuō)就是"利用CSSbackground相關(guān)元素進(jìn)行背景圖絕對(duì)定位"，把多次HTTP調(diào)用變?yōu)橐淮握{(diào)用，更多參考：CSSSprites:ImageSlicing"sKissofDeath

補(bǔ)充一下：對(duì)于這個(gè)技巧我曾經(jīng)見(jiàn)到有人濫用的。把多個(gè)背景圖片揉成一個(gè)，減少HTTP調(diào)用，這是一個(gè)很好的思路。但一定要記住這個(gè)大圖片不能太"重"，我看到過(guò)100多K的背景圖。一個(gè)圖片就把整個(gè)網(wǎng)站拖得很慢。比較好的例子可以參考雅虎關(guān)系的這個(gè)圖.

更新：使用CSSSprites的一個(gè)潛在的副作用是客戶端將消耗更多內(nèi)存(參考)。3.不要在HTML中使用縮放圖片(Don"tScaleImagesinHTML)

更多的時(shí)候，可能是因?yàn)橥祽卸鴽](méi)有制作合適大小的圖片，如果是批量處理圖片的話，可能一條ImageMagic命令（convert）就能搞定。必須提及的是，看到太多的對(duì)圖片拉伸很難看的頁(yè)面，救救這些頁(yè)面!

4.用更小的并且可緩存的favicon.ico(Makefavicon.icoSmallandCacheable)

更小，可緩存，這兩條可能都不是問(wèn)題。問(wèn)題是，太多站點(diǎn)根本沒(méi)有

favicon.ico。有的時(shí)候，判斷獨(dú)立域名的Blog是否專業(yè)，基本看一下是否有favicon.ico就差不多了。--EOF--

補(bǔ)充：視覺(jué)設(shè)計(jì)者應(yīng)該盡量考慮控制圖片大小，推薦在200K以下。這不是胡說(shuō)的，參考頁(yè)面。

Web前端優(yōu)化最佳實(shí)踐最后一部分是針對(duì)移動(dòng)應(yīng)用的，其實(shí)只是針對(duì)iPhone的，目前只有兩條規(guī)則。

1.單個(gè)數(shù)據(jù)對(duì)象小于25K(KeepComponentsunder25K)

這個(gè)似乎只是針對(duì)iPhone研究的。建議保持單個(gè)Web數(shù)據(jù)對(duì)象在25K以下。為什么是25K?Apple官方信息指出可緩存到內(nèi)存中的Web對(duì)象最大支持到10M，但經(jīng)過(guò)測(cè)試，發(fā)現(xiàn)也就是25K左右。

iPhone在市場(chǎng)上的優(yōu)異表現(xiàn)，讓W(xué)eb人員不得不考慮如何針對(duì)其進(jìn)行優(yōu)化。相信這部分內(nèi)容也在不斷變化中。2.PackComponentsintoaMultipartDocument

把Web頁(yè)面組件打包成一個(gè)多部分組成的文檔。其目的是減少HTTP請(qǐng)求。對(duì)這部分語(yǔ)焉不詳，等待后續(xù)更新吧。

友情提示：本文中關(guān)于《web前端性能》給出的范例僅供您參考拓展思維使用，web前端性能：該篇文章建議您自主創(chuàng)作。

來(lái)源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問(wèn)題，請(qǐng)聯(lián)系我們及時(shí)刪除。

《web前端性能》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請(qǐng)保留原作者信息,謝謝!
鏈接地址：http://www.hmlawpc.com/gongwen/585521.html

• 上一篇：幾個(gè)Web前端開(kāi)發(fā)框架的比較
• 下一篇：Web前端開(kāi)發(fā)工程師成長(zhǎng)之路