我變禿了，也變強了——再探部落格調優

「我苦心鍛鍊了三年，我變禿了，也變強了。」 —— 琦玉老師

0x00 大綱

0x01 前言

四個月前，我在《你是來找茬的吧？對自己的部落格進行調優》一文中探討了以部落格的使用者而不是開發者身份去進行優化，究竟能做到何種程度的問題。當時以 Edge 瀏覽器的開發者工具裡的 lighthouse 評分和載入時間作為基準，經過一系列的針對性優化調整，將部落格首頁的評分逼近到了「效能（99/100）」、「無障礙閱讀（100/100）」的水平，但是當時有一個遺憾，就是沒能完成雙百，那麼時隔多日，這次就要集中一點，登峰造極，完成雙百挑戰。

0x02 書接上回

上回說到，我們優化後的首頁 lighthouse 評分如下：

那麼效能部分扣掉的一分是在哪裡扣掉的呢？點選「檢視計算器」連結，裡面會有詳細的一個評分情況，如下圖所示：

可以看到評分是相當苛刻的，而且五項標準的分數權重不一樣，也即是說，只要你有任何一項有短板，就算其它分數再高，也沒辦法獲得100的評分。可以看到這裡主要的扣分項是 FCP 首次內容繪製時間和 LCP 最大內容繪製時間，至於原因，其實在上一篇文章的末尾有提到過，就是有些資源屬於頁面強制載入項，我們作為使用者是沒有辦法去裁剪和控制的。

既然堵不住，那能不能加速呢？

0x03 效能調優

DNS 預獲取（DNS-prefetch）

在自己的部落格首頁，按 F12 開啟開發者工具，切換到「網路」標籤，然後重新整理部落格首頁，在 URL 一列，可以檢視到所有資源的載入的URL地址。然後你會發現，這些資源並非全部來源於同一個伺服器，至少可以看到以下不同於主站地址 www.cnblogs.com 的二級或三級子域名：

https://common.cnblogs.com/
https://images.cnblogs.com/
https://pic.cnblogs.com/
https://blog-static.cnblogs.com/
https://account.cnblogs.com/

我們開啟命令提示字元或者其它你喜歡的終端，輸入nslookup命令（注意不能用ping指令，部分伺服器出於安全考慮，是禁用 ICMP 協定存取的），檢視各個域名對應的 DNS 解析地址，就會發現它們的 IP 地址是不一樣的，以主站和 pic.cnblogs.com 為例：

那麼如果將所有要存取的域名 DNS 提前進行解析，是不是可以加快存取速度呢？答案是肯定的。藉助 DNS 預獲取（DNS-prefetch）技術，可以達到我們的目的，在 MDN Web Docs 上，對於該技術是這樣闡述的：

DNS-prefetch (DNS 預獲取) 是嘗試在請求資源之前解析域名。這可能是後面要載入的檔案，也可能是使用者嘗試開啟的連結目標。

當瀏覽器從（第三方）伺服器請求資源時，必須先將該跨域域名解析為 IP 地址，然後瀏覽器才能發出請求。此過程稱為 DNS 解析。DNS 快取可以幫助減少此延遲，而 DNS 解析可以導致請求增加明顯的延遲。對於開啟了與許多第三方的連線的網站，此延遲可能會大大降低載入效能。

DNS-prefetch 可幫助開發人員掩蓋 DNS 解析延遲。

以我自己的部落格為例，我將以下域名加入了預取列表（注意因為這些地址都是基於 HTTPS 協定進行存取，所以我這裡省略了協定名稱，但如果你是載入第三方資源的，務必知曉其存取協定，可能需要指定 HTTP 字首，請根據實際情況修改）：

<link rel="dns-prefetch" href="//common.cnblogs.com">
<link rel="dns-prefetch" href="//images.cnblogs.com">
<link rel="dns-prefetch" href="//pic.cnblogs.com">
<link rel="dns-prefetch" href="//blog-static.cnblogs.com">
<link rel="dns-prefetch" href="//account.cnblogs.com">

注意這裡不需要新增主站的地址，因為主站的 DNS 在瀏覽器存取那一刻已經被解析過了。

預連線（preconnect）

DNS 預獲取（DNS-prefetch）技術可以與預連線（preconnect）技術聯用，這裡同樣援引 MDC Web Docs 的解釋：

DNS-prefetch 僅執行 DNS 查詢，但preconnect會建立與伺服器的連線。如果站點是通過 HTTPS （提供）服務的，則此過程包括 DNS 解析，建立 TCP 連線以及執行 TLS 握手。將兩者結合起來可提供進一步減少跨域請求的感知延遲的機會。

在上面的 DNS 預獲取列表後，增加下面的預連線列表：

<link rel="preconnect" href="//common.cnblogs.com">
<link rel="preconnect" href="//images.cnblogs.com/">
<link rel="preconnect" href="//pic.cnblogs.com/">
<link rel="preconnect" href="//blog-static.cnblogs.com/">
<link rel="preconnect" href="//account.cnblogs.com/">

我們看下效果，以userinfo介面呼叫為例（存取 account.cnblogs.com）為例，增加 DNS 預獲取優化之前耗時是這樣的：

優化之後，變成了這樣，可以看到還是有效果的：

預載入（preload）

如果頁面裡面有大量鏈式載入的資源就要注意了，這往往意味著前置資源載入之前，用到了後續關鍵資源的地方就有可能被阻塞，理想情況下，所有資源的請求鏈應儘可能的短。但是對於沒有辦法避免鏈式載入，而所需的資源又確定會在後續渲染當中用到的場景，就可以用預載入（preload）技術來優化。

以自定義的頭像為例，需要由自定義的主題指令碼通過prepend的方式動態新增節點，這意味著主題指令碼和jquery-2.2.0.min.js完成載入之前，該頭像都暫時不可用。但是頭像的 URL 地址我們是預先知道的，這個等待就白白浪費了許多時間。

我們可以把即將要用到的有確定地址的資源告訴瀏覽器，讓它把資料提前準備好，像這樣：

<link rel="preload" as="image" href="//images.cnblogs.com/cnblogs_com/mylibs/1647185/o_200214034545avatar.png">

可以看到請求鏈變短了，而且載入時間也提前了。同時也要注意，預載入（preload）並非在所有瀏覽器中都支援，不過好在它可以安全降級，頂多是不生效，不會影響到頁面的正常使用。

減少不必要的 HTTP 呼叫

儘管我已經在部落格園後臺-選項頁面中的「側邊欄控制元件」部分，取消勾選了「日曆」模組，但不知為何網路請求中還是有一次日曆介面的呼叫，儘管它啥也沒幹，卻白白浪費了幾十毫秒……

這個呼叫是從公告欄裡面的loadBlogDefaultCalendar函數發起的，這個函數定義在blog-common.min.js檔案裡——上一篇文章提到過，這個檔案是預設載入的，是部落格園的公共JavaScript函數庫，無法遮蔽。

但是loadBlogDefaultCalendar是作為全域性函數發起匿名呼叫的，那麼在blog-common.min.js檔案載入之後，loadBlogDefaultCalendar函數執行之前，我們是可以利用JavaScript Function Hijacking把它替換掉的，像這樣：

<script>window.loadBlogDefaultCalendar=Function.prototype</script>

它剛好可以與前面所有的優化一起放在部落格園後臺-設定頁面中「頁首 HTML 程式碼」處，儲存後重新整理頁面，再看原來的 AJAX 請求已經沒有了：

使用自定義的語法高亮

原先我使用的是園子自帶的prism.js語法高亮，它會根據頁面中的language type自動載入對應語言的高亮模組。對於一個頁面有多種語言或開啟了行號顯示的情況，可能會發生多次的模組載入，那麼你會在控制檯看到prism-autoloader.min.js同時載入了若干個prism-*開頭的指令碼。那為什麼說是可能呢？因為prism.js裡面其實已經整合了多種常用語言，除非你用到了裡面沒有的語言模組或者外掛，才會觸發載入動作。

出於減少網路請求次數和縮減體積的目的，我決定使用自定義的語法高亮，在prism.js的官網上可以很方便的客製化模組，只勾選自己常用的幾種語言即可，BTW，我還使用了彩虹括號外掛……總之，像買菜一樣選擇自己想要的東西就好了：

最終你會得到一份 JavaScript 和一份 CSS 檔案，把它像自定義指令碼和主題一樣引入到部落格里面就可以了。如果你追求極限，可以將它們與你自己的指令碼和樣式檔案合併——當然這是有代價的，不利於後期的獨立維護和升級。

進一步精簡 JavaScript 和 CSS

在開發者工具裡找到」覆蓋範圍「標籤，如果沒有，可能要點選旁邊的」+「號手工新增。點選」開始檢測覆蓋率並重新整理頁面「，覆蓋率統計在你手工點選停止前會一直進行，這時候你可以去頁面進行各種操作，儘可能地觸發程式碼。隨後在覆蓋率報告中，可以看到當前各個 JavaScript 和 CSS 的使用情況：

點選具體的檔案，會跳轉到」原始碼「標籤。 藍色表示該程式碼已被執行過，紅色表示這一行程式碼未執行，在載入網頁時不需要：

注意：僅僅依靠紅色來判斷程式碼未執行是不靠譜的，因為這並不表示該程式碼永遠不會用到，這裡僅僅是統計了頁面載入時的覆蓋率，如果你在頁面執行一些其它的操作，很有可能就會觸發更多的程式碼執行，覆蓋率也會隨之發生變化。

這樣做的目的是找出優先載入和優先執行項，如果指令碼和樣式表體積較大，就可以按照執行優先順序拆分，利用前面提到的預載入（preload）技術將最基礎部分優先載入，後續使用到的指令碼和樣式延遲載入或者按需載入。儘量減少或加快關鍵資源的載入，依然是提高 FP、FCP 和 LCP 分數的關鍵。

效能輔助分析

如果說 lighthouse 能幫你評估頁面的總體情況的話，那麼效能分析工具則可以助你從細節入手找到瓶頸。同為開發者工具裡，切換到「效能」標籤，點選」開始分析並重新載入頁面「按鈕，能夠自動重新整理當前頁面並對其進行取樣分析，最終生成的報告如下所示：

在這裡可以看到瀏覽器在渲染當前頁面時所做的各項工作的耗時統計以及負載分析，在報告摘要中，詳細羅列了各個步驟所消耗的時間佔比，建議從佔比最大的部分開始優化，因為這樣的收益可能是最高的。

如果效能報告中出現了紅色三角形長任務（被標記紅色），也是需要重點關注的，它指示主執行緒上耗時過長且效能緩慢的工作，通過檢視對應時間軸火焰圖上最寬的部分，找到耗時的原因。

此外，還可以關注 FP、FCP、LCP 的觸發時機，以及 CLS 的觸發次數和位置等諸多細節部分。前面我們提到過，如果 CLS 發生次數過多，將會使使用者體驗下降，同時嚴重影響評分。

另一類比較關鍵的事件是」重新計算樣式「事件，如果發現了長時間執行的 「重新計算樣式」事件，可以選中它，然後在下方點選 「選擇器統計資訊」功能來了解哪些 CSS 選擇器佔用的時間最多。從我的個人經驗來看，通常來說 CSS 的優化收益不是很大（微秒級），除非有很嚴重的效能問題，選擇前面幾項耗時最突出的選擇器進行優化是比較划算的方案。

由於每個使用者的頁面情況不盡相同，只能針對性的進行分析，這裡只能描述下大概的思路。

0x04 小結

在經過一系列的究極折磨後，這是首頁最終的 lighthouse 評分：

可以看到，我們其實並沒有拿到滿分，只是近似滿分：

(0.1×98 + 0.1×100 + 0.25×99 + 0.3×100 + 0.25×100)/(0.1 + 0.1 + 0.25 + 0.3 + 0.25) = 99.55

看來還可以繼續尋找新的優化方法。