1．關於減少http請求數
關於減少http請求數,是前端開發性能優化的一個非常重要方面,所以在基本所有的優化原則里,都有這一條原則:減少http請求數.
先不考慮其他的,我們先考慮為什么減少http請求可以優化性能.
減少http請求有這樣幾個優點:
(1) 減少DNS請求所耗費的時間.
且不說對錯,因為從基本來說,減少http請求數的確可以減少DNS請求和解析耗費的時間.
(2) 減少服務器壓力.
這個通常是被考慮最多的,也是我用來講解給別人聽的最大理由,因為每個http請求都會耗費服務器資源,特別是一些需要計算合並等操作的服務器,耗費服務器的cpu資源可不是開玩笑的事情,硬盤可以用錢買來,cpu資源可就沒那么廉價了.
(3) 減少http請求頭.
當我們對服務器發起一個請求的時候,我們會攜帶着這個域名下的cookie和一些其他的信息在http頭部里,然后服務器響應請求的時候也會帶回一些cookie之類的頭部信息.這些信息有的時候會很大,在這種請求和響應的時候會影響帶寬性能.
2．讓我們來一一道來
(1) 什么是DNS請求和解析呢?
簡單來說,例如:www.taobao.com這樣一個url,其中www部分被稱為主機名(hostname),taobao這部分則是二級域,com則是一級域,如果是這樣一個網址:www.ali.taobao.com.那么ali就是三級域.
當我們去請求一個url的時候,首先會到本地服務器里去尋找緩存中是否有解析結果,如果沒有解析結果,就去根域名服務器請求,根域名服務器返回給本 地域名服務器一個所查詢的域的主域名服務器的ip地址,然后我們再去請求剛才返回的ip地址的域名服務器,然后返回下一級域名的ip地址,直到我們找到域 名中所指的服務器ip,然后將結果緩存起來供下次使用,並返回此結果.
一個第一次請求的url的DNS解析過程可能耗費是很高的.但是解析一次之后,結果就會被緩存起來,之后再請求的時候就不用走上面這一套復雜的解析過程了.
關於一個正常的DNS請求到底會耗費多少時間,這個沒有定論,要看網速狀況和地域,但是考慮一個dns解析解析過后會被緩存起來,像淘寶這樣的大網站,來的都是回頭客,我們是否可以忽略DNS解析花費的時間呢?
在前端優化里還有一個優化方法,那就是增加hostname,例如,淘寶圖片服務器,分為img01，img02，img03等主機名,這樣做是因 為考慮到瀏覽器對同一個域名下同時進行的http連接數的限制,具體可以見下表: .然后我們在一個頁面里的圖片放在不同的hostname下,這樣就可以同時下載多個圖片了,瀏覽器http連接數的限制可以被緩解一下,但是這樣做的后 果就是yslow評分會下降,因為yslow將DNS請求看的比較重要.
Browser HTTP/1.1 HTTP/1.0 IE 6,7 2 4 IE 8 6 6 Firefox 2 2 8 Firefox 3 6 6 Safari 3,4 4 4 Opera 9.61 8 2
在此,就要引出我們想討論的東西,為什么yslow評分在合理的情況下分數反而會低,因為yslow只是一個機器程序,它並不知道 我們的網站是什么類型的,是何種規模的,是內容型還是應用型,所以我們可以用異步加載的方式來欺騙yslow對於dom節點的評分,但是異步加載真的適合 我們的網站么?同樣,別人寫了一篇文章,出了一個原則,一個最佳實踐,但是你確定他說的情況適合你的情況么?網站有大有小,大小不同,需要考慮的東西也就 不同.
為什么對於淘寶的圖片來說,使用不同的hostname是個更優的方案呢?
首先,因為淘寶網的特殊性,淘寶網大多數訪問者都是回頭客,他們電腦里大多緩存着dns記錄.這種情況,如果是小網站或者新興網站可能要考慮,因為新用戶比較多,可能dns請求的消耗更大一些,而且第一印象對於這些網站來說更為重要.
再者,淘寶里的圖片很多,一個頁面里通常會用到幾十張甚至上百張圖片,在這種情況下,我們更需要突破瀏覽器的http連接數的限制,以便加快加載速 度,這時候加載速度的考慮優先級遠遠高於DNS的影響,而yslow中對於DNS的着重考慮可能更偏向中小網站,圖片比較少的網站.
對於DNS請求或者tcp(tcp握手之類的也會消耗請求時間)請求之類的分配和解析的消耗,還有一個辦法是keeplive,讓你的鏈接保持keeplive,這樣可以只建立一次鏈接,然后傳輸多個文件,可以有效減少建立連接的時間.
(2) 減少服務器壓力
過多的http請求對於服務器來說是很危險的,如果你的服務器不是很強,請把這一條考慮放在第一位,其他的優化策略都只是優化,而這里涉及到的是服務器,你要保證你的服務器能正常運轉.
當然如果你是在淘寶的話,你就可以安心坐下來跟一群牛人談論為什么要忽略http對服務器的影響,因為我們要記住:我們是前端開發工程師,我們是在 做前端優化,后台和我們無關,因為我們有足夠強大的技術支持和硬件支持,當網站的技術發展到一定程度的時候,我們的關注點應該向用戶那里偏重,因為用戶看 到的才是我們最終要展示的,用戶感受到的體驗和速度才是我們要達到的速度,后台我們做的再快,前台呈現慢了,我們的服務器消耗少了,省錢了,但是用戶卻因 此拋棄了我們,一切都是白費.所以,當后台足夠支撐你不用你去考慮后台壓力的時候,那就安心考慮如何做好前台的工作吧.
Yslow真的是一個誤導人的工具,只要我們按照它的原則對網站進行優化,肯定最后可以拿到高分來欺騙老板,但是對於有些場景,這些優化往往是一種 對性能的破壞,例如淘寶網的商城首頁,為了提高Yslow評分,所有的圖片都采用了一個hostname,分數提高了,但是並行加載少了,不過商城首頁都 是異步渲染和異步加載的,所以這種影響看起來並不明顯.
商城首頁有很多針對yslow的優化點,當然大多數優化是正確的,例如:導航那里,本來是全部寫在頁面里的,不要小看那個導航,里面有N個鏈接節 點,以至於從瀏覽器里復制源代碼的時候瀏覽器會卡死,因為字節數太多了,這里yslow肯定不會饒過的,后來我們把導航做成了異步加載的,評分理所當然上 去了.但是這是淘寶網,我們有足夠的速度來提供足夠的用戶體驗.如果你的服務器提供不了這種速度,也承受不了這種頻繁的異步請求的話,這種優化就要慎重 了,延遲可能造成導航不可用.這也是針對場景來協調的.
淘寶現在在廣泛部署CDN,CDN可以給我們提供足夠的后台資源保障,在CDN和后台環境不斷萬善的情況下,考慮重點應該更加專注於前台傳輸速度和展現解析速度的提升.
(3) 合並腳本和樣式?
其實在前一篇文章里的那段討論也是對於不同應用場景的不同考慮,
減少http請求數的一個方法,對於前端來說,那就是合並腳本和樣式文件,稱為combo,通過將多個文件合並成一個文件,然后一次性傳輸到客戶 端,這樣可以減少http請求,的確是個有效的方法,甚至對於一些特殊的頁面,例如首頁,我們把樣式和腳本都寫在了頁面里,根本沒有分離出來,他們不會產 生http請求,當然,也不會被緩存,這是被犧牲的代價.
為什么我們要這么做,因為首頁的訪問量很大?這樣可以有效減少http請求數?恩,這只是一部分原因,的確這樣做有這樣的好處,而且對於assets服務器不夠強大的網站來說,在並發量大的首頁上實行這一套是很有效的.
但是,淘寶訪問量最大的頁面並不是首頁,而是detail頁面,也就是商品詳情頁!
這才是我們討論的重點,為什么首頁采用combo甚至寫在頁面里,而detail則按照正常的樣式和腳本來引用.首頁是類似靜態的頁面,detail則是應用型的.首頁沒有腳本,依然可以起到導向的作用,但是detail頁腳本沒有運行起來的話,甚至無法購買商品.
其實在這里這樣討論並不能明顯看出問題所在,因為淘寶在這些方面也不是很成熟,detail頁引用了大量腳本和樣式,很多內容是多余的過期的.
這從本質上來說代表兩種網頁類型,一種是內容型,一種則是應用型.對於內容型的網站,腳本並不是很重要(甚至樣式),因為沒有腳本,用戶仍然可以瀏 覽頁面,只是可能有些效果看不到而已,所以我們可以把腳本合並起來,一起放在body底部,在頁面內容都加載完后,再一次性加載進來.而對於應用型的網 頁,讓應用跑起來才是最重要的,因為沒有應用這個網頁就變得沒有意義了,這時候,按需加載腳本是一種趨勢,我們需要先把應用的基本框架和功能按需加載進 來,讓它們分別運行起來,而不是一起等腳本加載完再一起初始化,我們需要應用能夠快速響應用戶,
而且還是說到CDN,當CDN變得足夠強的時候,連接數已經不是瓶頸,我們應該更多考慮怎么讓網頁更快的展現給用戶,對於無需腳本也可以提供服務的 內容型的網頁,將腳本放在頁面底部,合並起來(減少連接數,我們仍然需要減少連接數,在不需要太快的使用腳本的情況下),而對於應用型的網頁,我們需要盡 快讓功能運轉,甚至讓他們一部分一部分按優先級初始化,這時候就要將腳本分開,按需加載.
(4) 減少http請求頭
http頭是個龐大的家伙,你打開taobao.com的首頁,alert一下document.cookie,會發現淘寶網的cookie是如此 龐大,甚至比小型網頁都大,每次你請求淘寶的服務器都會往返一次這些數據,還有一些其他的頭部信息,占用的空間也不小,可想而知這種消耗有多大.
然后其實自從用了CDN,這一切都無需考慮太多,因為CDN和淘寶主站不在一個域名下,cookie不會互相污染,而CDN的域名下基本是沒有 cookie和頭部信息的,所以每次請求靜態資源的時候,不會帶着主站的cookie到處跑,而只是傳輸資源的主題內容,所以這對於性能的影響在使用 cdn之后會變得很小.但是如果你的靜態資源服務器和主服務器在一個域名下,那就要控制好cookie和其他頭部信息的大小了,因為每次傳送都會傳送他 們.
最后
總之,優化原則不是絕對的,對於不同的場景應該考慮不同的側重點,別人的解決方案對於你來說不一定是最優的,應該針對自己的網站規模和類型進行適度的優化,不能盲目追求標准和最佳實踐.
原文鏈接：http://www.cnblogs.com/fsjohnhuang/articles/2422787.html