web前端性能

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

的希望指出。

瀏覽器的主要構成：

1>.用戶界面－包括地址欄、后退/前進按鈕、書簽目錄等，也就是你所看到的除了用來

顯示你所請求頁面的主窗口之外的其他部分。2>.瀏覽器引擎－用來查詢及操作渲染引擎的接口。

3>.渲染引擎－用來顯示請求的內(nèi)容，例如，如果請求內(nèi)容為html，它負責解析html

及css，并將解析后的結果顯示出來。

4>.網(wǎng)絡－用來完成網(wǎng)絡調(diào)用，例如http請求，它具有平臺無關的接口，可以在不同

平臺上工作。

5>.UI后端－用來繪制類似組合選擇框及對話框等基本組件，具有不特定于某個平臺

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

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

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

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

一個完整的頁面請求及響應過程：

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

5、web服務器接收請求后處理

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

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

9、當解析到頭部css外部鏈接時，同步去下載，如果遇到外部js鏈接也是下載【不過js鏈接不建議放在頭部，因為耽誤頁面第一展現(xiàn)時間】

10、接著解析body部分，邊解析邊開始生成對應的DOM樹，同時等待css文件下載11、一旦css文件下載完畢，那么就同步去用已經(jīng)生成的DOM節(jié)點+CSS去生成渲染樹12、渲染樹一旦有結構模型了，接著就會同步去計算渲染樹節(jié)點的布局位置13、一旦計算出來渲染的坐標后，又同步去開始渲染

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

15、同14步，如果渲染過程中出現(xiàn)js代碼調(diào)整DOM樹機構的情況，也會再次重新來過，從修改DOM那步開始

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

=========================================分析結束分割線==============================================17、渲染完成后開始page的onload事件18、整個頁面load完成

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

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

戶體驗。

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

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

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

新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，瀏覽器會

認為它是有效的，足夠新的：

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

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

校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽Etag（EntityTag），它可以用來作為瀏覽器再次請求過程的校驗標識。如過發(fā)現(xiàn)校驗標識

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

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

在先前至少有過一次有效訪問后，在以后對同一URI資源的請求中，瀏覽器只進行兩種動

作：

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

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

重載"例外。

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

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

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

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

可。

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

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

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

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

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

數(shù)限制影響的。

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

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

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

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

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

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

只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存

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

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

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

的頁面文件的編碼方式

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

試對象是我實際測試項目）

2>

2.2.Connection

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

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

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

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

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

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

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

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

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

作為第一條，可能也是最重要的一條。根據(jù)Yahoo!研究團隊的數(shù)據(jù)分析，有很大一部分用戶訪問會因為這一條而取得最大受益。有幾種常見的方法能切實減少HTTP請求：

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

2)CSSSprites利用CSSbackground相關元素進行背景圖絕對定位；參見：CSSSprites:ImageSlicing"sKissofDeath3)圖像地圖

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

2.減少DNS查找(ReduceDNSLookups)

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

3.避免重定向(AvoidRedirects)

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

與二者之間是有差異的。如果是Apache服務器，通過配置Alias或mod_rewrite或是DirectorySlash能夠消除這個問題。

4.使得Ajax可緩存(MakeAjaxCacheable)

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

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

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

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

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

對頁面鏈接的充分測試加上對Web服務器error日志的不斷跟蹤能有效減少404錯誤，亦能提升用戶體驗。值得一提的是，CSS與JavaScript引起的404錯誤因為定位稍稍"難"一點而往往容易被忽略。

這是內(nèi)容篇的10條。應該說具體引導性的內(nèi)容還不夠詳細。逐漸會根據(jù)自己的理解補充上來

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

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

各個瀏覽器都有針對的方案,Apache例子【注意：下面的說明例子還不夠精細，具體的環(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)

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

gzip_typestext/plaintext/htmltext/cssext/javascript;另外參見：

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

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

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

5.盡早刷新Buffer(FlushtheBufferEarly)

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

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

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

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

2.針對Web組件使用域名無關性的Cookie(UseCookie-freeDomainsforComponents)

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

從這篇WhentheCookieCrumbles能看出，MySpace和eBay的Cookie都不小的，想必是對用戶行為比較關心。eBay前不久構造了PersonalizationPlatform，就是從Cookie的限制中跳出來。

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

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

個人認為通過CSS表達式能做到的事情，通過其它手段也同樣能做到而且風險更小一些。

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

如果沒有JavaScript與CSS可能更好。但，這是不可能的，SO，盡量小點吧。語法能簡寫的簡寫。

5.使用而不是@importChooseover@import

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

6.避免使用Filter(AvoidFilters)

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

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

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

4.移除重復腳本(RemoveDuplicateScripts)

對于一些歷史遺留站點或是論壇類的網(wǎng)站來說，這倒是比較常見的。接手維護人前后變化過多，每個人都有自己的一套。這就會帶來一些潛在的麻煩。5.減少DOM訪問(MinimizeDOMAccess)有三條指導建議:

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

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

6.DevelopSmartEventHandlers

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

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

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

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

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

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

pngrewrite~jason1/pngrewrite/

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

PNGOut

另請參見:FiveTipsFortheEffectiveUseofPNGImages對JPEG圖片的優(yōu)化工具：

jpegtran()必需要強調(diào)的是，圖片設計的同學啊，請考慮設計面向Web的圖片，不要動不動就設計超過可接受尺寸之外大家伙，這應該是一種習慣，而不是什么高超的技能，只需要記住就成了。

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

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

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

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

更多的時候，可能是因為偷懶而沒有制作合適大小的圖片，如果是批量處理圖片的話，可能一條ImageMagic命令（convert）就能搞定。必須提及的是，看到太多的對圖片拉伸很難看的頁面，救救這些頁面!

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

更小，可緩存，這兩條可能都不是問題。問題是，太多站點根本沒有

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

補充：視覺設計者應該盡量考慮控制圖片大小，推薦在200K以下。這不是胡說的，參考頁面。

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

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

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

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

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

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

來源：網(wǎng)絡整理 免責聲明：本文僅限學習分享，如產(chǎn)生版權問題，請聯(lián)系我們及時刪除。

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

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