開發(fā)web前端需具備什么性能測(cè)試_web前端有哪些性能測(cè)試
Web前端開發(fā)是從網(wǎng)頁(yè)制作演變而來(lái)的,名稱上有很明顯的時(shí)代特征。那么,你知道web前端有什么性能嗎?下面由學(xué)習(xí)啦小編為大家整理的web前端性能測(cè)試,希望大家喜歡!
web前端性能測(cè)試
1. 測(cè)試目的
通過(guò)主要功能頁(yè)面的前端性能測(cè)試,從前端分析引起頁(yè)面響應(yīng)緩慢的原因,并根據(jù)優(yōu)化建議對(duì)其進(jìn)行優(yōu)化,提升前端性能,從而達(dá)到提升系統(tǒng)整體性能的目的。
2. 測(cè)試范圍
主要對(duì)用戶常用的頁(yè)面進(jìn)行測(cè)試,至少包括:首頁(yè)、各分類頁(yè)、搜索結(jié)果頁(yè)等,此處我們只以首頁(yè)為例進(jìn)行測(cè)試和分析。
3. 測(cè)試方法
利用YSlow、PageSpeed等工具進(jìn)行測(cè)試,因該網(wǎng)站是第三方的并不是我們自己的,所以無(wú)法進(jìn)行埋點(diǎn)測(cè)試。其他的測(cè)試方法大家可自行練習(xí)。
4. WEB端測(cè)試結(jié)果分析
通過(guò)YSlow、PageSpeed等工具的測(cè)試后,綜合結(jié)果并不算好,屬于較差的情況,其中YSlow給出的評(píng)級(jí)是F(最差),具體結(jié)果分析如下:
l 存在較多的HTTP請(qǐng)求。其中有16個(gè)external Javascript scripts,7個(gè)external stylesheets,18個(gè)external background images,這些都可以嘗試進(jìn)行合并。
l 未使用CDN。
l 未指定失效時(shí)間。部分CSS、JS和圖片等靜態(tài)資源未指定失效時(shí)間,尤其像logo這樣的不經(jīng)常變化的圖片應(yīng)該指定Expires headers,可指示瀏覽器從本地磁盤中加載以前下載的資源,而不是通過(guò)網(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é)空間。尤其是對(duì)類似客服電話.jpg這樣的圖片。對(duì)這些圖片資源進(jìn)行優(yōu)化后可將其大小減少282.1 KiB (47%)。
l 不要在HTML中進(jìn)行圖片縮放。本網(wǎng)站有11個(gè)圖片進(jìn)行了縮放。YSlow給出的建議是:你希望展現(xiàn)多大的圖片,原始的圖片大小就應(yīng)該是多大,圖片不要比期望的尺寸小,也不要比需要的尺寸大。
比如,如果我們要求現(xiàn)實(shí)一個(gè)200x200的圖片,而我們的原始圖片只有100x100,訪問(wèn)的時(shí)候?yàn)g覽器需要等待圖片完全下載完畢之后才知道圖片的實(shí)際尺寸,然后才會(huì)判斷圖片是否滿足預(yù)定的尺寸大小,如果大了就要縮小,如果小了就要放大。換句話說(shuō):圖片下載完畢之前,瀏覽器無(wú)法正確給出判斷,而且圖片的清晰度也可能受到影響。
5. 移動(dòng)端測(cè)試結(jié)果分析
移動(dòng)端發(fā)現(xiàn)的問(wèn)題以及需要優(yōu)化的資源同4.WEB端測(cè)試結(jié)果分析中的內(nèi)容,除此之外,還有如下內(nèi)容需要進(jìn)行優(yōu)化:
l 字體大小無(wú)法自適應(yīng),在移動(dòng)端不清晰。
l 頁(yè)面中并未設(shè)置視口。該網(wǎng)頁(yè)在移動(dòng)設(shè)備上的呈現(xiàn)尺寸將與在桌面瀏覽器中一樣,因此系統(tǒng)會(huì)將其縮小到適合在移動(dòng)屏幕上顯示的尺寸??梢栽贖eader區(qū)增加類似如下的代碼:
在實(shí)際應(yīng)用中還要注意優(yōu)先級(jí)的排序,在時(shí)間充裕時(shí),可以優(yōu)化所有內(nèi)容;當(dāng)時(shí)間緊急時(shí),可以通過(guò)優(yōu)化優(yōu)先級(jí)高且屬于公共資源的元素來(lái)縮短前端頁(yè)面的響應(yīng)時(shí)間。
web網(wǎng)站前端性能測(cè)試
響應(yīng)報(bào)文的狀態(tài)碼如下:
1:信息響應(yīng)類,表示接收到請(qǐng)求并繼續(xù)處理
2:處理成功響應(yīng)類,表示動(dòng)作被成功接收、理解和接收
3:重定向響應(yīng)類,表示為了完成指定的動(dòng)作,必須接收進(jìn)一步處理
4:客戶端錯(cuò)誤,表示客戶請(qǐng)求包含語(yǔ)法錯(cuò)誤或不能正確的執(zhí)行
5:服務(wù)端錯(cuò)誤,表示服務(wù)器不能正確執(zhí)行一個(gè)正確的請(qǐng)求
與前端性能相關(guān)的頭信息:
1、accept-encoding:告訴服務(wù)器所接受的頁(yè)面的編碼方式,gzip使用gzip壓縮,deflate不壓縮,壓縮可以減少下載所需的時(shí)間。
2、connection:因?yàn)镠TTP是費(fèi)面向連接的,無(wú)狀態(tài)的協(xié)議,每一個(gè)HTTP請(qǐng)求都會(huì)經(jīng)過(guò)“建立連接--請(qǐng)求頁(yè)面或資源--獲得資源--斷開連接”的過(guò)程。對(duì)于小的資源可能建立連接的時(shí)間都會(huì)超過(guò)對(duì)資源的處理時(shí)間,為了減少時(shí)間引入了持久連接。當(dāng)瀏覽器和服務(wù)器約定好后,當(dāng)某個(gè)資源傳輸完成后并不立即斷開連接,而是等待一段時(shí)間,在這段時(shí)間內(nèi)若傳輸其他的資源就復(fù)用該連接,否則就關(guān)閉。當(dāng)值為keep-alive時(shí)有持久連接。
3、expires:用于只是返回?cái)?shù)據(jù)的到期時(shí)間。到期時(shí)間之前都是從緩存處直接獲取相應(yīng)的資源,之后才會(huì)向服務(wù)器發(fā)送請(qǐng)求獲取。
提高前端性能的方法:
1、減少頁(yè)面加載的時(shí)間,
2、減少網(wǎng)絡(luò)時(shí)間:CDN技術(shù),DNS緩存技術(shù),減少文件的尺寸
3、減少發(fā)送的請(qǐng)求量:利用瀏覽器緩存
4、讓頁(yè)面盡早的開始顯示
對(duì)于前段性能測(cè)試的理解:
由于本人之前有兩三個(gè)月的時(shí)間接觸了前端,對(duì)于前端的知識(shí)點(diǎn)比較熟悉,在這方面理解起來(lái)不是很困難,對(duì)于http協(xié)議,用戶響應(yīng)請(qǐng)求的過(guò)程都熟悉,但是那個(gè)時(shí)候并沒(méi)有詳細(xì)的考慮到頁(yè)面的加載時(shí)間問(wèn)題,只是想著將頁(yè)面呈現(xiàn)出來(lái),而忽略了對(duì)于響應(yīng)時(shí)間的要求。由于自己都是在本機(jī)上實(shí)現(xiàn)的,所以每次想看結(jié)果的時(shí)候都要等很久,這就是沒(méi)有使用性能的思想,去減少頁(yè)面的加載時(shí)間,沒(méi)有考慮周全。現(xiàn)在對(duì)于這方面有了更深的理解。
Web前端框架與類庫(kù)的思考
1.前端框架的理解誤區(qū)
網(wǎng)站的價(jià)值在于它能為用戶提供什么價(jià)值,在于網(wǎng)站能做什么,而不在于它是怎么做的,所以在網(wǎng)站還很小的時(shí)候就去追求網(wǎng)站的架構(gòu)框架是舍本逐末,得不償失的。前端框架同理,如果是一個(gè)簡(jiǎn)單的頁(yè)面型產(chǎn)品,應(yīng)用只是依賴服務(wù)器來(lái)生成Web頁(yè)面和視圖,并且只需要使用一些簡(jiǎn)單的Javascript或者JQuery來(lái)使應(yīng)用更加具有互動(dòng)性,那么一個(gè)JQuery前端類庫(kù)就可以了,真的沒(méi)必要用上一些高大上的框架。
當(dāng)然,框架的確是很有用的,重點(diǎn)是我們要知道什么時(shí)候該用什么框架。大公司大項(xiàng)目的經(jīng)驗(yàn)和成功模式固然重要,值得學(xué)習(xí)借鑒,但我們不能因此變得盲從。只有深刻去理解前端框架,知道什么時(shí)候該用什么什么框架解決什么問(wèn)題,才能有的放矢,直擊要害。
2.前端框架與前端類庫(kù)的區(qū)別
使用框架前,我覺得很重要的一點(diǎn)是弄清類庫(kù)(諸如JQuery)和框架(諸如angularJS)的區(qū)別在何處。
簡(jiǎn)單而言,類庫(kù),解決的是代碼或者是模塊級(jí)別的復(fù)用或者對(duì)復(fù)雜度的封裝問(wèn)題,例如將一個(gè)解決復(fù)雜問(wèn)題的功能模塊封裝成一個(gè)函數(shù),提供一個(gè)簡(jiǎn)單的接口。庫(kù)它是一種工具,它提供了很多封裝好的方法,用與不用取決于我們自身,即使用了也不會(huì)影響我們呢的代碼結(jié)構(gòu)。
而框架,更多的是對(duì)模式級(jí)別的復(fù)用和對(duì)程序組織的規(guī)范。這里的模式是指比如MVC,為了實(shí)現(xiàn)M和V的解耦,把復(fù)雜的耦合關(guān)系由經(jīng)常變化的業(yè)務(wù)代碼轉(zhuǎn)移到不經(jīng)常變化的框架內(nèi)部消化。是面向一個(gè)領(lǐng)域來(lái)提供一套解決方案,提高開發(fā)效率,如果我們選擇了使用某框架,就應(yīng)該遵循該框架所規(guī)定的規(guī)則。
二者最主要的區(qū)別是:JQuery以DOM操作為中心,框架,準(zhǔn)確來(lái)說(shuō)是MVC框架,是以模型(model)為中心,而DOM操作是附加的。所以,以模型為中心最終達(dá)到的目的是帶來(lái)一整套工作流程的變更,使得后臺(tái)工程師可以編寫前端的模型代碼,把后臺(tái)與前端打通,交互設(shè)計(jì)師處理UI跟模型的互動(dòng)關(guān)系,UI設(shè)計(jì)師可以專注、無(wú)障礙的處理HTML源碼,把它們以界面模板的形式提交給交互工程師。這一整套協(xié)作機(jī)制能大大提高開發(fā)效率。使用MVC框架使得前端任務(wù)更好的被解耦。
3.前端MVC框架思想
我們知道,傳統(tǒng)的MVC模式將一個(gè)應(yīng)用劃分為——模型層(model)、視圖層(view)、控制層(controller)。他們?cè)趹?yīng)用系統(tǒng)中擔(dān)當(dāng)不同的角色,完成不同的任務(wù)。
Model:即數(shù)據(jù)模型,用來(lái)包裝和應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)或者對(duì)數(shù)據(jù)進(jìn)行處理,模型可以直接訪問(wèn)數(shù)據(jù)。
View:視圖用來(lái)有目的顯示數(shù)據(jù),在視圖中一般沒(méi)有程序上的邏輯,為了實(shí)現(xiàn)視圖上的最新功能,視圖需要訪問(wèn)它監(jiān)視的數(shù)據(jù)模型。
Controller:控制器調(diào)控模型和視圖的聯(lián)系,它控制應(yīng)用程序的流程,處理事件并作出響應(yīng),事件不僅僅包括用戶的行為還有數(shù)據(jù)模型上的改變。通過(guò)捕獲用戶事件,通知模型層作出相應(yīng)的更新處理,同時(shí)將模型層的更新和改變通知給視圖,使得視圖作出相應(yīng)改變。因此控制器保證了視圖和模型的一致性。