讀一開始我們的H5頁面秒開率只有30%左右，現(xiàn)在我們的H5頁面秒開率達到了 75%。這中間巨大的差異究竟有哪些黑科技在里面？我們?yōu)槭裁匆鯤5頁面的秒開優(yōu)化？我們的秒開指標是如何統(tǒng)計的？客戶端和H5是怎么配合做到 1+1>2的？監(jiān)控是如何發(fā)現(xiàn)H5頁面可優(yōu)化項的？我們又通過監(jiān)控發(fā)現(xiàn)了哪些可優(yōu)化的問題呢？

1. 背景

H5秒開優(yōu)化是一個老生常談的問題，本文將逐步介紹如何通過客戶端 + H5 的優(yōu)化手段（1+1>2）把秒開從 30% 提升到 75% ？后續(xù)接口預請求、客戶端預渲染以及預加載2.0上線后還會再次助力指標提升。

為什么要做優(yōu)化？

Global Web Performance Matters for ecommerce 的報告中指出：

• 47%的用戶更在乎網(wǎng)頁在2秒內(nèi)是否完成加載。
• 52%的在線用戶認為網(wǎng)頁打開速度影響到他們對網(wǎng)站的忠實度。
• 每慢1秒造成頁面 PV 降低11%，用戶滿意度也隨之降低降低16%。
• 近半數(shù)移動用戶因為在10秒內(nèi)仍未打開頁面從而放棄。

整體系統(tǒng)架構(gòu)圖：

2. 指標選擇

首先講一下得物用來衡量秒開的指標 FMP，那為什么不選擇 FCP 或者 LCP 呢？FCP 只有要渲染就會觸發(fā)，LCP 兼容性不佳，得物希望站在用戶的角度來衡量秒開這件事情，用戶從點擊打開一個WebView到首屏內(nèi)容完整的呈現(xiàn)出來的時間點就是得物定義的FMP觸發(fā)時機。

指標清楚了之后，再來看一下完整的 FMP 包含哪些耗時。

接下來將分為兩大部分進行介紹，客戶端優(yōu)化部分和H5 優(yōu)化部分。

3. 客戶端優(yōu)化

通過 HTML 預加載、HTML 預請求、離線包、接口預請求、鏈接?；?、預渲染等手段提升頁面首屏打開速度，其中預加載、預請求、離線包分別可提升10%左右的秒開。

3.1 HTML預加載

通過配置由客戶端提前下載好HTML主文檔，當用戶訪問時直接使用已經(jīng)下載好的HTML文檔，以此減少HTML網(wǎng)絡請求時間，從而提升網(wǎng)頁打開速度。

3.1.1 如何確定需要下載的頁面

前人栽樹后人乘涼，得物App有很多的資源位，banner、金剛位、中通位等，這些位置顯示什么內(nèi)容，早就已經(jīng)是智能推薦算法產(chǎn)出的了，那么就可以直接指定這些資源位進行預加載。

3.1.2 頁面緩存管理

頁面被預加載之后，總不能一直不更新吧？那么什么時候更新頁面的緩存呢？

• 預加載的頁面存放于內(nèi)存中，關(guān)閉App緩存就會被清除
• 通過配置過期時間人為控制最大緩存時間
• 在頁面進入后發(fā)起異步線程去更新HTML文檔。

被現(xiàn)實打臉：

但是在后面的灰度過程中被現(xiàn)實狠狠的教育了一頓，發(fā)現(xiàn)有些SSR的頁面會涉及到狀態(tài)的變更，比如說：領(lǐng)劵場景。這些狀態(tài)都是經(jīng)過SSR服務渲染好的，用戶在進入頁面時還沒有領(lǐng)劵，這個時候去更新HTML文檔，實屬更新了個寂寞，在用戶領(lǐng)劵之后關(guān)閉頁面再次進入，發(fā)現(xiàn)頁面中的狀態(tài)仍是讓用戶領(lǐng)劵，點擊領(lǐng)劵又告訴人家你已經(jīng)領(lǐng)過了。

改進措施

1. H5 頁面在打開時針對狀態(tài)可能會發(fā)生變更的組件，再次請求接口獲取最新的狀態(tài)數(shù)據(jù)。
2. 客戶端由進入頁面就更新HTML文檔修改為：關(guān)閉WebView時更新HTML文檔。

3.1.3 線上收益效果

至此問題也解決了，工程師的任務結(jié)束了嗎？如果你認為功能做上去就算結(jié)束，那么此時此刻請你一定要轉(zhuǎn)變思維，想一想我們的目標是什么？我們的目標是「提升秒開」，預加載只是一種提升秒開的手段，但是在功能做上去之后并不知道這個功能帶來了多少秒開的收益，因此在把功能開發(fā)完成上線之后，就要開始關(guān)注上線之后的結(jié)果，來看看預加載的性能表現(xiàn)如何。從下圖可以看到，預加載開啟狀態(tài)下可提升10%以上的秒開率。

3.1.4 遇到的挑戰(zhàn)

1. 預加載的頁面基本上都是 SSR 服務的頁面，預加載無形中造成了大量的請求，此時得物的SSR服務扛不住這么大的請求量；
2. 即使SSR 服務扛得住，也會對后端整個服務鏈路造成壓力。
3. 
   

（1）SSR服務擴容

要解決服務器壓力問題，很自然就會想到增加機器，于是我們對SSR機器數(shù)量做了一次擴容，將機器數(shù)量提升了一倍，這個時候繼續(xù)嘗試擴大預加載的用戶數(shù)量，但是仍然無法抗住這么大的QPS，而且此時還引發(fā)了第二個問題，算法部門的服務器發(fā)出了告警，于是放量計劃又一次遇到了阻礙。

（2）破局者 CDN

利用CDN 服務器的緩存能力既可以減輕 SSR 服務器的壓力又可以減少后端服務鏈路的壓力，這么好的東西為什么不用呢？這里留個懸念，后面將H5優(yōu)化部分會詳細介紹。

（3）客戶端配合改造

支持針對CDN域名進行全部開放預加載能力，針對非CDN域名保持原有放量比例。

3.1.5 開屏頁預加載

在這個過程中還分析了頁面的流量占比，發(fā)現(xiàn)開屏廣告來源的頁面流量占比也很高，那么是不是可以把開屏廣告的HTML文檔內(nèi)容也給預加載下來呢？

開屏頁面預加載策略

1. 對預加載列表進行去重，開屏廣告列表中可能會存在重復的頁面，他們的背景圖和生效時間是不同的；
2. 增加了生效時間相關(guān)配置，開屏廣告列表中存在于未來某段時間才會展示的頁面；
3. 添加黑白名單控制，開屏廣告列表中可能會有第三方合作頁面，他們不希望預加載統(tǒng)計會造成PV時不準確。

3.1.6 預加載展望

既然可以提前下載好HTML，那是不是可以更進一步，提前把頁面內(nèi)的資源加載好，這樣在打開一個頁面的時候可以減少大部分的網(wǎng)絡請求從而更快速的把內(nèi)容呈現(xiàn)給用戶。這里還需要考慮如何跟下面講到的離線包進行協(xié)作。

3.2 HTML預請求

在WebView初始化同時，去請求HTML主文檔，等待HTML文檔下載完成 且 WebView初始成功后渲染，減少用戶等待時間，客戶端請求成功后，WebView加載本地 HTML，并保存以供下次使用。預請求HTML開啟狀態(tài)下可提升8%左右的秒開。

預請求 VS 預加載

本質(zhì)上HTML預加載和HTML預請求的區(qū)別就是下載HTML文檔的時機不同， 預加載是在App啟動后用戶無任何操作的情況下就會去下載，但是預請求只會在用戶單擊打開H5頁面的時候才會去下載。如果用戶是第二次打開某個H5頁面，此時發(fā)現(xiàn)本地有已經(jīng)下載好的HTML且尚未過期就會直接使用，這個時候的行為表現(xiàn)就跟預加載的功能是一致的了。

3.2.1 遇到挑戰(zhàn)

上線之后發(fā)現(xiàn)預請求只提升了2%左右的秒開，經(jīng)過分析發(fā)現(xiàn)問題：

1. 緩存有效時間太短，頁面過期時間只配置了10分鐘，也就是說在10分鐘之后用戶就要重新去下載一次，那能不能把緩存時間延長呢？
2. H5頁面是沒有自更新能力，無法支持配置更長的緩存時間，跟預加載HTML問題一致。
3. 
   

3.2.2 深入挖掘

在本地用低端機對整個秒開耗時鏈路進行了分析，為什么要用低端機分析呢？低端機有個好處，天然的加上了慢放功能，可以最大程度發(fā)現(xiàn)問題。

（1）安卓h5 頁面加載 與 原生布局填充并行執(zhí)行

從圖中可以看出h5 頁面加載之前 耗時 分布在 activityStart() 函數(shù)，該函數(shù) 包含了 onCreateView ，其中耗時最長是 布局填充 inflate()，因為 WebView 對象是提前創(chuàng)建好的，直接從對象池中取出的，所以耗時主要在 初始化過程，WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines （耗時 87 us，不到 1 ms），耗時還有 WebView 的一些其他初始化，jockey 的初始化 等等。

而秒開的計算是包含了 View 初始化到 WebVIew url 加載 的耗時，從而發(fā)現(xiàn)了優(yōu)化點，可以將Webview loadUrl 前置，h5 頁面加載 與 原生布局填充并行執(zhí)行。在 onCreateView 時，創(chuàng)建 FrameLayout 進行返回，執(zhí)行 WebView loadUrl 之后，主線程開始 對布局進行 inflate，布局加載成功后，將其 addView 到 FrameLayout 中，減少了 loadUrl 的阻塞時長。中高端機型有 15ms 左右優(yōu)化，低端機型有 30 ~ 50 ms 優(yōu)化 效果。

（2）雙端下載HTML的時機提前至路由階段

預請求HTML時機是在進入到 native 頁面中，這個時間點距離用戶單擊事件已經(jīng)過去100ms，那么是否可以將下載HTML的時機提前呢？經(jīng)過一番探索，最終選擇在路由階段進行攔截，既可以統(tǒng)一收口而且距離用戶點擊的時間間隔可以忽略不計。通過這種方式將下載HTML時機提前了平均80ms+。

此時的流程變成了下面這樣。

可能有的同學會問了，為什么不在用戶點擊的時候去下載呢？從用戶點擊到路由肯定還是有耗時的。

1. 代碼層面不好維護，如果在點擊時就需要侵入到業(yè)務層面，入口千千萬，很難進行維護管理；
2. 從點擊到路由這部分耗時在線下進行了性能測試，幾乎可以忽略不計。

3.2.3 最終線上收益效果

在上述問題解決后，將緩存時間修改為1天，發(fā)現(xiàn)預請求HTML開啟狀態(tài)下可提升8%左右的秒開，已經(jīng)和預加載的效果相差不大了。

3.3 離線包

通過提前將H5頁面內(nèi)所需的css、js等資源聚合在一個壓縮包內(nèi)，由客戶端在App啟動后進行下載解壓縮，在后續(xù)訪問H5頁面時，匹配是否有本地離線資源，從而加速頁面訪問速度。

3.3.1 安卓實現(xiàn)

資源攔截這塊安卓這邊實現(xiàn)比較簡單，WebView支持 shouldInterceptRequest, 可以在該方法內(nèi)檢測是否需要進行資源攔截，需要的話返回 WebResourceResponse 對象，不需要直接返回 null。

3.3.2 iOS 實現(xiàn)

但是在iOS 這邊遇到了一些困難，調(diào)研了以下方案：

方案一：NSURLProtocol 攔截方式

NSURLProtocol 攔截方式，使用WKBrowsingContextController和registerSchemeForCustomProtocol。通過反射的方式拿到了私有的 class/selector。通過把注冊把 http 和 https 請求交給 NSURLProtocol 處理。通過這種方式確實可以攔截請求，但是發(fā)現(xiàn)post請求的body會出現(xiàn)丟失的問題。而且NSURLProtocol一經(jīng)注冊就是全局開啟。我們希望他只會攔截接入了離線包的頁面，但是沒有辦法控制他，他會攔截所有頁面的請求，包括第三方合作頁面，顯然這是無法接受的。

方案二：通過CustomProtocol攔截請求

在iOS 11及以上系統(tǒng)中, 擁有了加載自定義資源的API：WKURLSchemeHandler。

可以修改當前頁面url為自定義 scheme 協(xié)議，比如：https://fast.dewu.com 修改為 duapp://fast.dewu.com 然后在客戶端內(nèi)注冊該 scheme，前端配合修改頁面內(nèi)所有的資源請求未自適應協(xié)議，如：src="//fast.dewu.com/xxx" 就可以實現(xiàn)攔截。但是在測試過程中發(fā)現(xiàn)，接口為了安全起見只允許白名單內(nèi)的域名發(fā)起跨域請求，且無法配置多個域名，導致該方案無法繼續(xù)進行。

方案三：hook handlesURLScheme

仍然是使用 WKURLSchemeHandler 然后通過 hook WKWebview 的 handlesURLScheme 方法來支持 http 和 https 請求的代理。通過這種方式雖然可以攔截請求了，但是遇到了以下問題：

（1）body丟失問題

不過在 iOS 11.3 之后對這種情況做了修復處理，只有 blob 類型的數(shù)據(jù)會丟失。需要由JS來代理 fetch 和 XMLHttpRequest 的行為，在請求發(fā)起時將 body 內(nèi)容通過 JSBridge 告知 native，并將請求交給客戶端進行發(fā)起，客戶端在請求完成后 callback js 方法。

（2）Cookie 丟失、無法使用問題

通過代理 document.cookie 賦值和取值動作，交由客戶端來進行管理，但是這里需要額外注意一點，需要做好跨域校驗，防止惡意頁面對cookie進行修改。

3.3.3 遇到挑戰(zhàn)

至此功能開發(fā)完成上線，先來一組線上收益數(shù)據(jù)，安卓開啟離線情況有有10%左右的收益，但是iOS開啟離線的反而秒開率更低。經(jīng)過修復處理后iOS也可提升10%以上的秒開。

安卓和iOS實現(xiàn)差異

經(jīng)過分析對比發(fā)現(xiàn)，安卓的攔截動作比較輕，可以判斷是否需要攔截，不需要攔截可以交給WebView自己去請求。

但是iOS這邊一旦頁面開啟攔截后，頁面中所有的http和https請求都會被攔截掉，由客戶端發(fā)起請求進行響應，無法將請求交還給WebView自己去發(fā)起。

iOS 緩存問題修復

頁面中的資源經(jīng)過客戶端請求代理后原本第二次打開WebView本身會使用緩存的內(nèi)存，現(xiàn)在緩存也失效了，于是只能在客戶端內(nèi)實現(xiàn)了一套緩存機制。

1. 根據(jù) http 協(xié)議來判定哪些資源可以被緩存以及緩存的時長
2. 添加自定義的控制策略，僅允許部分類型的資源進行緩存

3.3.4 離線包下載錯誤率治理

從下圖可以看到離線包的下載錯誤率在 6% 左右浮動，這么高的下載錯誤率肯定是無法接受的， 經(jīng)過一系列優(yōu)化手段，把離線包下載錯誤率從6%左右浮動下降至 0.3%左右浮動。

先來看下優(yōu)化前的流程圖和問題點。

通過埋點發(fā)現(xiàn)大量 unknown host 、網(wǎng)絡請求失敗、網(wǎng)絡連接斷開的情況。分析代碼發(fā)現(xiàn)下載未做隊列控制，會同時并發(fā)下載多個離線包，從而導致多個下載任務爭搶資源的情況。針對發(fā)現(xiàn)的問題點做出了以下優(yōu)化：

1. 下載失敗添加重試機制，并可動態(tài)配置重試次數(shù)用于緩解網(wǎng)絡請求失敗、網(wǎng)絡連接斷開的問題。
2. 添加下載任務隊列管理功能，可動態(tài)配置并發(fā)下載數(shù)量，用于緩解不同下載任務爭搶資源的問題。
3. 針對弱網(wǎng)和無網(wǎng)絡情況延遲到網(wǎng)絡良好時下載。
4. 離線包下載支持 httpdns，用于解決域名無法解析的情況。

下面是優(yōu)化之后的流程圖：

3.3.5 展望

針對離線資源是直接存儲在磁盤上的，每次訪問都會有磁盤IO耗時，經(jīng)過在低端機器上做測試發(fā)現(xiàn)這個耗時會在 0 - 10ms 之間進行波動，后面會把內(nèi)存合理的利用起來，通過設置內(nèi)存上限，文件數(shù)量上限，甚至是文件類型，并通過 LRU 策略進行內(nèi)存文件的淘汰更新。

3.4 接口預請求

通過客戶端發(fā)起H5頁面首屏接口請求，遠比等待客戶端頁面初始化、下載HTML、JS下載執(zhí)行的時機更提前，從而節(jié)省用戶的首屏等待時間。在本地測試過程中發(fā)現(xiàn)接口預請求可提前100+ms，用戶也就可以更快的看到內(nèi)容。

3.4.1 功能介紹

客戶端會在App啟動后獲取配置，保存支持預請求的頁面地址及對應的接口信息，在用戶打開WebView時，會并行發(fā)起對應預請求的接口，并保存結(jié)果。當JS執(zhí)行開始獲取首屏數(shù)據(jù)時，會先詢問客戶端是否已經(jīng)存有對應的響應數(shù)據(jù)，如果此時已經(jīng)拿到數(shù)據(jù)則無需發(fā)起請求，否則 js 也會發(fā)起接口請求并開啟競速模式。以下是整體流程圖：

3.4.2 配置平臺

那么客戶端怎么知道這個頁面需要請求什么接口呢？以及接口的參數(shù)是什么呢？那自然少不了配置平臺，它支持以下功能：

1. 配置需要預加載的頁面 url并對應一個需要請求的 api url 以及參數(shù)
2. 配置審核功能，避免錯誤配置發(fā)布上線

3.4.3 QA 既然有了SSR服務端渲染為什么還需要接口預請求的功能？

首先即使是在 SSR 的情況下，首屏內(nèi)容中仍然可能有部分組件是骨架直出的，需要等待頁面渲染執(zhí)行時才會去請求數(shù)據(jù)，另外還有一部分頁面是SPA的。針對這兩種情況都能做到很好的補充。

3.5 預建連&鏈接?；?/h1>

開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。

3.5.1 網(wǎng)絡請求耗時分析

通過上圖可以看到一個網(wǎng)絡請求在經(jīng)過DNS解析耗時、TCP建連耗時、SSL建連耗時階段之后才能把請求發(fā)出去，那么是否可以節(jié)省這段時間的耗時呢？

客戶端常用的網(wǎng)絡請求框架如OkHttp等，都能完整支持http1.1與HTTP2的功能，也就支持連接復用。了解了這個連接復用機制優(yōu)勢，那就可以利用起來，比如在APP開屏等待的時候，就預先建立關(guān)鍵域名的連接，這樣進入相應頁面后可以更快的獲取到網(wǎng)絡請求結(jié)果，給予用戶更好體驗。在網(wǎng)絡環(huán)境偏差的情況下，這種預連接理論上會有更好的效果。

3.5.2 實現(xiàn)方案

可以通過對域名鏈接提前發(fā)起一個HEAD請求從而建立鏈接，網(wǎng)絡框架會自動將連接放入連接池。并在默認無操作5分鐘后進行釋放，在五分鐘內(nèi)重復執(zhí)行上述動作即可一直保持鏈接。

另外這里需要注意下連接池的數(shù)量問題，如果連接池的數(shù)據(jù)太小，但是域名比較多的話，通過預建連保持的鏈接很容易就會被釋放掉，這就需要通過域名收斂或者調(diào)大連接池的數(shù)量來進行優(yōu)化。

3.5.3 線上收益

那預建連會不會增加服務器的壓力呢？這個肯定是會的，首先會針對預建連功能本身就行灰度策略，在HTML頁面通過CDN托管后，直接針對 cdn 域名進行全量開啟，從而不用擔心 cdn 域名扛不住壓力。

來看一下線上效果，通過下圖可以看到在開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。

3.6 預渲染

客戶端提前通過WebView將頁面渲染好，等待用戶訪問時，可直接展示。從而達到瞬開效果。但是這種功能肯定不能對所有的頁面進行開放，而且存在一定的弊端。

1. 會額外消耗客戶端資源，需要在主線程空閑時執(zhí)行，并需要控制預渲染的頁面數(shù)量。
2. 如果頁面一進入就會下紅包雨，這種頁面是不適合做預渲染的，需要進行規(guī)避。

下圖【開學季】是業(yè)務上已經(jīng)進行預渲染的H5頁面，可以看到在打開【開學季】頁面時，頁面已經(jīng)渲染完畢，絲毫沒有等待過程。

后面計劃把這種能力放大到通用的webview上，針對大促以及PV量高的頁面進行開放。

4. H5 優(yōu)化

4.1 SSR服務端渲染

SSR服務端渲染（英語：server side render）一般情況下，一個H5頁面的數(shù)據(jù)渲染完全由客戶端來完成，先通過AJAX請求到頁面數(shù)據(jù)并把相應的數(shù)據(jù)填充到模板，形成完整的頁面來呈現(xiàn)給用戶。而服務端渲染把數(shù)據(jù)的請求和模板的填充放在了服務端，并把渲染的完整的頁面返回給客戶端。

SSR對于秒開有平均15%的提升，既然是服務端渲染，就會對服務器造成壓力，尤其是在預加載HTML功能開啟后，那得物是如何解決的呢？

4.1.1 前期優(yōu)化內(nèi)容

1. 接口緩存：node服務向ctx中注入redis實例，業(yè)務方在服務端渲染的邏輯中處理接口相關(guān)的緩存，這其中涉及：配置文件下發(fā)、ab接口。
2. 靜態(tài)頁面緩存：由于頁面完成是無接口交互，并且所有用戶展示都是一樣的，由renderToHtml生成靜態(tài)html資源，寫入緩存。
3. 無用戶狀態(tài)頁面緩存：此類頁面大多數(shù)情況下展示內(nèi)容都是一樣的，服務端請求的數(shù)據(jù)也都是一致的，服務端處理的時候根據(jù)是否有用戶登陸狀態(tài)判斷是否需要緩存。
4. 千人千面接口內(nèi)容由SSR修改為CSR，并顯示骨架圖，由于千人千面內(nèi)容都是由算法接口提供，且算法接口本身響應較慢，因此通過這種方式可以減少服務端響應耗時，且能更快速的給用戶展示內(nèi)容。

4.1.2 破局者CDN

通過這么多優(yōu)化手段仍然無法滿足預加載的需求，并且通過分析發(fā)現(xiàn)網(wǎng)絡階段耗時較長，最終還是搬出了CDN這個大殺器，一直沒上CDN的原因有很多，主要有以下幾方面：

（1）得物的頁面是千人千面的每個人看到的內(nèi)容都不同

通過上述優(yōu)化4即可解決，將原本SSR渲染的內(nèi)容修改CSR，由于已經(jīng)上了CDN了，后續(xù)計劃將這部分內(nèi)容再次修改回SSR，這樣用戶可以更快的看到商品而不是骨架，然后通過 CSR 的方式來更新內(nèi)容。

（2）頁面狀態(tài)變更，無法及時更新緩存

這個問題在上述客戶端預加載優(yōu)化部分已經(jīng)有解決方案了，可以通過在頁面打開后針對有需要的組件再次請求接口刷新數(shù)據(jù)以確保數(shù)據(jù)的準確性，但是這部分工作量也是比較大的，梳理出來的需要刷新狀態(tài)的組件就有30+，而且之后開發(fā)的組件都需要考慮狀態(tài)更新的事情。

（3）HTML模板內(nèi)容變更無法及時更新

引起模板內(nèi)容變更的地方有兩處，第一個場景就是在搭建器場景下，運營可以動態(tài)修改模板內(nèi)容導致頁面結(jié)構(gòu)變更（低頻次），第二個場景是項目發(fā)版后模板內(nèi)容需要更新（高頻）。

這個問題可以通過在感知到內(nèi)容變更時自動調(diào)用CDN服務商的刷新緩存接口來更新CDN緩存內(nèi)容。

4.2 預渲染HTML

通過puppeteer將SPA頁面渲染出來并將HTML文檔進行保存，配合上述頁面刷新策略，并將HTML通過CDN進行托管，讓你的 SPA 頁面 像 SSR 一樣絲滑。

主要實現(xiàn)方案是通過基于webpack的插件prerender-spa-plugin，并配置需要預渲染的路由，這樣經(jīng)過打包之后就會產(chǎn)出對應路由的頁面。方案本身是通用的，但是每接入一個頁面都需要人工check。

4.3 不起眼的css包大小優(yōu)化

眾所周知 css 加載會阻塞HTML渲染，最終將首屏公共css從118kb縮減至38kb，下圖通過 chrome 模擬弱網(wǎng)環(huán)境下的SSR頁面加載時序圖。從圖中可以看出 styles.fb201fce.chunk.css 下載耗時 18s，阻塞了頁面的渲染，HTML 主文檔耗時 2.38s 就已經(jīng)下載完成了，但是實際渲染時間卻是在 20s 之后。

優(yōu)化思路也比較單間，將首屏所需要的css 文件通過內(nèi)聯(lián)方式內(nèi)嵌到HTML中，由SSR服務一并返回，并對css文件進行拆分，按需加載。

思路有了，接下來就看怎么去實現(xiàn)了，最初嘗試了MiniCssExtractPlugin 插件他可以把css分成單獨的文件，并且每一個js會對應生成一個css文件，但是他需要建立在webpack5之上，然而項目中使用的next版本是9.5，于是就想著升級到最新版next12，升級后發(fā)現(xiàn)，在構(gòu)建中其他包各種報錯，發(fā)現(xiàn)有些包并不支持最新的next12，在嘗試一天的修復之后，仍未解決，且升級到最新版不確定是否會引發(fā)其他穩(wěn)定性問題，暫且擱置尋找其他方法。

經(jīng)過不懈的努力，通過閱讀 next 源碼發(fā)現(xiàn)了端倪，發(fā)現(xiàn)在打包時將所有的公共css通過 splitChunks 進行分組，由于項目中組件都是動態(tài)引入的，這里直接在 next.config.js 中修改webpack打包參數(shù)，將 splitChunks.cacheGroups.styles 配置刪除，使用默認的 chunks: async 配置，即可實現(xiàn)按需引入。

4.4 圖片優(yōu)化

（1）避免圖片src為空

雖然src屬性為空字符串，但瀏覽器仍然會向服務器發(fā)起一個HTTP請求，尤其是在SSR服務器壓力扛不住的情況下，因此這里需要特別注意一下。

（2）圖片壓縮以及格式選擇

WebP 的優(yōu)勢體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識別無差異的圖像質(zhì)量；同時具備了無損和有損的壓縮模式、Alpha 透明以及動畫的特性，在 JPEG 和 PNG 上的轉(zhuǎn)化效果都相當優(yōu)秀、穩(wěn)定和統(tǒng)一。

通過向圖片服務器傳遞參數(shù)選擇合適的分辨率。

4.5 細節(jié)優(yōu)化

（1）打包優(yōu)化

• 頁面組件拆分，優(yōu)先加載首屏內(nèi)容所需資源
• webpack splitchunks 有效拆分公共依賴，提高緩存利用率
• 組件按需加載
• Tree Shaking 縮減代碼體積

（2）非關(guān)鍵js、css延遲加載

• defer、async、動態(tài)加載js
• iOS 設備延遲加載 js

（3）媒體資源加載優(yōu)化

• 圖片、視頻懶加載
• 資源壓縮、通過向圖片服務器傳遞參數(shù)選擇合適的分辨率

（4）其他資源優(yōu)化

• 數(shù)據(jù)埋點上報延遲發(fā)送，不阻塞 onload 事件觸發(fā)
• 自定義字體優(yōu)化，使用 fontmin 生成精簡的字體包

（5）頁面渲染優(yōu)化

• 頁面渲染時間優(yōu)化

• SSR頁面首屏 css 內(nèi)聯(lián)(Critial CSS)

• 合理使用 Layers
• 布局抖動優(yōu)化：提前定好寬高
• 減少重排重繪操作

（6）代碼層面優(yōu)化

• 耗時任務分割

• 通過 Web Worker 減少主線程耗時

• 通過 RAF 回調(diào)，在線程空閑時執(zhí)行代碼邏輯
• 避免 css 嵌套過深

5. 監(jiān)控

為了幫助開發(fā)者更好地衡量和改進前端頁面性能，W3C性能小組引入了 Performance API ，其中Navigation Timing API 實現(xiàn)了自動、精準的頁面性能打點。得物前端性能監(jiān)控指標也都是從 Performance API 中獲取數(shù)據(jù)進行上報統(tǒng)計分析的。

5.1 系統(tǒng)架構(gòu)

SDK 數(shù)據(jù)采集完畢后，會上報到 阿里云 sls 日志平臺，隨后通過 flink 實時消費清洗數(shù)據(jù)后落庫至 clickhouse 中，平臺后端通過讀取 clickhouse 數(shù)據(jù)并做各種聚合處理后使用。

5.2 指標大盤

做優(yōu)化之前首先要建立監(jiān)控指標，互聯(lián)網(wǎng)稱之為抓手，沒有監(jiān)控指標的情況下，任你怎么優(yōu)化，都不知道優(yōu)化的效果怎么樣，更不知道下一步該做什么？以及還有哪些問題沒解決。因此優(yōu)化之前指標先行，當然一定要指標的準確性。

指標大盤主要包含以下功能：

1. 可快速查看某段時間內(nèi)的版本、設備廠商、設備名、設備系統(tǒng)版本以及網(wǎng)絡占比情況，還可以根據(jù)這些字段進行篩選排查。
2. 中間區(qū)域展示了比較關(guān)注的整體以及活動頁面的客戶端耗時和H5秒開耗時的情況。
3. 底部區(qū)域展示了各業(yè)務域的秒開耗時情況。
4. 這里同時展示了平均耗時和90分位耗時，平均耗時有個弊端就是很容易被平均，大家應該都有被平均的經(jīng)歷。90分位耗時這里簡單講解一下：意思就是有90%的訪問耗時是低于90分位耗時的，以此類推 50 分位就是有50%的訪問耗時是低于50分位的，分位值是將所有的耗時數(shù)據(jù)從小到大排序后得出的。

5.3 白屏監(jiān)控

在正常情況下，完成上述的優(yōu)化措施后用戶基本是可以秒開 H5 頁面的了。但異常情況總是會有的，用戶的網(wǎng)絡環(huán)境和系統(tǒng)環(huán)境千差萬別，甚至 WebView 也可能發(fā)生內(nèi)部崩潰。當發(fā)生問題時，用戶看到的可能就直接只是一個白屏頁面了，所以進一步的優(yōu)化手段就是需要去檢測是否發(fā)生白屏以及相應的應對措施。

檢測白屏最直觀的方案就是對 WebView 進行截圖，遍歷截圖的像素點的顏色值，如果非純色的顏色點超過一定的閾值，就可以認為不是白屏。首先獲取包含 WebView 視圖的 Bitmap 對象，然后把截圖縮小到指定的分辨率大小如:100*auto，遍歷檢測圖片的像素點，當非純色的像素點大于 5% 的時候就可以認為是非白屏的情況，但是還有很多列外的情況，我們通過圖片識別技術(shù)對截圖進行分析，可以很好的感知當前是否白屏、是不是在loading、是不是特殊頁面等。

白屏是一個重要的指標，我們針對整體白屏率快速拉升、新增白屏頁面發(fā)出告警通知，便于開發(fā)人員及時介入開始排查問題。

5.4 性能問題發(fā)現(xiàn)

主要通過 CDN 未覆蓋監(jiān)控、http請求監(jiān)控、網(wǎng)絡監(jiān)控（加載失敗、耗時異常、傳輸大小異常）、圖片監(jiān)控（未壓縮、分辨率異常）等監(jiān)控手段發(fā)現(xiàn)頁面中的潛在問題，同時還提供了問題分析能力，在問題分析頁面輸入頁面url地址即可幫助您發(fā)現(xiàn)問題并給出修改建議。

5.4.1 CDN未覆蓋監(jiān)控

CDN的重要性不言而喻，它可以加速資源訪問速度，從而提升用戶體驗，我們通過對線上埋點數(shù)據(jù)分析，找出CDN未覆蓋的資源列表，從而推動各業(yè)務同學優(yōu)化。

5.4.2 HTTP請求監(jiān)控

為什么要監(jiān)控HTTP請求呢？我們先來看一下HTTPS相對于HTTP新增的特點：

1. 內(nèi)容加密：采用混合加密技術(shù)，中間者無法直接查看明文內(nèi)容
2. 驗證身份：通過證書認證客戶端訪問的是自己的服務器
3. 保護數(shù)據(jù)完整性：防止傳輸?shù)膬?nèi)容被中間人冒充或者篡改

那么HTTP就容易被中間人查看到內(nèi)容，甚至被篡改，既然如此為了我們服務的安全性就需要對現(xiàn)有的http協(xié)議統(tǒng)一進行升級改造，那就需要監(jiān)控去發(fā)現(xiàn)。

5.4.3 網(wǎng)絡監(jiān)控

某些頁面秒開率低，那就要分析一下原因，是不是這個頁面的接口響應比較慢呢，還是說頁面本身有請求比較大的資源？如果發(fā)生網(wǎng)絡請求失敗的情況也要第一時間感知，不能被動等待用戶反饋。

5.4.4 圖片監(jiān)控

包含圖片未壓縮、圖片分辨率異常、圖片傳輸大小大于 300kb 異常、動圖資源傳輸大小大于 1M 異常功能。

5.4.5 頁面問題分析

上面列出來一堆功能，對于業(yè)務的同學可能比較煩惱，我一個頁面具體有哪些問題呢？你不能讓我去上面的功能里面一個個看，哪個異常是我負責的頁面的吧？這個功能本身就行將現(xiàn)有的功能利用起來，通過一個頁面path進行聚合分析。

5.5 異常監(jiān)控

H5異常一直是使用 sentry 進行監(jiān)控的，但是sentry系統(tǒng)因缺乏同PV、DAU數(shù)據(jù)的關(guān)聯(lián)性，因此無法衡量產(chǎn)品異常發(fā)生后所帶來的嚴重程度。在業(yè)務域關(guān)聯(lián)上的缺失導致異常問題無法根據(jù)業(yè)務域進行劃分。用戶行為日志也尚未與Native 端側(cè)打通，在問題分析時容易遇到上下文不全的瓶頸。還有一個問題是sentry會有限流措施，當qps較高時會丟棄一部分異常數(shù)據(jù)。

由于sentry已經(jīng)可以幫助我們進行一定的問題排查分析能力，我們不打算做sentry同樣的功能，而是做sentry不支持的部分，針對上述問題我們設計了以下功能：

• 異常問題指標衡量

• 增加異常率、頁面異常率、影響用戶率趨勢
• 增加問題多維度(系統(tǒng)版本、APP版本、H5發(fā)布版本、網(wǎng)絡等)下的分布占比、業(yè)務域劃分

• 異常問題聚合能力增強（聚合問題能力增強）

• 異常列表支持最新新增、Top PV、異常次數(shù)、影響用戶數(shù)排序
• 區(qū)分三方sdk異常、接口異常等不同異常類型劃分

6. 未來展望&總結(jié)

雖然目前秒開率已經(jīng)做到了75%以上，但是同時我們還有一個重要的指標，90分位耗時，致力于提升末尾用戶H5頁面使用體驗，在90分位優(yōu)化完成后，可能會考慮繼續(xù)深入優(yōu)化95分位耗時。

最后感謝那些為得物H5頁面秒開做出貢獻的同學，感謝H5團隊，同學們都很棒，各種優(yōu)化手段和想法層出不窮。

至此我們系統(tǒng)的講解了背景以及從指標建立到秒開優(yōu)化上線的全過程，全文分成了三個部分，客戶端、H5、以及監(jiān)控。如果閱讀本文對您有所收獲，麻煩您動一動發(fā)財?shù)男∈贮c個贊吧！如果閱讀完還意猶未盡或者有什么問題和想法歡迎留言區(qū)評論交流。

最后奉上整體優(yōu)化腦圖：

*文/徐銘

歡迎關(guān)注「得物技術(shù)」微信公眾號，每周一三五晚18:30更新技術(shù)干貨
要是覺得文章對你有幫助的話，歡迎評論轉(zhuǎn)發(fā)點贊～

近女王大人為了通過某認證考試，交了2000RMB，官方居然沒有給線下教材資料，直接給的是在線教材，教材是PDF的但是是內(nèi)嵌在網(wǎng)頁內(nèi)，可惜卻沒有給具體的PDF地址，無法下載，看到女王大人一點點的截圖保存，深感心痛。思考能否通過腳本實現(xiàn)爬取網(wǎng)頁內(nèi)嵌的PDF并完成下載。

思路：

1. 查看網(wǎng)頁源代碼,找尋PDF文件地址。很多時候,網(wǎng)站會在網(wǎng)頁源代碼中隱藏PDF文件的直接下載地址,我們可以通過查找關(guān)鍵字like ".pdf"找到該地址,然后直接下載。

2. 使用瀏覽器開發(fā)者工具分析網(wǎng)絡請求,找尋PDF文件地址。當我們訪問網(wǎng)頁時,瀏覽器會自動發(fā)出許多網(wǎng)絡請求,其中很可能包含PDF文件的請求,我們可以通過分析找到請求URL并下載。

3. 使用爬蟲程序自動分析網(wǎng)頁并下載PDF。我們可以編寫爬蟲程序使用Requests庫訪問網(wǎng)頁,自動解析網(wǎng)頁源代碼和網(wǎng)絡請求,一旦發(fā)現(xiàn)PDF文件請求就進行下載。

首先通過網(wǎng)頁源碼，查找PDF文件失敗，繼而轉(zhuǎn)為使用python進行爬取。

使用Requests獲取網(wǎng)頁內(nèi)容:

import requests
url="目標網(wǎng)頁地址"
response=requests.get(url)
html=response.text

解析網(wǎng)頁源碼找尋PDF地址:

import re
pattern=re.compile(r'http.*?.pdf')
result=pattern.findall(html)
pdf_url=result[0] # 獲取第一個匹配結(jié)果

下載PDF文件:

import requests
pdf_response=requests.get(pdf_url)
with open("pdf文件.pdf", "wb") as f:
f.write(pdf_response.content)

將上述腳本代碼的思路整合行程統(tǒng)一執(zhí)行腳本：

import requests
import re
url="目標網(wǎng)頁地址"
response=requests.get(url)
html=response.text
pattern=re.compile(r'http.*?.pdf')
result=pattern.findall(html)
pdf_url=result[0]
pdf_response=requests.get(pdf_url)
with open("course.pdf", "wb") as f:
f.write(pdf_response.content)
print("PDF文件已下載!")

執(zhí)行結(jié)果不理想，代碼報錯

pdf_url=result[0]
~~~~~~^^^
IndexError: list index out of range

報錯原因分析可能原因：

1. 網(wǎng)頁源碼中不存在PDF URL,正則表達式無法匹配,result為空列表。

2. 正則表達式匹配模式錯誤,無法正確匹配PDF URL,導致result為空列表。

通過重新打開瀏覽器打開目標網(wǎng)頁地址，發(fā)現(xiàn)跳轉(zhuǎn)至了首頁，并且處于未登陸狀態(tài)。開來要完成PDF爬取還需增加對網(wǎng)站當前賬號的cookie，session，token等信息的獲取，而這些信息基本都是通過瀏覽器開發(fā)者工具獲取。

有點復雜，既然又轉(zhuǎn)回開發(fā)者工具，那么轉(zhuǎn)變思路，通過控制臺命令的方式來進行PDF爬取試試。

開發(fā)者調(diào)試模式-控制臺命令：

let pdf_url="";
document.querySelectorAll("iframe, object, embed").forEach(element=> {
if (element.src.includes(".pdf")) {
pdf_url=element.src;
}
});
console.log(pdf_url);

執(zhí)行結(jié)果反饋了PDF的絕對地址，使用瀏覽器能正常打開該PDF文件，使用下載工具完成PDF的下載。