網站優化的要務 : 速度、速度、速度

 

 

圖片來源:cpc.tw

關於速度的問題，你必須注意的是「網站速度」而引發的資料抓取量，而非「網站速度」影響SERP。你必須注意的是「網站速度」對於使用者的影響，而非搜尋引擎怎麼看你的「網站速度」。

對於搜尋引擎而言，速度影響資料抓取，如果這次抓不到，過陣子再來抓，但是對於使用者而言，如果你的速度實在太爛的話，你可能就永遠失去一個客戶。

 

使用者的使用者經驗也會影響自然搜尋排名，所以如果能夠就網站速度來解決問題，可以同時滿足搜尋引擎與使用者。

前陣子機房出了點問題，原本都正常的網路，但是突然無法連外，外面也無法連進來到網站，檢查了半天，所有設備燈號都正常，防火牆連接路由器正常，路由器連接交換器正常，交換器連接其他交換器也都正常 ... 最後才由路由器的封包查到，一小段的網路線路不通，正常的燈號只是假象。

如果都不通還好，最可怕的是，有時通有時不通，有時很通有時很不通 ... 什麼時候會發生這種現象? 如果不談設備硬體的穩定度問題的話，大多都發生在流量過大造成系統無法負荷。

系統無法負荷可能的解決方式，一個是更新更強大夠用的硬體，另一個是進行微調(Fine Tuning)。

第一種解法可能會造成浪費，因為也許系統並不是真的善用資源，本來可以只用10K的記憶體的工作，如果程式沒寫好，可能會吃到1M；原本不需要每次都連接資料庫的工作，卻每次翻頁就去連資料庫，所以就必須思考如何微調來解決問題。

有哪些方法可以增加網站效率呢? 這篇文章"7 Ways to Take Advantage of Google's Site Speed Algorithm"有提到七個方法，我們補充資料並整理後如下:

(1)動態程式是否可以轉成靜態的HTML?

有些程式如 http://www.example.com/prog.php?a=1&b=2，這支程式可能每天會有數十萬人去執行，每次執行電腦就必須解譯、執行、連接資料庫然後傳輸，如果把他換成 http://www.example.com/prog-new.html，這支就只需傳輸，省略了解譯、執行、連接資料庫的動作，數十萬人次的累積，應該脽都知道資源使用的差別。

最常見的例子，就是各入口網站的新聞，幾乎所有新聞頁面都是HTML，而非程式，這些都是程式一次執行後，轉換成靜態HTML。

我們再看看PChome商店街首頁，其實也是靜態HTML : http://store.pchome.com.tw/index.htm

再看看 Amazon的首頁，也是靜態HTML : http://www.amazon.com/index.html

如果網路商店的首頁無法快速的出現，會損失的不是SERP而已。

(2)圖案是否都已經過壓縮?

圖案如果每個減少10K，100個圖案就減少1M，如此累積起來，如果沒有壓縮的話，網友看到的不是高解析度的圖案，而是緩慢的顯示。

曾經有業者吐苦水，不是不願意壓縮圖檔，而是壓縮過的圖檔沒有足夠的解析度，但是你知道你的讀者都使用什麼解析度嗎? 如果你使用Google Analytics 或者Yahoo站長工具找出大多使用者的解析度，並且善用各種壓縮方式，你就可以知道如何在兼顧美觀的情況下讓效能達到最佳化。

Yahoo的圖案壓縮工具
http://www.smushit.com/ysmush.it/

將圖案轉成base64的工具
http://webcodertools.com/imagetobase64converter

圖案Sprite工具
http://spriteme.org

CSS Sprite說明
http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/

Image Optimization
http://www.sitereportcard.com/imagereducer.php

其他參考資料
http://www.webdesignbooth.com/12-really-useful-image-optimization-tools-for-web-designers/
http://websitetips.com/optimization/images/
http://www.yourhtmlsource.com/optimisation/imageoptimisation.html

(3)是否啟動Gzip?

Gzip就是將壓縮過的檔案傳到瀏覽軟體，然後瀏覽軟體再自行解開檔案，這樣的過程就節省了中間傳輸的頻寬。

但是如果啟動Gzip，會多出CPU時間的負荷，所以如果你的問題在於伺服器本身資源不足而非頻寬，當然就不能使用Gzip來壓縮，否則越壓縮變越慢。

Gzip參考資料
http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

(4)Javasctipt與 CSS是否最佳化?

通常Javascript與CSS是經常被最佳化遺忘的，但是這兩者的設計優劣，對於整體網頁的顯示，影響不可謂不大。不過通常這類的最佳化，只是格式上的，也就是去除不必要的字元，無法解決Javascript浪費資源的寫法。

相關參考資料
http://www.codebeautifier.com/
http://www.cssportal.com/css-optimize/
http://www.javascriptoptimizer.co.uk/

(5)是否考慮使用外部Javascript/CSS?

大家都知道Javascript擺放位置會影響顯示效能，同樣的外部的Javascript與 CSS也可以提升顯示效能。但是不是絕對，也不能過多的外部Javascript/CSS。

當瀏覽軟體觀看一個網頁，是由上往下一一去解析語法，因此載入外部檔案就是另外一個Process，因此語法會由上往下逐一顯示。

將Javascript/CSS變成外部的好處是，修改方便並且可以放置於不同的伺服器。

因此使用外部的Javascript/CSS，就可能會提升效能，為何說「可能」?因為還要看整體的配置。

(6)DB Connection與SQL是否已經最佳化?

使用同樣的語言去連接同樣的資料庫，就可以使用太多種方式，這些不同實在無法一一列舉，光是connection方式就是效能評估的重點。

而牽涉到實體連接方式，是透過internal ip或legal ip的連接方式，也可能有不小的影響，例如如果http server直接以interanl方式連接，可以減少db server不必要的封包流量或是攻擊。

最後再來就跟 SQL Command有關了，是否使用stored procedure? SQL Command的寫法是否已經最精簡了? 做同樣一樣工作的 SQL Command如果給兩個不同的設計師來寫，是否會出現不同的寫法?

(7)是否考慮使用CDN(Content Delivery Network)?

什麼是 CDN? Wikipedia說是透過設置許多不同點來放檔案備份，以便讓網路存取更加快速。

這裡就有一堆免費CDN列表，舉個例子來說，如果你使用「Coral Content Distribution Network」，那麼如果你有一個圖檔的URL是http://www.dns.com.tw/blog/attach_files/seo-book-20090622.jpg，那麼這個 URL就是你的CDN:http://www.dns.com.tw.nyud.net/blog/attach_files/seo-book-20090622.jpg。

如果你的URL是 http://www.example.com:8080，那麼 CDN就是 http://www.example.com.8080.nyud.net; 如果你的URL是 http://www.dns.com.tw/seo/?p=707，那麼你的CDN就是 http://www.dns.com.tw.nyud.net/seo/?p=707，依此類推。

透過CDN的幫忙，許多原本要從你的伺服器下載的檔案，就可以依照網友的所在地去找到最快的傳輸路徑了，這個原理其實就是web proxy，CDN會去抓你的 URL的檔案，然後備分到各個不同的點，等待網友的使用。

(8)資料庫是否已經最佳化?

在上面(6)中說到SQL Command的寫法，有時候不良的資料庫結構，會導致無法精簡的撰寫SQL Command，這個已經有點超出SEO與網站優化人員的範圍。

筆者曾經碰過，原本可以用簡單的SELECT field-a FROM database-b WHERE condition 寫完的指令，但是因為可能沒有 field-a 這個欄位，或者根本沒有 database-b 資料庫，就必須寫一連串的語法來完成簡單的工作。

也許你會說，沒有欄位或資料庫，就加一個啊! 一個龐大的系統為了資料一致性跟修改的複雜度，不是增加一個欄位或資料庫的問題，沒有整體考量的亂加只是讓問題更複雜。

因此這個時候就必須整理資料庫進行最佳化，這些最佳化動作，可能是正規化，可能是適度重複性，也可能是分割到不同的伺服器 ... 等等。

(9)是否將較耗資源的工作分散?

許多伺服器可能規劃為檔案下載，可能規劃為圖檔伺服器，可能規劃為影音檔專用 ... 這些規劃都希望把較耗資源的工作分散到不同的伺服器，而不要影響web server的頁面顯示，並且可以更彈性的增加scalability。

如果圖檔伺服器效能不好，就將一台變兩台，或是變成叢集，就可以把複雜度切開，或是使用Cloud的概念將之視覺化，也可以降低管理的困難度。

(10)最後，當然就是負載平衡了

如果上面該做的都沒有辦法，也許就只能使用負載平衡(load balance)了，但是不是指負載平衡最好，如果上面該做的沒做，負載平衡只是浪費你的投資罷了。

負載平衡也有許多作法，有花大錢的作法，也有花小錢的作法，有些牽涉到OS，有些跟OS無關，有些是軟體的作法，有些是硬體的作法，就另篇再討論了。

上面列了十種方式來提升網頁的顯示效能，但是不保證所有網站一體適用，因為可能圖檔瘦身半天，結果完全沒有效果，也可能使用外部CSS，結果更慢! 所有的問題都應該適時適地，你必須仔細檢討(當然需要精準的數據)來找出問題，才能真正對症下藥。

---

文章出處:

http://seo.dns.com.tw/?p=707