http請求 302解決方法

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的封鎖請求。