站點優化記錄

本文使用「署名 4.0 國際 (CC BY 4.0)」許可協議，歡迎轉載、或從新修改使用，但須要註明來源。 署名 4.0 國際 (CC BY 4.0)

本文做者: 蘇洋

建立時間: 2018年10月14日 統計字數: 3902字 閱讀時間: 8分鐘閱讀 本文連接: soulteary.com/2018/10/14/…

---

站點優化記錄

還記得十年前，當時就在追求頁面在1s內打開，沒想到十年後，我依舊在追求頁面在1s內打開。

十年裏，不論是客戶端設備、客戶端和服務端網絡環境、服務端技術棧、甚至是開發語言技術棧都發生了不小的變化。

此次優化算是清理了幾年前的技術債，簡單記錄一下吧。

第五次重構

若是你對以前的幾回重構感興趣，能夠跳轉文章尾部開始閱讀。

九月的時候，我更新了配置並將運行了幾個月的 Traefik 重啓，進一步進行數據統計。

十一的時候，我購置了一臺新的機器做爲 Home Lab ，在將全部已有的服務進行了遷移，同時冗餘的資源，能夠提供給全部開發項目測試環境和預發驗證環境。

在新環境的加持之下，本來完整編譯發佈的 1 分鐘 能夠被縮減到 40 秒，若是配合緩存使用，時間能夠縮減到 25 秒 以內。

在環境完備以後，我將九月運行至今（42天）的數據下載並進行統計，發現幾個有趣的數據 （下面分別是包含、不包含爬蟲的數據截圖）。

包含爬蟲的數據

排除爬蟲的數據

• 個別請求響應時間慢
  • 天天接近 200MB 的流量使用，其中有的資源要完整響應客戶端，最大響應時間甚至到了 30s，個別例子甚至到了分鐘級別，猜想是高頻訪問時刻，帶寬被佔滿所致。
• 靜態資源效率不高
  • 靜態資源中，common.css 、 webfont 、core.js 、common.js、sidebar-cover.jpg 請求數量巨大，佔用了固定帶寬，影響了一部分用戶的訪問體驗，浪費了這部分用戶的移動流量。
• 古董瀏覽器用戶很少了
  • 訪客操做系統中 Windows、Mac、Android、iOS 等操做系統依次遞減。訪客瀏覽器佔中 IE 僅佔 4.56%，IE 系列中 IE 9 佔了 0.85%，其餘版本佔比低到能夠忽略。
• 404 資源須要進行兼容
  • 包含爬蟲在內，請求中有 14.18% 的請求出現了404，雖然流量只消耗了 2.97%，可是感受應該進一步下降這個數值，畢竟要提供有價值和意義的內容呈現不是。

下面的截圖是未重構前，包含異步加載圖片的首頁數據。

重構前請求數據

能夠看到 384KB 的數據加載，讓頁面 DOM Ready 延遲到了 300ms， 而頁面完整加載硬是拖到了 994ms。

尋遍訪問記錄，我發現輪播圖內容的訪問加起來不到 1%，並且腳本中用於適配桌面、移動端設備的輪播代碼包含組件庫代碼(腳本、樣式)，加起來接近 3k，延時加載的幾張圖竟然佔用了總流量的 3%，而且前面說到的徹底加載時間被拖慢，這個組件功不可沒，簡直是豬隊友，這種高投入低產出的組件，能夠直接幹掉。

爲了照顧古董瀏覽器而使用的 jQ 庫佔用了接近 13% 的流量，結合上面的訪客客戶端數據，這個基礎庫該減肥了，在不大規模修改原來程序的基礎上，考慮到最小成本替換，因而暫時使用 Zepto 進行了替換，源文件減小 60 KB，GZip 後的文件尺寸 13KB ，而隨後清理掉頁面加載的一些 inline script，每一個頁面的 GZip 後的尺寸又減小了 1KB 。

對於桌面系統展現的側邊欄的圖片，佔用了超過 10% 的流量，客戶端分辨率愈來愈高，可是這個圖片卻再也不好再進行尺寸上的擴張，一來浪費用戶流量，二來仍是投入產出比的問題，因而我使用幾張 SVG 化後的圖片對它們進行了替換，在 GZip 壓縮以後，每張圖片只佔用不到 10 KB，還可以應對將來分辨率的繼續擴張的問題。

在查看頁面數據的時候，我發現 common.css 和 Web Fonts 分別佔用了總流量的 22.15% 和 13.47%。前者源碼竟然 include 了大量未被使用的組件（前幾版重構過程當中操做失誤）、後者竟然沒有使用定製的字體文件。在簡單修正以後，兩個文件總共減小了 100 KB 以上。至於暫時不使用 SVG SPRITE，我是這樣考慮的，雖然將圖標和字體放在 SVG 中，甚至合併到頁面內容中，可以進一步減小請求，可是勢必要引入額外的腳本進行資源掛載，並且渲染性能影響過大，頁面DOM複雜度也會提高，還不利於緩存複用。等將來 Web Components 支持進一步完善再說吧。

另外，在處理過程，順便修正了 Node 和 Hugo TPL 存在的 ReDoS 的問題，如今網站中的多數文章應該都顯示正常了。

最後貼一下此次重構的戰鬥結果（Lighthouse v3.0.3）。

性能跑分

還有請求數據（無緩存）。

重構後請求數據

暫時的缺陷：

• PWA 徹底沒有作的狀況下，得分 58。
• 無障礙訪問 88 分，失分在界面部份內容對比度不足，低分辨率的狀況下不知足 WCAG 2 AA 高對比度要到 7:1 的要求。

回顧歷史

雖然以前有說過，在去年已經對網站進行了全面升級，拋棄了傳統的動態腳本，取而代之的是 Markdown 配合一個 DataBridge 進行全站靜態生成，可是網站主題使用的還一直是在淘寶工做時使用的編寫的模板。

初版

2014年最初設計模板的時候，其中有幾個小功能比較有意思。

• 資源加載全憑前端加載器，配合自動切換不一樣源頭的資源，能夠輕鬆作到站點資源永不失效。而且會針對不一樣的瀏覽器加載不一樣版本的jQ依賴庫，從而在知足兼容性處理的狀況下，提升執行性能。
• 模塊粒度很細，可是入口統一由前端腳本把控，不論腳本、樣式，仍是資源，都由頁面腳本引入，使用構建工具在編譯時，再進行拆分優化。
• 儘量避免 inline resource，每類頁面單獨具有該頁面的腳本和樣式，減小編寫時須要額外進行命名空間或者書寫規避，同時減小爬蟲以及用戶刷新帶來的額外傳輸損耗，提升資源緩存利用率，提升響應速度。
• 配合修改過的 nginx concat ，能夠作到在不更新資源的狀況下，動態對頁面進行調試。

第二版

隨後，隨着 gulp 的衰落、webpack 的興起，Markdown 的流行，BootStrap 的大版本升級，以及 SSL 證書的獲取從難到易，CDN 流量從貴到便宜，Hexo 缺少定製，網站服務器架構的變化… 網站又開始了變化。

• 使用 webpack 進行構建，基於 AST 進行資源優化和拆分，替換掉以前使用 AMD 進行資源顯示聲明以及手寫工具的模式。
• 子域名合併，在 SSL 未開始普及的時代，從前普通 HTTP 流量分發，像是七牛、新浪雲能夠做爲低成本、甚至無成本的服務商，可是伴隨 HTTP 2.0 到來的 SSL ，若是還繼續使用多域名，帶來的第一個問題即是你須要申請多個域名的證書（當時泛域名證書很是貴），以及支付不是很便宜的 HTTPS 流量成本。
• Hexo 之類的的靜態站點生成器不少，可是當時幾乎都須要將文章 Meta 信息寫在文章內部，而且對於特定目錄結構的站點生成極其不友好，並且性能說實話不是很好。

第三版

2017年的時候，隨着 Markdown 工具體驗愈來愈好，考慮以後，實在沒有必要在堅持使用 WordPress 做爲內容管理，因而在博客架構中廢棄了 WordPress 。而且當文章數量過千篇以後，Hexo 性能瓶頸愈來愈嚴重，交付於 CI 系統執行構建，須要消耗太多的資源，因而將其替換爲 Hugo。

• 在更換 Hexo 換爲 Hugo 前，我曾經掙扎着寫過幾個 Hexo 的插件，可是性能真的太差了，若是要平常使用，必須準備一臺起碼 2C2G 的雲主機閒置，太浪費了。
• 可是使用 Hugo 以後，失去了對 Node.js 這類容易「編輯執行」的程序能力後，想要達到以前的網站生成結果，除了修改 Hugo TPL外，全部的「花樣」便只剩下在構建先後進行文件處理、或者使用客戶端完善頁面內容了，不過這樣反而更加適合交付 CI ，進行徹底自動化。

第四版

今年五一假期的時候，網站在上一個版本的基礎上運行了快一年的時間裏，當初沒有轉換清理完畢的文章內容也陸陸續續的補齊了，在補齊內容的過程當中，我進一步抽象了 DataBridge，將來能夠輕易切換到更多不一樣的靜態站點生成工具或者靜態發佈平臺上。

而隨着一次次的迭代優化，CI/CD 流程和周邊腳本也變的效率愈來愈高， 準備數據 -> 生成站點 -> 處理文件 -> 進行發佈，這一套流程從最初的 2 分鐘縮減到了1 分鐘。

最後

計劃接下來再更新一輪，將未添加的 PWA 功能添加完畢，另外完全移除不須要的 Lib 依賴，進一步提升網站呈現速度，而後再嘗試可否將網站去中心化，藉助不一樣服務提供商的 CDN 和 頁面內埋入的版本控制腳本，變爲「分佈式」的網站，或許還會把網站關閉許久的評論功能補回來吧。

— EOF

---

我如今有一個小小的折騰羣，裏面彙集了一些喜歡折騰的小夥伴。

在不發廣告的狀況下，咱們在裏面會一塊兒聊聊軟件、HomeLab、編程上的一些問題，也會在羣裏不按期的分享一些技術沙龍的資料。

喜歡折騰的小夥伴歡迎掃碼添加好友。（請註明來源和目的，不然不會經過審覈） 關於折騰羣入羣的那些事

關於折騰羣入羣的那些事