web前端性能測試小點

關於前端性能的文章：

 http://www.cnblogs.com/fnng/archive/2011/09/19/2181894.html

       web應用的前端性能響應時間指瀏覽器的頁面加載時間。瀏覽器的頁面加載時間包括對html的解析，對頁面圖片及css等文件的獲取和加載、客戶端腳本的執行時間以及對你頁面進行展示所花費的時間。這個與併發用戶量的大小並無直接的關係，主要關注：如何提升瀏覽器下載和執行資源的併發性，如何讓瀏覽器儘快開始渲染頁面，如何讓瀏覽器儘量充分的利用緩存。在yahoo中，到少50個團隊經過純粹的前端性能相關的技巧，將最終用戶的響應時間減小了25%以上。

      在瞭解web前端性能時，咱們應該知道http協議。

      http協議採用請求/響應模型，客戶端向服務器發送一個請求，請求頭包含請求的方法、URI、協議版本等信息，服務器以一個狀態行做爲響應，響應的內容包括消息協議的版本、成功或者錯誤編碼加上包含服務器的信息、實體元信息等內容。該協議是一種非面向鏈接的協議，每一個http請求都是獨立的。

     請求報文的格式：請求行 | 通用信息頭 | 請求頭 | 實體頭 | 報文主體   Method     Request-URI  HTTP-versionCRIF

     響應報文的格式：狀態行 | 通用信息頭 | 響應頭 | 實體頭 | 報文主體

響應報文的狀態碼以下：

     1XX：信息響應類，表示接收到請求並繼續處理

     2XX：處理成功響應類，表示動做被成功接收、理解和接收

     3XX：重定向響應類，表示爲了完成指定的動做，必須接收進一步處理

     4XX：客戶端錯誤，表示客戶請求包含語法錯誤或不能正確的執行

     5XX：服務端錯誤，表示服務器不能正確執行一個正確的請求

與前端性能相關的頭信息：

     一、accept-encoding：告訴服務器所接受的頁面的編碼方式，gzip使用gzip壓縮，deflate不壓縮，壓縮能夠減小下載所需的時間。

     二、connection：由於HTTP是費面向鏈接的，無狀態的協議，每個HTTP請求都會通過「創建鏈接--請求頁面或資源--得到資源--斷開鏈接」的過程。對於小的資源可能創建鏈接的時間都會超過對資源的處理時間，爲了減小時間引入了持久鏈接。當瀏覽器和服務器約定好後，當某個資源傳輸完成後並不當即斷開鏈接，而是等待一段時間，在這段時間內若傳輸其餘的資源就複用該鏈接，不然就關閉。當值爲keep-alive時有持久鏈接。

    三、expires：用於只是返回數據的到期時間。到期時間以前都是從緩存處直接獲取相應的資源，以後纔會向服務器發送請求獲取。

提升前端性能的方法：

    一、減小頁面加載的時間，

    二、減小網絡時間：CDN技術，DNS緩存技術，減小文件的尺寸

    三、減小發送的請求量：利用瀏覽器緩存

    四、讓頁面儘早的開始顯示

對於前段性能測試的理解：

       因爲本人以前有兩三個月的時間接觸了前端，對於前端的知識點比較熟悉，在這方面理解起來不是很困難，對於http協議，用戶響應請求的過程都熟悉，可是那個時候並無詳細的考慮到頁面的加載時間問題，只是想着將頁面呈現出來，而忽略了對於響應時間的要求。因爲本身都是在本機上實現的，因此每次想看結果的時候都要等好久，這就是沒有使用性能的思想，去減小頁面的加載時間，沒有考慮周全。如今對於這方面有了更深的理解。