提醒：本文最後更新於 884 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

熟悉本部落格的同學可能早就發現，imququ.com 一直是我的一塊試驗田。我對網路協議、Web Server（Nginx）、服務端程式碼、前端程式碼每一層的研究和優化，最終都會在本部落格體現出來。我見過很多大談使用者體驗的博主，自己部落格體驗並不怎樣。我並不想在寫如何做好優化效能的同時，自己的部落格卻十分緩慢。

關於具體的優化方案，我之前寫過一些文章，如 Nginx 配置之效能篇、HTTP/2 相關優化，以後還會繼續寫。例如我最近在研究 ECC 證書對 HTTPS 效能的提升，等有結論了一定會跟大家分享。但同時有很多優化點我覺得比較常規，不值得分別寫一篇文章去介紹。我準備把這些零散優化點羅列在本文，並不進行深入討論。有興趣進一步瞭解和探討的同學，歡迎發表評論。

順便得瑟下，不久前我在 v2ex 發現這樣一條回覆，開心了好久（via）：

他的部落格速度最快，不服來辯 http://imququ.com/
專注 web 開發，他可是從底層協議到前端都有優化吧？

好了，下面開始進入正題。

靜態資源優化

大家可以看一下本部落格 HTML 原始碼，並沒有任何外鏈資源，甚至你很可能連大段 css、js 也找不到。這是因為我將常規外鏈轉成了 inline 輸出，同時存入 localStorage，之後不再輸出。這樣做的優點有兩個：1）首次訪問減少連線數，後續訪問減小頁面體積；2）不怕重新整理和強刷。

第一點很明顯，將 inline 和外鏈兩大方案取長補短。第二點也很重要，外鏈資源即使合理配置了強快取和協商快取，瀏覽器依然會在使用者主動重新整理時發起協商請求（響應碼通常是 304，無響應正文，但依然需要建立連線）；會在強刷時攜帶 Cache-Control:no-cache

圖片優化

不載入使用者看不見的圖片是最基本的優化，也就是圖片 lazyload 策略。其實任何資源包括 Dom 節點都可以做 lazyload，這是老生常談的話題，略過。

圖片需要預先壓縮。推薦一個 OSX 下的傻瓜式圖片壓縮工具 ImageOptim，非常好用。另外，使用 webp 格式，通常可以讓圖片檔案大小大幅減小，可使用 cwebp、imagemagick 等命令列工具進行轉換。判斷瀏覽器是否支援 webp 圖片，可以檢查請求頭中的 Accept

需要注意的是，如果選擇自己託管圖片，不要開啟伺服器 gzip，效果微乎其微還浪費 CPU。如果選擇將圖片託管在七牛這樣的雲平臺上，可以參考對應文件對圖片進行 webp 格式轉換，例如這是七牛的文件。另外，我諮詢過七牛客服，現階段使用七牛的 https 服務，已經沒有免費額度了（via）。

還有，本站文章中引用的圖片都在 HTML 中指定了高寬（在 Node.js 層解析 Markdown 語法時獲取圖片寬高），這樣能很好地避免圖片 lazyload 帶來的頁面跳動。

Google 統計優化

我一直在用 Google Analytics 分析本部落格一些訪問情況。大家知道使用 Google 統計需要引入它的 JS 檔案，這個檔案體積不小，快取時間也很短。我並不是十分在意詳細訪問情況，所以我把統計邏輯挪到了服務端。我自己生成使用者唯一標識，獲取訪問頁面的標題、URL、Referer，獲取使用者 IP 和瀏覽器 UA，隨著每次訪問發給 Google 的統計地址。服務端向 Google 發起的請求是非同步的，使用者端訪問速度絲毫不受影響。另外這個方案還可以解決 Google 統計經常被牆的問題（當然，前提是服務端到 Google 統計地址的訪問必須暢通）。

大家可以抓包看下本部落格網路請求，肯定找不到任何與統計有關的內容（更新：現在應該可以看到一個本站的統計請求，這是為了讓靜態頁也可以用上加速版的 Google 統計，我稍微改了一下實現）。但是，我所關注的統計功能絲毫不受影響，例如：

如果大家對我這個方案感興趣，可以參考 Google 官方文件瞭解下細節。需要提醒的是，由於 Spider 的存在，採用服務端統計最好加上 UA 黑名單策略。

類似地，本部落格使用了 Disqus 評論系統，每篇文章都會顯示評論數。這個數字也沒有使用 Disqus 的 JS API 線上獲取，而是通過定期跑指令碼離線更新，這樣可以最大限度避免第三方服務對速度的影響。有同學問我 Disqus 經常要翻牆才能訪問，為什麼不換成多說，主要是多說實在太不穩定了，另外我認為現在這樣也可以保證評論的高質量。

站內搜尋優化

對於個人部落格，一般有幾種方案處理站內搜尋。1）有自己資料庫的部落格，例如基於 WordPress、Typecho 搭建的部落格，預設使用的資料庫搜尋；2）大部分靜態部落格，會直接跳轉到 Google 等搜尋引擎進行 site: 站內搜尋；3）無論什麼部落格，都可以使用 Google CSE、Swiftype 之類的 JS Api 提供站內搜尋。

這些方案，要麼慢，要麼對中文支援差（不支援分詞、同義詞），要麼訪問速度慢（被牆），要麼收錄速度慢，都不能滿足我的需求。經過不懈研究，我最終採用了 bing 的 site: 搜尋做為資料來源，在服務端獲取、解析、處理並快取搜尋結果，直接以 HTML 的形式輸出搜尋結果。這樣無論是搜尋效果，還是訪問速度，都能令我滿意。大家可以親自試試，在本部落格搜尋 http/2、效能優化，或者其他任何詞語，體驗一下搜尋效果和速度。

這裡順便說下，其實 Google 站內搜尋效果也很好，但阿里雲機房到 Google 的連通性太差了（根本 ping 不通），只能放棄。

2016-01-05 更新：本站站內搜尋已經更換為自建的 Elasticsearch 引擎，具有更好的及時性和靈活性。檢視詳情 »

收錄速度優化

如何讓自己的文章更快被各大引擎收錄，這屬於 SEO 範疇，這裡不深入。保證語義化的頁面結構，使用友好的 URL 規則等等基本功，直接跳過。簡單說下我的一些策略：

首先，網站必須有一個即時更新的 sitemap 檔案，通過各大搜索引擎的站長平臺提交給 Spider：Google、Bing、百度、好搜。

sitemap 提交給搜尋引擎後，只能被動等待 Spider 週期性抓取。所以我在釋出新文章之後，還會主動呼叫各大搜索引擎的 ping 服務即時推送。一些搜尋引擎有自己私有格式的 ping 服務，具體格式可以參考各自站長平臺的說明；大部分搜尋引擎還支援通過 XML-RPC 遠端呼叫 weblogUpdates.ping 方法實現主動推送。下面是 python 呼叫程式碼：

#!/usr/bin/python
# -*- coding: utf-8 -*-

from xmlrpclib import ServerProxy
from pprint import pprint

s = ServerProxy('http://rpc.pingomatic.com/')
ret = s.weblogUpdates.ping(u'JerryQu 的小站', 
        'https://imququ.com', 
        'https://imququ.com/post/datauri-and-404.html', 
        'https://imququ.com/rss.html'
    )
pprint(ret)

除了上面程式碼中 pingomatic 提供的 ping 服務，百度和 Google 也有自己的服務地址：

另外，為了使得文章在釋出後，能實時出現在各大 RSS 閱讀平臺，本部落格還支援了 PubSubHubbub 協議。本部落格的 RSS 檔案指明瞭我所使用的 hub 服務地址為：https://imququ.superfeedr.com/，RSS 閱讀平臺會在這個網站註冊自己的回撥地址。這樣每當我通知 superfeedr 有新文章了，所有註冊過的 RSS 閱讀平臺就會收到通知，從而實時更新 Feed。常見的 Feedly、Inoreader 都支援 PubSubHubbub 協議。

國外訪問優化

將部落格搬到阿里雲主機之後，經常收到 Google Webmaster 的抓取超時郵件提醒。我嘗試通過 Linode Tokyo 機房訪問我的部落格，速度可以接受，於是決定用 Linode Tokyo 來加速國外訪問。

通過已換成同樣免費的 CloudXNS，可以很輕鬆地將域名針對國內、國外使用者解析到不同 IP。為了讓兩個 IP 都能訪問到我的部落格，我可以在 Linode 上再部署一遍部落格系統，這樣就需要考慮程式碼及資料的同步，有點麻煩。我最終選擇在 Linode 上使用 Nginx 的 proxy_pass 配置反向代理。

這樣國外使用者訪問我的部落格，會被解析到 Linode Tokyo，再反向代理到部署在阿里雲上的服務。由於國外訪問 Linode 很快，Linode 到阿里雲的速度還可以接受，這樣改造後比從國外直接訪問阿里雲要快不少。以下是 Google Webmaster 中有關本部落格下載時間的統計：

可以看到，遷移到阿里雲之後，Google 下載頁面所需時間大幅提升。配置反向代理後，又有大幅減少。

2016-01-30 更新：實際上，寫完本文後沒多久，從 Linode Tokyo 訪問阿里雲青島變得非常不穩定，我還是選擇了部署了兩套獨立的服務。

啟用 Google 翻譯

前幾天，我在 Mozilla 官方部落格一篇文章的評論中反饋了一個問題，最終 Mozilla 的工作人員通過 Google 翻譯看懂了我的部落格，並確認了這個問題（via）：

The comment author's blog post discusses caching scripts in localStorage and reloading them using blobs or data URIs with integrity. SRI is used to prevent XSS attacks from becoming persistent.

I could read and understand the post quite well using Google Translate. The summary is that Data URI don't work, because Chrome treats them cross-origin. Blobs work in Chrome but fail to load in Firefox. See the table at https://imququ.com/post/enhance-security-for-ls-code.html for more.

為了讓這極少數的國際友人更好地閱讀我的部落格，我決定在本部落格加上 Google 翻譯元件。頁面內建的 Google 翻譯元件可以更好地處理評論這一類非同步生成的內容，使用也很簡單，新增 HTML 結構及對應的 JS 檔案就可以了。需要注意的是，如果網站啟用了 CSP 策略，需要把 Google 翻譯的域名加進去。

如果僅僅是不管青紅皁白加上 Google 翻譯程式碼，顯然不符合我對本部落格效能的極致追求。為此，我做了兩點處理：1）對於國內 IP，始終不啟用翻譯功能，不額外載入任何資源；2）對於國外 IP，判斷使用者瀏覽器語言，不是簡體中文才啟用翻譯並載入相關資源。

判斷瀏覽器語言好辦，但是國內外 IP 如何判斷呢？我採用了一個取巧的辦法：前一節我寫到利用 DNSPodCloudXNS 的國內外解析到不同 IP 的功能，在 Linode 上搭建反向代理來加速。在這個基礎上，只要在 Nginx 反向代理配置中，通過 proxy_set_header 指令增加一個額外的自定義請求頭，再在源站程式中判斷一下這個頭是否存在，就可以區分訪問是來自國內還是國外了。

2016-08-10 更新：本策略已下線。

實際上，本部落格訪問速度很快還有一個原因：Web 框架選型，我選擇了 ThinkJS 這個效能非常優秀的 NodeJS 框架。ThinkJS 框架自身開銷只有幾毫秒，還有豐富的快取機制和靈活的擴充套件介面，使得實現高效的 Web 應用變得更容易。關於這部分內容，後續有時間再專門介紹。

--EOF--

發表於 2015-09-12 02:03:13 ，並被新增「 效能優化 、 QuQuBlog 」標籤 ，最後修改於 2016-08-10 00:53:17 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 884 天前，文中所描述的資訊可能已發生改變，請謹慎使用。