1.理所固然咱們是這樣想的html
關於減小http請求數,是前端開發性能優化的一個很是重要方面,因此在基本全部的優化原則裏,都有這一條原則:減小http請求數.前端
先不考慮其餘的,咱們先考慮爲何減小http請求能夠優化性能.瀏覽器
減小http請求有這樣幾個優勢:緩存
(1) 減小DNS請求所耗費的時間.性能優化
且不說對錯,由於從基原本說,減小http請求數的確能夠減小DNS請求和解析耗費的時間.服務器
(2) 減小服務器壓力.cookie
這個一般是被考慮最多的,也是我用來說解給別人聽的最大理由,由於每一個http請求都會耗費服務器資源,特別是一些須要計算合併等操做的服務器,耗費服務器的cpu資源可不是開玩笑的事情,硬盤能夠用錢買來,cpu資源可就沒那麼廉價了.併發
(3) 減小http請求頭.框架
當咱們對服務器發起一個請求的時候,咱們會攜帶着這個域名下的cookie和一些其餘的信息在http頭部裏,而後服務器響應請求的時候也會帶回一些cookie之類的頭部信息.這些信息有的時候會很大,在這種請求和響應的時候會影響帶寬性能.dom
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和其餘頭部信息的大小了,由於每次傳送都會傳送他 們.
最後
總之,優化原則不是絕對的,對於不一樣的場景應該考慮不一樣的側重點,別人的解決方案對於你來講不必定是最優的,應該針對本身的網站規模和類型進行適度的優化,不能盲目追求標準和最佳實踐.