一、背景

隨著互動游戲業(yè)務 DAU 量級增加，性能和體驗重要性也越發(fā)重要，好的性能和體驗不僅可以增加用戶使用體感，也可以增加用戶對于互動游戲的使用粘性。

對現狀分析，主要存在首屏渲染速度慢、打開頁面存在白屏、頁面加載過多資源等問題，核心手段是增加骨架、接口優(yōu)先級調整、預渲染、減小包體積等。

優(yōu)化后，互動游戲簽到功能做到同類業(yè)務性能體驗 Top 級別，下面是優(yōu)化后數據：

• 首屏渲染速度：優(yōu)化后提升首屏渲染速度 39%。
• 首屏骨架：骨架體積大小減少 44%（壓縮后減少 50%）。
• 首次加載總資源：資源總體積優(yōu)化后，大小減少 69%。

二、骨架

骨架屏是指在頁面加載時，臨時顯示出頁面的主要結構，可以讓用戶在等待頁面加載完成時，得到視覺上的反饋，提升頁面的用戶體驗。

圖片

骨架示意圖vs數據渲染

圖片

圖片

可以看出在接口返回數據之前，可以先使用骨架得到一些界面反饋。

三、緩存

雖然骨架屏可以讓用戶在視覺上得到反饋，畢竟不是真實的數據，總體還是有一些簡陋，用戶也可能并不知道這塊區(qū)域實際渲染的是什么樣的內容，若是網絡環(huán)境不好，很可能會長時間的停留在骨架屏階段，為了增強一些體感，使用緩存進一步對頁面進行優(yōu)化。

圖片

使用緩存渲染具備以下優(yōu)勢：

• 與骨架屏相比，緩存渲染十分接近用戶最終所見，因為每次接口返回數據都會更新緩存，用戶再次進入時看到的都是自己上次進入時的數據。
• 當用戶處在弱網或者斷網等不可抗力的環(huán)境中時，可以得到較為完整的頁面數據展示，可以很好減弱用戶環(huán)境帶來的網絡營銷。

使用緩存注意事項：

• 一些緩存渲染應屏蔽事件響應，避免造成不必要的報錯和客訴。比如商品的緩存渲染，由于商品存在下架、優(yōu)惠券調整等情況，緩存的數據和實際數據會存在一定的偏差。
• 緩存渲染邏輯需要更加前置，不應該將緩存渲染的邏輯放在原本的位置，這樣會拖慢渲染的時機。

四、接口后置

瀏覽器對同一時間內的請求數量是有限制的，既并發(fā)請求限制。當一個頁面首次渲染時需要瀏覽器發(fā)起很多接口請求，用于填充頁面渲染需要的數據，若是對于頁面渲染時的請求數量不加以控制，便可能導致一些問題出現。

現在有 home 和 info 兩個接口，home 接口返回的數據是首屏渲染需要依賴的，info 接口返回的數據則不是首屏必須依賴的。假設現在還有一些其他請求占據了并發(fā)請求限制的數量，導致 home 接口請求變慢。

圖片

若是 info 接口響應慢，長時間占據這瀏覽器的請求進程，會導致頁面首屏渲染速度更慢，那么就需要有個一套方案可以根據接口的優(yōu)先級進行加載順序控制，可以將順序變?yōu)槿缦隆?/p>

圖片

方案：當頁面加載完成后一定時間后，進行低優(yōu)先級接口的請求，或者觸發(fā)頁面的滾動、點擊等時立即進行接口請求。

此方案適用于：確定接口延遲加載并不會阻塞用戶的交互和操作。

將其封裝為一個 hooks，便于復用，直接先看代碼再解釋：

import { useRM, createRM } from 'xxx'


const listen = (type: string, listener: () => void) => {
  const l = () => {
    listener()
    document.removeEventListener(type, l)
  }
  document.addEventListener(type, l)
}


const pageFlowModule = createRM(
  {
    assemble(state) {
      const reactionObserver = () => {
        state.isUserReactioned = true
      }


      ;['scroll', 'mousedown', 'touchstart'].forEach((type) => {
        listen(type, reactionObserver)
      })
      setTimeout(reactionObserver, 4000)
    },
  },
  { isUserReactioned: false },
)


pageFlowModule.actions.assemble()


export const usePageFlow = () => {
  const [state] = useRM(pageFlowModule)
  return state
}

使用：

import { usePageFlow } from 'xxx'


const Demo = () => {
    const { isUserReactioned } = usePageFlow()


    const fetchHanlder = useCallback(() => {
        // 接口請求數據
    }, [])


    useEffect(() => {
        if(isUserReactioned) {
            fetchHanlder()
        }
    }, [isUserReactioned, fetchHanlder])


    return <div>{/* 渲染接口返回的數據 */}</div>
}

從上面代碼可以看到，會將一些非首屏需要的請求后置，后置的接口可以在頁面加載完成 4s 后自動觸發(fā)調用，也會在用戶有觸屏、滾動頁面等行為的時觸發(fā)接口的調用。

五、骨架優(yōu)化

簽到和許愿樹目前主文檔中除了骨架部分還包含了一些公共的 JS 和 CSS，對不同資源類型進行拆分、匯總后發(fā)現，不管是簽到還是許愿樹，實際包含 HTML + JS 部分僅占極小比例，大量的流量消耗在了 CSS 上。

對 HTML 中 CSS 部分再進行梳理發(fā)現，文件中包含的除了骨架的 CSS 部分和公共組件庫的 CSS 部分之外，還包含了大量彈框的 CSS。這三類中，骨架的 CSS 要保留，公共組件庫的 CSS 可以拆分但是難度較大，剩下的就是彈框或者非骨架部分的 CSS。

• 需要把彈框部分組件做異步加載，保證預渲染的時候這部分 CSS 文件不會被加載到。
• 拆分骨架組件，把骨架組件從業(yè)務組件中剝離，預渲染的時候只渲染和加載骨架部分，不加載其余主文件部分 CSS，進一步縮小骨架。

圖片

六、localStorage性能問題

在做優(yōu)化之前，并未意識到 localStorage 所隱藏的性能問題，業(yè)務中使用了大量的本地存儲，使用 Performance 記錄一下存儲消耗的時間。

記錄核心代碼：

export const setMallFlowStoreData = (data: any) => {
  performance.mark('start_localstorage_operation')
  // localStorage 操作.....
  performance.mark('end_localstorage_operation')


  performance.measure('localstorage_operation_duration', 'start_localstorage_operation', 'end_localstorage_operation')
}

輸出記錄的時間：

const entries = performance.getEntriesByName('localstorage_operation_duration')
const TOTAL_TIME = entries.reduce((current, next) => {
return current + next?.duration
}, 0)


console.log('全部記錄:', entries, '共耗時:', TOTAL_TIME)

輸出結果：

可以看到通過 localStorage 進行一次存儲操作，大致需要耗時 0.2-0.5ms 之間，若是當頁面存在大量的前端的存儲操作時，低端機型在存儲操作上消耗甚至達到 10-20ms，若是代碼寫的不合理，導致頁面 reload、反復觸發(fā)獲取操作等情況，這個時間又將會成倍的增加。

接下來先一起看看為何會存在性能方面的問題和解決方案。

存儲數據

問題：

localStorage 的存儲是同步的操作，因此在存儲大量數據時，可能會導致阻塞 UI 線程，影響用戶體驗。

方案：

核心思路便是將同步操作轉換為異步操作，這樣就不會阻塞 UI 線程。

• 使用 Web Worker ，會增加一些項目維護的復雜度，且其是 HTML5 標準中新增的技術，存在一定的兼容性（ChatGPT 給的，應該是錯誤答案，并未在 MDN 中看到）。

圖片

• 使用 setTimeout、setInterval，兼容性絕對的好，但是并未從根本解決問題。
• 不用 localStorage，直接上 IndexDB，但是由于代碼項目原因，不能改動原有的太多邏輯。

綜合解決方案和歷史原因，只能退而求其次選擇 setTimeout 的方式解決這個問題。

讀取數據

問題：

每次讀取 localStorage 數據時，都需要從磁盤中讀取數據，因此在處理大量數據時，可能會出現性能問題。

方案：

可以將數據進行放到內存中緩存處理，在用戶的整個操作周期內只從 localStorage 獲取一次數據，需要注意的是每次對數據進行操作時，需要將 localStorage 和內存緩存的數據同步更新。

數據類型轉換

問題：

在存儲和讀取數據時，需要將數據進行序列化和反序列化操作。這些操作可能會導致性能問題。

方案：

使用 JSON.stringify() 和 JSON.parse() 函數來處理數據的序列化和反序列化。

經過對 localStorage 存儲優(yōu)化以后，在紅米 note 11 上面進行了簡單測試，首屏打開速度提升，對于整體提升首屏提升約 2%。

七、動效執(zhí)行時機

頁面存在漸入漸現的動效，在頁面首次加載時，由于漸現動效的存在，會延遲用戶感知該模塊，從而導致感覺頁面存在更多時間的白屏，動效如下：

圖片

核心問題是首次渲染直出 DOM 結構，不走漸現動效便可，這個比較偏向于邏輯處理，屬于體驗優(yōu)化的范疇，主打的就是在后續(xù)有相關首屏動效時，有意識對其做一下處理，保證首屏首次渲染的完整讀。

八、渲染模塊的取舍

首先看一下兩種狀態(tài)各自的樣式：未簽到 VS 已簽到。

圖片

簽到業(yè)務的日歷會根據用戶當天簽到狀態(tài)進行渲染，存在已簽到和未簽到兩種渲染邏輯，由于當前的架構限制，并不能在預渲染時感用戶的簽到狀態(tài)，導致日歷部分的渲染會滯后，嚴重影響頁面的首屏渲染速度。

第一版本優(yōu)化

將簽到狀態(tài)進行緩存，當用戶進入簽到時的大致流程如下：

圖片

當用戶進入頁面時，會優(yōu)先獲取緩存中的數據進行渲染，確保用戶可以第一時間看到日歷部分的渲染，這里需要注意：

1. 緩存需要結合用戶 token 一起判斷，避免造成切換賬號時造成數據污染。
2. 若是用戶第一次進入或者當天未簽到，會使用系統(tǒng)時間作為小日歷上的數字展示，當用戶修改了系統(tǒng)時間設置時，日期判斷會存在誤差。

緩存數據必然會先于接口響應數據，因此頁面第一時間看到的肯定是緩存數據（沒有緩存數據，會默認使用未簽到數據）所渲染的頁面，那么當接口響應完成時，需要使用真實的數據觸發(fā)頁面的 rerender，需要注意處理，避免造成頁面閃爍。

雖然這樣做可以提高頁面的渲染體感，當進入頁面時，頂部區(qū)域還是會存在一定時間的空白，畢竟還是需要執(zhí)行 JS 后才能執(zhí)行骨架渲染邏輯，本質提升速度為：接口響應時間 - JS 執(zhí)行時間，在低端機表現會較為好一些，高端機體感并非太明顯。

第二版優(yōu)化

日歷部分由于已簽到和未簽到的樣式存在著較大的出入，不能像某些競品一樣：已簽、未簽的整體頁面布局并未有區(qū)分，使用一套公用的渲染邏輯，這樣也導致簽到業(yè)務需要將渲染日歷部分的動作滯后，那么核心就是怎么解決這個問題。

綜合考慮后，決定將未簽到樣式作為預渲染時直接生成 DOM，這樣可以保證用戶未簽到的狀態(tài)下進入到頁面可以第一時間對的狀態(tài)，也可以更快的完成首屏的渲染。

若是用戶已簽到，便在此基礎之上復用今日簽到的邏輯，就是會在簽到完成后展示一個小的動效，將小日歷變成大日歷的樣式。這樣做的好處可以是獲取到用戶真實狀態(tài)后，自動切換到大日歷狀態(tài)，效果如下。

圖片

結合用戶行為分析：多數用戶一天不會多次訪問，也就是在即不怎么犧牲高頻率訪問用戶的體驗之下，提高了絕大多數用戶的體驗。

九、首屏數據優(yōu)先請求

前置小知識：最大并發(fā)請求數

為了避免瀏覽器過度占用系統(tǒng)資源，瀏覽器對于同一域名下的請求數量是有一定限制的，也就是常見的瀏覽器最大請求數量。

以 Chrome 瀏覽器舉例：同一域名下，HTTP 協(xié)議最多允許同時存在 6 個 TCP 連接進行，HTTPS 協(xié)議最多為 4 個。

業(yè)務現狀

簽到進入頁面共計加載許多接口。

其中首屏渲染需要的幾個核心接口如圖紅色標記所示，核心的接口滯后會導致頁面數據渲染的更慢，嚴重影響體驗，那么到底影響多少呢？可以在瀏覽器 Network 中查看 Waterfall。

圖片

核心接口是在其他完成后開始，是因為其沒有趕上瀏覽器第一批次接口請求隊列中，需要等待前面某些接口結束后，才會將其放到請求隊列中。

動作

有了問題，接下來便是如何做：

• 首先是制定方案，如何確保接口的請求可以搭上瀏覽器請求隊列的第一班車，本質是將之前散落在各個組件內的 useEffect 中的初始化邏輯進行提取，統(tǒng)一觸發(fā)。
• 梳理接口和首屏渲染的關聯度，確定哪些接口的優(yōu)先級權重更高。

核心代碼如下：

export const StartModule = createRM(
  {
    init() {
      SigninTopModule?.actions?.getHomeData()
      AdModule?.actions?.reqAdInfoList()
      HomeModule?.actions?.getBubbleList()
    },
  }
)

在頁面初始化時執(zhí)行 StartModule?.actions?.init()，將核心接口優(yōu)化執(zhí)行，通過控制接口請求順序，簽到業(yè)務在此提升了大致 6-8% 的首屏渲染速度。

十、字體使用和優(yōu)化

字體加載和優(yōu)化是前端開發(fā)中的一個重要問題，特別是在移動端和低網絡狀況下。下面是一些字體加載和優(yōu)化的技巧。

FOUT問題

通過設置 Font-Display 屬性可以控制字體加載時的顯示效果，包括 Auto、Swap、Block、FallBack 和 Optional 幾種模式，可以減少字體加載時間和防止文本閃爍。

設置屬性為FallBack時效果：

圖片

可以看到日期存在明顯的 FOUT（無樣式文本閃現）問題，設置 Swap 也是類似效果，并不符合預期。

設置屬性為 Block 時效果：

圖片

可以看到第一時間并沒有渲染日期，而是有點的短暫空白，因為其可以避免 FOUT，字體文件必須在后臺下載完全后，文本才能顯示。

最終選擇了 font-display: block；效果會更好一些。

注意，并不是整個頁面都使用 Block 屬性，對于一些非首屏關鍵渲染的樣式，使用 fallback 更為合適一些，因為其會使用瀏覽器默認字體，所以還是需要結合業(yè)務、場景合理使用。

字體庫大小，你得懂

先看一個 GPT 對于簽到業(yè)務常用字體庫打下的統(tǒng)計：

• DIN Condensed 字體庫的大小在幾百KB 到幾MB之間
• Helvetica Neue 字體庫的大小在幾MB到十幾MB之間

也就是這兩種字體的大小，如果不加以處理，全部加載的大小在幾 MB 到十幾 MB 之間，對于前端項目而言，這是挺夸張的一件事。

可以和設計人員溝通，將字體庫中常用的字體導出，前端項目僅僅引入需要的字體就好，比如 DIN Condensed 字體都是使用在阿拉伯數字上，并不會在其他字上使用，那么只需要將阿拉伯數字導出即可。比如漢字，根據《現代漢語通用字表》（GB/T 13000-2018），常用漢字（包括簡體字和繁體字）共計 3500 個，其中常用的一般是指前 1000 個左右的漢字，那么在使用字體庫的時候，是不是可以默認只需要導出部分即可。

經過處理后的字體庫大小如下圖：

圖片

字體庫數量，你得控制

上面說了一個字體庫的大小是多大，就算是經過處理，最少也會有 30KB 大小，所以項目引入的字體種類是需要控制的，不能設計同學使用了多少種類字體設計，我們就要照單全收。

當設計同學新增字體庫時，如果字體使用在 3 次以內，是不是可以使用圖片來代替文字，或者使用現有的字體庫來平替。

十一、慎用三方庫

業(yè)務中存在一些簡單的校驗、轉換和動效并不需要引入三方庫，尤其是因為一個較為簡單的功能引入了一個較為大且冷門的庫時，不僅會增加項目的打包體積，還會增加項目后續(xù)維護的溝通、學習成本。

例如下面一個簡單切換動效：

圖片

是一個比較常規(guī)的切換動效，卻在項目中引入了一個第三方庫來實現，該庫的使用也是有一些學習成本，因為其具備實現比較復雜的動效能力，在業(yè)務動效具備一定復雜度且非首屏的場景下，是可以考慮引入使用的，否則類似這種首屏便需要加載的動效，還是慎重。

上述的切換動效 CSS 實現代碼如下：

@keyframes bigScale {
  0% {
    opacity: 0;
    transform: scale(0.95);
  }


  to {
    transform: scale(1);
    opacity: 1;
  }
}


@keyframes smallScale {
  0% {
    transform: scale(1);
    opacity: 1;
  }


  to {
    transform: scale(0.95);
    opacity: 0;
  }
}


.squareInCenter {
  animation: 0.3s linear 0s 1 normal forwards running bigScale;
}


.squareOutCenter {
  animation: 0.3s linear 0s 1 normal forwards running smallScale;
}

在業(yè)務開發(fā)的過程中，尤其是 C 端的頁面，在實現功能時對于引入額外的庫是一件需要十分謹慎的事情，在內部就看到不少項目在引入關于日期處理方面的庫時，DayJS、MomentJS 同時都會引用到項目中，B 端項目都不能忍，更何況 C 端項目。

十二、總結

本文僅僅介紹得物前端增長團隊在互動游戲側一些體驗優(yōu)化實踐心得，后續(xù)還在不斷迭代和優(yōu)化，將實踐經驗應用擴大至多個業(yè)務中，將整個互動游戲性能體驗優(yōu)化至 TOP 級別。