Web前端開發(fā)是從網(wǎng)頁制作演變而來的，名稱上有很明顯的時代特征。那么，你知道web前端有什么性能嗎?下面由學(xué)習(xí)啦小編為大家整理的web前端性能測試，希望大家喜歡!

　　web前端性能測試

　　1. 測試目的

　　通過主要功能頁面的前端性能測試，從前端分析引起頁面響應(yīng)緩慢的原因，并根據(jù)優(yōu)化建議對其進(jìn)行優(yōu)化，提升前端性能，從而達(dá)到提升系統(tǒng)整體性能的目的。

　　2. 測試范圍

　　主要對用戶常用的頁面進(jìn)行測試，至少包括：首頁、各分類頁、搜索結(jié)果頁等，此處我們只以首頁為例進(jìn)行測試和分析。

　　3. 測試方法

　　利用YSlow、PageSpeed等工具進(jìn)行測試，因該網(wǎng)站是第三方的并不是我們自己的，所以無法進(jìn)行埋點測試。其他的測試方法大家可自行練習(xí)。

　　4. WEB端測試結(jié)果分析

　　通過YSlow、PageSpeed等工具的測試后，綜合結(jié)果并不算好，屬于較差的情況，其中YSlow給出的評級是F(最差)，具體結(jié)果分析如下：

　　l 存在較多的HTTP請求。其中有16個external Javascript scripts，7個external stylesheets，18個external background images，這些都可以嘗試進(jìn)行合并。

　　l 未使用CDN。

　　l 未指定失效時間。部分CSS、JS和圖片等靜態(tài)資源未指定失效時間，尤其像logo這樣的不經(jīng)常變化的圖片應(yīng)該指定Expires headers，可指示瀏覽器從本地磁盤中加載以前下載的資源，而不是通過網(wǎng)絡(luò)加載。

　　l 未啟用壓縮。部分CSS、JS和圖片等靜態(tài)資源未啟用壓縮，為這些資源資源啟用壓縮可將其傳送大小減少135.2 KiB (68%)。

　　l 未優(yōu)化圖片。適當(dāng)?shù)卦O(shè)置圖片的格式并進(jìn)行壓縮可以節(jié)省大量的數(shù)據(jù)字節(jié)空間。尤其是對類似客服電話.jpg這樣的圖片。對這些圖片資源進(jìn)行優(yōu)化后可將其大小減少282.1 KiB (47%)。

　　l 不要在HTML中進(jìn)行圖片縮放。本網(wǎng)站有11個圖片進(jìn)行了縮放。YSlow給出的建議是：你希望展現(xiàn)多大的圖片，原始的圖片大小就應(yīng)該是多大，圖片不要比期望的尺寸小，也不要比需要的尺寸大。

　　比如，如果我們要求現(xiàn)實一個200x200的圖片，而我們的原始圖片只有100x100，訪問的時候瀏覽器需要等待圖片完全下載完畢之后才知道圖片的實際尺寸，然后才會判斷圖片是否滿足預(yù)定的尺寸大小，如果大了就要縮小，如果小了就要放大。換句話說：圖片下載完畢之前，瀏覽器無法正確給出判斷，而且圖片的清晰度也可能受到影響。

　　5. 移動端測試結(jié)果分析

　　移動端發(fā)現(xiàn)的問題以及需要優(yōu)化的資源同4.WEB端測試結(jié)果分析中的內(nèi)容，除此之外，還有如下內(nèi)容需要進(jìn)行優(yōu)化：

　　l 字體大小無法自適應(yīng)，在移動端不清晰。

　　l 頁面中并未設(shè)置視口。該網(wǎng)頁在移動設(shè)備上的呈現(xiàn)尺寸將與在桌面瀏覽器中一樣，因此系統(tǒng)會將其縮小到適合在移動屏幕上顯示的尺寸?？梢栽贖eader區(qū)增加類似如下的代碼：

　　在實際應(yīng)用中還要注意優(yōu)先級的排序，在時間充裕時，可以優(yōu)化所有內(nèi)容;當(dāng)時間緊急時，可以通過優(yōu)化優(yōu)先級高且屬于公共資源的元素來縮短前端頁面的響應(yīng)時間。

　　web網(wǎng)站前端性能測試

　　響應(yīng)報文的狀態(tài)碼如下：

　　1：信息響應(yīng)類，表示接收到請求并繼續(xù)處理

　　2：處理成功響應(yīng)類，表示動作被成功接收、理解和接收

　　3：重定向響應(yīng)類，表示為了完成指定的動作，必須接收進(jìn)一步處理

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

　　5：服務(wù)端錯誤，表示服務(wù)器不能正確執(zhí)行一個正確的請求

　　與前端性能相關(guān)的頭信息：

　　1、accept-encoding：告訴服務(wù)器所接受的頁面的編碼方式，gzip使用gzip壓縮，deflate不壓縮，壓縮可以減少下載所需的時間。

　　2、connection：因為HTTP是費(fèi)面向連接的，無狀態(tài)的協(xié)議，每一個HTTP請求都會經(jīng)過“建立連接--請求頁面或資源--獲得資源--斷開連接”的過程。對于小的資源可能建立連接的時間都會超過對資源的處理時間，為了減少時間引入了持久連接。當(dāng)瀏覽器和服務(wù)器約定好后，當(dāng)某個資源傳輸完成后并不立即斷開連接，而是等待一段時間，在這段時間內(nèi)若傳輸其他的資源就復(fù)用該連接，否則就關(guān)閉。當(dāng)值為keep-alive時有持久連接。

　　3、expires：用于只是返回數(shù)據(jù)的到期時間。到期時間之前都是從緩存處直接獲取相應(yīng)的資源，之后才會向服務(wù)器發(fā)送請求獲取。

　　提高前端性能的方法：

　　1、減少頁面加載的時間，

　　2、減少網(wǎng)絡(luò)時間：CDN技術(shù)，DNS緩存技術(shù)，減少文件的尺寸

　　3、減少發(fā)送的請求量：利用瀏覽器緩存

　　4、讓頁面盡早的開始顯示

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

　　由于本人之前有兩三個月的時間接觸了前端，對于前端的知識點比較熟悉，在這方面理解起來不是很困難，對于http協(xié)議，用戶響應(yīng)請求的過程都熟悉，但是那個時候并沒有詳細(xì)的考慮到頁面的加載時間問題，只是想著將頁面呈現(xiàn)出來，而忽略了對于響應(yīng)時間的要求。由于自己都是在本機(jī)上實現(xiàn)的，所以每次想看結(jié)果的時候都要等很久，這就是沒有使用性能的思想，去減少頁面的加載時間，沒有考慮周全?，F(xiàn)在對于這方面有了更深的理解。

　　Web前端框架與類庫的思考

　　1.前端框架的理解誤區(qū)

　　網(wǎng)站的價值在于它能為用戶提供什么價值，在于網(wǎng)站能做什么，而不在于它是怎么做的，所以在網(wǎng)站還很小的時候就去追求網(wǎng)站的架構(gòu)框架是舍本逐末，得不償失的。前端框架同理，如果是一個簡單的頁面型產(chǎn)品，應(yīng)用只是依賴服務(wù)器來生成Web頁面和視圖，并且只需要使用一些簡單的Javascript或者JQuery來使應(yīng)用更加具有互動性，那么一個JQuery前端類庫就可以了，真的沒必要用上一些高大上的框架。

　　當(dāng)然，框架的確是很有用的，重點是我們要知道什么時候該用什么框架。大公司大項目的經(jīng)驗和成功模式固然重要，值得學(xué)習(xí)借鑒，但我們不能因此變得盲從。只有深刻去理解前端框架，知道什么時候該用什么什么框架解決什么問題，才能有的放矢，直擊要害。

　　2.前端框架與前端類庫的區(qū)別

　　使用框架前，我覺得很重要的一點是弄清類庫(諸如JQuery)和框架(諸如angularJS)的區(qū)別在何處。

　　簡單而言，類庫，解決的是代碼或者是模塊級別的復(fù)用或者對復(fù)雜度的封裝問題，例如將一個解決復(fù)雜問題的功能模塊封裝成一個函數(shù)，提供一個簡單的接口。庫它是一種工具，它提供了很多封裝好的方法，用與不用取決于我們自身，即使用了也不會影響我們呢的代碼結(jié)構(gòu)。

　　而框架，更多的是對模式級別的復(fù)用和對程序組織的規(guī)范。這里的模式是指比如MVC，為了實現(xiàn)M和V的解耦，把復(fù)雜的耦合關(guān)系由經(jīng)常變化的業(yè)務(wù)代碼轉(zhuǎn)移到不經(jīng)常變化的框架內(nèi)部消化。是面向一個領(lǐng)域來提供一套解決方案，提高開發(fā)效率，如果我們選擇了使用某框架，就應(yīng)該遵循該框架所規(guī)定的規(guī)則。

　　二者最主要的區(qū)別是：JQuery以DOM操作為中心，框架，準(zhǔn)確來說是MVC框架，是以模型(model)為中心，而DOM操作是附加的。所以，以模型為中心最終達(dá)到的目的是帶來一整套工作流程的變更，使得后臺工程師可以編寫前端的模型代碼，把后臺與前端打通，交互設(shè)計師處理UI跟模型的互動關(guān)系，UI設(shè)計師可以專注、無障礙的處理HTML源碼，把它們以界面模板的形式提交給交互工程師。這一整套協(xié)作機(jī)制能大大提高開發(fā)效率。使用MVC框架使得前端任務(wù)更好的被解耦。

　　3.前端MVC框架思想

　　我們知道，傳統(tǒng)的MVC模式將一個應(yīng)用劃分為——模型層(model)、視圖層(view)、控制層(controller)。他們在應(yīng)用系統(tǒng)中擔(dān)當(dāng)不同的角色，完成不同的任務(wù)。

　　Model：即數(shù)據(jù)模型，用來包裝和應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)或者對數(shù)據(jù)進(jìn)行處理，模型可以直接訪問數(shù)據(jù)。

　　View：視圖用來有目的顯示數(shù)據(jù)，在視圖中一般沒有程序上的邏輯，為了實現(xiàn)視圖上的最新功能，視圖需要訪問它監(jiān)視的數(shù)據(jù)模型。

　　Controller：控制器調(diào)控模型和視圖的聯(lián)系，它控制應(yīng)用程序的流程，處理事件并作出響應(yīng)，事件不僅僅包括用戶的行為還有數(shù)據(jù)模型上的改變。通過捕獲用戶事件，通知模型層作出相應(yīng)的更新處理，同時將模型層的更新和改變通知給視圖，使得視圖作出相應(yīng)改變。因此控制器保證了視圖和模型的一致性。