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

　　基于我所發現的和沒有發現的，我總結了一些使網頁緊縮的方法。既然你已經使你的圖像和表格盡可能地苗條，現在讓我們看看優化網站的最后一關。

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

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

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

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

　　一些同樣的網站也為放入大量的交叉連接感到內疚。有時他們故意這么做來增加頁面點擊率，但是通常可以加一個附加的頁來容納其它用戶感興趣的內容。

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

　　把JavaScript/” target=”_blank”>JavaScript當作垃圾

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

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

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

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

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

　　測試你的網頁

　　在過去的四天里，我們為你提供了很多加速網頁的方法。為了能讓用戶能有所體會，你需要為網頁制定一些行為標準并實行之。

　　制定你的標準

　　別只自問：“網頁現在有多快？”并試圖進行改善。應該問“頁面應該有多快？”。或者減少用戶的等待時間，或者讓用戶覺得他們的等待是值得的。

　　制定合理指導方針的最佳方法是檢查你的競爭對手的網站。查找與你的網站提供相同內容、服務、價值等的網站，研究它們的表現。請教你們公司市場部、銷售部或其它部門的人，讓他們評價你的競爭對手的網站。可以進行一次角色扮演：把你自己當成一個用戶，進行一次網上漫游。

　　當你確定了要查看哪些網站后，確定你要進行到哪里。或許整個頁面裝載完，但是或許應該確定某個特定條目的裝載時間（例如，一個新網站的頂部標題）。我們研究過的一些站點非常好：

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

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

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

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

　　快速表格的技巧處理表格使用表格時間長了，你會發現大量小表格渲染起來比一個有很多行的大表格快。至少看起來是這樣-真象那么回事（記住：是感覺到的速度，而不是實際速度）。

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

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

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

看看下面的表格：

　　現在假設用戶增加了缺省字體的大小。當表格放大以容納變大了的文字時，布局依然沒變。

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

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

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

要不要嵌套？

永遠不要嵌套表格

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

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

除非……

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

This is not that big a deal.

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

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

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

結構越好，頁面越快

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

　　下面是相同的頁面結構，只是商標、導航和內容分別定義在獨立的表格內。

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

　　在上面的第二個例子里，商標表格最早出現，然后是導航表格，然后是內容表格。整個頁面下載很快，用戶馬上就有可以看到的東西。

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

　現在，我準備講一講如何使這些網頁更苗條。

　　首先，頁面出現在網上時，有三種速度：

　　下載時間渲染時間可視性

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

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

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

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

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

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

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

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

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

　圖像可值上千個字-特別在網上，一個簡單的圖像下載的時間相當于若干頁下載的時間。到網上去看看，你會發現大塊的下載時間來自于圖像文件。

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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