這篇”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) 在明顯的地方，放置最相關的連結內容。

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

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

根據Google的說法，WebP ( 發音如weppy) 比JPEG增強39.8%的壓縮效能，並且可以在壓縮比與圖像品質上讓使用者決定。

這裡有參考資料: Google新「WebP」影像技術 讓圖檔更小！

根據這篇文章Google’s Really Taking This Speed Thing Seriously，網頁傳輸上有65%都是影像檔案，因此如果能夠改善圖檔的效能，就能讓網頁更加快速的顯示。你可以透過Google的展示站台來看看WebP的樣貌，並且還有轉換工具。

Google比較了WebP/JPEG 2000/JPEG，發現確實WebP在壓縮上表現都比其他格式來得好 (如下圖)。

在WebP Gallery中有些範例圖片，如下圖

136780 bytes

122260 bytes (10.6%)

上面的圖檔中，以WebP格式的檔案減少了10.6%。

這篇Image Comparisons: PNG, WebP, and HIPIX表示，WebP確實具有最好的壓縮功能，但是在WebP的Wikipedia中，Jason Garrett-Glaser認為與JPEG/x264相比較，WebP的品質最糟糕 …

但是不管如何，WebP的格式雖然品質未必最優，但是與檔案大小的壓縮相比，WebP的品質應該是可以接受的。在Google’s New WebP Image Standard Is All About SEO就明白的指出了，搞SEO就必須要用WebP啦。

改天真的必須花點時間來開始使用WebP好好的壓縮壓縮了。

關於速度的問題，我們已經在”網站速度是否為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，結果更慢! 所有的問題都應該適時適地，你必須仔細檢討(當然需要精準的數據)來找出問題，才能真正對症下藥。