http請求頭的資料量
每次請求都會帶上一些額外的資訊進行傳輸，當請求的資源很小，比如1個不到1k的圖示，可能request帶的資料比實際圖示的資料量還大。 所以當請求越多的時候，在網路上傳輸的資料自然就多，傳輸速度自然就慢了。
其實request自帶的資料量還是小問題，畢竟request能帶的資料量還是有限的。
http連線的開銷
事情到這裡還沒完，網上看到有人提出了這樣的疑問：
在http1.1，keep-alive是預設的，而且現代瀏覽器都有dns快取，那麼對於「100條請求」和「對100條請求合併為1條請求」這兩種方案來說：
* dns定址由於有dns快取–無差別；
* 3次握手由於有keep-alive，一條和一百條都只需一次tcp握手–無差別；
* 伺服器解析–無差別；
只是增多了http報文頭，在實際應用中，是否有大的效能差別？
答案是否定的。
即使有dns快取，瀏覽器也需要查詢快取，多個請求就需要查詢多次，而且快取有可能被無故清空，這樣多個請求的dns查詢有可能花費更多時間。
tcp握手時間確實沒差別，但時間效能上差別非常大。http1.1協議規定請求只能序列傳送，這也是http效能最差和最讓人詬病的地方，也就是說一百個請求必須依次逐個傳送。第80個請求必須依賴於第79個請求正常返回之後才能傳送。這樣就平白無故多出了99個網路rtt（網路延遲）。合併請求比keep-alive下不合併請求理論上能節省大概 rtt * (n - 1) 的載入時間。由此可見，網路延遲其實是在有keep-alive情況下仍然需要請求合併的主要動力。
head of line blocking（隊頭阻塞）。設想這樣乙個場景，乙個頁面有100個請求，第99個請求時，tcp丟了乙個包，tcp自然會重傳，重傳時間是t1，重傳成功後，瀏覽器才能獲取到完整頁面的響應內容，然後渲染和展示整個頁面。也就是說整個頁面的載入時間延遲了t1時間。在此之前，使用者沒有得到任何內容。但如果建立了100個tcp連線呢？第99個請求出現丟包，那也只影響了第99個資源的展現，前面接收到的98個資源依然能正常載入，不會導致整個頁面無法載入。
瀏覽器通過乙個tcp連線傳送100個請求的事情根本就不可能發生。當你有100個資源時，這100個資源在瀏覽器看來是「同時都要」，而瀏覽器並沒有什麼智商去判斷應該用1個鏈結解決這100個資源，還是用100個鏈結來解決，不然瀏覽器永遠都只有乙個tcp鏈結了。因此瀏覽器的靜態的策略是在自己可承受的範圍內盡可能地用多的鏈結來解決，大部分瀏覽器似乎是6-8個鏈結，這就導致握手也是6-8次。
所以，我們要理解合併請求是為了什麼？減少了哪些時間？優化了哪些策略？權衡了什麼利弊？合併請求並不是萬能的。
為什麼要減少操作DOM
為什麼要減少操作dom？下面將按照以下布局同時操作div1和div2 然後在控制台列印出所需的時間，對時間盡心對比 以下是布局 lang en charset utf 8 titletitle head id div1 div id div2 div 這裡寫 script body html 對di...
使用CSS sprites減少HTTP請求
sprites是鬼怪，小妖精，調皮鬼的意思，初聽這個高階洋氣的名字我被震懾住了，一步步掀開其面紗後發覺很簡單的東西，作用卻很大 css sprites是指把網頁中很多小 很多圖示檔案 做成按規律排列的一張大圖上，在顯示的時候通過background image background position...
怎麼減少http請求次數
1.減少頁面中的元素 網頁中的的 form flash等等元素都會發出http請求，盡可能的減少頁面中非必要的元素，可以減少http請求的次數。2.css sprites css精靈 是增加http請求的最大可能者，把全站的圖示都放在乙個影象檔案中，然後用css的background image和b...