by falcon wuzhangjin@gmail.com of TinyLab.org
2014/07/20

前言

本站建站有1段時間，買的阿里云，搭的WordPress, 剛開始1直有各種問題，致使沒法訪問，嘗試過：

• 升級Web服務器：從Apache到Nginx
• 創建文件并配置Swap服務
• 升級RAM：從512M到2G

但是發現有時訪問還是很慢，特別是連接多了以后，服務器就down掉，所以得繼續抽空優化。

兼容性問題

先做HTML的W3C兼容性測試，如果不兼容，很多閱讀器可能沒法訪問，果然，通過http://validator.nu/1測，發現1大堆問題。最重要的問題莫過于：

Almost standards mode doctype. Expected “”

查了1下，發現首惡居然是M$引入”BOM”(Byte Order Mark, UTF8文件的Magic Number，但是并沒有標準化)，不知道哪一個插件作者用Windows開發的，致使文件里頭帶有BOM字節，而標準HTML在文件頭是不允許有額外字節的，否則，有些閱讀器就解析不了，比如M$ IE。這就是原來在IE上閱讀不了該站的本源（所有頁面靠左對齊了）。

通過以下命令可以確認網頁開頭到底有無額外的BOM字節，如果有的話，會是這個模樣：

$ curl -s http://www.your-web-site.com/ | head ⑴ | sed -n l
357273277
$

前3個字節是8進制的，對應106進制恰好是：EF、BB、BF。

在Windows下可以用notepad++等直接去掉和添加BOM字節，在Linux下可以用vim做到：

$ vim test.c
:set fileencoding=utf⑻

:set bomb
:set nobomb
:set bomb?

以上3個設置分別為添加/刪除/查詢bomb標志。

對WordPress，如果安裝插件很多，那得把含有BOM的文件1個1個找出來。我們可以用grep，只需要匹配文件頭是不是有BOM字節就能夠：

$ grep -r -I -l $'^xEFxBBxBF' test.c
test.c

找到以后，可以用sed -i做替換（注：千萬記得備份）：

$ sed -i -e '1s/^xEFxBBxBF//g' test.c

這里是批處理（Again：操作前，千萬要備份）：

$ grep -ur -I -l $'^xEFxBBxBF' /test-dir | xargs -i sed -i -e '1s/^xEFxBBxBF//g' {}

關于更多的不兼容性問題，就根據測試的結果1個1個解吧。

本節參考：

• Why Firefox highlights HTML transitional doctype in red?
• UTF⑻編碼中BOM的檢測與刪除

性能問題

接下來，我們測試1下默許配置的性能，有蠻多免費的站點：12 個最好的免費網站速度和性能測試工具。

當前試用了Google PageSpeed Insights和Load Impact。

前者允許用戶分析網站頁面的內容，并且會提供加快網站訪問速度的建議，后者允許用戶做些 web 利用的負載和性能測試。它不斷增加網站流量來丈量網站性能。Load Impact 會選擇1個全球負載區，測試摹擬客戶，帶寬，接收數據和每秒要求等。愈來愈多客戶變活躍，這個工具會用個漂亮的圖表來展現丈量的加載時間。

通過Load Impact測試以后發現，訪問時間跟并發數成線性關系，那意味著，前面提到的并發訪問多了以后，全部服務性能逐漸降落了，到最后Nginx都沒法提供服務了。

化動為靜；緩存起來

這個問題，通過查找資料并分析，發現務必要做幾個工作：

• 把動態頁面轉換為靜態頁面

這個跟Android上的ART1個原理，頁面1旦編輯完就能夠生成1個靜態的html頁面，用戶訪問時就能夠直接從磁盤乃至內存里頭拿html代碼，無需額外的PHP解析開消（包括處理器和內存）了。

• 把1些SQL訪問緩存

大量并發的數據庫訪問會帶來很大的IO性能開消，可以把1些SQL查詢的結果緩存起來，這樣可以節省IO開消。

上面兩個的選擇很多，經過對照，分別采取了：

• 頁面緩存：Hyper Cache
• SQL緩存：DB Cache Reloaded Fix

除雜去冗，化繁為簡

后面綜合Google PageSpeed Insights的測試結果，又做了以下幾項優化：

• CSS Minify：Autoptimize，注：不能使用其JS優化，有嚴重Bug。
• JS Minify：HeadJS Plus
• HTML Minify：WP-HTML-Compression

線性轉并行；同步轉異步

需要特別強調的是 JS 異步加載優化，這個效果非常明顯也很典型。

該站用到了第3方統計，發現通過國外 VPN 進來的時候，統計站點的 Javascript 加載嚴重拖慢了全部系統，致使文章帶有代碼高亮插件的內容沒法正常渲染。

因而乎，想到了異步加載 Javascript 應當能解決問題，通過查找確切發現大部份閱讀器都已支持 async 或 defer 屬性，后者確保履行時序，前者則不會保障 Javascript 的加載順序。

對我們這里的特例，統計站點與站內其他資源有任何依賴關系，完全可以用 async 屬性，用法以下：

異步以后，效果相當明顯，系統其他部份順利加載，統計就讓它慢吞吞地干吧。

需要注意的是，上面的方法好像效果不好，對站長統計，會致使那個統計圖標不顯示，這樣的話，可以用類似下面的思路（站長統計和百度統計都已支持，可以直接復制過來）：

性能測試和優化建議

后面又嘗試了其他幾個測試服務：

• neustar展現各地的連接速度，并且詳細地展現了各個資源的獲得時間，可以很方便地輔助開發者定位問題并做針對性優化。
• Web Page Analyzer非常強大，提供了詳細的網站分析數據并且會提供提高網站性能的建議。它提供大量的 web 頁面速度報告，global report，外部文件計算，加載時間，網站分析數據和改良建議。
• Octa Gate Site Timer 允許用戶檢測每一個用戶加載1個或多個頁面的時間。當頁面加載的時候，SiteTimer 存儲每一個項目加載的數據和用戶接收的數據，這些數據會用1個網格來顯示。
• Pingdom 是個非常杰出的工具，幫助用戶生成大量網站的報告（頁面大小，閱讀器緩存，性能等級等），肯定網站的加載時間，而且允許用戶跟蹤性能的歷史記錄，能在不同位置進行網站測試。
• GTmetrix 可以幫助用戶開發1個快速，高效，能全面改良用戶體驗的網站。它會為網站性能打分，然后提供可行性的建議來改良已發現的問題。

本節參考：

• WordPress緩存插件Hyper Cache使用方法與緩存加速效果對照分析
• wordpress插件之緩存類插件總結與點評
• Improving Page Load Speed

搜索引擎收錄問題

這里觸及3個動作，分別是：

• robots.txt協議：告知搜索引擎能不能搜，哪些目錄可以搜
• SiteMap協議：告知搜索引擎我這個網站有哪些東西
• 直接提交給搜索引擎進行收錄

首先是robots.txt，這個可以通過1些網站自動生成1個配置文件：robots.txt，例如http://tool.chinaz.com/robots/，生成后這個文件放在網站根目錄下。

接著是安裝1個SiteMap自動生成的插件，例如：Baidu Sitemap Generator。生成后，在robots.txt的最后加入以下兩行，例如，本站：

Sitemap: http://tinylab.org/sitemap_baidu.xml
Sitemap: http://tinylab.org/sitemap.html

在最后，我們可以主動給各大搜索引擎提交收錄，各大收錄的入口地址這里有1份清單。

經過這3步以后，搜索引擎的收錄問題就不大了。

更多SEO

除上述問題外，通過1些專門的SEO評測站點可以獲得更多有價值的優化信息。

• SEO綜合查詢

該站提供了各家搜索引擎的收錄情況，域名，備案，服務性能，站點描寫與關鍵字設置情況等。通過該工具查到該站的主題沒有添加站點描寫和關鍵字信息。

• Website Review

這個網站則提供了另外的1些視角，比如上面的兼容性問題測試就是該站提出的建議。

通過SEO綜合查詢和相干的檢索后，找到了手動為各種場景添加關鍵字和描寫的方式，那就是在header.php的head部份添加以下內容：

記得把首頁部份的描寫和關鍵字修改成你自己的內容。

小結

上面的優化其實都是最基礎的，要真正優化SEO，那就是要逐漸豐富與站點主體相干的內容，保持延續的更新和保護，吸引足夠的忠實讀者。