李 夢(mèng),江 山,黃 幸,安立鵬
(1.武漢郵電科學(xué)研究院 湖北 武漢 430000;2.武漢理工光科股份有限公司 湖北 武漢 430070)
基于前端的WEB優(yōu)化設(shè)計(jì)
李 夢(mèng)1,江 山2,黃 幸2,安立鵬2
(1.武漢郵電科學(xué)研究院 湖北 武漢 430000;2.武漢理工光科股份有限公司 湖北 武漢430070)
為了加快web網(wǎng)站的響應(yīng)速度,提高用戶的體驗(yàn)感,本文從減少Http的請(qǐng)求、緩存Http響應(yīng)、壓縮組件、規(guī)范頁(yè)面呈現(xiàn)順序、DNS緩存、精簡(jiǎn)JavaScript和Css、避免從定向7個(gè)方面來(lái)設(shè)計(jì)優(yōu)化方案。通過(guò)緩存Http響應(yīng)能減少響應(yīng)時(shí)間的50%,使用Gzip壓縮能將響應(yīng)數(shù)據(jù)量減少70%。
Web網(wǎng)站;Web前端;前端優(yōu)化;響應(yīng)速度
如今隨著Internet網(wǎng)的不斷高速發(fā)展,人們對(duì)于網(wǎng)站需要不在基于可用性這么簡(jiǎn)單,網(wǎng)站的用戶體驗(yàn)越來(lái)越被重視。在Web優(yōu)化中,我們分為前端和后端的優(yōu)化,通過(guò)調(diào)查,我們發(fā)現(xiàn)只有10%~20%的時(shí)間是用在從web服務(wù)器端獲取HTML文檔并傳到瀏覽器中,有80%~90%的時(shí)間都用響應(yīng)前端上面,這里包括HTML文檔、CSS樣式、JavaScript腳本。相比繁瑣的后端的優(yōu)化,前端的優(yōu)化只需要較少的時(shí)間和資源,并且優(yōu)化的成效也要大的多,修改少量的程序便能快速提高網(wǎng)站的速度,所以本文將主要講述前端優(yōu)化方案。
Web前端HTML文檔里面的組件進(jìn)行HTTP請(qǐng)求的時(shí)間是相當(dāng)大的,首先,我們能想到最簡(jiǎn)單直觀的方法就是減少組件數(shù)量,從而減少HTTP請(qǐng)求,但過(guò)多的減少組件又會(huì)和產(chǎn)品的設(shè)計(jì)相矛盾,所以要用最少的HTTP請(qǐng)求獲取最多的組件。
1.1圖片地圖Image-Map
圖片地圖是指帶有可點(diǎn)擊區(qū)的一幅圖像,它允許在一個(gè)圖片上放置多個(gè)URL,卻只產(chǎn)生一個(gè)HTTP請(qǐng)求,點(diǎn)擊相應(yīng)圖片的位置便可訪問(wèn)對(duì)應(yīng)的URL。
<Map>定義客戶端圖像映射,通過(guò)<area>設(shè)定不同圖片的位置,在<img>中的 通過(guò)“usemap”[1]屬性可引用相應(yīng)的圖片地圖。制作導(dǎo)航菜單的時(shí)候使用圖片地圖能大大提高性能,同時(shí)導(dǎo)航菜單的缺陷是獲取地圖區(qū)域的坐標(biāo)時(shí)可能比較局限。
1.2CSSSprites
CSS Sprites是一種圖片整合技術(shù),將頁(yè)面所有的零散的圖片合成到一張大圖里面,在利用CSS的屬性確定出要使用圖片的位置,這樣所有的頁(yè)面所需的icon僅需一次HTTP請(qǐng)求,且通過(guò)合成之后大圖的字節(jié)總數(shù)小于單張字節(jié)的總和。CSS Sprites更適合于存在大量圖片的情況,并且獲取圖片的坐標(biāo)要比圖片地圖容易。
1.3內(nèi)聯(lián)圖片
內(nèi)聯(lián)圖片的語(yǔ)法格式如下<img src="data:image/png;base64,iVBOR....>,將圖片進(jìn)行base64編碼[2],這樣方法不會(huì)產(chǎn)生額外的HTPP請(qǐng)求,同時(shí)瀏覽器也不能緩存這種格式的圖片。一般來(lái)說(shuō)內(nèi)聯(lián)圖片主要是用于背景平鋪類圖片,讓用戶最大限度的體驗(yàn)到Web網(wǎng)站的流暢。
以上處理圖片的方式都是在初次訪問(wèn)直接減少HTTP請(qǐng)求,而使用Expires頭可以在初次訪問(wèn)之后將這些組件緩存起來(lái),并控制緩存失效的日期,只要組件沒(méi)有過(guò)期,瀏覽器就會(huì)使用緩存版本,從避免不必要的HTTP請(qǐng)求。
2.1Cache-Control
眾所周知客戶端的時(shí)間是可以被修改的,然而Expires規(guī)定的時(shí)間格式是GMT(格林尼治時(shí)間)[3],由于這個(gè)時(shí)間是特定的,就可能會(huì)導(dǎo)致服務(wù)器與客戶端時(shí)間不一致,存在緩存不穩(wěn)定,將提前失效的情況。
HTTP1.1使用Cache-Control來(lái)克服Expires頭的限制。。Cache-Control使用max-age控制組件被緩存時(shí)間,max-age單位是秒[4],用這個(gè)相對(duì)時(shí)間段,就不存在客戶端服務(wù)端時(shí)間不統(tǒng)一的情況。若max-age和Expires同時(shí)出現(xiàn),前者據(jù)有更高的優(yōu)先級(jí)。在Cache-Control中還有以下標(biāo)簽,no-cache:瀏覽器不進(jìn)行緩存;no-store:資源既不能被緩存,也不能放入磁盤(pán);private:默認(rèn)值,代理服務(wù)器將不能緩存資源,僅客戶端緩存;public:任何服務(wù)器均可以緩存資源。
2.2緩存的內(nèi)容
緩存的內(nèi)容應(yīng)該是不經(jīng)常變化的組件,包括圖片、腳本、樣式、Flash組件。如果頁(yè)面的所有組件都據(jù)有緩存,第二次瀏覽頁(yè)面時(shí)只需進(jìn)行一個(gè)HTTP請(qǐng)求,這樣響應(yīng)時(shí)間會(huì)減少50%,甚至更多。
前兩點(diǎn)主要從減少HTTP請(qǐng)求方面考慮,第3點(diǎn)將HTTP響應(yīng)的大小來(lái)減少響應(yīng)時(shí)間,若服務(wù)器傳給客戶端的響應(yīng)包越小,傳輸時(shí)間就會(huì)隨之減少。
3.1GZIP
GZIP是GNUzip的縮寫(xiě),它是一個(gè)GNU自由軟件的文件壓縮程序[4]。Web客戶端通過(guò)HTTP請(qǐng)求中的 Accept-Encoding頭來(lái)告知服務(wù)器它所支持的壓縮文件格式類型,web服務(wù)器解析請(qǐng)求頭,使用客戶端提供的一種方法來(lái)壓縮響應(yīng)碼,并用響應(yīng)頭Content-Encoding頭回傳給客戶端它使用的壓縮方式。
3.2壓縮內(nèi)容
在使用壓縮時(shí)會(huì)消耗服務(wù)端CPU,客戶端進(jìn)行解壓也需要一定的時(shí)間,所以我們要考慮何種文件適合壓縮,一般來(lái)說(shuō),使用GZIP壓縮HTML文檔、XML和JSON文本響應(yīng)、腳本和樣式表。圖片和PDF不應(yīng)該在壓縮了,通常是對(duì)于1kb 和2kb的文件進(jìn)行壓縮。GZIP壓縮一般能將響應(yīng)的數(shù)據(jù)量減少將近70%,deflate壓縮只能減少60%。
3.3代理服務(wù)器緩存
當(dāng)瀏覽器使用代理發(fā)送請(qǐng)求時(shí),一些老的瀏覽器可能還不支持緩存,這里我們?cè)诜?wù)器響應(yīng)頭中增加“Vary:Accept-Encoding”,此時(shí)能讓代理服務(wù)器緩存響應(yīng)的壓縮和非壓縮版兩種格式。現(xiàn)在絕大多數(shù)瀏覽器都支持壓縮,但是添加Vary并不需要額外的開(kāi)銷,所以保險(xiǎn)起見(jiàn)最好添加。
瀏覽器渲染頁(yè)面的過(guò)程是下載html生成Dom tree,在根據(jù)css結(jié)構(gòu)生成Render tree,我們希望頁(yè)面在能迅速的逐步的呈現(xiàn)給用戶,不會(huì)因?yàn)槟承┙M件的阻塞而造成“白屏”現(xiàn)象。
4.1CSS樣式表放在頂部
當(dāng)css樣式表放在底部時(shí),你會(huì)發(fā)現(xiàn)頁(yè)面一直處于空白狀態(tài),突然所有的組件都出現(xiàn)在屏幕上,這是因?yàn)槌绦蛲瓿闪薱ss的下載。在這種情況下,如果空白時(shí)間過(guò)長(zhǎng),用戶會(huì)誤認(rèn)為頁(yè)面是死掉了而結(jié)束頁(yè)面,這將會(huì)損失很大一批用戶。若將css樣式放在頂部,頁(yè)面就會(huì)逐步呈現(xiàn),對(duì)于用戶來(lái)說(shuō),頁(yè)面本身就像是進(jìn)度指示器,這些會(huì)為等待頁(yè)面的用戶提供一個(gè)良好的視覺(jué)反饋。文檔中有Link和@import兩種規(guī)則來(lái)包含樣式表,基于兼容性和穩(wěn)定性來(lái)說(shuō),還是提倡的還是用Link標(biāo)簽。
4.2將腳本放在底部
由于瀏覽器的順序執(zhí)行,無(wú)論腳本放置在哪個(gè)位置,都會(huì)阻塞其后的內(nèi)容呈現(xiàn)及組件下載,都需要腳本加載完畢之后,后面的內(nèi)容才會(huì)被顯示出來(lái)。若腳本加載時(shí)間過(guò)長(zhǎng),也會(huì)影響用戶體驗(yàn)。為了避免阻塞,我們通常將腳本放置在文檔底部,還有一種做法是在腳本中設(shè)置defer屬性,通過(guò)defer來(lái)提示瀏覽器可以繼續(xù)解析HTML文檔,并延遲執(zhí)行腳本。在出現(xiàn)腳本從外部文件載入時(shí),瀏覽器能繼續(xù)向下執(zhí)行不必等待外部文件載入完成,這能有效的提高性能。其存在的缺點(diǎn)是并不是所有的瀏覽器都支持這個(gè)特性,延遲的腳本總是被延遲,直到文檔結(jié)束,而不是只延遲到下一個(gè)非延遲的腳本,這可能會(huì)使延遲腳本的執(zhí)行順序混亂,所以還是建議使用第一種方法。
Internet是通過(guò)IP地址查找服務(wù)器,由于IP地址的不利于人們的記憶,通常將包含主機(jī)名的URL來(lái)取代它。當(dāng)瀏覽器發(fā)送請(qǐng)求時(shí),通過(guò)DNS(Domain Name System)協(xié)議將主機(jī)名轉(zhuǎn)換成IP地址,進(jìn)行訪問(wèn)[5]。DNS查找過(guò)程的順序是瀏覽器緩存、本機(jī)DNS緩存、DNS服務(wù)器,這段時(shí)間通常花費(fèi)20~120毫秒,在DNS查找完成之前,瀏覽器不能從主機(jī)名那里下載任何東西。TTL(Time To Live):表示查找返回的DNS記錄包含的一個(gè)存活時(shí)間,過(guò)期則這個(gè)DNS記錄將被拋棄。
5.1DNS緩存
當(dāng)DNS查找被緩存起來(lái)時(shí),短時(shí)間內(nèi)都不需要進(jìn)行DNS查找,只有這個(gè)記錄被緩存丟棄時(shí),才需重新發(fā)起請(qǐng)求,花費(fèi)額外的時(shí)間。同時(shí),我們應(yīng)該想到IP地址會(huì)發(fā)生變化以及過(guò)多的緩存會(huì)消耗內(nèi)存,我們應(yīng)該周期性的清除緩存中的DNS記錄。
5.2減少DNS查找
當(dāng)客戶端的DNS緩存(瀏覽器和本機(jī))為空時(shí),DNS查找的數(shù)量與web頁(yè)面中唯一主機(jī)名的數(shù)量相等[6]。通過(guò)減少主機(jī)名的數(shù)量來(lái)相應(yīng)減少的DNS查找數(shù)量,但是減少主機(jī)名數(shù)量又會(huì)導(dǎo)致頁(yè)面并行下載數(shù)量的降低,而增加相應(yīng)時(shí)間。如何權(quán)衡這兩者呢?現(xiàn)如今,頁(yè)面一般具有大量的組件,我們可以將組件分別放到大于2小于4的主機(jī)名下,這將會(huì)保證既減少了DNS查找又允許并行下載。
通過(guò)減小JavaScript和Css文件的大小來(lái)改善加載時(shí)[7]。
6.1精簡(jiǎn)格式
在JS代碼的精簡(jiǎn)過(guò)程中,可以刪除不必要的注釋和空白字符(空格、換行、制表符),使文件大小減小,
6.2混淆
混淆是不僅會(huì)溢出注釋和空白,同時(shí)還會(huì)改寫(xiě)代碼。改寫(xiě)的一部分,函數(shù)和變量名將被轉(zhuǎn)換為更短的字符串,這是雖然代碼更加精煉,但是也更難閱讀,大大增加了調(diào)試和對(duì)代碼進(jìn)行反向工程的難度,混淆過(guò)程本身也很可能引入錯(cuò)誤,一般推薦使用精簡(jiǎn)而不是混淆。
6.3工具
現(xiàn)在有很多精簡(jiǎn)JS代碼的工具,例如Yahoo的UI Compressor、Google的 Closure Compiler、Packer、ShrinkSafe精簡(jiǎn)工具能減少文件的三分之一甚至更多、JSMin可以減少一半的大小。結(jié)合應(yīng)用程序的不同,找到合適的壓縮工具。精簡(jiǎn)CSS帶來(lái)的優(yōu)化常小于精簡(jiǎn)JavaScript,CSS中的注釋和空白比Js要少,優(yōu)化CSS還可以合并相同的類,移除不使用的類。
重定向是將用戶從一個(gè)鏈接重定向到另一個(gè)鏈接,常出現(xiàn)的重定向是301:永久重定向和302:臨時(shí)重定向[8]。當(dāng)出現(xiàn)重定向時(shí),客戶端會(huì)不斷地向服務(wù)器進(jìn)行請(qǐng)求,浪費(fèi)響應(yīng)時(shí)間。
7.1缺少結(jié)尾的“/”
重定向會(huì)降級(jí)頁(yè)面的響應(yīng)速度,有種頻繁發(fā)生修改容易的重定向是在URL的結(jié)尾缺少斜線(“/”)。凡是在訪問(wèn)地址中,沒(méi)有帶文件名后綴(例如aspx,asp等),服務(wù)器都試圖解析為一個(gè)文件夾,自動(dòng)加上一個(gè)路徑斜線,然后自動(dòng)查找內(nèi)部的默認(rèn)頁(yè)面。把在URL結(jié)尾添加“/”作為一種習(xí)慣,花費(fèi)少量的時(shí)間即可避免這種重定向。
以上從7個(gè)方面來(lái)談Web前端優(yōu)化,這是一個(gè)繁瑣的過(guò)程,需要處理許多的小細(xì)節(jié)才會(huì)效果顯著的提高響應(yīng)速度,但是不斷改善用戶體驗(yàn)和提升產(chǎn)品的價(jià)值和競(jìng)爭(zhēng)力來(lái)說(shuō),web前端優(yōu)化還是具有長(zhǎng)遠(yuǎn)的意義。
[1]明日科技.HTML5從入門(mén)到精通[M].北京:清華大學(xué)出版社,2012.
[2]唐武生,田立紅,曹偉.Base64編碼的實(shí)現(xiàn)與應(yīng)用研究[J].長(zhǎng)春大學(xué)學(xué)報(bào),2006(4):69-72.
[3]David GourleyBrian TottyMarjorie Sayer,等.HTTP權(quán)威指南[M].北京:人民郵電出版社,2012.
[4]唐長(zhǎng)安 陳玉紅.基于前端的Web性能優(yōu)化[J].電腦知識(shí)與技術(shù),2011(6):3811-3813.
[5]劉阿爾貝茨,譯者:房向明,孫云,陳治州,DNS與BIND[M].北京:人民郵電出版社,2014.
[6]SteveSounders,高性能網(wǎng)站建設(shè)指南[M].北京:電子工業(yè)出版社,2008.
[7]linux和aix下常用的壓縮和解壓縮命令[J].計(jì)算機(jī)與網(wǎng)絡(luò),2012(12):31.
[8]朱杰.網(wǎng)站建設(shè)及維護(hù)中的重定向問(wèn)題分析[J].信息與電腦,2014(9):186-187.
WEB optimization design base on front-end
LI Meng1,JIANG Shan2,HUANG Xing2,AN Li-peng2
(1.Wuhan Research Institute of Posts and Telecommunications,Wuhan 430000,China;2.Wuhan University of Technology Optic Science Company Limited,Wuhan 430070,China)
In order to speed up response web site,improve user experience,this paper through reduction Http request,caching Http response,compression component,specification page presentation order,DNS cache,streamlined JavaScript and Css,avoid redirects,seven areas to design optimization.Http response by caching can reduce response time by 50%,using Gzip component can reduce the amount of data in response to 70%.
WebSite;Web Front-end;front-end optimization;response speed
TP39
A
1674-6236(2016)09-0078-03
2015-05-18稿件編號(hào):201505151
李 夢(mèng)(1990—),女,湖北荊州人,碩士。研究方向:通信與信息系統(tǒng)。