http請求+302解決方法 相關文章
當前，許多站點的部署方式都對自身的性能產生了消極影響，而網站的所有者並沒有意識到這個問題。我們今天針對性的討論以下幾個常見的影響網站性能的瓶頸，觀察其變化趨勢，並簡單說明一些解決方案來提升網站的性能。
瓶頸一：緩存
在面對靜態內容的時候，我們最常用的方式就是通過將其緩存在瀏覽器、中間代理服務器或者CDN之上。因為能夠提供相當大的卸載，這種將靜態內容的緩存行為毫無疑問將對終端用戶和源站服務器產生良好的影響。根據當前的趨勢，我們可以看到，許多站點實際上都在緩存類似於JS，圖像，CSS等對象；但是，我們卻發現能夠對HTML進行緩存的站點卻並不多見。基礎頁面一般是比較動態化的，大部分的網站所有者都不會對這種頁面進行緩存，因為HTML頁面是在不斷變化的。
我們對盡可能多的網站數據進行了評估，結果如下：
根據上圖，我們可以看到：
34%的獨立站點對HTML頁面進行了緩存。
66%的獨立站點沒有對HTML頁面進行緩存。
分析：
我們發現，大量站點沒有緩存基礎頁面，這將對站點的SpeedIndex（速度參數）造成直接影響。SpeedIndex能夠反映視覺元素的平均完成程度，也是提升客戶體驗的一個重要方面。
如果頁面包含了動態的內容，那么我們可以采取幾種方式來確保其可緩存性，或者對動態內容進行潛在復用。
解決方法：
利用低TTL對基礎頁面進行緩存——如果這樣做，我們就能為內容提供一個較低的TTL，然后根據最終用戶所在位置等不同變量進行變化，減少HTML請求次數進而卸載源站的負載。
異步JavaScript及XML（Ajax）——利用Ajax來動態地創建多頁面組件，這使我們可以對多種存儲進行緩存響應，包括sessionstorage和localstorage。可緩存的Ajax也是一種將發往源站服務器的請求數量減少的有效方法。
邊緣側包含（EdgeSideInclude）。
瓶頸二：壓縮
另外一種非常常見的提升站點性能的方式就是對內容進行壓縮，這樣可以確保內容的比特數盡可能小，傳輸速度盡可能快。壓縮一般是針對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響應代碼的出現率是相當低的。因為我們得到的數據是基於HTTPArchive上所使用的WebPageTest第一屏結果，這種檢測方式對於這兩種響應代碼的情況反映是不夠精確的。
盡管如此，我們還是值得去討論一下，在源站使用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，我們使用了HTTPArchive關於頁面和資源請求的分析數據。通過對最新的請求數據的分析，我們可以發現在資源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的封鎖請求。