資訊專欄INFORMATION COLUMN
摘要：目標(biāo)是探索是否能夠加快頁面首屏速度。實(shí)驗(yàn)組瀏覽器支持，本次時(shí)，進(jìn)行初始化。從上面的直觀對(duì)比可以看出，個(gè)指標(biāo)，組的分位值都略微大于組的分位值，差距在幾十毫秒左右。最終，我也沒有采用來優(yōu)化首屏速度。
寫在前面本文首發(fā)于公眾號(hào)：符合預(yù)期的CoyPan
不久之前，我簡(jiǎn)單探索了service worker在一個(gè)活動(dòng)運(yùn)營頁面中的應(yīng)用，可以參考我之前的這篇文章：
service worker輕度探索 - 解決運(yùn)營活動(dòng)需求中的圖片加載問題");
那個(gè)時(shí)候，我就發(fā)現(xiàn)了一個(gè)現(xiàn)象：一張圖片從service worker中加載的耗時(shí)，大于其從瀏覽器緩存中加載的耗時(shí)。最近在做頁面首屏性能優(yōu)化的相關(guān)工作，那么service worker能讓頁面首屏加載變快么？
業(yè)務(wù)場(chǎng)景首先明確一下業(yè)務(wù)場(chǎng)景：一個(gè)App的h5分享頁。這個(gè)分享頁是一個(gè)使用react開發(fā)的單頁應(yīng)用，用戶的交互只會(huì)停留在這個(gè)頁面，不會(huì)跳轉(zhuǎn)到其他的頁面。業(yè)務(wù)中使用service worker來緩存靜態(tài)資源(js，css)，邏輯很簡(jiǎn)單，就是在service worker初始化的時(shí)候，將頁面的靜態(tài)資源緩存下來，后續(xù)訪問頁面時(shí)，可以直接從service worker中加載靜態(tài)資源。有一個(gè)點(diǎn)需要注意，service worker的優(yōu)先級(jí)是高于瀏覽器自帶緩存的。目標(biāo)是探索service worker是否能夠加快頁面首屏速度。
探索service worker的效果針對(duì)本文提到的業(yè)務(wù)場(chǎng)景，我設(shè)計(jì)了小流量實(shí)驗(yàn)來驗(yàn)證service worker對(duì)網(wǎng)頁首屏速度的影響。
首先明確一下實(shí)驗(yàn)指標(biāo)：
指標(biāo)①：頁面fetchStart到window.onload觸發(fā)時(shí)的耗時(shí)。
指標(biāo)②：頁面fecthStart到最外層組件的componentDidMount觸發(fā)時(shí)的耗時(shí)。
指標(biāo)③：FP，頁面首次繪制的時(shí)間點(diǎn)。
指標(biāo)④：FCP，頁面首次內(nèi)容繪制的時(shí)間點(diǎn)。
關(guān)于首屏速度的更多指標(biāo)，可以參考我之前寫的這篇文章：
當(dāng)考慮網(wǎng)頁首屏加速的時(shí)候，我們?cè)诳紤]什么
我通過用戶id將頁面的流量均分成了兩組，對(duì)照組A，實(shí)驗(yàn)組B。
對(duì)照組A：不包含service worker邏輯，完全走之前的頁面加載模式。
實(shí)驗(yàn)組B：包含service worker邏輯，使用service worker劫持網(wǎng)頁中的靜態(tài)資源請(qǐng)求。
在實(shí)驗(yàn)組B中，包含了以下多種情況：
實(shí)驗(yàn)組B1: 瀏覽器根本就不支持service worker。
實(shí)驗(yàn)組B2: 瀏覽器支持service worker，本次pv時(shí)，service worker進(jìn)行初始化。
實(shí)驗(yàn)組B3: 瀏覽器支持service worker，本次pv時(shí)，service worker已經(jīng)劫持了靜態(tài)資源請(qǐng)求，靜態(tài)資源是從service worker中加載的。
我統(tǒng)計(jì)了5個(gè)自然天里，各個(gè)指標(biāo)的50分位值，60分位值，90分位值和平均數(shù)。我們先來直觀地看下A組和B組各個(gè)指標(biāo)的50分位值的對(duì)比吧。
從上面的直觀對(duì)比可以看出，4個(gè)指標(biāo)，B組的50分位值都略微大于A組的50分位值，差距在幾十毫秒左右。
其實(shí)，各個(gè)指標(biāo)的50分位值，60分位值，90分位值和平均數(shù)，都是B組的值略大于A組的值。
到這里，其實(shí)已經(jīng)可以得出一個(gè)結(jié)論了：在本文所描述的業(yè)務(wù)場(chǎng)景中，service worker并不能提高首屏速度。
下面是本次實(shí)驗(yàn)的詳細(xì)數(shù)據(jù)。
首先給出一個(gè)上圖看不出來的數(shù)據(jù)：
在實(shí)驗(yàn)組B中，B1，B2，B3三個(gè)組的PV占比大致為：20%，46%，34%。
接著，從上面的數(shù)據(jù)中，可以發(fā)現(xiàn)幾個(gè)比較有意思的點(diǎn)：
那些根本不支持service worker的瀏覽器，他們的指標(biāo)①和指標(biāo)②其實(shí)是挺快的。
不支持service worker的瀏覽器，也不支持FP和FCP這兩個(gè)指標(biāo)。
service worker初始化時(shí)，會(huì)拖慢所有的指標(biāo)，也就是說，會(huì)影響頁面的首屏速度。
當(dāng)service worker已經(jīng)劫持了網(wǎng)絡(luò)請(qǐng)求，靜態(tài)文件通過sw加載時(shí)，所有的指標(biāo)都是最快的，可以提升首屏速度。
思考總結(jié)從詳細(xì)數(shù)據(jù)來看，如果靜態(tài)文件通過service worker加載時(shí)，確實(shí)可以較大幅度提高首屏速度。但是從整體的效果上來看，service worker并不能提高首屏速度，甚至還會(huì)略微降低首屏速度。這是由業(yè)務(wù)場(chǎng)景決定的。最終，我也沒有采用service worker來優(yōu)化首屏速度。
那么，什么情況下，能用service worker來優(yōu)化首屏速度呢？我覺得主要是以下兩個(gè)場(chǎng)景：
老用戶回訪率很高的業(yè)務(wù)。老用戶回訪時(shí)，service worker已經(jīng)劫持了網(wǎng)絡(luò)請(qǐng)求，靜態(tài)文件是可以通過service worker加載的。如果每天的頁面pv里，大部分都是新用戶，從整體上看，service worker并不能發(fā)揮作用，并且維護(hù)service worker本身也是需要一定的成本的，就沒有必要上service worker了。
頁面之間相互依賴。比如說有一個(gè)入口A頁面，A頁面可以跳轉(zhuǎn)到B頁面，那么可以在A頁面中使用service worker將B頁面的靜態(tài)文件也緩存下來，這樣可以較大幅度地提高B頁面的首屏速度。
本文通過實(shí)驗(yàn)，收集了詳細(xì)的數(shù)據(jù)，研究了service worker在首屏加速問題上的表現(xiàn)。雖然最終并沒有在業(yè)務(wù)中采用service worker來加速首屏，但是在過程中也收獲了很多的東西，符合預(yù)期。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/6740.html
摘要：所以，關(guān)于優(yōu)化實(shí)戰(zhàn)我們主要分為兩部分加載渲染鏈路優(yōu)化和編程代碼優(yōu)化。加載渲染鏈路優(yōu)化從訪問到頁面呈現(xiàn)，整個(gè)鏈路可以做優(yōu)化的思路。資源緩存這一節(jié)我們單獨(dú)介紹緩存，是的，利用好緩存可以解決很多問題，包括頁面加載和渲染的問題都能得到很好的優(yōu)化。 優(yōu)化實(shí)戰(zhàn) 本文屬于思否課堂VirtualDOM到AST玩轉(zhuǎn)前端性能原理解析與代碼實(shí)戰(zhàn)課程官方博客：fed123.com 我們已經(jīng)全面分析總結(jié)了評(píng)估頁...
摘要：所以，關(guān)于優(yōu)化實(shí)戰(zhàn)我們主要分為兩部分加載渲染鏈路優(yōu)化和編程代碼優(yōu)化。加載渲染鏈路優(yōu)化從訪問到頁面呈現(xiàn)，整個(gè)鏈路可以做優(yōu)化的思路。資源緩存這一節(jié)我們單獨(dú)介紹緩存，是的，利用好緩存可以解決很多問題，包括頁面加載和渲染的問題都能得到很好的優(yōu)化。 優(yōu)化實(shí)戰(zhàn) 本文屬于思否課堂VirtualDOM到AST玩轉(zhuǎn)前端性能原理解析與代碼實(shí)戰(zhàn)課程官方博客：fed123.com 我們已經(jīng)全面分析總結(jié)了評(píng)估頁...
摘要：往往純的單頁面應(yīng)用一般不會(huì)太復(fù)雜，所以這里不引入和等等，在后面復(fù)雜的跨平臺(tái)應(yīng)用中我會(huì)將那些技術(shù)一擁而上。構(gòu)建極度復(fù)雜，超大數(shù)據(jù)的應(yīng)用。 showImg(https://segmentfault.com/img/bVbvphv?w=1328&h=768); React為了大型應(yīng)用而生，Electron和React-native賦予了它構(gòu)建移動(dòng)端跨平臺(tái)App和桌面應(yīng)用的能力，Taro則賦...
摘要：往往純的單頁面應(yīng)用一般不會(huì)太復(fù)雜，所以這里不引入和等等，在后面復(fù)雜的跨平臺(tái)應(yīng)用中我會(huì)將那些技術(shù)一擁而上。構(gòu)建極度復(fù)雜，超大數(shù)據(jù)的應(yīng)用。 showImg(https://segmentfault.com/img/bVbvphv?w=1328&h=768); React為了大型應(yīng)用而生，Electron和React-native賦予了它構(gòu)建移動(dòng)端跨平臺(tái)App和桌面應(yīng)用的能力，Taro則賦...
閱讀 2061·2023-04-25 17:48
閱讀 3578·2021-09-22 15:37
閱讀 2932·2021-09-22 15:36
閱讀 5864·2021-09-22 15:06
閱讀 1634·2019-08-30 15:53
閱讀 1422·2019-08-30 15:52
閱讀 706·2019-08-30 13:48
閱讀 1116·2019-08-30 12:44
