1.統一域名下資源併發請求限制
- 瀏覽器的網絡請求資源數是針對單一域名的。同一時間針對同一域名下的請求有一定數量限制。超過限制數目的請求會被阻塞，這就是很多網站專門解決這個問題的原因。
- 不同瀏覽器，不同http協議版本允許的網絡請求資源數是不一樣的（具體自行百度），不過總的來說在2-8個之間。
2.對頁面加載的影響：
假如一個頁面有120個靜態資源（css、js、img），並且所有資源都在一個域名下，使用的瀏覽器最大網絡並行請求資源數是6，假設理想一些：所有請求時間都是一樣的，每個文件加載需要500ms，則所有資源加載完成需要 120/6 * 0.5 = 10s 的時間。
有的請求會持續很長時間，如果把 img, css, js… 都放到http://一個域名下面，其他請求就遲遲無法完成，瀏覽者看來就是『卡住了』。而把圖片放到另一個域名之後，css和圖片就可以併發請求了。
3.針對性的優化方案：
1、減少網絡請求數：
（1）使用css spirit（精靈圖），將圖標合成在一張圖中，減少圖片數量，減少http請求數；
（2）使用打包工具合併css和js，減少文件數量，減少http請求數（壓縮和合並文件）
2、增加靜態資源來源
（1）將靜態資源分佈在不同的服務器中，使用多個域名，加大併發量；
（2）將靜態資源和html文檔分放在不用的域名下也有另一個原因，每次頁面請求都會將相同域名下的cookie帶給服務器端，實際上靜態資源帶上cookie是沒必要的。
實例
百度首頁 – js和圖片用的域名
加快頁面靜態資源請求方法（前端優化）
-
從用戶角度而言，優化能夠讓頁面加載得更快、對用戶的操作響應得更及時，能夠給用戶提供更爲友好的體驗。
-
從服務商角度而言，優化能夠減少頁面請求數、或者減小請求所佔帶寬，能夠節省可觀的資源。
總之，恰當的優化不僅能夠改善站點的用戶體驗並且能夠節省相當的資源利用。
優化方向兩類：
- 第一類是頁面級別的優化，例如HTTP請求數、腳本的無阻塞加載、內聯腳本的位置優化等;
- 第二類則是代碼級別的優化，例如Javascript中的DOM操作優化、CSS選擇符優化、圖片優化以及HTML結構優化等等。
一、減少HTTP請求數
首先，每個請求都是有成本的，既包含時間成本也包含資源成本。
一個完整的請求都需要經過DNS尋址（輸入網址-瀏覽器來解析dns-直到解析出ip爲止）、與服務器建立連接、發送數據、等待服務器響應、接收數據這樣一個”漫長”而複雜的過程（dns尋址-三次握手-發送報文-服務器將請求發給servlet容器-servlet容器來響應請求-返回客戶端）。
時間成本就是用戶需要看到或者”感受”到這個資源是必須要等待這個過程結束的，資源上由於每個請求都需要攜帶數據，因此每個請求都需要佔用帶寬。
另外，由於瀏覽器進行併發請求的請求數是有上限的，因此請求數多了以後，瀏覽器需要分批進行請求，因此會增加用戶的等待時間，會給用戶造成站點速度慢這樣一個印象，即使可能用戶能看到的第一屏的資源都已經請求完了，但是瀏覽器的進度條會一直存在。
- 靜態資源分域存放
- 統一域名下資源併發請求限制
- 不過過多的散佈會導致DNS解析上付出額外的代價，所以一般也是控制在2-4之間。
- css sprites–用精靈圖
再怎麼提速，頁面上過百的總資源數也仍然是很可觀的，如果能將其中一些很多頁面都用到的元素如常用元素如按鈕、導航、Tab等的背景圖，指示圖標等等合併爲一張大圖，並利用cssbackground-position的定位來使多個樣式引用同一張圖片，那也就可以大大的減少總請求數了，這就是css sprites的由來 - js/css combine(合併壓縮文件)
站的js/css原本並不多，其合併技術的產生卻是有着和圖片不同的考慮。 由於css/js通常可能對dom佈局甚至是內容造成影響，在瀏覽器解析上，不連貫的載入是會造成多次重新渲染的。因此，在網站需要保持模塊化來提高可維護性的前提下，js/css combine也就自然衍生了，同時也是minify、compress等對內容進行多餘空格、空行、註釋的整理和壓縮的技術出現的原因。
公共文件壓縮，非公共文件合併。 - 延遲加載
很多頁面瀏覽量很大，但其實用戶直接很大比例直接就跳走了，第一屏以下的內容用戶根本就不感興趣。 對於超大流量的網站如淘寶、新浪等，這個問題尤其重要。 這個時候一般是通過將圖片的src標籤設置爲一個loading或空白的樣式，在用戶翻頁將圖片放入可見區或即將放入可見區時再去載入。 不過這個優化其實和併發資源數的關係就比較小了，只是對一些散佈不合理，或第一頁底部的資源會有一定的幫助。 主要意圖還是降低帶寬費用。