當(dāng)我最近在HotBot工作并試圖加速我的網(wǎng)頁時，我花了很多時間查看其它網(wǎng)站，想從他們的成功和失敗中學(xué)點什么。我學(xué)到很多如何使頁面裝載和繪制很快的方法，但是也發(fā)現(xiàn)非常多的沒有必要的臃腫的東西。

　　基于我所發(fā)現(xiàn)的和沒有發(fā)現(xiàn)的，我總結(jié)了一些使網(wǎng)頁緊縮的方法。既然你已經(jīng)使你的圖像和表格盡可能地苗條，現(xiàn)在讓我們看看優(yōu)化網(wǎng)站的最后一關(guān)。

　　與松弛做斗爭的最后防線我理解找到完美方法實現(xiàn)好的設(shè)計使廣告商高興和每個頁面可用是多么的困難。但是我希望設(shè)計者最好避免海嘯般的連接。

　　很多出版商（如ZDNet和CNET）因為連接太多而使網(wǎng)頁阻塞-每頁上都有大量指向其它頁和其它網(wǎng)站的連接。我甚至在我們自己的后院發(fā)現(xiàn)了同樣的問題（或者是不是可以說我們的前門？）。

　　這樣的交叉連接通常是考慮到市場的原因：讓讀者知道同一公司的其它內(nèi)容和站點。但是你也不必象一個人類問題專家那樣認(rèn)為網(wǎng)頁上連接越多，單個連接被訪問的機會越少。經(jīng)過10個左右連接后，讀者趨向于只讀頁中間的文章。這些未讀、未被接觸的“連接農(nóng)場”可以占到網(wǎng)頁HTML的一半。并且，不象logo和icon駐留在cache里，調(diào)用每頁時，它們重新下載。

　　這些連接背后的長URL的累加也很可觀。AltaVista為附加查詢結(jié)果頁的“1 2 3 … 20”（在每個查詢結(jié)果頁的底部）連接就要浪費4KB的HTML。通過實現(xiàn)更短、更少的URL，最近AltaVista重新進行了設(shè)計，把連接的尺寸平均減少到1KB。結(jié)果是，通過撥號modem的頁面下載速度明顯提高（就金錢和常識來說，意味著客戶更愉悅，每分鐘的頁面點擊率越多）。

　　一些同樣的網(wǎng)站也為放入大量的交叉連接感到內(nèi)疚。有時他們故意這么做來增加頁面點擊率，但是通?？梢约右粋€附加的頁來容納其它用戶感興趣的內(nèi)容。

　　如果你不想讓讀者下載他們不需要的字節(jié)，同時又不希望他們退回去重新下載讀過的頁面，那么你知道他們無論如何也要一頁。所以要研究你的服務(wù)器日志，發(fā)現(xiàn)用戶點擊最多和最少的是什么。刪掉沒人讀的內(nèi)容，把它們替換為日志數(shù)據(jù)證明有必要的信息。

　　把JavaScript/” target=”_blank”>JavaScript當(dāng)作垃圾

　　很多網(wǎng)猴認(rèn)為頁面中的JavaScript/” target=”_blank”>JavaScript不使頁面變慢。然而，JavaScript/” target=”_blank”>JavaScript是一種解釋語言，而不是編譯語言-這意味著它被裝載后還要被分析。我們習(xí)慣于在HotBot中使用JavaScript/” target=”_blank”>JavaScript函數(shù)使瀏覽者的鍵盤輸入聚焦到文本輸入框內(nèi)。這樣 桓齪??掛趁嫻淖霸孛饗員瀆??詞顧?某踔允俏?思鈾儼檠??

　　檢查你頁面中的JavaScript/” target=”_blank”>JavaScript，看看它是如何影響裝載和初始化時間的。如果你用JavaScript/” target=”_blank”>JavaScript控制plug-in或dHTML，應(yīng)該查看用戶手冊看看這些組件是如何使用的。你可能會發(fā)現(xiàn)你的20行的JavaScript/” target=”_blank”>JavaScript程序可以用一個內(nèi)置的裝載和運行更快的函數(shù)來替代。我們就犯過這樣的錯誤：我們用JavaScript/” target=”_blank”>JavaScript寫了一個“NextTen”函數(shù)來改變裝載到MSIE4的一個表中的內(nèi)容。后來我們知道IE的內(nèi)置nextPage函數(shù)比它快10倍，而且當(dāng)它運行時不會使頁面混亂。如果你的讀者遇到過這樣的麻煩，試試這個函數(shù)-對每個人都有利。

　　扔掉小技巧、計數(shù)器和其它活動的部分

　　坦白地說，關(guān)心你的網(wǎng)站的訪問人數(shù)的人不會很多（如果是一些令人印象很深的數(shù)字，可以在你的頁面中編碼，當(dāng)它突變時再更新之）。初始化Java并裝入一個applet只是使頁面中的一些文本滾動-這樣的頁面不值得去等。今年早些時候，CNN通過移去它的Java大字標(biāo)題把頁面裝載速度從50秒減少到20秒。

　　你是怎么想的？- CNN的點擊率和觀眾份額會增加還是減少？

　　測試你的網(wǎng)頁

　　在過去的四天里，我們?yōu)槟闾峁┝撕芏嗉铀倬W(wǎng)頁的方法。為了能讓用戶能有所體會，你需要為網(wǎng)頁制定一些行為標(biāo)準(zhǔn)并實行之。

　　制定你的標(biāo)準(zhǔn)

　　別只自問：“網(wǎng)頁現(xiàn)在有多快？”并試圖進行改善。應(yīng)該問“頁面應(yīng)該有多快？”?；蛘邷p少用戶的等待時間，或者讓用戶覺得他們的等待是值得的。

　　制定合理指導(dǎo)方針的最佳方法是檢查你的競爭對手的網(wǎng)站。查找與你的網(wǎng)站提供相同內(nèi)容、服務(wù)、價值等的網(wǎng)站，研究它們的表現(xiàn)。請教你們公司市場部、銷售部或其它部門的人，讓他們評價你的競爭對手的網(wǎng)站?？梢赃M行一次角色扮演：把你自己當(dāng)成一個用戶，進行一次網(wǎng)上漫游。

　　當(dāng)你確定了要查看哪些網(wǎng)站后，確定你要進行到哪里?；蛟S整個頁面裝載完，但是或許應(yīng)該確定某個特定條目的裝載時間（例如，一個新網(wǎng)站的頂部標(biāo)題）。我們研究過的一些站點非常好：

　　在頁面完成裝載之前，用戶可以看到一些很重要的東西。

　也許是布局頁面的理想方式，但是你將失去運行2.x和3.x瀏覽器的用戶。如果想得到一個真正跨瀏覽器、跨平臺的設(shè)計方案，還得用表格進行布局。

　　不是所有表格都那么壞。大多數(shù)設(shè)計者需要使用網(wǎng)格進行設(shè)計，所以使用表格就很自然。我們也很喜歡它們的二元性：表格既可以定義布局，又可以應(yīng)付頁面中不可預(yù)知的因素。作為一個設(shè)計者，既要處理不確定性，又要在你的設(shè)計和用戶的靈活性（例如，用戶要使字體變大）之間取得平衡。不幸的是，表格同時也增加了顯示頁面的時間，有時這樣的時間很長。

　　因為瀏覽器需要在填充表格的內(nèi)容之前完全理解表格的結(jié)構(gòu)，在大部分（如果不是全部）表格的內(nèi)容下載之前，瀏覽器什么也不能渲染。當(dāng)表格變大時，需要處理的信息將呈指數(shù)性增長。在先前的計算機上，這些處理性工作很不容易，表格渲染需要大量時間幸運的是，可以找到避免這些缺陷的方法。

　　快速表格的技巧處理表格使用表格時間長了，你會發(fā)現(xiàn)大量小表格渲染起來比一個有很多行的大表格快。至少看起來是這樣-真象那么回事（記?。菏歉杏X到的速度，而不是實際速度）。

　　如果你在用一個九行的表格（每個單元有很多信息），可以把它分成三個各有三行的小表格。如果你的網(wǎng)頁很長，這種策略特別有益-在后面的表格下載時用戶可以看前面的表格。

　　使用Width屬性為使你的HTML盡量對瀏覽器友好，應(yīng)該對$#@60;TABLE$#@62;和$#@60;TD$#@62;標(biāo)記適當(dāng)?shù)厥褂肳idth屬性。這種屬性允許你定義整個表格的寬度，也可以定義單元格的寬度。如果事情并沒有好起來，你應(yīng)該懷疑瀏覽器-是它的原因。所以只要檢查你是否算對了就行了- 如果你把一個單元格設(shè)為100個像素寬，可是卻把一個110個像素寬的圖像插入其中，結(jié)果是：表格暫時出現(xiàn)，然后當(dāng)重繪自己以便能容納圖像時又消失了。不用說，瀏覽器的這種過濾作用同它的慢速一樣令人討厭。

　　把窗體放在表格里不幸的是，不同的瀏覽器和操作系統(tǒng)對窗體元素的處理方式不同。Mac上的下拉菜單比Windows中的要寬很多。Netscape 4處理可寫的文本框和處理文本一樣，所以如果增加瀏覽器的缺省字體大小，所有的文本框都會變大。Netscape 4中的可寫文本框比其它瀏覽器中的寬20%，而且受字體標(biāo)記的影響。所以，總而言之，你的窗體 恍┯沒Э蠢椿岷芷婀?除非你有意支配它們。

看看下面的表格：

　　現(xiàn)在假設(shè)用戶增加了缺省字體的大小。當(dāng)表格放大以容納變大了的文字時，布局依然沒變。

不要相信所見即所得的編輯器

　　表格真令人痛苦，這就是為什么所見即所得的HTML編輯器流行起來的原因。但是，在這些編輯器使建表格變得容易的同時，它們也產(chǎn)生了一些令人吃驚的低效率的代碼。特別是GoLive的CyberStudio使用了一種產(chǎn)生夢魘般臃腫表格的布局系統(tǒng)（尤其當(dāng)你沒有認(rèn)真按用戶手冊操作時）。

　　所見即所得編輯器的布局和預(yù)覽窗口在處理不必要的嵌套表格、沒有設(shè)置合適大小的表格的列或奇怪的、轉(zhuǎn)彎抹角的HTML代碼時感到力不從心。因此，如果你希望你的表格盡可能地苗條和高效，同時又舍不得放棄所見即所得的編輯器，那么只好最后花些時間清理你的代碼。一旦所有內(nèi)容看起來都象那么回事，用文本編輯器打開HTML代碼看看，你會發(fā)現(xiàn)你的表格漂亮而且干凈。

要不要嵌套？

永遠(yuǎn)不要嵌套表格

　　使網(wǎng)頁讀起來很慢的首犯是嵌套的表格：即把表格放在另一個表格的單元格里。因為瀏覽器必須從里到外進行處理-在計算外層表格之前必須先估算內(nèi)層表格的大小-嵌套表格的表現(xiàn)真令人討厭。

　　所以盡量避免使用嵌套表格，即使意味著頁面布局會有一些小的變化。如果你不得不使用嵌套表格，至少應(yīng)保持被嵌套表格盡量簡單，而且，不要用三層嵌套。我們是在建網(wǎng)站，不是做俄羅斯娃娃。

除非……

　　嵌套表格：最后的禁忌。不過，簡單表格之間的嵌套的代碼會是簡單的幾行 – 瀏覽饗??鵠幢紉桓齔?陡叢擁謀碭窀?菀住?/p>

This is not that big a deal.

　　下面的西洋跳棋盤不涉及嵌套表格，但是由于它的復(fù)雜性，下載起來很慢。

　　通過使用嵌套表格，可以使問題簡單。結(jié)果相同，但是下載時間會縮短。

　　使用表格的關(guān)鍵是找到安排它們的最有效的方法。有時嵌套表格就是答案，有時卻不是。

結(jié)構(gòu)越好，頁面越快

　　下面是一個典型網(wǎng)頁的例子：商標(biāo)在頂部，導(dǎo)航在左邊，內(nèi)容在其余部分。對于這樣的頁，一般用一個大表格定義整個網(wǎng)格。在整個框架表格內(nèi)嵌套商標(biāo)、導(dǎo)航和內(nèi)容表格，使瀏覽器渲染起來很困難。

　　下面是相同的頁面結(jié)構(gòu)，只是商標(biāo)、導(dǎo)航和內(nèi)容分別定義在獨立的表格內(nèi)。

　　通過使每個表格獨立和簡潔，瀏覽器可以每讀完一個元素就渲染之。因此頁面的第一個元素最早出現(xiàn)，用戶可以馬上利用頁面最頂端的信息。

　　在上面的第二個例子里，商標(biāo)表格最早出現(xiàn)，然后是導(dǎo)航表格，然后是內(nèi)容表格。整個頁面下載很快，用戶馬上就有可以看到的東西。

　　和處理圖像一樣，使表格達到最佳效果需要試用不同的方案，直到找到令你和你的用戶都滿意的布局。你可能懷疑為了省幾秒鐘就要花費這么多的精力是否值得，但是隨著對用戶的爭奪越來越激烈，這些努力還是值得的。

　現(xiàn)在，我準(zhǔn)備講一講如何使這些網(wǎng)頁更苗條。

　　首先，頁面出現(xiàn)在網(wǎng)上時，有三種速度：

　　下載時間渲染時間可視性

　　用戶在做是進行下去還是退回的決定時，主要考慮這三種速度的整體效果。好的設(shè)計者需要找到平衡這三者的方法，進而產(chǎn)生理想的下載：從用戶點擊請求到下一頁出現(xiàn)只是一眨眼的瞬間。

　　記住：用戶的忍耐期限在存取頁面的第一秒就結(jié)束了，而不是在頁面完成渲染時。就用戶經(jīng)驗來說，確定渲染時間是很有學(xué)問的。我有一輛老車，我不在乎它的外觀和聲響。我想要的只是能用鑰匙打開車，加油，能開走。我的一位有錢的朋友有一輛Saab車，只用一分鐘就能達到顛峰速度。我的車要20分鐘預(yù)熱，但是我無所謂-引擎點著火時我用腳踩加速器，我只要駕駛就夠了，加速的事讓車自己去考慮吧！

　　我用攪拌器輪子的例子說明實際速度與感覺到的速度的重要區(qū)別。知道頁面要有一定時間渲染用戶才能看到，設(shè)計者可以從布局的觀點出發(fā)創(chuàng)建成功的頁面。當(dāng)瀏覽器窗口一片灰色，什么也不做時，只要用戶不問：“喂，到底頁面有多大？”，那么頁面還在工作。

　　我要向你展示我是如何增加頁面的可感覺的尺寸的。和Jason一樣，我也保持圖形和圖像的尺寸到最小。但是，不是簡單地減少圖像的顏色數(shù)，而是非常注意顏色的安排。

　　第一頁：網(wǎng)站優(yōu)化教程-第2天昨天Jason告訴第二頁：在一行里不要放入所有顏色GIF只是顏色的列表。如果一個GIF文件有10個像素高，顏色列表就有10行。如果第一行是100個白色像素，GIF格式通過寫一次“白”，然后加一條這種顏色再重復(fù)99次的注釋。這種方法應(yīng)在每一行中使用，所以如果第二行是粉紅色，第三行是蘭色都沒有關(guān)系。換句話說，一行一行地重復(fù)白色并不能減少文件大小。實際上，在一行上有大量顏色的變化。假如第一行在黑和白之間不斷交替- GIF格式不會通過加注釋來減少文件大小-它只是記住白、黑、白、黑，等等。另外，黑白相間的行在一英尺外看只是灰色。當(dāng)你沿著水平方向改變顏色時，盡量使用更多的相同顏色的片段：20個白色像素，然后是20個粉紅色像素，然后是20個蘭色的，20個紅色的，20個綠色的，這樣顏色的索引將是#FFFFFF*20、#FF00FF*20、#0000FF*20、#FF0000*20、#00FF00*20，這樣可以把文件壓縮得更小。

　　記?。和ㄟ^使用 L的HEIGHI和WIDTH標(biāo)記簡單地放大圖像不會增加速度。一個1*1的蘭色矩形很小，傳輸也比100*100的矩形快。但是把一個蘭色像素擴展到100*100的矩形，最后卻是一個24位的100*100的圖像。GIF壓縮只趨向于減少存儲空間和傳輸速度。一旦瀏覽器的渲染引擎解壓你的圖像并顯示到屏幕上，處理實際圖像的時間和縮放到相同尺寸的時間差不多。在使用每一個技巧時看看它是否節(jié)省時間。　

　　第三頁：全是文本，沒有圖像和Jason一樣，我盡可能用文本而不用圖形，但是我的觀點更極端：我認(rèn)為應(yīng)對每個使用GIF顯示文本的設(shè)計者罰款15美圓。用戶花錢上網(wǎng)，很慢的下載和渲染速度意味著時間和金錢的損失。設(shè)計者應(yīng)為選擇最適合文本意義的字體而驕傲。因為用戶的計算機上不存在“灰姑娘的水晶鞋”這樣的字體。（有多少人的機器上安裝了Wiese字體？）-這樣GIF格式的文本就產(chǎn)生了。如果你用圖像表示文字只是保持字型的一致或控制字型大小和間隔，對于你的頁面來說沒有任何意義。所以別這樣做。

　　要真正地減少下載時間，把渲染留給用戶的操作系統(tǒng)。如今，瀏覽器通過解釋HTML文檔來渲染頁面依賴于操作系統(tǒng)。利用用戶的計算機產(chǎn)生神奇的字體或形狀是最有效地利用帶寬和處理器的最有效方法-把信息包含在GIF圖像中是一種資源的浪費。用HTML定義矩形（table or layer），用ASCII表示文字，把字體留給操作系統(tǒng)，給每種顏色一個十六進制的值（例如#FF0000代表紅色）。

　　此時，我們還不能畫圓，我們只有Times, Courier和Helvetical/Arial幾種字型可用。但是用好這幾種字型是我們設(shè)計快速頁面的關(guān)鍵。對于復(fù)雜的多邊形，漂亮的字體和照片，只好用GIFJPEG圖形來犧牲下載時間了。

　圖像可值上千個字-特別在網(wǎng)上，一個簡單的圖像下載的時間相當(dāng)于若干頁下載的時間。到網(wǎng)上去看看，你會發(fā)現(xiàn)大塊的下載時間來自于圖像文件。

　　在以后的四天里，我們會看到使頁面趨向完美的所有不同的方法。今天我們從最明顯的罪魁開始-圖像。

　　第一：網(wǎng)頁訪問者往往沒有耐心。你的圖像可能很酷，但是如果她們對于快速下載來說太豐滿，很少有人會堅持到最后以求一睹她們的尊容。幸運的是，網(wǎng)頁設(shè)計者可以使用一些技巧和優(yōu)化來加速圖像和頁面的下載。

　　第二：不必要的就不要其實沒有什么特別的技巧。做其它事之前，從你的頁面中把所有多余的圖像去掉。這里“多余”不是指你們公司的標(biāo)志或你們辦公室的地圖。我們是指那個精明的、在“發(fā)郵件”旁邊的動畫信封。也許在你的頁面底部還放著隨處可見的NetscapeNavigator和Internet Explorer按鈕。說實話，有多少人沒聽說過這些產(chǎn)品呢？

　　在網(wǎng)站中減少一個瑣碎的10KB的圖形文件可能對整個網(wǎng)站改進不大。但是如果你的整個頁面才40KB，減少10KB就可以減少25%的下載時間-減少一個跳舞嬰兒的按鈕還是合算的。

　　如果你的網(wǎng)頁確實需要削減，可以考慮用文本“提交”按鈕代替圖形“提交”按鈕。用靜態(tài)圖形代替動態(tài)GIF圖形可以減少下載時間。最后，一些神奇的“header”圖形可以用$#@60;FONT SIZE$#@62;和$#@60;FONT FACE$#@62;標(biāo)記代替。

　　第三：GIF文件和JPEG文件除非你想得到ARCHIE或GOPHER一樣的火箭速度，你總會用到一些圖形。遵守一些創(chuàng)建圖像的規(guī)則，你的頁面下載的時間就會可行。

　　開始時，確定一個圖像用GIF格式還是JPEG格式。這看起來很基本，但是還有一大部分網(wǎng)頁犯這樣的錯誤。

　　GIF用在看起來干脆整潔的小圖形上是很完美的，但是不會超過256色。GIF也可存為“透明色”-允許圖形有不規(guī)則的邊界。簡單的公司標(biāo)志、小按鈕和導(dǎo)航條是應(yīng)用GIF圖形格式的很好的例子。不象JPEG，GIF是一種無損失的壓縮格式，所以你的圖形不會變得模糊不清。如果你在掃描有詳細(xì)細(xì)節(jié)的地圖，應(yīng)該選擇GIF格式。不過，如果圖片很大，GIF文件會很大，下載時間也會很長。


　　你不能從根本上壓縮GIF文件，但是可以減少位深，即限制顏色數(shù)。給定位深的顏色數(shù)等于2的位深次冪（即，8位=256色）。顏色數(shù)越少，圖像的字節(jié)數(shù)越少。假設(shè)你正在建一個可口可樂的網(wǎng)站，可以把很多標(biāo)志的位深減少到3或4位（ ?祝?蛐砘剮枰?飭街盅丈?囊跤吧?詞貢囈綣饣??？梢雜媚ebabelizer軟件改變位深。

　　JPEG文件可以顯示幾千種顏色，而且壓縮率比GIF文件高。它們很適合照片方式的圖像。不過壓縮成JPEG文件時會損失一些照片的細(xì)節(jié)。

　　第四：合適的尺寸當(dāng)你使用圖形編輯器時，保證圖形尺寸（72dpi）與將要在網(wǎng)頁上顯示的相同。在HTML中，用$#@60;IMAGE$#@62;標(biāo)記的WIDTH和HEIGHT屬性重述圖像的實際尺寸。這可以使瀏覽器在圖像下載時同時呈現(xiàn)頁面的其余部分-于是人們在等待圖像是有其它東西讀-并且保證在“關(guān)閉圖像”瀏覽時可以看到正確的頁面布局。

　　如果在頁面中使用表格，圖像尺寸非常重要：因為沒有定義尺寸的圖像會迫使瀏覽器清除和重繪頁面。這種情況發(fā)生在當(dāng)瀏覽器按照$#@60;TABLE$#@62;和$#@60;TD$#@62;來建造表格，然后卻發(fā)現(xiàn)表格單元中的圖像沒有尺寸參數(shù)卻太大而不能放在表格中時。瀏覽器只得重繪表格來容納如此笨拙的圖像。效率低下的頁面重繪浪費時間，而且用戶看到不斷消失和重繪的頁面時也會不高興。

　　使用WIDTH和HEIGHT時，最重要的是不要用它們調(diào)整頁面圖形的大小或形狀。通過HTML調(diào)整大小是很差勁的，有兩個原因。如果你放大圖像，你會得到一幅有鋸齒的圖片。

　　用HTML使圖像變小不是一直很壞，但在表現(xiàn)上很差。因為瀏覽器下載的數(shù)據(jù)比實際要顯示的圖像多，于是增加了下載時間。

　　第五：緩存是你的朋友有一個使圖像下載更快的重要技術(shù)。那些在網(wǎng)站中重復(fù)出現(xiàn)的圖像-比如通用標(biāo)志、頁首或?qū)Ш綏l-不必一遍一遍地下載。缺省地，Netscape和Internet Explorer在RAM或硬盤上設(shè)置緩存來存儲最近用到的圖像。如果瀏覽器認(rèn)識是相同的文件名，它會讀緩存，而不是從網(wǎng)上下載。這種方法大大地提高了效率，以至于很多自動記時程序無法識別-你只好用跑表自己測測了。

　　既然客戶端的緩存如此有用，在設(shè)計網(wǎng)頁時就應(yīng)考慮到瀏覽器的緩存。例如，如果網(wǎng)站有大量相似的頁首圖形，應(yīng)試圖把它進行分割，使其中不變的部分能從緩存中立刻讀出來。雖然在每頁還要調(diào)用一個新圖，因為這個圖很小，所以下載很快。

　　最后，把你的圖像放在一個地方，最好在你的服務(wù)器上。這可以減少DNS查找的時間。另外，如果你要存儲圖像的一個或幾個服務(wù)器崩潰，將是一件很不幸的事。