李 夢，江 山，黃 幸，安立鵬

（1.武漢郵電科學研究院 湖北 武漢 430000；2.武漢理工光科股份有限公司 湖北 武漢　430070）

基于前端的WEB優(yōu)化設計

李 夢1，江 山2，黃 幸2，安立鵬2

（1.武漢郵電科學研究院 湖北 武漢 430000；2.武漢理工光科股份有限公司 湖北 武漢430070）

為了加快web網(wǎng)站的響應速度，提高用戶的體驗感，本文從減少Http的請求、緩存Http響應、壓縮組件、規(guī)范頁面呈現(xiàn)順序、DNS緩存、精簡JavaScript和Css、避免從定向7個方面來設計優(yōu)化方案。通過緩存Http響應能減少響應時間的50%，使用Gzip壓縮能將響應數(shù)據(jù)量減少70%。

Web網(wǎng)站；Web前端；前端優(yōu)化；響應速度

如今隨著Internet網(wǎng)的不斷高速發(fā)展，人們對于網(wǎng)站需要不在基于可用性這么簡單，網(wǎng)站的用戶體驗越來越被重視。在Web優(yōu)化中，我們分為前端和后端的優(yōu)化，通過調(diào)查，我們發(fā)現(xiàn)只有10%～20%的時間是用在從web服務器端獲取HTML文檔并傳到瀏覽器中，有80%～90%的時間都用響應前端上面，這里包括HTML文檔、CSS樣式、JavaScript腳本。相比繁瑣的后端的優(yōu)化，前端的優(yōu)化只需要較少的時間和資源，并且優(yōu)化的成效也要大的多，修改少量的程序便能快速提高網(wǎng)站的速度，所以本文將主要講述前端優(yōu)化方案。

1　減少HTTP請求

Web前端HTML文檔里面的組件進行HTTP請求的時間是相當大的，首先，我們能想到最簡單直觀的方法就是減少組件數(shù)量，從而減少HTTP請求，但過多的減少組件又會和產(chǎn)品的設計相矛盾，所以要用最少的HTTP請求獲取最多的組件。

1.1圖片地圖Image-Map

圖片地圖是指帶有可點擊區(qū)的一幅圖像，它允許在一個圖片上放置多個URL，卻只產(chǎn)生一個HTTP請求，點擊相應圖片的位置便可訪問對應的URL。

＜Map＞定義客戶端圖像映射，通過＜area＞設定不同圖片的位置，在＜img＞中的 通過“usemap”［1］屬性可引用相應的圖片地圖。制作導航菜單的時候使用圖片地圖能大大提高性能，同時導航菜單的缺陷是獲取地圖區(qū)域的坐標時可能比較局限。

1.2CSSSprites

CSS Sprites是一種圖片整合技術(shù)，將頁面所有的零散的圖片合成到一張大圖里面，在利用CSS的屬性確定出要使用圖片的位置，這樣所有的頁面所需的icon僅需一次HTTP請求，且通過合成之后大圖的字節(jié)總數(shù)小于單張字節(jié)的總和。CSS Sprites更適合于存在大量圖片的情況，并且獲取圖片的坐標要比圖片地圖容易。

1.3內(nèi)聯(lián)圖片

內(nèi)聯(lián)圖片的語法格式如下＜img src="data：image/png；base64，iVBOR....＞，將圖片進行base64編碼［2］，這樣方法不會產(chǎn)生額外的HTPP請求，同時瀏覽器也不能緩存這種格式的圖片。一般來說內(nèi)聯(lián)圖片主要是用于背景平鋪類圖片，讓用戶最大限度的體驗到Web網(wǎng)站的流暢。

2　使用Expires頭

以上處理圖片的方式都是在初次訪問直接減少HTTP請求，而使用Expires頭可以在初次訪問之后將這些組件緩存起來，并控制緩存失效的日期，只要組件沒有過期，瀏覽器就會使用緩存版本，從避免不必要的HTTP請求。

2.1Cache-Control

眾所周知客戶端的時間是可以被修改的，然而Expires規(guī)定的時間格式是GMT（格林尼治時間）［3］，由于這個時間是特定的，就可能會導致服務器與客戶端時間不一致，存在緩存不穩(wěn)定，將提前失效的情況。

HTTP1.1使用Cache-Control來克服Expires頭的限制。。Cache-Control使用max-age控制組件被緩存時間，max-age單位是秒［4］，用這個相對時間段，就不存在客戶端服務端時間不統(tǒng)一的情況。若max-age和Expires同時出現(xiàn)，前者據(jù)有更高的優(yōu)先級。在Cache-Control中還有以下標簽，no-cache：瀏覽器不進行緩存；no-store：資源既不能被緩存，也不能放入磁盤；private：默認值，代理服務器將不能緩存資源，僅客戶端緩存；public：任何服務器均可以緩存資源。

2.2緩存的內(nèi)容

緩存的內(nèi)容應該是不經(jīng)常變化的組件，包括圖片、腳本、樣式、Flash組件。如果頁面的所有組件都據(jù)有緩存，第二次瀏覽頁面時只需進行一個HTTP請求，這樣響應時間會減少50%，甚至更多。

3　壓縮組件

前兩點主要從減少HTTP請求方面考慮，第3點將HTTP響應的大小來減少響應時間，若服務器傳給客戶端的響應包越小，傳輸時間就會隨之減少。

3.1GZIP

GZIP是GNUzip的縮寫，它是一個GNU自由軟件的文件壓縮程序［4］。Web客戶端通過HTTP請求中的 Accept-Encoding頭來告知服務器它所支持的壓縮文件格式類型，web服務器解析請求頭，使用客戶端提供的一種方法來壓縮響應碼，并用響應頭Content-Encoding頭回傳給客戶端它使用的壓縮方式。

3.2壓縮內(nèi)容

在使用壓縮時會消耗服務端CPU，客戶端進行解壓也需要一定的時間，所以我們要考慮何種文件適合壓縮，一般來說，使用GZIP壓縮HTML文檔、XML和JSON文本響應、腳本和樣式表。圖片和PDF不應該在壓縮了，通常是對于1kb 和2kb的文件進行壓縮。GZIP壓縮一般能將響應的數(shù)據(jù)量減少將近70%，deflate壓縮只能減少60%。

3.3代理服務器緩存

當瀏覽器使用代理發(fā)送請求時，一些老的瀏覽器可能還不支持緩存，這里我們在服務器響應頭中增加“Vary：Accept-Encoding”，此時能讓代理服務器緩存響應的壓縮和非壓縮版兩種格式?，F(xiàn)在絕大多數(shù)瀏覽器都支持壓縮，但是添加Vary并不需要額外的開銷，所以保險起見最好添加。

4　頁面呈現(xiàn)

瀏覽器渲染頁面的過程是下載html生成Dom tree，在根據(jù)css結(jié)構(gòu)生成Render tree，我們希望頁面在能迅速的逐步的呈現(xiàn)給用戶，不會因為某些組件的阻塞而造成“白屏”現(xiàn)象。

4.1CSS樣式表放在頂部

當css樣式表放在底部時，你會發(fā)現(xiàn)頁面一直處于空白狀態(tài)，突然所有的組件都出現(xiàn)在屏幕上，這是因為程序完成了css的下載。在這種情況下，如果空白時間過長，用戶會誤認為頁面是死掉了而結(jié)束頁面，這將會損失很大一批用戶。若將css樣式放在頂部，頁面就會逐步呈現(xiàn)，對于用戶來說，頁面本身就像是進度指示器，這些會為等待頁面的用戶提供一個良好的視覺反饋。文檔中有Link和@import兩種規(guī)則來包含樣式表，基于兼容性和穩(wěn)定性來說，還是提倡的還是用Link標簽。

4.2將腳本放在底部

由于瀏覽器的順序執(zhí)行，無論腳本放置在哪個位置，都會阻塞其后的內(nèi)容呈現(xiàn)及組件下載，都需要腳本加載完畢之后，后面的內(nèi)容才會被顯示出來。若腳本加載時間過長，也會影響用戶體驗。為了避免阻塞，我們通常將腳本放置在文檔底部，還有一種做法是在腳本中設置defer屬性，通過defer來提示瀏覽器可以繼續(xù)解析HTML文檔，并延遲執(zhí)行腳本。在出現(xiàn)腳本從外部文件載入時，瀏覽器能繼續(xù)向下執(zhí)行不必等待外部文件載入完成，這能有效的提高性能。其存在的缺點是并不是所有的瀏覽器都支持這個特性，延遲的腳本總是被延遲，直到文檔結(jié)束，而不是只延遲到下一個非延遲的腳本，這可能會使延遲腳本的執(zhí)行順序混亂，所以還是建議使用第一種方法。

5　減少DNS查找

Internet是通過IP地址查找服務器，由于IP地址的不利于人們的記憶，通常將包含主機名的URL來取代它。當瀏覽器發(fā)送請求時，通過DNS（Domain Name System）協(xié)議將主機名轉(zhuǎn)換成IP地址，進行訪問［5］。DNS查找過程的順序是瀏覽器緩存、本機DNS緩存、DNS服務器，這段時間通?；ㄙM20～120毫秒，在DNS查找完成之前，瀏覽器不能從主機名那里下載任何東西。TTL（Time To Live）：表示查找返回的DNS記錄包含的一個存活時間，過期則這個DNS記錄將被拋棄。

5.1DNS緩存

當DNS查找被緩存起來時，短時間內(nèi)都不需要進行DNS查找，只有這個記錄被緩存丟棄時，才需重新發(fā)起請求，花費額外的時間。同時，我們應該想到IP地址會發(fā)生變化以及過多的緩存會消耗內(nèi)存，我們應該周期性的清除緩存中的DNS記錄。

5.2減少DNS查找

當客戶端的DNS緩存（瀏覽器和本機）為空時，DNS查找的數(shù)量與web頁面中唯一主機名的數(shù)量相等［6］。通過減少主機名的數(shù)量來相應減少的DNS查找數(shù)量，但是減少主機名數(shù)量又會導致頁面并行下載數(shù)量的降低，而增加相應時間。如何權(quán)衡這兩者呢？現(xiàn)如今，頁面一般具有大量的組件，我們可以將組件分別放到大于2小于4的主機名下，這將會保證既減少了DNS查找又允許并行下載。

6　精簡JavaScript和CSS

通過減小JavaScript和Css文件的大小來改善加載時［7］。

6.1精簡格式

在JS代碼的精簡過程中，可以刪除不必要的注釋和空白字符（空格、換行、制表符），使文件大小減小，

6.2混淆

混淆是不僅會溢出注釋和空白，同時還會改寫代碼。改寫的一部分，函數(shù)和變量名將被轉(zhuǎn)換為更短的字符串，這是雖然代碼更加精煉，但是也更難閱讀，大大增加了調(diào)試和對代碼進行反向工程的難度，混淆過程本身也很可能引入錯誤，一般推薦使用精簡而不是混淆。

6.3工具

現(xiàn)在有很多精簡JS代碼的工具，例如Yahoo的UI Compressor、Google的 Closure Compiler、Packer、ShrinkSafe精簡工具能減少文件的三分之一甚至更多、JSMin可以減少一半的大小。結(jié)合應用程序的不同，找到合適的壓縮工具。精簡CSS帶來的優(yōu)化常小于精簡JavaScript，CSS中的注釋和空白比Js要少，優(yōu)化CSS還可以合并相同的類，移除不使用的類。

7　避免重定向

重定向是將用戶從一個鏈接重定向到另一個鏈接，常出現(xiàn)的重定向是301：永久重定向和302：臨時重定向［8］。當出現(xiàn)重定向時，客戶端會不斷地向服務器進行請求，浪費響應時間。

7.1缺少結(jié)尾的“/”

重定向會降級頁面的響應速度，有種頻繁發(fā)生修改容易的重定向是在URL的結(jié)尾缺少斜線（“/”）。凡是在訪問地址中，沒有帶文件名后綴（例如aspx，asp等），服務器都試圖解析為一個文件夾，自動加上一個路徑斜線，然后自動查找內(nèi)部的默認頁面。把在URL結(jié)尾添加“/”作為一種習慣，花費少量的時間即可避免這種重定向。

8　結(jié)束語

以上從7個方面來談Web前端優(yōu)化，這是一個繁瑣的過程，需要處理許多的小細節(jié)才會效果顯著的提高響應速度，但是不斷改善用戶體驗和提升產(chǎn)品的價值和競爭力來說，web前端優(yōu)化還是具有長遠的意義。

［1］明日科技.HTML5從入門到精通［M］.北京：清華大學出版社，2012.

［2］唐武生，田立紅，曹偉.Base64編碼的實現(xiàn)與應用研究［J］.長春大學學報，2006（4）：69-72.

［3］David GourleyBrian TottyMarjorie Sayer，等.HTTP權(quán)威指南［M］．北京：人民郵電出版社，2012．

［4］唐長安 陳玉紅．基于前端的Web性能優(yōu)化［J］．電腦知識與技術(shù)，2011（6）：3811-3813.

［5］劉阿爾貝茨，譯者：房向明，孫云，陳治州，DNS與BIND［M］.北京：人民郵電出版社，2014．

［6］SteveSounders，高性能網(wǎng)站建設指南［M］.北京：電子工業(yè)出版社，2008.

［7］linux和aix下常用的壓縮和解壓縮命令［J］.計算機與網(wǎng)絡，2012（12）：31.

［8］朱杰.網(wǎng)站建設及維護中的重定向問題分析［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稿件編號：201505151

李 夢（1990—），女，湖北荊州人，碩士。研究方向：通信與信息系統(tǒng)。