平均分 (74個評分)前端的高性能部分，主要是指減少請求數(shù)、減少傳輸?shù)臄?shù)據(jù)以及提高用戶體驗，在這個部分，圖片的優(yōu)化顯得至關重要。許多網(wǎng)站的美化，都是靠絢麗的圖片達到的，圖片恰恰是占用帶寬的元兇。每個 img 標簽，瀏覽器都會試圖發(fā)起一個下載請求。本文就詳細介紹了圖片優(yōu)化的幾種方式，介紹了使用的工具以及優(yōu)化后的結(jié)果。
減少圖片的大小，可以明顯的提高性能，而對于已有圖片，要想減少圖片的大小，只能改變圖片的格式，這里推薦的是 PNG8 的格式，它可以在基本保持清晰度的情況下，減少圖片的大小。知道這個原理以后，可以用 Windows 的畫圖工具、以及 PhotoShop 工具逐個的改變。但是這樣做的缺點是單張?zhí)幚?，效率太慢。本文推薦一個在線轉(zhuǎn)換工具 Smush.it，可以批量的進行壓縮與轉(zhuǎn)換。它的地址是：www.smushit.com/ysmush.it。打開后效果如下圖所示。
圖 1. Yahoo 提供的在線壓縮工具
我們上傳了一張大小為 3790K 的圖片，待在線程序處理完畢后，點擊 Download Smushed Images 下載查看結(jié)果。下載界面如下圖所示。
圖 2. 壓縮后的結(jié)果
打開下載下來的壓縮包，查看結(jié)果可以看到，圖片從 3790 減少到了 3344，就如下圖所示。對于大批量的圖片網(wǎng)站，這個方法會幫助快速實現(xiàn)批量圖片壓縮。
圖 3. 壓縮后的結(jié)果
CSS Sprites 是一個吸引人的技術，它其實就是把網(wǎng)頁中一些背景圖片整合到一張圖片文件中，再利用 CSS 的“background-image”，“background- repeat”，“background-position”的組合進行背景定位，background-position 可以用數(shù)字能精確的定位出背景圖片的位置。利用 CSS Sprites 能很好地減少網(wǎng)頁的 HTTP 請求，從而大大的提高了頁面的性能，這也是 CSS Sprites 最大的優(yōu)點，也是其被廣泛傳播和應用的主要原因。CSS Sprites 能減少圖片的字節(jié)，由于圖像合并后基本信息不用重復，那么多張圖片合并成 1 張圖片的字節(jié)往往總是小于這些圖片的字節(jié)總和。同時 CSS Sprites 解決了網(wǎng)頁設計師在圖片命名上的困擾，只需對一張集合的圖片上命名就可以了，不需要對每一個小元素進行命名，從而提高了網(wǎng)頁的制作效率。更換風格方便，只需要在一張或少張圖片上修改圖片的顏色或樣式，整個網(wǎng)頁的風格就可以改變。維護起來更加方便。同時，由于將圖片合并到一張圖片，因此圖片的請求數(shù)就被縮減到 1 個。其他的請求都可以用到本地緩存，不需要訪問服務器。下圖是一個合并以后的圖片。它將很多小圖標都拼到了一起。
圖 4. 合并后的圖片
這里介紹一個小工具 ---“CSS Sprites 樣式生成工具 2.0”，可以從 這里下載。這是一個簡單免費的小工具，用該工具打開上面的圖片，選中圖片中的某塊。如下圖的“綠色大拇指”部分，工具會計算出這個部分的長、寬、距離左上角的距離。勾選復制類名、復制寬、復制高，再點擊“復制當前樣式”按鈕。這樣生成的樣式會被復制到剪切板上。
圖 5. 小工具的使用
生成的 CSS 代碼如清單 1 所示。
清單 1. 小工具生成的 CSS 代碼
.div_6148{width:18px;height:20px;background-position:-17px -209px;}
|
將這段代碼運用在網(wǎng)頁上，它的代碼如下清單所示。
清單 2. 測試 CSS Sprites 代碼
<html>
<head>
<style>
.div_6148
{
width:18px;
height:20px;
background-image:url(css-sprites-source.gif);
background-position:-17px -209px;
}
</style>
</head>
<body>
<div class="div_6148"></div>
</body>
</html>
|
打開測試網(wǎng)頁顯示結(jié)果如下圖所示。
圖 6. 測試網(wǎng)頁效果
可以看到，網(wǎng)頁只顯示工具選擇的“綠色大拇指”部分，這樣的代碼可以運用在網(wǎng)頁的多個部分，而圖片只需要下載一次，這就是該技術的最大優(yōu)勢，減少了因為小圖片引起的多個請求。
有時候，圖片數(shù)據(jù)太多，一些公司的解決方法是將圖片數(shù)據(jù)分到多個域名的服務器上，這在一方面是將服務器的請求壓力分到多個硬件服務器上。另一方面，是利用了瀏覽器的特性。一般來說，瀏覽器對于相同域名的圖片，最多用 2-4 個線程并行下載。不同瀏覽器的并發(fā)下載數(shù)，都是不同的，并發(fā)數(shù)如下清單所示。
清單 3. 各瀏覽器的并發(fā)下載數(shù)
Browsers HTTP/1.1 HTTP/1.0 IE6,7 2 4 IE8 6 6 FireFox 2 2 8 FireFox 3 6 6 Safari 3,4 4 4 Chrome 1,2 6 ? Chrome 3 4 4 Opera 9.63,10.00alpha 4 4 |
而相同域名的其他圖片，則要等到其他圖片下載完后才會開始下載。 這里我做了一個測試，選擇了多個相同域名的圖片在同一網(wǎng)頁上。代碼如清單 5 所示。
清單 4. 單域名的多圖片下載
<html> <body> <img src="http://img1./news/pics/hv1/123/231/804/52339128.jpg"><br> <img src="http://img1./news/pics/hv1/87/235/804/52340112.jpg"><br> <img src="http://img1./finance/pics/hv1/41/119/804/52310486.jpg"><br> <img src="http://img1./sports/pics/hv1/246/198/804/52330836.jpg"><br> <img src="http://img1./ent/pics/hv1/101/54/805/52358996.jpg"><br> <img src="http://img1./blog/pics/hv1/169/226/804/52337899.jpg"> </body> </html> |
接下來，使用 FireFox 的 Firebug 插件監(jiān)控網(wǎng)絡。結(jié)果如下圖所示。
圖 7. 單域名多圖片的監(jiān)控效果
可以看到，相同域名的多張圖片，它們下載的起始點是存在延遲的。它們并不是并行下載。當我們將其中的 3 張圖片換成別的域名圖片。如清單 6 所示。
清單 5. 多域名多圖片下載
<html> <body> <img src="http://img1./news/pics/hv1/123/231/804/52339128.jpg"><br> <img src="http://img1./news/pics/hv1/87/235/804/52340112.jpg"><br> <img src="http://img1./finance/pics/hv1/41/119/804/52310486.jpg"><br> <img src="http://i0./20110624/64a_2ee7d710_2ec6_b38d_b678_dc3af28392be_1.jpg"><br> <img src="http://i0./20110624/3b0_643eaea5_1233_b543_82b7_9c7273c7f97c_1.jpg"><br> <img src="http://i0./20110623/962_fa6e8a78_625a_1234_147f_3a627fe17033_1.jpg"> </body> </html> |
再次查看網(wǎng)絡監(jiān)控，可以看到，這些圖片是并行下載的。
圖 8. 多域名多圖片測試結(jié)果
多域名的下載固然很好，但是太多域名并不太好，一般在 2-3 個域名下載就差不多。
不管如何，圖片的下載始終都要向服務器發(fā)出請求，要是圖片的下載不用向服務器發(fā)出請求，而可以隨著 HTML 的下載同時下載到本地那就太好了。而目前，瀏覽器已經(jīng)支持了該特性，我們可以將圖片數(shù)據(jù)編碼成 BASE64 的字符串，使用該字符串代替圖像地址。假設用 S代表這個 BASE64 字符串，那么就可以使用 <img src="data:image/png;base64,S"> 來顯示這個圖像?？梢钥闯觯瑘D像的數(shù)據(jù)包含在了 HTML 代碼里，無需再次訪問服務器。那么圖像要如何編碼成 BASE64 字符串呢？可以使用 在線的工具---“Base64 Online”，這個工具可以上傳圖片將圖片轉(zhuǎn)換為 BASE64 字符串。當然，如果讀者有興趣，完全可以自己實現(xiàn)一個 BASE64 編碼工具，比如使用 Java 開發(fā)，它的代碼就如清單 7 所示。
清單 6. BASE64 的 Java 代碼
public static String getPicBASE64(String picPath) {
String content = null;
try {
FileInputStream fis = new FileInputStream(picPath);
byte[] bytes = new byte[fis.available()];
fis.read(bytes);
content = new sun.misc.BASE64Encoder().encode(bytes); // 具體的編碼方法
fis.close();
} catch (Exception e) {
e.printStackTrace();
}
return content;
}
|
本文編碼了一個圖像，并且將編碼獲得的 BASE64 字符串，寫到了 HTML 之中，如下清單 8 所示。
清單 7. 嵌入 BASE64 的測試 HTML 代碼
<html> <body> <img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAeQAAAB8BAMAAABKwt5QAAAAA3NCSVQICAjb4U/gAAAAGFBMVEX/ ……（省略了大部分編碼）… BJRU5ErkJggg=="> </body> </html> |
由于圖片數(shù)據(jù)包含在了 BASE64 字符串中，因此無需向服務器請求圖像數(shù)據(jù)，結(jié)果顯示如下圖所示。
圖 9. BASE64 顯示圖像
然而這種策略并不能濫用，它適用的情況是瀏覽器連接服務器的時間 > 圖片下載時間，也就是發(fā)起連接的代價要大于圖片下載，那么這個時候?qū)D片編碼為 BASE64 字符串，就可以避免連接的建立，提高效率。如果圖片較大的話，使用 BASE64 編碼雖然可以避免連接建立，但是相對于圖像下載，請求的建立只占很小的比例，如果用 BASE64，對于動態(tài)網(wǎng)頁來說圖像緩存就會失效（靜態(tài)網(wǎng)頁可以緩存），而且 BASE64 字符串的總大小要大于純圖片的大小，這樣一算就非常不合適了。因此，如果你的頁面已經(jīng)靜態(tài)化，圖像又不是非常大，可以嘗試 BASE64 編碼，客戶端會將網(wǎng)頁內(nèi)容和圖片的 BASE64 編碼一起緩存；而如果你的頁面是動態(tài)頁面，圖像還較大，每次都要下載 BASE64 字符串，那么就不能用 BASE64 編碼圖像，而正常引用圖像，從而使用到瀏覽器的圖像緩存，提高下載速度。從現(xiàn)實我們接觸的角度看，如一些在線 HTML 編輯器，里面的小圖標，如笑臉等，都使用到了 BASE64 編碼，因為它們非常小，數(shù)量多，BASE64 可以幫助網(wǎng)頁減少圖標的請求數(shù)，提高效率。
為了減少傳輸?shù)臄?shù)據(jù)，壓縮是一個不錯的選擇，而 HTTP 協(xié)議支持 GZIP 的壓縮格式，服務器響應的報頭包含 Content-Encoding: gzip，它告訴瀏覽器，這個響應的返回數(shù)據(jù)，已經(jīng)壓縮成 GZIP 格式，瀏覽器獲得數(shù)據(jù)后要進行解壓縮操作。這在一定程度可以減少服務器傳輸?shù)臄?shù)據(jù)，提高系統(tǒng)性能。那么如何給服務器響應添加 Content-Encoding: gzip 報頭，同時壓縮響應數(shù)據(jù)呢？如果你用的是 Tomcat 服務器，打開 $tomcat_home$/conf/server.xml 文件，對 Connector 進行配置，配置如清單 9 所示。
清單 8. TOMCAT 配置清單
<Connector port ="80" maxHttpHeaderSize ="8192" maxThreads ="150" minSpareThreads ="25" maxSpareThreads ="75" enableLookups ="false" redirectPort ="8443" acceptCount ="100" connectionTimeout ="20000" disableUploadTimeout ="true" URIEncoding ="utf-8" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml" /> |
我們?yōu)?Connector 添加了如下幾個屬性，他們意義分別是：
compression="on" 打開壓縮功能
compressionMinSize="2048" 啟用壓縮的輸出內(nèi)容大小，這里面默認為 2KB
noCompressionUserAgents="gozilla, traviata" 對于以下的瀏覽器，不啟用壓縮
compressableMimeType="text/html,text/xml, image/png" 壓縮類型
有時候，我們無法配置 server.xml，比如如果我們只是租用了別人的空間，但是它并沒有啟用 GZIP，那么我們就要使用程序啟用 GZIP 功能。我們將需要壓縮的文件，放到指定的文件夾，使用一個過濾器，過濾對這個文件夾里文件的請求。
清單 9. 自定義 Filter 壓縮 GZIP
// 監(jiān)視對 gzipCategory 文件夾的請求
@WebFilter(urlPatterns = { "/gzipCategory/*" })
public class GZIPFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
String parameter = request.getParameter("gzip");
// 判斷是否包含了 Accept-Encoding 請求頭部
HttpServletRequest s = (HttpServletRequest)request;
String header = s.getHeader("Accept-Encoding");
//"1".equals(parameter) 只是為了控制，如果傳入 gzip=1，才執(zhí)行壓縮，目的是測試用
if ("1".equals(parameter) && header != null && header.toLowerCase().contains("gzip")) {
HttpServletResponse resp = (HttpServletResponse) response;
final ByteArrayOutputStream buffer = new ByteArrayOutputStream();
HttpServletResponseWrapper hsrw = new HttpServletResponseWrapper(
resp) {
@Override
public PrintWriter getWriter() throws IOException {
return new PrintWriter(new OutputStreamWriter(buffer,
getCharacterEncoding()));
}
@Override
public ServletOutputStream getOutputStream() throws IOException {
return new ServletOutputStream() {
@Override
public void write(int b) throws IOException {
buffer.write(b);
}
};
}
};
chain.doFilter(request, hsrw);
byte[] gzipData = gzip(buffer.toByteArray());
resp.addHeader("Content-Encoding", "gzip");
resp.setContentLength(gzipData.length);
ServletOutputStream output = response.getOutputStream();
output.write(gzipData);
output.flush();
} else {
chain.doFilter(request, response);
}
}
// 用 GZIP 壓縮字節(jié)數(shù)組
private byte[] gzip(byte[] data) {
ByteArrayOutputStream byteOutput = new ByteArrayOutputStream(10240);
GZIPOutputStream output = null;
try {
output = new GZIPOutputStream(byteOutput);
output.write(data);
} catch (IOException e) {
} finally {
try {
output.close();
} catch (IOException e) {
}
}
return byteOutput.toByteArray();
}
……
}
|
該程序的主體思想，是在響應流寫回之前，對響應的字節(jié)數(shù)據(jù)進行 GZIP 壓縮，因為并不是所有的瀏覽器都支持 GZIP 解壓縮，如果瀏覽器支持 GZIP 解壓縮，會在請求報頭的 Accept-Encoding 里包含 gzip。這是告訴服務器瀏覽器支持 GZIP 解壓縮，因此如果用程序控制壓縮，為了保險起見，還需要判斷瀏覽器是否發(fā)送 accept-encoding: gzip 報頭，如果包含了該報頭，才執(zhí)行壓縮。為了驗證壓縮前后的情況，使用 Firebug 監(jiān)控請求和響應報頭。
清單 10. 壓縮前請求
GET /testProject/gzipCategory/test.html HTTP/1.1 Accept: */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: localhost:9090 Connection: Keep-Alive |
清單 11. 不壓縮的響應
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/"5060-1242444154000" Last-Modified: Sat, 16 May 2009 03:22:34 GMT Content-Type: text/html Content-Length: 5060 Date: Mon, 18 May 2009 12:29:49 GMT |
清單 12. 壓縮后的響應
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/"5060-1242444154000" Last-Modified: Sat, 16 May 2009 03:22:34 GMT Content-Encoding: gzip Content-Type: text/html Content-Length: 837 Date: Mon, 18 May 2009 12:27:33 GMT |
可以看到，壓縮后的數(shù)據(jù)比壓縮前數(shù)據(jù)小了很多。壓縮后的響應報頭包含 Content-Encoding: gzip。同時 Content-Length 包含了返回數(shù)據(jù)的大小。GZIP 壓縮是一個重要的功能，前面提到的是對單一服務器的壓縮優(yōu)化，在高并發(fā)的情況，多個 Tomcat 服務器之前，需要采用反向代理的技術，提高并發(fā)度，而目前比較火的反向代理是 Nginx（這在后續(xù)的文章會進行詳細的介紹）。對 Nginx 的 HTTP 配置部分里增加如下配置。
清單 13. Nginx 的 GZIP 配置
gzip on; gzip_min_length 1000; gzip_buffers 4 8k; gzip_types text/plain application/x-javascript text/css text/html application/xml; |
由于 Nginx 具有更高的性能，利用該配置可以更好的提高性能。在高性能服務器上該配置將非常有用。
預加載和懶加載，是一種改善用戶體驗的策略，它實際上并不能提高程序性能，但是卻可以明顯改善用戶體驗或減輕服務器壓力。
預加載原理是在用戶查看一張圖片時，就將下一張圖片先下載到本地，而當用戶真正訪問下一張圖片時，由于本地緩存的原因，無需從服務器端下載，從而達到提高用戶體驗的目的。為了實現(xiàn)預加載，我們可以實現(xiàn)如下的一個函數(shù)。
清單 14. 預加載函數(shù)
function preload(callback) {
var imageObj = new Image();
images = new Array();
images[0]="pre_image1.jpg";
images[1]=" pre_image2.jpg";
images[2]=" pre_image3.jpg";
for(var i=0; i<=2; i++) {
imageObj.src=images[i];
if (imageObj.complete) { // 如果圖片已經(jīng)存在于瀏覽器緩存，直接調(diào)用回調(diào)函數(shù)
callback.call(imageObj);
} else {
imageObj.onload = function () {// 圖片下載完畢時異步調(diào)用 callback 函數(shù)
callback.call(imageObj);// 將回調(diào)函數(shù)的 this 替換為 Image 對象
};
}
}
}
function callback()
{
alert(this.src + “已經(jīng)加載完畢 , 可以在這里繼續(xù)預加載下一組圖片”);
}
|
上面的代碼，首先定義了 Image 對象，并且聲明了需要預加載的圖像數(shù)組，然后逐一的開始加載（.src=images[i]）。如果已經(jīng)在緩存里，則不做其他處理；如果不在緩存，監(jiān)聽 onload 事件，它會在圖片加載完畢時調(diào)用。
而懶加載則是在用戶需要的時候再加載。當一個網(wǎng)頁中可能同時有上百張圖片，而大部分情況下，用戶只看其中的一部分，如果同時顯示上百張，則浪費了大量帶寬資源，因此可以當用戶往下拉動滾動條時，才去請求下載被查看的圖像，這個原理與 word 的顯示策略非常類似。
在 JavaScript 中，它的基本原理是首先要有一個容器對象，容器里面是 img 元素集合。用隱藏或替換等方法，停止 img 的加載，也就是停止它去下載圖像。然后歷遍 img 元素，當元素在加載范圍內(nèi)，再進行加載（也就是顯示或插入 img 標簽）。加載范圍一般是容器的視框范圍，即瀏覽者的視覺范圍內(nèi)。當容器滾動或大小改變時，再重新歷遍元素判斷。如此重復，直到所有元素都加載后就完成。當然對于開發(fā)來講，選擇已有的成熟組件，并不失為一個上策，Lazy Load Plugin for jQuery 是基于 JQuery 的懶加載組件，它有自己的 官方網(wǎng)站。這是一個不錯的免費插件?？梢詭椭绦騿T快速的開發(fā)懶加載應用。
本文總結(jié)了前端圖片高性能優(yōu)化的幾種方式，將它們歸結(jié)起來，在讀者需要的時候，可以查看本文的內(nèi)容，相信按照本文的方法，可以輔助讀者進行前端的高性能優(yōu)化。筆者將繼續(xù)寫后續(xù)的部分，包括數(shù)據(jù)庫的優(yōu)化、負載均衡、反向代理等。包括由于筆者水平有限，如有錯誤，請聯(lián)系我批評指正。
接下來在第二部分文章中，我將介紹前端的 BigPipe 技術、Flush 機制、動靜分離、HTTP 持久連接、HTTP 協(xié)議靈活應用、靜態(tài)化與偽靜態(tài)化、頁面緩存（整體、部分）等，并且將它們應用到 Java Web 的開發(fā)中。使用這些技術可以幫助提高 Java Web 應用程序的性能。
學習
- 參考“CSS Sprites 圖片切割術與圖片優(yōu)化”，具體了解 CSS Sprites 圖片切割術與圖片優(yōu)化的技術。
- 了解 “GZIP 壓縮詳解”，了解 GZIP 壓縮的詳細原理。
- 查看“深入理解 HTTP 協(xié)議”，了解 HTTP 協(xié)議，更加理解 HTTP 的含義。
- 查看“CSS Sprite”，了解 CSS Sprite 的發(fā)源和原理。
- 查看“當前瀏覽器的并行下載數(shù)”，查看瀏覽器的并行下載數(shù)。
- 查看“淺談 BASE64”，了解 BASE64 的基本原理。
- 查看“預加載與懶加載”，大致了解預加載與懶加載的原理和概念。
- developerWorks Web development 專區(qū)：通過專門關于 Web 技術的文章和教程，擴展您在網(wǎng)站開發(fā)方面的技能。
- developerWorks Ajax 資源中心：這是有關 Ajax 編程模型信息的一站式中心，包括很多文檔、教程、論壇、blog、wiki 和新聞。任何 Ajax 的新信息都能在這里找到。
- developerWorks Web 2.0 資源中心，這是有關 Web 2.0 相關信息的一站式中心，包括大量 Web 2.0 技術文章、教程、下載和相關技術資源。您還可以通過 Web 2.0 新手入門 欄目，迅速了解 Web 2.0 的相關概念。
- 查看 HTML5 專題，了解更多和 HTML5 相關的知識和動向。
討論
- 加入 developerWorks 中文社區(qū)。查看開發(fā)人員推動的博客、論壇、組和維基，并與其他 developerWorks 用戶交流。
為本文評分
平均分 (74個評分)
