“我苦心鍛煉了三年，我變禿了，也變強了。” —— 琦玉老師 0x00 大綱 0x01 前言 四個月前，我在《你是來找茬的吧？對自己的博客進行調優》一文中探討了以博客的使用者而不是開發者身份去進行優化，究竟能做到何種程度的問題。當時以 Edge 瀏覽器的開發者工具里的 lighthouse 評分和載入 ...
“我苦心鍛煉了三年，我變禿了，也變強了。” —— 琦玉老師
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
看來還可以繼續尋找新的優化方法。
