http鏈接優化與瀏覽器容許的併發請求資源數相關資料(整理轉載)

網頁性能優化相關資料：

 https://developer.yahoo.com/performance/rules.html#page-nav

前端技術的逐漸成熟，還衍生了domain hash, cookie free, css sprites, js/css combine, max expires time, loading images on demand等等技術。這些技術的出現和大量使用都和併發資源數有關。

1. 按照普通設計，當網站cookie信息有1 KB、網站首頁共150個資源時，用戶在請求過程當中須要發送150 KB的cookie信息，在512 Kbps的常見上行帶寬下，須要長達3秒左右才能所有發送完畢。 儘管這個過程能夠和頁面下載不一樣資源的時間併發，但畢竟對速度形成了影響。 並且這些信息在js/css/images/flash等靜態資源上，幾乎是沒有任何須要的。 解決方案是啓用和主站不一樣的域名來放置靜態資源，也就是cookie free。
2. 將css放置在頁面最上方應該是很天然的習慣，但第一個css內引入的圖片下載是有可能堵塞後續的其餘js的下載的。而在目前廣泛過百的整頁請求數的前提下，瀏覽器提供的僅僅數個併發，對於進行了良好優化甚至是前面有CDN的系統而言，是極大的性能瓶頸。 這也就衍生了domain hash技術來使用多個域名加大併發量（由於瀏覽器是基於domain的併發控制，而不是page），不過過多的散佈會致使DNS解析上付出額外的代價，因此通常也是控制在2-4之間。 這裏常見的一個性能小坑是沒有機制去確保URL的哈希一致性（即同一個靜態資源應該被哈希到同一個域名下），而致使資源被屢次下載。
3. 再怎麼提速，頁面上過百的總資源數也仍然是很可觀的，若是能將其中一些不少頁面都用到的元素如經常使用元素如按鈕、導航、Tab等的背景圖，指示圖標等等合併爲一張大圖，並利用css background的定位來使多個樣式引用同一張圖片，那也就能夠大大的減小總請求數了，這就是css sprites的由來。
4. 全站的js/css本來並很少，其合併技術的產生倒是有着和圖片不一樣的考慮。 因爲cs/js一般可能對dom佈局甚至是內容形成影響，在瀏覽器解析上，不連貫的載入是會形成屢次從新渲染的。所以，在網站變大須要保持模塊化來提升可維護性的前提下，js/css combine也就天然衍生了，同時也是minify、compress等對內容進行多餘空格、空行、註釋的整理和壓縮的技術出現的緣由。
5. 隨着cookie free和domain hash的引入，網站總體的打開速度將會大大的上一個臺階。 這時咱們一般看到的問題是大量的請求因爲全站公有header/footer/nav等關係，其對應文件早已在本地緩存裏存在了，但爲了確保這個內容沒有發生修改，瀏覽器仍是須要請求一次服務器，拿到一個304 Not Modified才能放心。 一些比較大型的網站在創建了比較規範的發佈制度後，會將大部分靜態資源的有效期設置爲最長，也就是Cache-Control max-age爲10年。 這樣設置後，瀏覽器就不再會在有緩存的前提下去確認文件是否有修改了。 超長的有效期可讓用戶在訪問曾訪問過的網站或網頁時，得到最佳的體驗。 帶來的複雜性則體如今每次對靜態資源進行更新時，必須發佈爲不一樣的URL來確保用戶從新加載變更的資源。
6. 即便是這樣作完，仍然還存在着一個很大的優化空間，那就是不少頁面瀏覽量很大，但其實用戶直接很大比例直接就跳走了，第一屏如下的內容用戶根本就不感興趣。 對於超大流量的網站如淘寶、新浪等，這個問題尤爲重要。 這個時候通常是經過將圖片的src標籤設置爲一個loading或空白的樣式，在用戶翻頁將圖片放入可見區或即將放入可見區時再去載入。 不過這個優化其實和併發資源數的關係就比較小了，只是對一些散佈不合理，或第一頁底部的資源會有必定的幫助。 主要意圖仍是下降帶寬費用。

 

配置nginx實現經過cookie-free域名發送靜態資源

使用 cookie-free 域名的好處

當瀏覽器加載 HTML 文件中引用的靜態資源 —— 如圖片、外部 CSS、外部 JS 等 —— 時，若該資源所屬域與當前頁面相同，則會在 HTTP 頭請求中加載當前域的 cookie 信息。

下面須要舉個例子：

好吧，不是這個意思，認真的舉個栗子例子：

你的網站爲 http://www.whatever.com，啓用了 Google Analytics 或百度統計或任意第三方統計代碼。用戶訪問你的網站首頁，首頁 html 代碼引用了 10 個圖片文件，圖片地址是 http://www.whatever.com/images/[0-9].jpg （此處有正則）。

由於 Google Analytics 在 http://www.whatever.com 這個域下設置了 cookie，瀏覽器在加載這些圖片時，會把 Google Analytics 設置的 cookie 放在頭信息裏發過去。

原本一個 cookie 也沒多大，頂多 1KB，可是若是你要加載 50 個圖片（或其它靜態文件），這樣發送的 cookie 總量就多達 50KB 了。對於靜態資源來講，發送這些 cookie 徹底沒有意義，因此咱們不想讓瀏覽器請求這些靜態資源時發送 cookie。

下圖是蘋果教程網未設置 cookie-free 域名前請求某靜態資源時 HTTP 請求頭中包含 cookie 內容的慘狀：

配置nginx實現cookie-free域名

其實單獨把 cookie-free 域名這個事兒單獨拎出來講是一件很傷感的事情，由於有錢淫通常都會同時選擇 VIP 套餐：CDN。使用 CDN，將靜態資源分發在多臺服務器上，用戶在請求資源時智能判斷哪一個節點速度最快並返回，同時再啓用一個 cookie-free 域名用來指向靜態資源。

對於沒有能力搞 CDN 的人，只能單獨配置一下 cookie-free 域名了。不要緊，等咱有了錢，服務器買 20 個，什麼聯通、電信、鐵通、長寬、移動、電信通，統統給接上，帶寬怎麼着也得 20M，還得上下行速率對等。

好了不廢話了，下面使用專業的語言描述一下要乾的事：

前提條件：一臺本身的服務器（VPS），安裝了 nginx，已經有可用的 nginx 配置文件（假定 server_name 爲 www.whatever.com），網站運轉正常。

待辦事項：修改 nginx 的配置文件，讓 nginx 監聽 cdn.whatever.com，並修改部分對靜態文件的處理規則。

具體步驟

首先你要增長一個子域名（cdn.whatever.com）指向你的服務器，這個不用多說了吧……

而後須要編輯你的 nginx 配置文件，它原來大概可能長這樣

server { listen 80; server_name www.whatever.com whatever.com; root /root/to/your/site; location / { index index.html index.php; } location ~* \.(gif|jpg|png)$ { expires 30d; } /*此處略去若干*/ }

你須要作的是首先修改 server_name 字段，讓 nginx 同時監聽 cdn.whatever.com。

server_name www.whatever.com whatever.com cdn.whatever.com;

而後新增一個 location 塊，寫以下內容，並確保這個 location 塊處於全部已存在的 location 塊以前，即 nginx 須要優先處理這個 location 中的內容。

location ~* \.(?:js|css|png|jpg|jpeg|gif|ico)$ { expires max; add_header Pragma public; add_header Cache-Control "public, must-revalidate, proxy-revalidate"; access_log off; log_not_found off; tcp_nodelay off; break; }

搞定後保存 nginx 配置文件，而後重啓 nginx。

最後一步，將網頁中引用的全部 www.whatver.com 域下的靜態文件統統改成 cdn.whatever.com。以上文所說的那個首頁爲例，新的圖片地址爲 http://cdn.whatver.com/images/[0-9].jpg。

下圖爲蘋果教程網啓用了 cookie-free 域名來發送靜態資源後的 HTTP 頭請求截圖，是否清爽了不少。最重要的是，由於沒有 cookie 的發送，用戶的流量節省了不少，且網頁的加載速度也節省了不少，我開心的笑了。（畫外音：別傻了，能省幾 KB 啊）

小記

其實要實現 cookie-free，只須要換一個域名並保證當前頁面沒有給根域名設置 cookie 便可。好比咱們雖然啓用了 cdn.whatever.com，可是因爲 Google Analytics（如下簡稱 GA） 設置 cookie 的域爲 .whatever.com 而不是 .www.ppios.com，會致使請求 cdn.whatever.com 中的內容時依然會發送 cookie。具體 cookie 的設置狀況請自行打開開發者工具查看。

這裏再提一下關於限制 GA 設置 cookie 的內容，原則上 GA 應該是默認只設置當前域名的，好比你的頁面 URL 是 http://www.whatever.com，則 GA 設置 cookie 的域就是 www.whatever.com；同理若是你的 URL 是 http://whatever.com，則 GA 會把 cookie 設置爲 .whatever.com，這樣你全部的子域名都會被這個 cookie 影響了。

解決方法就是修改 GA 統計代碼，在

_gaq.push(['_setAccount', 'UA-123456788-1']); _gaq.push(['_trackPageview']);

這兩行以前新增一行

_gaq.push(['_setDomainName', 'www.whatever.com']);

這樣就是告訴 GA 只准在 www.whatever.com 域下設置 cookie，關於這個設置順序折騰了小半個晚上，你們必定要注意啊。