整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
讀一開始我們的H5頁面秒開率只有30%左右，現(xiàn)在我們的H5頁面秒開率達(dá)到了 75%。這中間巨大的差異究竟有哪些黑科技在里面？我們?yōu)槭裁匆鯤5頁面的秒開優(yōu)化？我們的秒開指標(biāo)是如何統(tǒng)計的？客戶端和H5是怎么配合做到 1+1>2的？監(jiān)控是如何發(fā)現(xiàn)H5頁面可優(yōu)化項的？我們又通過監(jiān)控發(fā)現(xiàn)了哪些可優(yōu)化的問題呢？
H5秒開優(yōu)化是一個老生常談的問題，本文將逐步介紹如何通過客戶端 + H5 的優(yōu)化手段（1+1>2）把秒開從 30% 提升到 75% ？后續(xù)接口預(yù)請求、客戶端預(yù)渲染以及預(yù)加載2.0上線后還會再次助力指標(biāo)提升。
為什么要做優(yōu)化？
Global Web Performance Matters for ecommerce 的報告中指出：
整體系統(tǒng)架構(gòu)圖：
首先講一下得物用來衡量秒開的指標(biāo) FMP，那為什么不選擇 FCP 或者 LCP 呢？FCP 只有要渲染就會觸發(fā)，LCP 兼容性不佳，得物希望站在用戶的角度來衡量秒開這件事情，用戶從點擊打開一個WebView到首屏內(nèi)容完整的呈現(xiàn)出來的時間點就是得物定義的FMP觸發(fā)時機。
指標(biāo)清楚了之后，再來看一下完整的 FMP 包含哪些耗時。
接下來將分為兩大部分進(jìn)行介紹，客戶端優(yōu)化部分和H5 優(yōu)化部分。
通過 HTML 預(yù)加載、HTML 預(yù)請求、離線包、接口預(yù)請求、鏈接保活、預(yù)渲染等手段提升頁面首屏打開速度，其中預(yù)加載、預(yù)請求、離線包分別可提升10%左右的秒開。
通過配置由客戶端提前下載好HTML主文檔，當(dāng)用戶訪問時直接使用已經(jīng)下載好的HTML文檔，以此減少HTML網(wǎng)絡(luò)請求時間，從而提升網(wǎng)頁打開速度。
前人栽樹后人乘涼，得物App有很多的資源位，banner、金剛位、中通位等，這些位置顯示什么內(nèi)容，早就已經(jīng)是智能推薦算法產(chǎn)出的了，那么就可以直接指定這些資源位進(jìn)行預(yù)加載。
頁面被預(yù)加載之后，總不能一直不更新吧？那么什么時候更新頁面的緩存呢？
被現(xiàn)實打臉：
但是在后面的灰度過程中被現(xiàn)實狠狠的教育了一頓，發(fā)現(xiàn)有些SSR的頁面會涉及到狀態(tài)的變更，比如說：領(lǐng)劵場景。這些狀態(tài)都是經(jīng)過SSR服務(wù)渲染好的，用戶在進(jìn)入頁面時還沒有領(lǐng)劵，這個時候去更新HTML文檔，實屬更新了個寂寞，在用戶領(lǐng)劵之后關(guān)閉頁面再次進(jìn)入，發(fā)現(xiàn)頁面中的狀態(tài)仍是讓用戶領(lǐng)劵，點擊領(lǐng)劵又告訴人家你已經(jīng)領(lǐng)過了。
改進(jìn)措施
至此問題也解決了，工程師的任務(wù)結(jié)束了嗎？如果你認(rèn)為功能做上去就算結(jié)束，那么此時此刻請你一定要轉(zhuǎn)變思維，想一想我們的目標(biāo)是什么？我們的目標(biāo)是「提升秒開」，預(yù)加載只是一種提升秒開的手段，但是在功能做上去之后并不知道這個功能帶來了多少秒開的收益，因此在把功能開發(fā)完成上線之后，就要開始關(guān)注上線之后的結(jié)果，來看看預(yù)加載的性能表現(xiàn)如何。從下圖可以看到，預(yù)加載開啟狀態(tài)下可提升10%以上的秒開率。
（1）SSR服務(wù)擴容
要解決服務(wù)器壓力問題，很自然就會想到增加機器，于是我們對SSR機器數(shù)量做了一次擴容，將機器數(shù)量提升了一倍，這個時候繼續(xù)嘗試擴大預(yù)加載的用戶數(shù)量，但是仍然無法抗住這么大的QPS，而且此時還引發(fā)了第二個問題，算法部門的服務(wù)器發(fā)出了告警，于是放量計劃又一次遇到了阻礙。
（2）破局者 CDN
利用CDN 服務(wù)器的緩存能力既可以減輕 SSR 服務(wù)器的壓力又可以減少后端服務(wù)鏈路的壓力，這么好的東西為什么不用呢？這里留個懸念，后面將H5優(yōu)化部分會詳細(xì)介紹。
（3）客戶端配合改造
支持針對CDN域名進(jìn)行全部開放預(yù)加載能力，針對非CDN域名保持原有放量比例。
在這個過程中還分析了頁面的流量占比，發(fā)現(xiàn)開屏廣告來源的頁面流量占比也很高，那么是不是可以把開屏廣告的HTML文檔內(nèi)容也給預(yù)加載下來呢？
開屏頁面預(yù)加載策略
既然可以提前下載好HTML，那是不是可以更進(jìn)一步，提前把頁面內(nèi)的資源加載好，這樣在打開一個頁面的時候可以減少大部分的網(wǎng)絡(luò)請求從而更快速的把內(nèi)容呈現(xiàn)給用戶。這里還需要考慮如何跟下面講到的離線包進(jìn)行協(xié)作。
在WebView初始化同時，去請求HTML主文檔，等待HTML文檔下載完成 且 WebView初始成功后渲染，減少用戶等待時間，客戶端請求成功后，WebView加載本地 HTML，并保存以供下次使用。預(yù)請求HTML開啟狀態(tài)下可提升8%左右的秒開。
預(yù)請求 VS 預(yù)加載
本質(zhì)上HTML預(yù)加載和HTML預(yù)請求的區(qū)別就是下載HTML文檔的時機不同， 預(yù)加載是在App啟動后用戶無任何操作的情況下就會去下載，但是預(yù)請求只會在用戶單擊打開H5頁面的時候才會去下載。如果用戶是第二次打開某個H5頁面，此時發(fā)現(xiàn)本地有已經(jīng)下載好的HTML且尚未過期就會直接使用，這個時候的行為表現(xiàn)就跟預(yù)加載的功能是一致的了。
上線之后發(fā)現(xiàn)預(yù)請求只提升了2%左右的秒開，經(jīng)過分析發(fā)現(xiàn)問題：
在本地用低端機對整個秒開耗時鏈路進(jìn)行了分析，為什么要用低端機分析呢？低端機有個好處，天然的加上了慢放功能，可以最大程度發(fā)現(xiàn)問題。
從圖中可以看出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 進(jìn)行返回，執(zhí)行 WebView loadUrl 之后，主線程開始 對布局進(jìn)行 inflate，布局加載成功后，將其 addView 到 FrameLayout 中，減少了 loadUrl 的阻塞時長。中高端機型有 15ms 左右優(yōu)化，低端機型有 30 ~ 50 ms 優(yōu)化 效果。
預(yù)請求HTML時機是在進(jìn)入到 native 頁面中，這個時間點距離用戶單擊事件已經(jīng)過去100ms，那么是否可以將下載HTML的時機提前呢？經(jīng)過一番探索，最終選擇在路由階段進(jìn)行攔截，既可以統(tǒng)一收口而且距離用戶點擊的時間間隔可以忽略不計。通過這種方式將下載HTML時機提前了平均80ms+。
此時的流程變成了下面這樣。
可能有的同學(xué)會問了，為什么不在用戶點擊的時候去下載呢？從用戶點擊到路由肯定還是有耗時的。
在上述問題解決后，將緩存時間修改為1天，發(fā)現(xiàn)預(yù)請求HTML開啟狀態(tài)下可提升8%左右的秒開，已經(jīng)和預(yù)加載的效果相差不大了。
通過提前將H5頁面內(nèi)所需的css、js等資源聚合在一個壓縮包內(nèi)，由客戶端在App啟動后進(jìn)行下載解壓縮，在后續(xù)訪問H5頁面時，匹配是否有本地離線資源，從而加速頁面訪問速度。
資源攔截這塊安卓這邊實現(xiàn)比較簡單，WebView支持 shouldInterceptRequest, 可以在該方法內(nèi)檢測是否需要進(jìn)行資源攔截，需要的話返回 WebResourceResponse 對象，不需要直接返回 null。
但是在iOS 這邊遇到了一些困難，調(diào)研了以下方案：
NSURLProtocol 攔截方式，使用WKBrowsingContextController和registerSchemeForCustomProtocol。通過反射的方式拿到了私有的 class/selector。通過把注冊把 http 和 https 請求交給 NSURLProtocol 處理。通過這種方式確實可以攔截請求，但是發(fā)現(xiàn)post請求的body會出現(xiàn)丟失的問題。而且NSURLProtocol一經(jīng)注冊就是全局開啟。我們希望他只會攔截接入了離線包的頁面，但是沒有辦法控制他，他會攔截所有頁面的請求，包括第三方合作頁面，顯然這是無法接受的。
在iOS 11及以上系統(tǒng)中, 擁有了加載自定義資源的API：WKURLSchemeHandler。
可以修改當(dāng)前頁面url為自定義 scheme 協(xié)議，比如：https://fast.dewu.com 修改為 duapp://fast.dewu.com 然后在客戶端內(nèi)注冊該 scheme，前端配合修改頁面內(nèi)所有的資源請求未自適應(yīng)協(xié)議，如：src="//fast.dewu.com/xxx" 就可以實現(xiàn)攔截。但是在測試過程中發(fā)現(xiàn)，接口為了安全起見只允許白名單內(nèi)的域名發(fā)起跨域請求，且無法配置多個域名，導(dǎo)致該方案無法繼續(xù)進(jìn)行。
仍然是使用 WKURLSchemeHandler 然后通過 hook WKWebview 的 handlesURLScheme 方法來支持 http 和 https 請求的代理。通過這種方式雖然可以攔截請求了，但是遇到了以下問題：
（1）body丟失問題
不過在 iOS 11.3 之后對這種情況做了修復(fù)處理，只有 blob 類型的數(shù)據(jù)會丟失。需要由JS來代理 fetch 和 XMLHttpRequest 的行為，在請求發(fā)起時將 body 內(nèi)容通過 JSBridge 告知 native，并將請求交給客戶端進(jìn)行發(fā)起，客戶端在請求完成后 callback js 方法。
（2）Cookie 丟失、無法使用問題
通過代理 document.cookie 賦值和取值動作，交由客戶端來進(jìn)行管理，但是這里需要額外注意一點，需要做好跨域校驗，防止惡意頁面對cookie進(jìn)行修改。
至此功能開發(fā)完成上線，先來一組線上收益數(shù)據(jù)，安卓開啟離線情況有有10%左右的收益，但是iOS開啟離線的反而秒開率更低。經(jīng)過修復(fù)處理后iOS也可提升10%以上的秒開。
安卓和iOS實現(xiàn)差異
經(jīng)過分析對比發(fā)現(xiàn)，安卓的攔截動作比較輕，可以判斷是否需要攔截，不需要攔截可以交給WebView自己去請求。
但是iOS這邊一旦頁面開啟攔截后，頁面中所有的http和https請求都會被攔截掉，由客戶端發(fā)起請求進(jìn)行響應(yīng)，無法將請求交還給WebView自己去發(fā)起。
iOS 緩存問題修復(fù)
頁面中的資源經(jīng)過客戶端請求代理后原本第二次打開WebView本身會使用緩存的內(nèi)存，現(xiàn)在緩存也失效了，于是只能在客戶端內(nèi)實現(xiàn)了一套緩存機制。
從下圖可以看到離線包的下載錯誤率在 6% 左右浮動，這么高的下載錯誤率肯定是無法接受的， 經(jīng)過一系列優(yōu)化手段，把離線包下載錯誤率從6%左右浮動下降至 0.3%左右浮動。
先來看下優(yōu)化前的流程圖和問題點。
通過埋點發(fā)現(xiàn)大量 unknown host 、網(wǎng)絡(luò)請求失敗、網(wǎng)絡(luò)連接斷開的情況。分析代碼發(fā)現(xiàn)下載未做隊列控制，會同時并發(fā)下載多個離線包，從而導(dǎo)致多個下載任務(wù)爭搶資源的情況。針對發(fā)現(xiàn)的問題點做出了以下優(yōu)化：
下面是優(yōu)化之后的流程圖：
針對離線資源是直接存儲在磁盤上的，每次訪問都會有磁盤IO耗時，經(jīng)過在低端機器上做測試發(fā)現(xiàn)這個耗時會在 0 - 10ms 之間進(jìn)行波動，后面會把內(nèi)存合理的利用起來，通過設(shè)置內(nèi)存上限，文件數(shù)量上限，甚至是文件類型，并通過 LRU 策略進(jìn)行內(nèi)存文件的淘汰更新。
通過客戶端發(fā)起H5頁面首屏接口請求，遠(yuǎn)比等待客戶端頁面初始化、下載HTML、JS下載執(zhí)行的時機更提前，從而節(jié)省用戶的首屏等待時間。在本地測試過程中發(fā)現(xiàn)接口預(yù)請求可提前100+ms，用戶也就可以更快的看到內(nèi)容。
客戶端會在App啟動后獲取配置，保存支持預(yù)請求的頁面地址及對應(yīng)的接口信息，在用戶打開WebView時，會并行發(fā)起對應(yīng)預(yù)請求的接口，并保存結(jié)果。當(dāng)JS執(zhí)行開始獲取首屏數(shù)據(jù)時，會先詢問客戶端是否已經(jīng)存有對應(yīng)的響應(yīng)數(shù)據(jù)，如果此時已經(jīng)拿到數(shù)據(jù)則無需發(fā)起請求，否則 js 也會發(fā)起接口請求并開啟競速模式。以下是整體流程圖：
那么客戶端怎么知道這個頁面需要請求什么接口呢？以及接口的參數(shù)是什么呢？那自然少不了配置平臺，它支持以下功能：
首先即使是在 SSR 的情況下，首屏內(nèi)容中仍然可能有部分組件是骨架直出的，需要等待頁面渲染執(zhí)行時才會去請求數(shù)據(jù)，另外還有一部分頁面是SPA的。針對這兩種情況都能做到很好的補充。
開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。
通過上圖可以看到一個網(wǎng)絡(luò)請求在經(jīng)過DNS解析耗時、TCP建連耗時、SSL建連耗時階段之后才能把請求發(fā)出去，那么是否可以節(jié)省這段時間的耗時呢？
客戶端常用的網(wǎng)絡(luò)請求框架如OkHttp等，都能完整支持http1.1與HTTP2的功能，也就支持連接復(fù)用。了解了這個連接復(fù)用機制優(yōu)勢，那就可以利用起來，比如在APP開屏等待的時候，就預(yù)先建立關(guān)鍵域名的連接，這樣進(jìn)入相應(yīng)頁面后可以更快的獲取到網(wǎng)絡(luò)請求結(jié)果，給予用戶更好體驗。在網(wǎng)絡(luò)環(huán)境偏差的情況下，這種預(yù)連接理論上會有更好的效果。
可以通過對域名鏈接提前發(fā)起一個HEAD請求從而建立鏈接，網(wǎng)絡(luò)框架會自動將連接放入連接池。并在默認(rèn)無操作5分鐘后進(jìn)行釋放，在五分鐘內(nèi)重復(fù)執(zhí)行上述動作即可一直保持鏈接。
另外這里需要注意下連接池的數(shù)量問題，如果連接池的數(shù)據(jù)太小，但是域名比較多的話，通過預(yù)建連保持的鏈接很容易就會被釋放掉，這就需要通過域名收斂或者調(diào)大連接池的數(shù)量來進(jìn)行優(yōu)化。
那預(yù)建連會不會增加服務(wù)器的壓力呢？這個肯定是會的，首先會針對預(yù)建連功能本身就行灰度策略，在HTML頁面通過CDN托管后，直接針對 cdn 域名進(jìn)行全量開啟，從而不用擔(dān)心 cdn 域名扛不住壓力。
來看一下線上效果，通過下圖可以看到在開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。
客戶端提前通過WebView將頁面渲染好，等待用戶訪問時，可直接展示。從而達(dá)到瞬開效果。但是這種功能肯定不能對所有的頁面進(jìn)行開放，而且存在一定的弊端。
下圖【開學(xué)季】是業(yè)務(wù)上已經(jīng)進(jìn)行預(yù)渲染的H5頁面，可以看到在打開【開學(xué)季】頁面時，頁面已經(jīng)渲染完畢，絲毫沒有等待過程。
后面計劃把這種能力放大到通用的webview上，針對大促以及PV量高的頁面進(jìn)行開放。
SSR服務(wù)端渲染（英語：server side render）一般情況下，一個H5頁面的數(shù)據(jù)渲染完全由客戶端來完成，先通過AJAX請求到頁面數(shù)據(jù)并把相應(yīng)的數(shù)據(jù)填充到模板，形成完整的頁面來呈現(xiàn)給用戶。而服務(wù)端渲染把數(shù)據(jù)的請求和模板的填充放在了服務(wù)端，并把渲染的完整的頁面返回給客戶端。
SSR對于秒開有平均15%的提升，既然是服務(wù)端渲染，就會對服務(wù)器造成壓力，尤其是在預(yù)加載HTML功能開啟后，那得物是如何解決的呢？
通過這么多優(yōu)化手段仍然無法滿足預(yù)加載的需求，并且通過分析發(fā)現(xiàn)網(wǎng)絡(luò)階段耗時較長，最終還是搬出了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ù)加載優(yōu)化部分已經(jīng)有解決方案了，可以通過在頁面打開后針對有需要的組件再次請求接口刷新數(shù)據(jù)以確保數(shù)據(jù)的準(zhǔn)確性，但是這部分工作量也是比較大的，梳理出來的需要刷新狀態(tài)的組件就有30+，而且之后開發(fā)的組件都需要考慮狀態(tài)更新的事情。
（3）HTML模板內(nèi)容變更無法及時更新
引起模板內(nèi)容變更的地方有兩處，第一個場景就是在搭建器場景下，運營可以動態(tài)修改模板內(nèi)容導(dǎo)致頁面結(jié)構(gòu)變更（低頻次），第二個場景是項目發(fā)版后模板內(nèi)容需要更新（高頻）。
這個問題可以通過在感知到內(nèi)容變更時自動調(diào)用CDN服務(wù)商的刷新緩存接口來更新CDN緩存內(nèi)容。
通過puppeteer將SPA頁面渲染出來并將HTML文檔進(jìn)行保存，配合上述頁面刷新策略，并將HTML通過CDN進(jìn)行托管，讓你的 SPA 頁面 像 SSR 一樣絲滑。
主要實現(xiàn)方案是通過基于webpack的插件prerender-spa-plugin，并配置需要預(yù)渲染的路由，這樣經(jīng)過打包之后就會產(chǎn)出對應(yīng)路由的頁面。方案本身是通用的，但是每接入一個頁面都需要人工check。
眾所周知 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服務(wù)一并返回，并對css文件進(jìn)行拆分，按需加載。
思路有了，接下來就看怎么去實現(xiàn)了，最初嘗試了MiniCssExtractPlugin 插件他可以把css分成單獨的文件，并且每一個js會對應(yīng)生成一個css文件，但是他需要建立在webpack5之上，然而項目中使用的next版本是9.5，于是就想著升級到最新版next12，升級后發(fā)現(xiàn)，在構(gòu)建中其他包各種報錯，發(fā)現(xiàn)有些包并不支持最新的next12，在嘗試一天的修復(fù)之后，仍未解決，且升級到最新版不確定是否會引發(fā)其他穩(wěn)定性問題，暫且擱置尋找其他方法。
經(jīng)過不懈的努力，通過閱讀 next 源碼發(fā)現(xiàn)了端倪，發(fā)現(xiàn)在打包時將所有的公共css通過 splitChunks 進(jìn)行分組，由于項目中組件都是動態(tài)引入的，這里直接在 next.config.js 中修改webpack打包參數(shù)，將 splitChunks.cacheGroups.styles 配置刪除，使用默認(rèn)的 chunks: async 配置，即可實現(xiàn)按需引入。
（1）避免圖片src為空
雖然src屬性為空字符串，但瀏覽器仍然會向服務(wù)器發(fā)起一個HTTP請求，尤其是在SSR服務(wù)器壓力扛不住的情況下，因此這里需要特別注意一下。
（2）圖片壓縮以及格式選擇
WebP 的優(yōu)勢體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識別無差異的圖像質(zhì)量；同時具備了無損和有損的壓縮模式、Alpha 透明以及動畫的特性，在 JPEG 和 PNG 上的轉(zhuǎn)化效果都相當(dāng)優(yōu)秀、穩(wěn)定和統(tǒng)一。
通過向圖片服務(wù)器傳遞參數(shù)選擇合適的分辨率。
（1）打包優(yōu)化
（2）非關(guān)鍵js、css延遲加載
（3）媒體資源加載優(yōu)化
（4）其他資源優(yōu)化
（5）頁面渲染優(yōu)化
（6）代碼層面優(yōu)化
為了幫助開發(fā)者更好地衡量和改進(jìn)前端頁面性能，W3C性能小組引入了 Performance API ，其中Navigation Timing API 實現(xiàn)了自動、精準(zhǔn)的頁面性能打點。得物前端性能監(jiān)控指標(biāo)也都是從 Performance API 中獲取數(shù)據(jù)進(jìn)行上報統(tǒng)計分析的。
SDK 數(shù)據(jù)采集完畢后，會上報到 阿里云 sls 日志平臺，隨后通過 flink 實時消費清洗數(shù)據(jù)后落庫至 clickhouse 中，平臺后端通過讀取 clickhouse 數(shù)據(jù)并做各種聚合處理后使用。
做優(yōu)化之前首先要建立監(jiān)控指標(biāo)，互聯(lián)網(wǎng)稱之為抓手，沒有監(jiān)控指標(biāo)的情況下，任你怎么優(yōu)化，都不知道優(yōu)化的效果怎么樣，更不知道下一步該做什么？以及還有哪些問題沒解決。因此優(yōu)化之前指標(biāo)先行，當(dāng)然一定要指標(biāo)的準(zhǔn)確性。
指標(biāo)大盤主要包含以下功能：
在正常情況下，完成上述的優(yōu)化措施后用戶基本是可以秒開 H5 頁面的了。但異常情況總是會有的，用戶的網(wǎng)絡(luò)環(huán)境和系統(tǒng)環(huán)境千差萬別，甚至 WebView 也可能發(fā)生內(nèi)部崩潰。當(dāng)發(fā)生問題時，用戶看到的可能就直接只是一個白屏頁面了，所以進(jìn)一步的優(yōu)化手段就是需要去檢測是否發(fā)生白屏以及相應(yīng)的應(yīng)對措施。
檢測白屏最直觀的方案就是對 WebView 進(jìn)行截圖，遍歷截圖的像素點的顏色值，如果非純色的顏色點超過一定的閾值，就可以認(rèn)為不是白屏。首先獲取包含 WebView 視圖的 Bitmap 對象，然后把截圖縮小到指定的分辨率大小如:100*auto，遍歷檢測圖片的像素點，當(dāng)非純色的像素點大于 5% 的時候就可以認(rèn)為是非白屏的情況，但是還有很多列外的情況，我們通過圖片識別技術(shù)對截圖進(jìn)行分析，可以很好的感知當(dāng)前是否白屏、是不是在loading、是不是特殊頁面等。
白屏是一個重要的指標(biāo)，我們針對整體白屏率快速拉升、新增白屏頁面發(fā)出告警通知，便于開發(fā)人員及時介入開始排查問題。
主要通過 CDN 未覆蓋監(jiān)控、http請求監(jiān)控、網(wǎng)絡(luò)監(jiān)控（加載失敗、耗時異常、傳輸大小異常）、圖片監(jiān)控（未壓縮、分辨率異常）等監(jiān)控手段發(fā)現(xiàn)頁面中的潛在問題，同時還提供了問題分析能力，在問題分析頁面輸入頁面url地址即可幫助您發(fā)現(xiàn)問題并給出修改建議。
CDN的重要性不言而喻，它可以加速資源訪問速度，從而提升用戶體驗，我們通過對線上埋點數(shù)據(jù)分析，找出CDN未覆蓋的資源列表，從而推動各業(yè)務(wù)同學(xué)優(yōu)化。
為什么要監(jiān)控HTTP請求呢？我們先來看一下HTTPS相對于HTTP新增的特點：
那么HTTP就容易被中間人查看到內(nèi)容，甚至被篡改，既然如此為了我們服務(wù)的安全性就需要對現(xiàn)有的http協(xié)議統(tǒng)一進(jìn)行升級改造，那就需要監(jiān)控去發(fā)現(xiàn)。
某些頁面秒開率低，那就要分析一下原因，是不是這個頁面的接口響應(yīng)比較慢呢，還是說頁面本身有請求比較大的資源？如果發(fā)生網(wǎng)絡(luò)請求失敗的情況也要第一時間感知，不能被動等待用戶反饋。
包含圖片未壓縮、圖片分辨率異常、圖片傳輸大小大于 300kb 異常、動圖資源傳輸大小大于 1M 異常功能。
上面列出來一堆功能，對于業(yè)務(wù)的同學(xué)可能比較煩惱，我一個頁面具體有哪些問題呢？你不能讓我去上面的功能里面一個個看，哪個異常是我負(fù)責(zé)的頁面的吧？這個功能本身就行將現(xiàn)有的功能利用起來，通過一個頁面path進(jìn)行聚合分析。
H5異常一直是使用 sentry 進(jìn)行監(jiān)控的，但是sentry系統(tǒng)因缺乏同PV、DAU數(shù)據(jù)的關(guān)聯(lián)性，因此無法衡量產(chǎn)品異常發(fā)生后所帶來的嚴(yán)重程度。在業(yè)務(wù)域關(guān)聯(lián)上的缺失導(dǎo)致異常問題無法根據(jù)業(yè)務(wù)域進(jìn)行劃分。用戶行為日志也尚未與Native 端側(cè)打通，在問題分析時容易遇到上下文不全的瓶頸。還有一個問題是sentry會有限流措施，當(dāng)qps較高時會丟棄一部分異常數(shù)據(jù)。
由于sentry已經(jīng)可以幫助我們進(jìn)行一定的問題排查分析能力，我們不打算做sentry同樣的功能，而是做sentry不支持的部分，針對上述問題我們設(shè)計了以下功能：
雖然目前秒開率已經(jīng)做到了75%以上，但是同時我們還有一個重要的指標(biāo)，90分位耗時，致力于提升末尾用戶H5頁面使用體驗，在90分位優(yōu)化完成后，可能會考慮繼續(xù)深入優(yōu)化95分位耗時。
至此我們系統(tǒng)的講解了背景以及從指標(biāo)建立到秒開優(yōu)化上線的全過程，全文分成了三個部分，客戶端、H5、以及監(jiān)控。如果閱讀本文對您有所收獲，麻煩您動一動發(fā)財?shù)男∈贮c個贊吧！如果閱讀完還意猶未盡或者有什么問題和想法歡迎留言區(qū)評論交流。
最后奉上整體優(yōu)化腦圖：
*文/徐銘
歡迎關(guān)注「得物技術(shù)」微信公眾號，每周一三五晚18:30更新技術(shù)干貨
要是覺得文章對你有幫助的話，歡迎評論轉(zhuǎn)發(fā)點贊～
SS的4種引入方式是：行內(nèi)樣式、內(nèi)嵌樣式、鏈接樣式、導(dǎo)入樣式
1.行內(nèi)樣式
最直接最簡單的一種，直接對HTML標(biāo)簽使用style=""，例如：
<p style="color:#F00; "></p>
缺點：HTML頁面不純凈，文件體積大，不利于蜘蛛爬行，后期維護不方便。
2.內(nèi)嵌樣式
內(nèi)嵌樣式就是將CSS代碼寫在<head></head>之間，并且用<style></style>進(jìn)行聲明，例如：
<style type="text/css">
body,div,a,img,p{margin:0; padding:0;}
</style>
優(yōu)缺點：頁面使用公共CSS代碼，也是每個頁面都要定義的，如果一個網(wǎng)站有很多頁面，每個文件都會變大，后期維護難度也大，如果文件很少，CSS代碼也不多，這種樣式還是很不錯的。
3.鏈接樣式
鏈接樣式是使用頻率最高，最實用的樣式，只需要在<head></head>之間加上<link…/>就可以了，如下：
<link type="text/css" rel="stylesheet" href="style.css" />
優(yōu)缺點：實現(xiàn)了頁面框架代碼與表現(xiàn)CSS代碼的完全分離，使得前期制作和后期維護都十分方便
4.導(dǎo)入樣式（不建議使用）
導(dǎo)入樣式和鏈接樣式比較相似，采用@import樣式導(dǎo)入CSS樣式表，在HTML初始化時，會被導(dǎo)入到HTML或者CSS文件中，成為文件的一部分，類似第二種內(nèi)嵌樣式。
@import在html中使用，如下：
<style type="text/css">
@import url(style.css);
</style>
@import在CSS中使用，如下：
@import url(style.css);
四種CSS引入方式的優(yōu)先級
1.就近原則
2.理論上：行內(nèi)>內(nèi)嵌>鏈接>導(dǎo)入
3.實際上：內(nèi)嵌、鏈接、導(dǎo)入在同一個文件頭部，誰離相應(yīng)的代碼近，誰的優(yōu)先級高
文章地址：peixun.qietu.com
文/丁向明
做一個有博客的web前端自媒體人，專注web前端開發(fā)，關(guān)注用戶體驗，加我qq/微信交流：6135833
基于vue2.x+vuex+vue-cli+vue-router+element-ui+swiper等技術(shù)開發(fā)仿微信pc端界面聊天應(yīng)用，實現(xiàn)了發(fā)送消息+表情(動圖gif)、圖片/視頻預(yù)覽、右鍵長按菜單、紅包/朋友圈、截圖發(fā)送等功能。
<script src="https://lf3-cdn-tos.bytescm.com/obj/cdn-static-resource/tt_player/tt.player.js?v=20160723"></script>
github地址
Element | 是一套為開發(fā)者、設(shè)計師和產(chǎn)品經(jīng)理準(zhǔn)備的基于 Vue 2.0 的桌面端組件庫
https://element.eleme.cn/https://github.com/ElemeFE/elementnpm install element-ui -Simport Vue from 'vue'
import Element from 'element-ui'
Vue.use(Element)
// 按需引入
import {
Select,
Button
// ...
} from 'element-ui'
Vue.component(Select.name, Select)
Vue.component(Button.name, Button)/*
引入公共及全局組件配置
*/
// 引入側(cè)邊欄及聯(lián)系人
import winBar from './components/winbar'
import sideBar from './components/sidebar'
import recordList from './components/recordList'
import contactList from './components/contact'
// 引入jquery
import $ from 'jquery'
// 引入wcPop彈窗插件
import wcPop from './assets/js/wcPop/wcPop'
import './assets/js/wcPop/skin/wcPop.css'
// 引入餓了么pc端UI庫
import elementUI from 'element-ui'
import 'element-ui/lib/theme-chalk/index.css'
// 引入圖片預(yù)覽插件
import photoPreview from 'vue-photo-preview'
import 'vue-photo-preview/dist/skin.css'
// 引入自定義滾動條插件
import geminiScrollbar from 'vue-gemini-scrollbar'
// 引入加載更多插件
import infiniteLoading from 'vue-infinite-scroll'
// 引入高德地圖
import vueAMap from 'vue-amap'
const install = Vue => {
// 注冊組件
Vue.component('win-bar', winBar)
Vue.component('side-bar', sideBar)
Vue.component('record-list', recordList)
Vue.component('contact-list', contactList)
// 應(yīng)用實例
Vue.use(elementUI)
Vue.use(photoPreview, {
loop: false,
fullscreenEl: true, //是否全屏
arrowEl: true, //左右按鈕
});
Vue.use(geminiScrollbar)
Vue.use(infiniteLoading)
Vue.use(vueAMap)
vueAMap.initAMapApiLoader({
key: "e1dedc6bdd765d46693986ff7ff969f4",
plugin: [
"AMap.Autocomplete", //輸入提示插件
"AMap.PlaceSearch", //POI搜索插件
"AMap.Scale", //右下角縮略圖插件 比例尺
"AMap.OverView", //地圖鷹眼插件
"AMap.ToolBar", //地圖工具條
"AMap.MapType", //類別切換控件，實現(xiàn)默認(rèn)圖層與衛(wèi)星圖、實施交通圖層之間切換的控制
"AMap.PolyEditor", //編輯 折線多，邊形
"AMap.CircleEditor", //圓形編輯器插件
"AMap.Geolocation" //定位控件，用來獲取和展示用戶主機所在的經(jīng)緯度位置
],
uiVersion: "1.0"
});
}
export default install/*
* 主頁面js
*/
import Vue from 'vue'
import App from './App.vue'
import router from './router'
import store from './vuex'
// 引入公共Js
import './common.js'
// 引入全局組件
// 方式一：
// Vue.component('headerBar', resolve => require(['./common/header'], resolve))
// Vue.component('tab-bar', resolve => require(['./common/footer'], resolve))
// 方式二：
import _g_component from './components.js'
Vue.use(_g_component)
new Vue({
el: '#app',
router,
store,
render: h => h(App)
})<template>
<div id="app">
<div class="vChat-wrapper flexbox flex-alignc">
<div class="vChat-panel" style="background-image: url(src/assets/img/placeholder/vchat__panel-bg01.jpg);">
<div class="vChat-inner flexbox">
<!-- //頂部按鈕(最大、最小、關(guān)閉) -->
<win-bar></win-bar>
<!-- //側(cè)邊欄 -->
<side-bar v-if="!$route.meta.hideSideBar"></side-bar>
<keep-alive>
<router-view class="flex1 flexbox"></router-view>
</keep-alive>
</div>
</div>
</div>
</div>
</template><style>
/* 引入公共樣式 */
@import './assets/fonts/iconfont.css';
@import './assets/css/reset.css';
@import './assets/css/layout.css';
</style>/*
* 頁面地址路由js
*/
import Vue from 'vue'
import Router from 'vue-router'
import store from '../vuex'
// 通過改寫router.go方法，當(dāng)new Router 實例就包含back方法
Router.prototype.back = function(){
window.history.go(-1)
}
Vue.use(Router)
const router = new Router({
routes: [
// 登錄、注冊
{
path: '/login',
component: resolve => require(['../views/auth/login'], resolve),
meta: { hideSideBar: true },
},
{
path: '/register',
component: resolve => require(['../views/auth/register'], resolve),
meta: { hideSideBar: true },
},
//...
// 聊天頁面
{
path: '/chat',
component: resolve => require(['../views/chat/group-chat'], resolve),
meta: { requireAuth: true }
},
//...
]
});
export default routerrouter.beforeEach和next實現(xiàn)路由攔截驗證
// 注冊全局鉤子（攔截登錄狀態(tài)）
router.beforeEach((to, from, next) => {
const token = store.state.token
// 判斷該路由地址是否需要登錄權(quán)限
if(to.meta.requireAuth){
// 判斷token是否存在
if(token){
next()
}else{
next()
// 未登錄授權(quán)
wcPop({
content: '還未登錄授權(quán)！', anim: 'shake', style: 'background:#e03b30;color:#fff;', time: 2,
end: function(){
next({ path: '/login' })
}
});
}
}else{
next()
}
})?? 最后
如果你覺得這篇文章對你有幫助，麻煩點個「關(guān)注/轉(zhuǎn)發(fā)」，讓更多的人也能看到你的分享！
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
