## 一、加載慢   在直播間有一個小時榜的Web頁面，經常有用戶反映點擊小時榜，彈出的頁面會有蠻長的一段（3秒上下）時間白屏。 :-:    查看性能監控中的白屏時間，發現最多1.6秒，最少0.4秒平均每小時的白屏在1秒左右（有待優化），那么大概還有2秒的時間可能是其他原因造成的。 :-:    在頁面中會包含很多主播頭像，有可能是圖片太多阻塞了渲染，于是將主播的頭像都改成異步加載，在調試的時候直接將他們都隱藏掉，并且在動態讀取的部分加入loading效果。   發到預生產做調試，通過Charles把線上地址映射成預發地址。為了讓APP的環境更加純粹，特地刪除了APP重新安裝。   但是在iOS中打開小時榜的時候，還是會有2秒以上非常明顯的白屏時間。查詢資源瀑布圖，也就900ms的樣子，離體驗到的白屏時間還是差點。 :-:    讓iOS和安卓給WebView加了個加載進度條，確認白屏的時候到底有沒有開始請求資源。   安卓的情況比iOS好很多，白屏時間并不長，幾乎是一閃而過。   后面讓iOS的人查看代碼才發現，原來他們是在等到彈出動畫結束后開始請求資源，差不多有1秒的動畫時間。怪不得每次都要2、3秒的白屏時間。 ## 二、預請求   經過觀察發現每次請求后端數據的API大概要花100~200ms，如果把這段時間省下來，那么也能減少白屏時間，于是想到了數據預請求。   數據預請求是將數據預請求的時機由業務發起請求的時機，提前到用戶點擊時，并行發送數據請求，縮短數據等待時間。 :-:    在Webview啟動的時候，并行的去請求首屏需要的數據，流程圖如下所示： :-:    首屏數據的接口信息，可以通過一些配置關聯起來，比如一個單獨的配置接口。   對客戶端而言，H5初始化的時間和數據請求的時間先后不確定。   所以，如果客戶端先拿到數據，會把數據緩存在一個全局變量中，等待H5來調用。   具體的實現方案： * 客戶端分析出當前URL中的路徑和參數，其中 refresh 參數（有的話）是一個時間戳（秒），這次參數用來控制客戶端是否需要重新請求配置接口。 * 當分析的URL參數中無 refresh 字段時，訪問 https://xxx.com/settings 接口，并將URL路徑、客戶端默認帶的參數（包含用戶ID等）和 URL 本身的參數全部傳遞過來，然后本地緩存。 ~~~ https://xxx.com/settings?path=game%2Fstrick&uid=xxxxx&refresh=1618451992 ~~~ * 客戶端會將settings接口的響應數據緩存到本地，而key就是當前URL，也就是說URL不變的話，默認就不會去請求settings接口。若要穿透緩存，那么加上refresh參數，賦一個與之前不同的值即可。 * settings 接口返回的JSON格式，包含 urls 字段，是個數組，由接口集合組成，已經拼接好參數。 ~~~ { "urls": [ "http://xxx.com/xx/xx?id=2", "http://xxx.com/yy/yy?uid=1" ] } ~~~ * 客戶端將讀取到的數據注入到 WebView 的全局對象中，可以用全局變量同步讀取，名字叫 TheLClientResponse，讀取方式：window.TheLClientResponse，JSON格式如下，其中key是api的路徑，如果無數據可以返回 null。 ~~~ { "xx/xx": { code: 0, msg: "test", data: { list: [] } }, "yy/yy": { code: 0, msg: "test", data: { list: [] } } } ~~~ ***** > 原文出處： [博客園-從零開始搞系列](https://www.cnblogs.com/strick/category/1928903.html) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。