關於速度的問題,我們已經在"網站速度是否為SEO的重要因素?"說明過,是的,你必須注意的是「網站速度」而引發的資料抓取量,而非「網站速度」影響SERP。你必須注意的是「網站速度」對於使用者的影響,而非搜尋引擎怎麼看你的「網站速度」。
對於搜尋引擎而言,速度影響資料抓取,如果這次抓不到,過陣子再來抓,但是對於使用者而言,如果你的速度實在太爛的話,你可能就永遠失去一個客戶。
在SEO關鍵解碼書中,也一再強調,使用者的使用者經驗也會影響自然搜尋排名,所以如果能夠就網站速度來解決問題,可以同時滿足搜尋引擎與使用者。
前陣子機房出了點問題,原本都正常的網路,但是突然無法連外,外面也無法連進來到網站,檢查了半天,所有設備燈號都正常,防火牆連接路由器正常,路 由器連接交換器正常,交換器連接其他交換器也都正常 ... 最後才由路由器的封包查到,一小段的網路線路不通,正常的燈號只是假象。
如果都不通還好,最可怕的是,有時通有時不通,有時很通有時很不通 ... 什麼時候會發生這種現象? 如果不談設備硬體的穩定度問題的話,大多都發生在流量過大造成系統無法負荷。
系統無法負荷可能的解決方式,一個是更新更強大夠用的硬體,另一個是進行微調(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://www.dns.com.tw/seo/?p=707