當前，許多站點的部署方式都對自身的效能產生了消極影響，而網站的所有者並沒有意識到這個問題。我們今天針對性的討論以下幾個常見的影響網站效能的瓶頸，觀察其變化趨勢，並簡單說明一些解決方案來提升網站的效能。 瓶頸一：快取在面對靜態內容的時候，我們最常用的方式就是通過將其快取在瀏覽器、中間代理伺服器或者CDN之上。因為能夠提供相當大的解除安裝，這種將靜態內容的快取行為毫無疑問將對終端使用者和源站伺服器產生良好的影響。根據當前的趨勢，我們可以看到，許多站點實際上都在快取類似於JS，影象，CSS等物件；但是，我們卻發現能夠對HTML進行快取的站點卻並不多見。基礎頁面一般是比較動態化的，大部分的網站所有者都不會對這種頁面進行快取，因為HTML頁面是在不斷變化的。我們對儘可能多的網站資料進行了評估，結果如下：根據上圖，我們可以看到：34%的獨立站點對HTML頁面進行了快取。66%的獨立站點沒有對HTML頁面進行快取。分析：我們發現，大量站點沒有快取基礎頁面，這將對站點的Speed Index（速度引數）造成直接影響。Speed Index能夠反映視覺元素的平均完成程度，也是提升客戶體驗的一個重要方面。
如果頁面包含了動態的內容，那麼我們可以採取幾種方式來確保其可快取性，或者對動態內容進行潛在複用。
解決方法：利用低TTL對基礎頁面進行快取——如果這樣做，我們就能為內容提供一個較低的TTL，然後根據終端使用者所在位置等不同變數進行變化，減少HTML請求次數進而解除安裝源站的負載。
非同步JavaScript及XML（Ajax）——利用Ajax來動態地建立多頁面元件，這使我們可以對多種儲存進行快取響應，包括session storage和local storage。可快取的Ajax也是一種將發往源站伺服器的請求數量減少的有效方法。
邊緣側包含（Edge Side Include）。
瓶頸二：壓縮另外一種非常常見的提升站點效能的方式就是對內容進行壓縮，這樣可以確保內容的位元數儘可能小，傳輸速度儘可能快。壓縮一般是針對JS和CSS這種靜態物件來使用的，而無需考慮內容變換的速度和頻率，因為快取規則能夠使得基於Last-Modified-Since和Time-To-Live這兩個值的物件失效。
觀察：根據我們觀察到的最新資料，一些站點最多能夠包括115種字型資源，最少1種，平均4種。這一結果說明，由於種種原因，很少有站點會對字型資源進行壓縮，其中一種原因有可能是這些字型資源來自第三方：如圖所示：1.  9.6%的本站字型資源經過壓縮2.  2.4%的第三方字型資源經過壓縮3.  22.4%的本站字型資源未經壓縮4.  64.6%的第三方字型資源未經壓縮分析：我們剛才已經說到了，站點能夠包含的字型最多有115種，所以對這些字型進行壓縮就變得異常重要，因為這可以縮短頁面載入的時間，並且從終端使用者的角度來提升頁面渲染的速度。
根據最新的資料統計顯示，87%的站點沒有對字型進行壓縮，而22%的站點自己使用的字型沒有采用壓縮。這些資源是通過主站的域名來進行控制和訪問的，所以可以在源站伺服器上進行壓縮配置。
還有更復雜的情況，也就是使用第三方字型資源的時候，比如來自谷歌等。我們發現，最近有65%的站點使用了第三方字型資源，而這些字型都沒有進行壓縮。
解決方法：對於自有的字型資源，壓縮可以在源站伺服器上來進行，或者在使用代理和CDN的前提下，在最後一公里進行壓縮。總體來說，現在的瀏覽器大部分都支援GZIP，這也使得瀏覽器對字型壓縮不再成為問題。
對於第三方字型資源，Akamai也可以提供更為具體的解決方案，來保證字型能夠以最快的速度進行分發。
瓶頸三：HTTP響應程式碼毋庸置疑，當內容回到源站伺服器（或者快取）的時候，大部分站點所使用的響應程式碼都是“200/OK”。也就是說，除了這個特定的響應程式碼之外，還有相當大比例的請求響應程式碼在被使用，這也是會對站點效能造成顯著影響的一個因素。下面，我們來看看這些程式碼的使用比例：右側圖例上現實的響應碼分別是：部分內容/206重定向/301/302未修改/304未發現/404錯誤/4xx/5xx其他非200響應程式碼“錯誤”響應程式碼總體而言，“錯誤”響應程式碼從低到高代表了不同的意思，最高的493錯誤程式碼意味著整個站點都出錯了。 而大多數情況下我們看到的錯誤程式碼並不是493， 而是像404“未發現”這樣的響應程式碼，原因是內容名稱或者內容發生變化、而且沒有得到解決。這在使用內容管理系統將資源直接從源站拉出或者推入的時候尤為常見。這種問題的優先順序都不是太高，相關人員會更加著急解決其他更為重要的麻煩。隨著時間的推移，這些錯誤就會不斷堆積，進而導致快取率不足而影響源站的效能，或者是由於請求並不存在的內容請求指向源站造成流量上升而影響速度和效能。 伺服器端的錯誤響應程式碼是5xx，出現這種錯誤程式碼的原因有可能是：源站伺服器的超時設定、初始連結等待響應的時長等。對源站的健康度檢測是預防這種錯誤程式碼出現的好辦法，如果一旦健康度低於預設的某個閾值，儀表板上的警告機制就會被觸發。
“快取”響應程式碼304/206根據上面的圖表，304/206響應程式碼的出現率是相當低的。因為我們得到的資料是基於HTTP Archive上所使用的WebPage Test第一屏結果，這種檢測方式對於這兩種響應程式碼的情況反映是不夠精確的。
儘管如此，我們還是值得去討論一下，在源站使用If-Modified-Since的頭部檔案來產生304響應程式碼可以如何為網站減壓。使用這種響應程式碼，我們可以儘可能地減少對未變更內容的分發需要。如果我們在終端使用者和源站伺服器之間使用了代理伺服器或者CDN，那麼使用304響應程式碼可以帶來的收益就更大了。
對於觸發206響應程式碼的大型物件的請求，將部分物件進行快取可以提升向終端使用者進行分發的效率。這樣做，我們可以減少指向源站的請求數量，同時提升大型物件的分發速度。
301/302重定向響應程式碼根據上面圖表所顯示的資訊，重定向響應程式碼佔據了相當大的比例，而且也是除了200響應程式碼之外使用最為頻繁的響應程式碼。對於想要進行品牌再造或者僅僅是想要避免在Web應用伺服器側進行重大變更的網站而言，使用率是相當高的。根據最新的調查結果，網站使用最多的重定向響應碼是910，而對於那些使用了CDN服務的網站而言，使用最多的是353。重定向會影響到SEO排名，而更為常見的是，會增加對頁面的請求次數，進而拖慢網站或者頁面的載入時間。我們可以看到，使用了CDN服務的網站持續使用了大量的重定向響應程式碼，那麼問題來了：有了CDN的話，尤其是當CDN服務商可以幫助你對路由進行重定向的時候，這麼做還有必要嗎？
Web效能瓶頸：進階我們在上面提到了一些常見的Web效能瓶頸，除了這些因素之外，我們還需要認識到：一些更加明顯、更加常見的Web效能瓶頸導致了JavaScript資源的超量使用。下面我們來舉一個比較貼切的例子：
使用多重JavaScript框架：JavaScript的本質是“阻擋（Blocking）”，所以某個頁面所包含的JS越多，在頁面開始載入或者結束載入之前，就會有更多的內容要求被進行解析。為了瞭解有多少的頁面使用了多重的JavaScript，我們使用了HTTP Archive關於頁面和資源請求的分析資料。通過對最新的請求資料的分析，我們可以發現在資源URL自身內部所包含的不同的單一JavaScript框架名稱。我們把這些名稱返回到最新的頁面請求資料內（頁面ID），來確定在一個頁面中一共使用了多少框架，並獲得相應的清單。這個關於JS框架使用的調查最終顯示了這樣的結果：jquery，dojo，angular，prototype，backbone，emberjs，sencha，scriptaculous，d3，three，bootstrap 和foundation。根據最新的調查結果我們可以發現，大概有20%的網站使用了2到7個框架。大部分使用單一框架的站點主要採用了jQuery，因為通過這一框架，就可以使用許多不同的定製化擴充套件和裝置。
我們可以從上面的圖表看到，接近80%的站點使用了1個以上的JS框架。網站使用多個框架的原因其實顯而易見——他們需要在頁面上植入來自多個框架和庫的多個元件——尤其是那些在github隨手就可以拿到的。在github上面，開發和下載特定的裝置，可以幫助他們在某一個站點內達成其所期待實現的行為。現在的潮流是，jquery，prototype，d3，bootstrap，angular，foundation和scriptaculous這幾種框架比較受歡迎。當某個功能或者特性需要使用多重庫的時候，網站就會傾向於使用多個框架，原因有二：樣式和功能（取決於使用者的互動方式）。所以現在的問題就是：我們為什麼需要把資源浪費在下載和解析指令碼上呢？而且某些指令碼在頁面開始載入之前，根本沒有被包括在樣式裡。 我們在WebPageTest上獲取了一些引數，並把這些引數和框架及庫的數量進行比較，就會發現其對效能在整體上產生的不良影響。
右側的圖例分別是：1.  平局渲染時間2.  平均內容載入時間3.  平均載入時間4.  平均完全載入時間5.  平均視覺完成時間6.  平均速度引數
這張圖顯示的是，隨著頁面上包含的JS框架數量的增多（X軸從左到右），上述時間引數不斷變大（毫秒單位，Y軸從下到上）。 進一步說，包含過多的JS框架會使得頁面大小進一步增長，因為JavaScript的位元數都會落到頁面的整體體積上面。當然，框架數量並不是影響位元數大小的唯一因素，但卻仍然會成為影響Web效能的一個瓶頸。這種頁面體積的增加，會需要更多的工作和技巧來解決。此圖顯示的是：JS框架增加與其位元數總量的關係。也就是說，框架數量越多，位元數就越大。 除了將站點內不必要的框架移除之外，如果必須要使用多個框架和庫，我們還可以通過一些前端優化的技術來改善網站的體驗。
解決方法：1.  指令碼在網站中扮演兩個主要角色：樣式和功能。指令碼並不包含在樣式裡，指令碼是包含在導航裡的。一旦使用者開始載入了某個頁面，這就會造成執行的延遲。a)  在這種情況下，我們可以使用非同步的JavaScript以及上傳事件後的指令碼執行遞延來幫忙提升頁面渲染的啟動及完成效率。
2.  將指令碼進行整合，會對頁面的請求數量進行大幅度地縮減。通過這種方式，瀏覽器可以使用其他平行連結來開始下載頁面上的其他內容。a)  通過CDN平臺，我們可以將Javascript整合到一個單獨的html請求中，這樣我們可以縮減JavaScript的封鎖請求。
當前，我們面對的Web效能瓶頸的數量是很多的。有一些瓶頸是非常常見的，比如沒有進行妥當的快取、壓縮以及響應程式碼的問題等等，這些問題都是可以通過我們上面談到的方式來解決。此外，我們也可以看到應用多重JavaScript帶來的問題，儘管指令碼的使用非常必要，但是確實也會對效能和整體的使用者體驗造成影響。