這篇”Easy Ways to Reduce Your Website’s Bounce Rate“提到，當然要讓每個頁面都讓訪客滿意是不可能的，但是如果太多頁面的跳離率都非常高的時候，例如60%~80%時，你可能就必須好好思考如何降低跳離率了。

以下列出了幾個可以有效解決跳離率(跳出率)過高的方向:

(1) Check Browser Compatibility 檢查網頁的瀏覽相容性。

這項是最應該即刻檢討的項目，因為許多網頁都沒有經過各種版本瀏覽軟體的測試，更可能沒有經過各種設備的瀏覽測試。你的網站是否可以被不同版本的Internet Explorer、FireFox、Chrome、Safari、Opera所瀏覽呢? 你的網站是否可以被桌上型電腦、手機、平板所瀏覽呢? 你的網站是否使用特殊的Javascript呢? 你的網站內容是否必須使用特殊的播放軟體呢 (如Flash或是一些影片)?

你可以順利瀏覽你的網站，不代表大家也都可以順利瀏覽你的網站，如果你的網站能夠檢查網頁的瀏覽相容性，肯定可以快速的降低跳離率。

其他參考資料:
Responsive Web Design對於SEO有何好處?
應該如何進行Mobile SEO?

(2) Improve Your Page Load Times 改善你的網頁載入時間。

我們在”網站優化的要務 : 速度、速度、速度“說過，對於使用者而言，如果你的速度實在太爛的話，你可能就永遠失去一個客戶。以前的使用者也許可以等30秒的網頁載入時間，但是現在可能超過3秒無法看到網頁，就會馬上離開。

要改善你的網頁載入時間，最快的方式就是找一家連線最快的代管廠商，只要花錢就能馬上解決。另外就是必須檢視你的網站結構，找出拖慢網頁載入時間的最大原因，然後改善它。最常看到的是圖檔過大、外掛過多、Javascript過於複雜、後台資料庫問題 … 等等。

(3) Create Better Content 創造較好的內容。

其實解決了上述(1)(2)的問題，大概跳離率就可以有明顯的改善了。再來就是可以快速降低跳離率，但是沒有那麼簡單的項目了。

我們在”什麼是網頁內容的品質? 為什麼品質關係SEO的成敗?“說到，如果能夠解決網頁的品質問題，可以先取得一些優勢，然後再來檢視內容的品質。要能夠讓內容有品質，就要先避開Think Content的問題，然後再考慮投入行銷的問題。

(4) Make Your Purpose Known 讓你的意圖被知道。

讓你的意圖被知道的意思就是把網頁的主要內容突顯出來，不要再讓訪客找半天。這個說起來簡單，但是其實不是太容易。因為許多網頁都希望網頁能夠「內容豐富」，所以會有雜七雜八的內容跟連結，例如我們的網頁就是有點太龐雜，哈哈，但是實在沒有太多時間去簡化。

如果你的搜尋流量進來，但是無法在三到五秒鐘找到想要的內容，就可能造成跳離。

(5) Avoid Pissing Off Your Readers 避免惹惱讀者。

什麼樣的網頁會惹惱讀者呢? 就是pop-up window (跳出視窗)、過多讓人分心的廣告、關不掉的廣告、自動播放的影片或是音樂、或是過多跳動的元素等等。

許多沒有內容的網頁，都會以上述的方式來騷擾讀者，目的就是要讓讀者誤點廣告，然後賺取廣告費。但是這類的網站久了之後，會讓訪客記得你的網址，不是避免點選就是點入後馬上離開。

(6) 避免過長的內容，或是過於困難閱讀的內容。

過長的內容或是過於困難閱讀的內容，會讓訪客閱讀很久的時間，雖然有實際閱讀活動，但是根據跳離率的定義，還是可能算是跳離。因此一個網頁的內容要「豐富度適中」，單頁不要讓訪客停留過久，最好能夠繼續點選閱讀，或是造成投入。

(7) 在明顯的地方，放置最相關的連結內容。

如上所述，訪客沒有太多的耐心去尋找你的網頁，因此如果內容不是訪客期待的話，至少可以在明顯的地方，讓訪客看到有興趣的內容。

以上七大項目就是可以快速解決跳離率過高的問題，雖然未必都很簡單推動，但是如果你能夠依照這些方向去思考，你的網站跳離率將可以很快的降低下來。

關於速度的問題，我們已經在”網站速度是否為SEO的重要因素?“說明過，是的，你必須注意的是「網站速度」而引發的資料抓取量，而非「網站速度」影響SERP。你必須注意的是「網站速度」對於使用者的影響，而非搜尋引擎怎麼看你的「網站速度」。

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

在SEO關鍵解碼書中，也一再強調，使用者的使用者經驗也會影響自然搜尋排名，所以如果能夠就網站速度來解決問題，可以同時滿足搜尋引擎與使用者。

網站優化最新文章 : 數據驅動的網站優化 Data Driven Website Optimization

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

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

系統無法負荷可能的解決方式，一個是更新更強大夠用的硬體，另一個是進行微調(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，結果更慢! 所有的問題都應該適時適地，你必須仔細檢討(當然需要精準的數據)來找出問題，才能真正對症下藥。

Is Load-Speed the Ultimate Google Ranking Factor?

Using site speed in web search ranking

Google搜尋排序要考量網站速度 龜速網站只能進後段班

我們來檢視一下這些說法吧 …..

我們在”SEO關鍵解碼“書中第三章90頁，已經說過搜尋引擎會以幾個原則來決定抓取資料的策略。

(1)選擇策略–選擇抓取網站的順序

(2)重訪策略–多久重新回來拜訪

(3)並行策略–安排分散式的資料抓取

(4)不擾策略–以不影響網站的方式抓取

以上四個策略的「不擾策略」就跟網站速度有關係，因為你的網站如果效能不佳，搜尋引擎就會盡量不打擾你的網站，以免影響使用者的使用。

所以，網站速度是否為SEO的重要因素? 其實本網本來就告訴讀者，網站速度當然是一個SEO的重要因素。

NowNews說: “據報導，Google的搜尋結果排序考量了超過200種因素，Google搜尋工程師Amit Singhal和Matt Cutts 9日在部落格中宣布，數個月後，要在Google網頁搜尋結果的排序考量要新添一項：「網站速度」，過去數個星期並已開始測試，因為網站反應速度夠快，網友也會有比較愉快的使用體驗。”

其實「網站速度」只是由資料抓取因素又變成評等因素，也就是說，原本「網站速度」會影響搜尋引擎的資料抓取，資料抓取的多寡當然就會影響SERP，因此「網站速度」並非影響SEO結果的新因素，只是體現在不同的階段罷了。

更有人認為: “One commenter even went so far as to announce that he/she will remove all Analytics and AdSense scripts because their slow performance will now obviously ruin his/her website’s performance.” 有人說應該把一些Google分析程式移除，因為會影響網站的效能。

Google的官方部落格說: “While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point. We launched this change a few weeks back after rigorous testing. If you haven’t seen much change to your site rankings, then this site speed change possibly did not impact your site.” 指出「網站速度」當ranking factor只佔很小的比重，並且不到1%的搜尋會因此受到影響，並且目前只用在英文的搜尋上。

綜合來說，搜尋引擎不會以少數的連線來決定某站的「網站速度」，「網站速度」也不可能比「內容相關性」更重要。

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

如下圖，你應該注意的是，搜尋引擎的資料抓取量是往正向因素還是負向因素?

如果下載所需時間沒有大變化，但是下載資料量卻變小，或是下載資料量沒有大變化，但是下載所需時間卻變大了 …. 這就必須特別注意了。

因此結論是，網站速度是SEO的重要因素之一，但是重點還是網頁內容的相關性，不必因為出現新的因素而太過緊張，只需好好體會”SEO關鍵解碼“書中所說的要點，就可以高枕無憂了。