Java Web 高性能開發，第 1 部分: 前端的高性能
Web 發展的速度讓許多人歎爲觀止，層出不窮的組件、技術，只需要合理的組合、恰當的設置，就可以讓 Web 程序性能不斷飛躍。所有 Web 的思想都是通用的，它們也可以運用到 Java Web。這一系列的文章，將從各個角度，包括前端高性能、反向代理、數據庫高性能、負載均衡等等，以 Java Web 爲背景進行講述，同時用實際的工具、實際的數據來對比被優化前後的 Java Web 程序。第一部分 , 主要講解網頁前端的性能優化，這一部分是最直接與用戶接觸的。事實證明，與其消耗大量時間在服務器端，在前端進行的優化更易獲得用戶的肯定。
12
評論：
引言
前端的高性能部分，主要是指減少請求數、減少傳輸的數據以及提高用戶體驗，在這個部分，圖片的優化顯得至關重要。許多網站的美化，都是靠絢麗的圖片達到的，圖片恰恰是佔用帶寬的元兇。每個 img 標籤，瀏覽器都會試圖發起一個下載請求。本文就詳細介紹了圖片優化的幾種方式，介紹了使用的工具以及優化後的結果。
圖片壓縮
減少圖片的大小，可以明顯的提高性能，而對於已有圖片，要想減少圖片的大小，只能改變圖片的格式，這裏推薦的是 PNG8 的格式，它可以在基本保持清晰度的情況下，減少圖片的大小。知道這個原理以後，可以用 Windows 的畫圖工具、以及 PhotoShop 工具逐個的改變。但是這樣做的缺點是單張處理，效率太慢。本文推薦一個在線轉換工具 Smush.it，可以批量的進行壓縮與轉換。它的地址是：www.smushit.com/ysmush.it。打開後效果如下圖所示。
圖 1. Yahoo 提供的在線壓縮工具
我們上傳了一張大小爲 3790K 的圖片，待在線程序處理完畢後，點擊 Download Smushed Images 下載查看結果。下載界面如下圖所示。
圖 2. 壓縮後的結果
打開下載下來的壓縮包，查看結果可以看到，圖片從 3790 減少到了 3344，就如下圖所示。對於大批量的圖片網站，這個方法會幫助快速實現批量圖片壓縮。
圖 3. 壓縮後的結果
圖像合併實現 CSS Sprites
CSS Sprites 是一個吸引人的技術，它其實就是把網頁中一些背景圖片整合到一張圖片文件中，再利用 CSS 的“background-image”，“background- repeat”，“background-position”的組合進行背景定位，background-position 可以用數字能精確的定位出背景圖片的位置。利用 CSS Sprites 能很好地減少網頁的 HTTP 請求，從而大大的提高了頁面的性能，這也是 CSS Sprites 最大的優點，也是其被廣泛傳播和應用的主要原因。CSS Sprites 能減少圖片的字節，由於圖像合併後基本信息不用重複，那麼多張圖片合併成 1 張圖片的字節往往總是小於這些圖片的字節總和。同時 CSS Sprites 解決了網頁設計師在圖片命名上的困擾，只需對一張集合的圖片上命名就可以了，不需要對每一個小元素進行命名，從而提高了網頁的製作效率。更換風格方便，只需要在一張或少張圖片上修改圖片的顏色或樣式，整個網頁的風格就可以改變。維護起來更加方便。同時，由於將圖片合併到一張圖片，因此圖片的請求數就被縮減到 1 個。其他的請求都可以用到本地緩存，不需要訪問服務器。下圖是一個合併以後的圖片。它將很多小圖標都拼到了一起。
圖 4. 合併後的圖片
這裏介紹一個小工具 ---“CSS Sprites 樣式生成工具 2.0”，可以從 這裏下載。這是一個簡單免費的小工具，用該工具打開上面的圖片，選中圖片中的某塊。如下圖的“綠色大拇指”部分，工具會計算出這個部分的長、寬、距離左上角的距離。勾選複製類名、複製寬、複製高，再點擊“複製當前樣式”按鈕。這樣生成的樣式會被複制到剪切板上。
圖 5. 小工具的使用
生成的 CSS 代碼如清單 1 所示。
清單 1. 小工具生成的 CSS 代碼
.div_6148{width:18px;height:20px;background-position:-17px -209px;}
將這段代碼運用在網頁上，它的代碼如下清單所示。
清單 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>
打開測試網頁顯示結果如下圖所示。
圖 6. 測試網頁效果
可以看到，網頁只顯示工具選擇的“綠色大拇指”部分，這樣的代碼可以運用在網頁的多個部分，而圖片只需要下載一次，這就是該技術的最大優勢，減少了因爲小圖片引起的多個請求。
多域名請求
有時候，圖片數據太多，一些公司的解決方法是將圖片數據分到多個域名的服務器上，這在一方面是將服務器的請求壓力分到多個硬件服務器上。另一方面，是利用了瀏覽器的特性。一般來說，瀏覽器對於相同域名的圖片，最多用 2-4 個線程並行下載。不同瀏覽器的併發下載數，都是不同的，併發數如下清單所示。
清單 3. 各瀏覽器的併發下載數
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
而相同域名的其他圖片，則要等到其他圖片下載完後纔會開始下載。 這裏我做了一個測試，選擇了多個相同域名的圖片在同一網頁上。代碼如清單 5 所示。
清單 4. 單域名的多圖片下載
<html> <body> <img src="http://img1.gtimg.com/news/pics/hv1/123/231/804/52339128.jpg"><br> <img src="http://img1.gtimg.com/news/pics/hv1/87/235/804/52340112.jpg"><br> <img src="http://img1.gtimg.com/finance/pics/hv1/41/119/804/52310486.jpg"><br> <img src="http://img1.gtimg.com/sports/pics/hv1/246/198/804/52330836.jpg"><br> <img src="http://img1.gtimg.com/ent/pics/hv1/101/54/805/52358996.jpg"><br> <img src="http://img1.gtimg.com/blog/pics/hv1/169/226/804/52337899.jpg"> </body> </html>
接下來，使用 FireFox 的 Firebug 插件監控網絡。結果如下圖所示。
圖 7. 單域名多圖片的監控效果
可以看到，相同域名的多張圖片，它們下載的起始點是存在延遲的。它們並不是並行下載。當我們將其中的 3 張圖片換成別的域名圖片。如清單 6 所示。
清單 5. 多域名多圖片下載
<html> <body> <img src="http://img1.gtimg.com/news/pics/hv1/123/231/804/52339128.jpg"><br> <img src="http://img1.gtimg.com/news/pics/hv1/87/235/804/52340112.jpg"><br> <img src="http://img1.gtimg.com/finance/pics/hv1/41/119/804/52310486.jpg"><br> <img src="http://i0.itc.cn/20110624/64a_2ee7d710_2ec6_b38d_b678_dc3af28392be_1.jpg"><br> <img src="http://i0.itc.cn/20110624/3b0_643eaea5_1233_b543_82b7_9c7273c7f97c_1.jpg"><br> <img src="http://i0.itc.cn/20110623/962_fa6e8a78_625a_1234_147f_3a627fe17033_1.jpg"> </body> </html>
再次查看網絡監控，可以看到，這些圖片是並行下載的。
圖 8. 多域名多圖片測試結果
多域名的下載固然很好，但是太多域名並不太好，一般在 2-3 個域名下載就差不多。
圖像的 BASE64 編碼
不管如何，圖片的下載始終都要向服務器發出請求，要是圖片的下載不用向服務器發出請求，而可以隨着 HTML 的下載同時下載到本地那就太好了。而目前，瀏覽器已經支持了該特性，我們可以將圖片數據編碼成 BASE64 的字符串，使用該字符串代替圖像地址。假設用 S代表這個 BASE64 字符串，那麼就可以使用 <img src="data:image/png;base64,S"> 來顯示這個圖像。可以看出，圖像的數據包含在了 HTML 代碼裏，無需再次訪問服務器。那麼圖像要如何編碼成 BASE64 字符串呢？可以使用 在線的工具---“Base64 Online”，這個工具可以上傳圖片將圖片轉換爲 BASE64 字符串。當然，如果讀者有興趣，完全可以自己實現一個 BASE64 編碼工具，比如使用 Java 開發，它的代碼就如清單 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>
由於圖片數據包含在了 BASE64 字符串中，因此無需向服務器請求圖像數據，結果顯示如下圖所示。
圖 9. BASE64 顯示圖像
然而這種策略並不能濫用，它適用的情況是瀏覽器連接服務器的時間 > 圖片下載時間，也就是發起連接的代價要大於圖片下載，那麼這個時候將圖片編碼爲 BASE64 字符串，就可以避免連接的建立，提高效率。如果圖片較大的話，使用 BASE64 編碼雖然可以避免連接建立，但是相對於圖像下載，請求的建立只佔很小的比例，如果用 BASE64，對於動態網頁來說圖像緩存就會失效（靜態網頁可以緩存），而且 BASE64 字符串的總大小要大於純圖片的大小，這樣一算就非常不合適了。因此，如果你的頁面已經靜態化，圖像又不是非常大，可以嘗試 BASE64 編碼，客戶端會將網頁內容和圖片的 BASE64 編碼一起緩存；而如果你的頁面是動態頁面，圖像還較大，每次都要下載 BASE64 字符串，那麼就不能用 BASE64 編碼圖像，而正常引用圖像，從而使用到瀏覽器的圖像緩存，提高下載速度。從現實我們接觸的角度看，如一些在線 HTML 編輯器，裏面的小圖標，如笑臉等，都使用到了 BASE64 編碼，因爲它們非常小，數量多，BASE64 可以幫助網頁減少圖標的請求數，提高效率。
GZIP 壓縮
爲了減少傳輸的數據，壓縮是一個不錯的選擇，而 HTTP 協議支持 GZIP 的壓縮格式，服務器響應的報頭包含 Content-Encoding: gzip，它告訴瀏覽器，這個響應的返回數據，已經壓縮成 GZIP 格式，瀏覽器獲得數據後要進行解壓縮操作。這在一定程度可以減少服務器傳輸的數據，提高系統性能。那麼如何給服務器響應添加 Content-Encoding: gzip 報頭，同時壓縮響應數據呢？如果你用的是 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" />
我們爲 Connector 添加了如下幾個屬性，他們意義分別是：
compression="on" 打開壓縮功能
compressionMinSize="2048" 啓用壓縮的輸出內容大小，這裏面默認爲 2KB
noCompressionUserAgents="gozilla, traviata" 對於以下的瀏覽器，不啓用壓縮
compressableMimeType="text/html,text/xml, image/png" 壓縮類型
有時候，我們無法配置 server.xml，比如如果我們只是租用了別人的空間，但是它並沒有啓用 GZIP，那麼我們就要使用程序啓用 GZIP 功能。我們將需要壓縮的文件，放到指定的文件夾，使用一個過濾器，過濾對這個文件夾裏文件的請求。
清單 9. 自定義 Filter 壓縮 GZIP
// 監視對 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，才執行壓縮，目的是測試用
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 壓縮字節數組
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();
}
……
}
該程序的主體思想，是在響應流寫回之前，對響應的字節數據進行 GZIP 壓縮，因爲並不是所有的瀏覽器都支持 GZIP 解壓縮，如果瀏覽器支持 GZIP 解壓縮，會在請求報頭的 Accept-Encoding 裏包含 gzip。這是告訴服務器瀏覽器支持 GZIP 解壓縮，因此如果用程序控制壓縮，爲了保險起見，還需要判斷瀏覽器是否發送 accept-encoding: gzip 報頭，如果包含了該報頭，才執行壓縮。爲了驗證壓縮前後的情況，使用 Firebug 監控請求和響應報頭。
清單 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
可以看到，壓縮後的數據比壓縮前數據小了很多。壓縮後的響應報頭包含 Content-Encoding: gzip。同時 Content-Length 包含了返回數據的大小。GZIP 壓縮是一個重要的功能，前面提到的是對單一服務器的壓縮優化，在高併發的情況，多個 Tomcat 服務器之前，需要採用反向代理的技術，提高併發度，而目前比較火的反向代理是 Nginx（這在後續的文章會進行詳細的介紹）。對 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 具有更高的性能，利用該配置可以更好的提高性能。在高性能服務器上該配置將非常有用。
懶加載與預加載
預加載和懶加載，是一種改善用戶體驗的策略，它實際上並不能提高程序性能，但是卻可以明顯改善用戶體驗或減輕服務器壓力。
預加載原理是在用戶查看一張圖片時，就將下一張圖片先下載到本地，而當用戶真正訪問下一張圖片時，由於本地緩存的原因，無需從服務器端下載，從而達到提高用戶體驗的目的。爲了實現預加載，我們可以實現如下的一個函數。
清單 14. 預加載函數
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) { // 如果圖片已經存在於瀏覽器緩存，直接調用回調函數
callback.call(imageObj);
} else {
imageObj.onload = function () {// 圖片下載完畢時異步調用 callback 函數
callback.call(imageObj);// 將回調函數的 this 替換爲 Image 對象
};
}
}
}
function callback()
{
alert(this.src + “已經加載完畢 , 可以在這裏繼續預加載下一組圖片”);
}
上面的代碼，首先定義了 Image 對象，並且聲明瞭需要預加載的圖像數組，然後逐一的開始加載（.src=images[i]）。如果已經在緩存裏，則不做其他處理；如果不在緩存，監聽 onload 事件，它會在圖片加載完畢時調用。
而懶加載則是在用戶需要的時候再加載。當一個網頁中可能同時有上百張圖片，而大部分情況下，用戶只看其中的一部分，如果同時顯示上百張，則浪費了大量帶寬資源，因此可以當用戶往下拉動滾動條時，纔去請求下載被查看的圖像，這個原理與 word 的顯示策略非常類似。
在 JavaScript 中，它的基本原理是首先要有一個容器對象，容器裏面是 img 元素集合。用隱藏或替換等方法，停止 img 的加載，也就是停止它去下載圖像。然後歷遍 img 元素，當元素在加載範圍內，再進行加載（也就是顯示或插入 img 標籤）。加載範圍一般是容器的視框範圍，即瀏覽者的視覺範圍內。當容器滾動或大小改變時，再重新曆遍元素判斷。如此重複，直到所有元素都加載後就完成。當然對於開發來講，選擇已有的成熟組件，並不失爲一個上策，Lazy Load Plugin for jQuery 是基於 JQuery 的懶加載組件，它有自己的 官方網站。這是一個不錯的免費插件。可以幫助程序員快速的開發懶加載應用。
小結
本文總結了前端圖片高性能優化的幾種方式，將它們歸結起來，在讀者需要的時候，可以查看本文的內容，相信按照本文的方法，可以輔助讀者進行前端的高性能優化。筆者將繼續寫後續的部分，包括數據庫的優化、負載均衡、反向代理等。包括由於筆者水平有限，如有錯誤，請聯繫我批評指正。
接下來在第二部分文章中，我將介紹前端的 BigPipe 技術、Flush 機制、動靜分離、HTTP 持久連接、HTTP 協議靈活應用、靜態化與僞靜態化、頁面緩存（整體、部分）等，並且將它們應用到 Java Web 的開發中。使用這些技術可以幫助提高 Java Web 應用程序的性能。