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