一、背景介紹

1.1 頁(yè)面性能優(yōu)化的價(jià)值與意義

在業(yè)務(wù)迅猛發(fā)展的時(shí)代，用戶體驗(yàn)已成為企業(yè)成功的關(guān)鍵因素之一，而頁(yè)面性能則是塑造用戶體驗(yàn)的核心要素。早在十多年前，亞馬遜就已經(jīng)意識(shí)到頁(yè)面加載速度對(duì)商業(yè)成果的深遠(yuǎn)影響：亞馬遜支付頁(yè)面每增加100毫秒的延遲，可能減少1%有效轉(zhuǎn)化。頁(yè)面加載時(shí)間的延長(zhǎng)和交互操作的不流暢性，不僅會(huì)損害用戶體驗(yàn)，還可能導(dǎo)致轉(zhuǎn)化率下降和用戶流失等后果。

在快手商業(yè)化團(tuán)隊(duì)，我們深知頁(yè)面性能對(duì)提升用戶體驗(yàn)的重要性。因此，我們基于快手內(nèi)部動(dòng)態(tài)化技術(shù)的特點(diǎn)，并參考了Google的性能標(biāo)準(zhǔn)，制定了快手商業(yè)化頁(yè)面性能達(dá)標(biāo)的北極星指標(biāo)（如下）

1.2 核心頁(yè)面性能現(xiàn)狀

在實(shí)際的商業(yè)化業(yè)務(wù)場(chǎng)景中，盡管端側(cè)頁(yè)面繁多，但流量卻高度集中于少數(shù)核心系統(tǒng)與頁(yè)面之上。因此，從ROI的角度出發(fā)，我們采取了頁(yè)面分級(jí)治理策略，將優(yōu)化資源聚焦于核心頁(yè)面。我們界定核心頁(yè)面依據(jù)兩大關(guān)鍵要素：一是它們直接面向外部用戶，位于廣告投放的核心路徑之中；二是依據(jù)頁(yè)面訪問量（PV數(shù)）的統(tǒng)計(jì)結(jié)果。

遵循這些原則，我們挑選出了12個(gè)流量較大且處于廣告投放核心路徑的快手商業(yè)化核心系統(tǒng)，涵蓋了廣告投放、廣告落地頁(yè)等核心業(yè)務(wù)流程，并進(jìn)一步從中篩選出超過30+核心頁(yè)面作為優(yōu)化的重點(diǎn)對(duì)象。那么，這些承載著巨大流量的核心頁(yè)面，其性能表現(xiàn)究竟如何呢？

我們借助雷達(dá)平臺(tái)（快手內(nèi)部的性能監(jiān)控平臺(tái)），對(duì)各核心頁(yè)面的性能數(shù)據(jù)進(jìn)行了全面且細(xì)致的整理與分析，包括靜態(tài)資源、接口等維度，并得出以下結(jié)論：

• 僅有18.42%的頁(yè)面即7個(gè)頁(yè)面達(dá)到了“性能優(yōu)秀”的基線標(biāo)準(zhǔn)，且其中有4個(gè)頁(yè)面只是略優(yōu)于基線標(biāo)準(zhǔn)。有15個(gè)頁(yè)面其性能被判定為“較差”。

• 在C端系統(tǒng)中，主要性能瓶頸在于靜態(tài)資源加載耗時(shí)過長(zhǎng)，約47.36%頁(yè)面靜態(tài)資源耗時(shí)超過1500ms，約65.78%頁(yè)面的靜態(tài)資源耗時(shí)超過1000ms。這意味著用戶在訪問這些頁(yè)面時(shí)，需要等待較長(zhǎng)時(shí)間來加載頁(yè)面內(nèi)容，這無(wú)疑會(huì)嚴(yán)重影響用戶體驗(yàn)。

• 而在B端系統(tǒng)中，主要性能瓶頸在于接口耗時(shí)過長(zhǎng)，約31.57%頁(yè)面的接口請(qǐng)求耗時(shí)超過2500ms，約21.05%頁(yè)面的請(qǐng)求接口耗時(shí)占比超過60%。這對(duì)于B端系統(tǒng)的操作效率構(gòu)成了嚴(yán)峻挑戰(zhàn)，也直接影響了廣告投放等核心業(yè)務(wù)流程的順暢進(jìn)行。

1.3 核心性能問題分析

基于上述性能現(xiàn)狀的深入分析，我們明確了當(dāng)前面臨的核心性能問題主要?dú)w為兩大類：一是靜態(tài)資源加載和渲染耗時(shí)過長(zhǎng)，二是接口請(qǐng)求耗時(shí)較長(zhǎng)。針對(duì)這兩大類核心性能問題，我們需要進(jìn)一步細(xì)化問題原因，制定針對(duì)性的優(yōu)化策略，并付諸實(shí)施。

1.3.1 靜態(tài)資源加載和渲染耗時(shí)過長(zhǎng)

為了進(jìn)一步下鉆分析「靜態(tài)資源」相關(guān)的性能問題，我們通過破曉平臺(tái)（快手內(nèi)部的性能診斷平臺(tái)）對(duì)上述各核心頁(yè)面進(jìn)行性能評(píng)測(cè)，發(fā)現(xiàn)這些核心項(xiàng)目普遍存在較多顯而易見的問題。我們對(duì)這些問題進(jìn)行了歸類，主要有以下4個(gè)方面：

1. HTTP/2覆蓋率較低：所有項(xiàng)目均存在使用HTTP/1.1的情況，作為對(duì)比，HTTP/2能顯著提高頁(yè)面加載性能、減少延遲、提高帶寬利用效率等

2. 圖片資源優(yōu)化空間大：絕大部分項(xiàng)目直接引用原始圖片的CDN鏈接，沒有對(duì)圖片做任何處理；

3. 頁(yè)面渲染結(jié)構(gòu)較復(fù)雜：以廣告投放平臺(tái)為首的核心業(yè)務(wù)的頁(yè)面首屏渲染結(jié)構(gòu)非常復(fù)雜；

4. 腳本資源較大：腳本資源請(qǐng)求體積較大，JS覆蓋率較低，腳本解析時(shí)長(zhǎng)占高，影響資源加載時(shí)長(zhǎng)和渲染時(shí)長(zhǎng)

1.3.2 接口請(qǐng)求耗時(shí)較長(zhǎng)

眾所周知，B端系統(tǒng)往往邏輯非常復(fù)雜，尤其是像商業(yè)化的廣告投放平臺(tái)這樣邏輯復(fù)雜且規(guī)模龐大的系統(tǒng)，涉及的接口數(shù)量眾多，管理起來極具挑戰(zhàn)性。為此我們對(duì)核心頁(yè)面加載鏈路上的相關(guān)接口進(jìn)行了細(xì)致的梳理和分析。在梳理過程中，我們重點(diǎn)關(guān)注了4個(gè)B端系統(tǒng)中的14個(gè)核心頁(yè)面，這些頁(yè)面是用戶訪問頻率高、業(yè)務(wù)邏輯復(fù)雜的關(guān)鍵區(qū)域。通過監(jiān)測(cè)和分析，我們發(fā)現(xiàn)這些頁(yè)面中累計(jì)存在30個(gè)接口性能表現(xiàn)不佳。

二、面臨的挑戰(zhàn)

在深入了解快手商業(yè)化內(nèi)部性能現(xiàn)狀及問題的基礎(chǔ)上，我們意識(shí)到在推進(jìn)性能治理的過程中，仍需克服以下三方面的挑戰(zhàn)：

挑戰(zhàn)一：統(tǒng)一推進(jìn)各核心系統(tǒng)治理的難度較高

性能優(yōu)化治理是一項(xiàng)復(fù)雜且長(zhǎng)期的工作，尤其是在頁(yè)面較多、項(xiàng)目發(fā)展階段不一、技術(shù)棧差異化的情況下。商業(yè)化端側(cè)性能治理專項(xiàng)涉及12個(gè)項(xiàng)目30+頁(yè)面，涉及頁(yè)面流量大，且項(xiàng)目間發(fā)展階段不同，導(dǎo)致性能問題的根源也各不相同，統(tǒng)一推進(jìn)治理的難度較高，若任由業(yè)務(wù)方自行優(yōu)化則重復(fù)勞動(dòng)較多，同時(shí)難以形成可復(fù)制、可推廣的最佳實(shí)踐。為了解決這一問題，我們需要建立一套性能治理機(jī)制，既要針對(duì)性地解決端側(cè)性能問題，也要在項(xiàng)目推進(jìn)中引入性能優(yōu)化卡口，防止性能問題后期劣化。

挑戰(zhàn)二：B端業(yè)務(wù)核心鏈路體驗(yàn)度量模型缺失

快手商業(yè)化的B端業(yè)務(wù)主要集中在廣告投放、企業(yè)服務(wù)、內(nèi)容變現(xiàn)、電商合作等領(lǐng)域，主要服務(wù)于廣告主、代理商、品牌等，幫助他們?cè)谄脚_(tái)上實(shí)現(xiàn)品牌曝光、用戶轉(zhuǎn)化和銷售增長(zhǎng)。B端業(yè)務(wù)交互邏輯重，用戶停留時(shí)間長(zhǎng)，操作次數(shù)多，除了關(guān)注頁(yè)面加載階段的性能以外，還需要關(guān)注業(yè)務(wù)核心鏈路的操作體驗(yàn)。目前，快手商業(yè)化缺乏B端體驗(yàn)度量模型，難以評(píng)估廣告投放系統(tǒng)的用戶體驗(yàn)。因此，我們亟需建立B端業(yè)務(wù)核心鏈路體驗(yàn)度量模型，以評(píng)估用戶使用商業(yè)化B端核心系統(tǒng)的流暢度，并基于數(shù)據(jù)洞察問題，不斷改進(jìn)B端核心系統(tǒng)的用戶體驗(yàn)。

挑戰(zhàn)三：C端業(yè)務(wù)Web和Native結(jié)合不夠深入

在現(xiàn)代的互聯(lián)網(wǎng)應(yīng)用中，Web端和Native端的界限日益模糊。用戶的使用場(chǎng)景不再局限于某一特定平臺(tái)，而Web與Native端的緊密結(jié)合可以有效提升產(chǎn)品開發(fā)效率、用戶體驗(yàn)和資源共享度。由于早期業(yè)務(wù)開發(fā)周期緊急、動(dòng)態(tài)化技術(shù)棧熟悉度不足等原因，商業(yè)化端內(nèi)項(xiàng)目采用Web技術(shù)棧的比例較高，與Native側(cè)結(jié)合不夠深入。這導(dǎo)致了一些頁(yè)面未能充分利用端上優(yōu)化手段，如離線包、預(yù)建連、預(yù)請(qǐng)求等。為了應(yīng)對(duì)多變的業(yè)務(wù)環(huán)境和技術(shù)挑戰(zhàn)，我們需要借助「大前端」的組織優(yōu)勢(shì)，打破技術(shù)壁壘，搭建統(tǒng)一、高效且靈活的大前端技術(shù)體系。

三、治理思路與落地實(shí)踐

基于上述的背景現(xiàn)狀分析，我們進(jìn)一步制定治理思路，核心能力包括以下三個(gè)方面：

• 性能評(píng)估模型和防劣化機(jī)制：建立系統(tǒng)化的性能評(píng)估模型，評(píng)估性能健康度，發(fā)掘并解決端側(cè)在性能維度的潛在問題，提升用戶體驗(yàn)；同時(shí)，建立性能防劣化機(jī)制，使性能問題能夠有效的收斂在產(chǎn)品上線發(fā)布前。

• B端核心鏈路體驗(yàn)度量模型：建立以「操作卡頓率」和「任務(wù)達(dá)成率」為核心指標(biāo)的B端鏈路體驗(yàn)度量模型，從而評(píng)估用戶使用商業(yè)化B端系統(tǒng)的流暢度，并基于數(shù)據(jù)洞察問題，不斷改進(jìn)商業(yè)化B端系統(tǒng)的平臺(tái)體驗(yàn)。

• C端Web和Native緊密結(jié)合：搭建端內(nèi)頁(yè)面的技術(shù)選型標(biāo)準(zhǔn)，推動(dòng)端內(nèi)項(xiàng)目接入已有的端上能力&進(jìn)行動(dòng)態(tài)化改造，同時(shí)，持續(xù)探索Web&Native緊密結(jié)合的可能性，進(jìn)一步輸出體系化的方案，從而提升端內(nèi)動(dòng)態(tài)化頁(yè)面的流量占比。

下面我們進(jìn)一步拆解上述三大核心建設(shè)方向下的關(guān)鍵技術(shù)實(shí)現(xiàn)方案：

3.1 性能評(píng)估模型和防劣化機(jī)制

為了系統(tǒng)化地提升和維護(hù)頁(yè)面性能，我們構(gòu)建了一套「事前-事中-事后」的性能評(píng)估模型和防劣化機(jī)制。

【事前-事中-事后】整體思路

1. 事前-數(shù)據(jù)置信

• • 問題：在快手內(nèi)部，性能上報(bào)依賴主動(dòng)打點(diǎn)，難以保證數(shù)據(jù)準(zhǔn)確性，易發(fā)生數(shù)據(jù)打點(diǎn)時(shí)機(jī)和用戶體感差距較大的可能性；
  • 解法：落地?cái)?shù)據(jù)置信方案計(jì)算FMP誤差率（Web頁(yè)面對(duì)比瀏覽器內(nèi)核計(jì)算的LCP，動(dòng)態(tài)化頁(yè)面對(duì)比動(dòng)態(tài)化內(nèi)核計(jì)算的FMP），對(duì)于差值 > 20%的頁(yè)面進(jìn)行上報(bào)點(diǎn)位校準(zhǔn)

2. 事中-推進(jìn)治理

• • 問題：性能優(yōu)化治理涉及頁(yè)面較多，且項(xiàng)目間發(fā)展階段不同，影響性能背后的問題差異較大，統(tǒng)一推進(jìn)治理難度較高，但如果放任業(yè)務(wù)方各自優(yōu)化則重復(fù)工作較多，探索最佳實(shí)踐的難度較大；
  • 解法：
  • • 利用破曉平臺(tái)（快手內(nèi)部的性能評(píng)測(cè)平臺(tái)）對(duì)頁(yè)面進(jìn)行性能評(píng)測(cè)，得出當(dāng)前核心頁(yè)面存在的核心問題；
    • 以評(píng)測(cè)結(jié)果為指引，針對(duì)性地梳理出8項(xiàng)核心優(yōu)化策略和治理最佳實(shí)踐，并推進(jìn)各核心頁(yè)面治理；

3. 事后-防劣化

• • 問題：隨著項(xiàng)目持續(xù)迭代，存在性能持續(xù)劣化的可能性，難以畢其功于一役；

  • 解法：基于「事中-推進(jìn)治理」的各項(xiàng)策略，定義明確可度量的準(zhǔn)出規(guī)則，推進(jìn)在治理完成后加入性能卡口，防止性能劣化；

3.1.1 事前-數(shù)據(jù)置信

快手內(nèi)部目前性能上報(bào)依賴主動(dòng)打點(diǎn)，這種方式雖有較好的靈活性，但一線開發(fā)同學(xué)較難感知上報(bào)時(shí)機(jī)是否準(zhǔn)確，且隨著業(yè)務(wù)的迭代，難以保證上報(bào)邏輯是否會(huì)被更改。因此，需要針對(duì)FMP/T3上報(bào)點(diǎn)位進(jìn)行數(shù)據(jù)置信。

如上圖所示，F(xiàn)MP/T3數(shù)據(jù)置信過程主要包括三個(gè)核心步驟：

• 首先，根據(jù)頁(yè)面類型選擇基準(zhǔn)值，Web頁(yè)面采用Google提出的LCP作為基準(zhǔn)，而動(dòng)態(tài)化頁(yè)面則使用動(dòng)態(tài)化內(nèi)核自動(dòng)計(jì)算的FMP作為基準(zhǔn)；
• 其次，通過錄屏方式記錄頁(yè)面加載過程中的關(guān)鍵性能指標(biāo)，并截取關(guān)鍵幀以便一線開發(fā)團(tuán)隊(duì)了解上報(bào)FMP時(shí)的頁(yè)面狀態(tài)；
• 最后，結(jié)合關(guān)鍵幀圖片識(shí)別對(duì)比基準(zhǔn)值與上報(bào)點(diǎn)的誤差比例來計(jì)算FMP誤差率，對(duì)于誤差率超過20%的頁(yè)面，會(huì)提出檢查上報(bào)時(shí)機(jī)的建議。這一20%的閾值是基于快手內(nèi)部2023年對(duì)核心前端項(xiàng)目的校驗(yàn)結(jié)果得出

如上圖所示是當(dāng)前FMP置信能力的效果圖，F(xiàn)MP置信能力的實(shí)現(xiàn)僅是起點(diǎn)，更重要的是產(chǎn)品化能力的落地。如下方的時(shí)序圖所示，我們?cè)谄茣云脚_(tái)（快手內(nèi)部的性能評(píng)測(cè)平臺(tái)）實(shí)現(xiàn)FMP置信的產(chǎn)品化能力：

• 依托openAPI與雷達(dá)平臺(tái)（快手內(nèi)部的性能監(jiān)控平臺(tái)）無(wú)縫對(duì)接，預(yù)獲取項(xiàng)目信息、高流量頁(yè)面URL等，同時(shí)開放業(yè)務(wù)方手動(dòng)錄入
• 為確保登錄便捷，實(shí)現(xiàn)自動(dòng)登錄服務(wù)，兼容快手內(nèi)網(wǎng)SSO、快手Web及App等多種登錄方式
• 通過定時(shí)巡檢機(jī)制，每日收集頁(yè)面性能數(shù)據(jù)，定期向部門、項(xiàng)目組或單項(xiàng)業(yè)務(wù)進(jìn)行推送數(shù)據(jù)，提升各角色對(duì)重點(diǎn)項(xiàng)目置信現(xiàn)狀的洞察力

3.1.2 事中-推進(jìn)治理

如下圖所示，我們以破曉平臺(tái)的評(píng)測(cè)結(jié)果為指引，針對(duì)性地梳理出8項(xiàng)核心優(yōu)化策略和治理最佳實(shí)踐。在此，我們選取在靜態(tài)資源、網(wǎng)絡(luò)請(qǐng)求等維度下具有代表性的治理策略展開講述。

• 靜態(tài)資源優(yōu)化：圖片資源、腳本打包優(yōu)化等

圖片資源優(yōu)化：

圖片資源的優(yōu)化成為提升網(wǎng)站性能的關(guān)鍵一環(huán)，我們采用兼容性較好的WebP格式。與傳統(tǒng)的JPG和PNG格式相比，WebP通常能提供更小的文件體積，從而加快網(wǎng)頁(yè)加載速度并節(jié)省帶寬。同時(shí)，快手的CDN服務(wù)支持自動(dòng)將PNG、JPG等格式的圖片資源轉(zhuǎn)換為WebP格式。以下面的圖片為例，將PNG圖片轉(zhuǎn)換為WebP可以減少80+%的體積：

同時(shí)，我們還針對(duì)性地提供了一個(gè)功能全面的圖片處理庫(kù)，支持以下特性：

• 支持JPG、PNG、WebP、GIF等多種圖片格式的轉(zhuǎn)換，具備圖片裁剪、縮放、模糊、背景色設(shè)置等功能

• 能處理域名收斂問題，支持特定CDN域名和全局CDN域名的傳入

• 能根據(jù)端內(nèi)網(wǎng)絡(luò)環(huán)境智能加載不同質(zhì)量的圖片，并根據(jù)設(shè)備像素比自動(dòng)調(diào)整圖片裁剪尺寸，確保圖片資源的高效利用和優(yōu)質(zhì)顯示

盡管WebP已經(jīng)表現(xiàn)出色，但隨著技術(shù)的不斷進(jìn)步，更高效的圖片格式如HEIF和AVIF相繼出現(xiàn)。HEIF使用HEVC的幀內(nèi)編碼技術(shù)，具有HEVC幀內(nèi)編碼工具集，達(dá)到了更高的壓縮率、更好的畫質(zhì)。AVIF則是基于AV1視頻編解碼器的圖片格式，在高壓縮比和較高的視覺質(zhì)量方面比WebP和HEIF更優(yōu)。然而，這些新格式在兼容性方面仍存在挑戰(zhàn)，尤其是與老舊設(shè)備和瀏覽器的兼容性問題，限制了它們的廣泛應(yīng)用。目前，快手APP已經(jīng)支持HEIF格式，端內(nèi)的圖片庫(kù)也增加了相關(guān)參數(shù)以支持這一格式。此外，快手還自主研發(fā)了KVIF格式，比AVIF和HEIF更優(yōu)。

腳本資源打包優(yōu)化：

快手商業(yè)化前端針對(duì)前期各自獨(dú)立的研發(fā)工具和方案帶來的維護(hù)成本高、低效協(xié)作等問題，在23年進(jìn)行了前端工程方案的整合升級(jí)，統(tǒng)一將數(shù)百個(gè)前端工程遷移至Kmi（快手商業(yè)化的前端工程化解決方案）。從工程角度來看，統(tǒng)一遷移Kmi不僅提升開發(fā)效率和降低維護(hù)成本，同時(shí)還保證了靈活性和可擴(kuò)展性，為性能優(yōu)化提供了便利的先發(fā)優(yōu)勢(shì)。Kmi提供了三種Code Splitting策略，以適應(yīng)不同的項(xiàng)目需求：

• bigVendors：將async chunk 里的node_modules的文件打包到一起，避免重復(fù)，但容易導(dǎo)致單文件尺寸過大，無(wú)緩存效率可言；

<!---->

• depPerChunk：和bigVendors類似，將依賴按package name + version 進(jìn)行拆分，解決bigVendors的尺寸和緩存效率問題，但請(qǐng)求較多；

<!---->

• granularChunks：在bigVendors和depPerChunk之間取了中間值，同時(shí)又能在緩存效率上有更好的利用

在默認(rèn)使用granularChunks策略的基礎(chǔ)上，Kmi針對(duì)各核心項(xiàng)目定制化打包優(yōu)化，以最大化提升商業(yè)化前端應(yīng)用的性能和用戶體驗(yàn)。此外，Kmi在每次構(gòu)建后自動(dòng)生成詳細(xì)報(bào)告，幫助團(tuán)隊(duì)深入了解每次構(gòu)建過程中的關(guān)鍵差異，為代碼質(zhì)量和構(gòu)建速度的持續(xù)優(yōu)化提供數(shù)據(jù)支持，也為排查問題提供了快速還原現(xiàn)場(chǎng)的能力。

• 網(wǎng)絡(luò)請(qǐng)求優(yōu)化：HTTP/2+域名收斂、數(shù)據(jù)預(yù)請(qǐng)求等

升級(jí)HTTP/2+域名收斂

為了提升性能，我們針對(duì)仍在使用HTTP/1.1的商業(yè)核心項(xiàng)目域名（包括業(yè)務(wù)域名、CDN域名、埋點(diǎn)域名等）進(jìn)行了HTTP/2升級(jí)。HTTP/2的多路復(fù)用特性允許在同一TCP連接上并行交換多重請(qǐng)求-響應(yīng)消息，從而克服了HTTP/1.1中同一域名下請(qǐng)求數(shù)量受限的問題。

在升級(jí)HTTP/2的同時(shí)，我們還建議業(yè)務(wù)收斂域名，將資源集中到更少的域名下，以減少TCP連接數(shù)和優(yōu)化DNS查詢。此外，我們針對(duì)端內(nèi)場(chǎng)景配置了預(yù)建連，提前建立與目標(biāo)域名的TCP連接和TLS握手，進(jìn)一步減少延遲，提升首次請(qǐng)求的響應(yīng)速度。

數(shù)據(jù)預(yù)請(qǐng)求

如下圖所示，常規(guī)頁(yè)面流程可簡(jiǎn)化為「HTML/Bundle加載解析 -> 頁(yè)面資源加載解析 ->數(shù)據(jù)API請(qǐng)求 -> 頁(yè)面渲染」4個(gè)過程，數(shù)據(jù)預(yù)請(qǐng)求的核心思路是最大限度提前頁(yè)面數(shù)據(jù)加載時(shí)機(jī)，提前獲取當(dāng)前或未來需要的數(shù)據(jù)，以便用戶在訪問時(shí)能夠更快地體驗(yàn)到完整的內(nèi)容。

我們的數(shù)據(jù)預(yù)請(qǐng)求方案結(jié)合KMI實(shí)現(xiàn)了發(fā)起預(yù)請(qǐng)求、消費(fèi)預(yù)請(qǐng)求、日志上報(bào)和緩存機(jī)制等主要功能。通過工程配置，用戶可以在解析時(shí)立即發(fā)起預(yù)請(qǐng)求并緩存結(jié)果，隨后通過插件暴露的適配器對(duì)預(yù)請(qǐng)求結(jié)果進(jìn)行消費(fèi)。同時(shí)，我們?cè)陉P(guān)鍵節(jié)點(diǎn)上報(bào)自定義事件，收集預(yù)請(qǐng)求API信息以完善日志能力。緩存機(jī)制避免重復(fù)請(qǐng)求同一數(shù)據(jù)，進(jìn)一步加速了頁(yè)面加載速度。

在推進(jìn)接入過程中，為了適配各接入方的使用場(chǎng)景，我們?cè)谡?qǐng)求時(shí)機(jī)、底層請(qǐng)求庫(kù)兼容、日志能力完善、業(yè)務(wù)定制化需求的問題中不斷優(yōu)化進(jìn)行了40+次的迭代，功能不斷提升。目前該方案在B端各核心項(xiàng)目中發(fā)揮了較大的作用，單項(xiàng)目FMP平均減少600ms+。上述方案主要針對(duì)web項(xiàng)目，端內(nèi)項(xiàng)目則主要是使用客戶端在端內(nèi)提供的預(yù)請(qǐng)求方案，可見下方的【結(jié)合客戶端能力】這一章節(jié)。

3.1.3 事后-防劣化

如上面的時(shí)序圖所示，主要結(jié)合天穹平臺(tái)（快手內(nèi)部的前端代碼審查平臺(tái)）實(shí)現(xiàn)性能維度的天穹平臺(tái)插件，在前端研發(fā)流程上建立性能防劣化機(jī)制，具備性能維度下的任務(wù)打標(biāo)、流程阻斷、豁免審批、結(jié)果觸達(dá)等性能卡口能力。目前已為快手商業(yè)化端側(cè)核心項(xiàng)目加入卡口，一期選取5項(xiàng)web指標(biāo)、7項(xiàng)動(dòng)態(tài)化指標(biāo)作為卡口規(guī)則，規(guī)則詳見下表：

3.2 B端核心鏈路體驗(yàn)度量模型

為了更好地監(jiān)控B端系統(tǒng)的用戶操作體驗(yàn)和流程完成情況，我們建設(shè)以【操作卡頓率】和【任務(wù)達(dá)成率】為核心指標(biāo)的B端核心鏈路體驗(yàn)度量模型。其中操作卡頓率關(guān)注核心路徑的操作響應(yīng)體驗(yàn)，任務(wù)達(dá)成率則關(guān)注核心任務(wù)流程的完成情況。

3.2.1 操作卡頓率：核心路徑的操作響應(yīng)體驗(yàn)

操作卡頓率是衡量用戶操作體驗(yàn)的核心指標(biāo)，它反映了用戶在執(zhí)行操作時(shí)等待時(shí)間超出預(yù)設(shè)閾值的占比情況。該指標(biāo)通過對(duì)比卡頓操作數(shù)與有效操作數(shù)來計(jì)算得出，直觀展現(xiàn)了用戶在不同使用場(chǎng)景下可能遭遇的延遲問題。其中，有效操作數(shù)記錄了用戶每次成功執(zhí)行的操作，而卡頓操作數(shù)則統(tǒng)計(jì)因等待時(shí)間超出閾值而引發(fā)的卡頓事件。

在操作卡頓率的核心思路中，我們?yōu)楹诵逆溌飞系闹饕僮髟O(shè)定了明確的響應(yīng)閾值，一旦超出此閾值，即視為一次卡頓。針對(duì)B端用戶多樣化的操作場(chǎng)景，我們進(jìn)一步細(xì)化了操作場(chǎng)景，并制定了相應(yīng)的細(xì)分指標(biāo)和閾值，以確保評(píng)估的準(zhǔn)確性和針對(duì)性。

基于這些通用規(guī)則，我們?yōu)椴煌珺端核心業(yè)務(wù)平臺(tái)在不同場(chǎng)景下的操作卡頓設(shè)定了合理的閾值，并設(shè)計(jì)通用的卡頓率數(shù)據(jù)上報(bào)SDK，以便業(yè)務(wù)輕松接入各自平臺(tái)，降低接入成本。在快手商業(yè)化前端團(tuán)隊(duì)的B端體驗(yàn)度量模型中，操作卡頓率占據(jù)舉足輕重的地位：

• 卡頓率能夠客觀、準(zhǔn)確地反映用戶體驗(yàn)的流暢度，不會(huì)跟產(chǎn)品形態(tài)強(qiáng)耦合，也不會(huì)因業(yè)務(wù)需求的迭代而產(chǎn)生大幅波動(dòng)；

• 作為一個(gè)全局性的性能指標(biāo)，卡頓率與前端和后端的優(yōu)化工作緊密相連，后端接口的優(yōu)化和前端頁(yè)面的提升都能直接反映在卡頓率的改善上，這充分體現(xiàn)了技術(shù)優(yōu)化的價(jià)值，并幫助團(tuán)隊(duì)清晰評(píng)估技術(shù)優(yōu)化的成果，最終助力提升用戶的交互體驗(yàn)。

3.2.2 任務(wù)達(dá)成率：核心任務(wù)流程的完成情況

任務(wù)達(dá)成率是衡量用戶成功完成任務(wù)或達(dá)成目標(biāo)的比例，其計(jì)算基于提交成功數(shù)（經(jīng)過訪問ID去重處理）與頁(yè)面開始加載數(shù)的比值。這一指標(biāo)深受前端靜態(tài)資源可用性、后端接口服務(wù)穩(wěn)定性以及用戶個(gè)體差異等多重因素的影響。

以商業(yè)化廣告投放平臺(tái)的創(chuàng)編流程（即創(chuàng)建廣告的過程）為例，用戶在進(jìn)行廣告創(chuàng)建時(shí)，會(huì)經(jīng)歷一系列有序的步驟。具體包括：

• 頁(yè)面到達(dá)成功率：衡量從用戶開始訪問頁(yè)面到主JS執(zhí)行完畢，再到頁(yè)面加載完成的整個(gè)過程的成功率

• 提交轉(zhuǎn)化率：關(guān)注用戶在填寫完廣告屬性后點(diǎn)擊提交按鈕的轉(zhuǎn)化率

• 提交成功率：記錄提交操作成功的情況，并通過訪問ID進(jìn)行細(xì)致區(qū)分，以確保統(tǒng)計(jì)的準(zhǔn)確性

為了分析任務(wù)達(dá)成率的異?，F(xiàn)象，我們還會(huì)收集一系列技術(shù)指標(biāo)進(jìn)行監(jiān)控。當(dāng)任務(wù)達(dá)成率的細(xì)分指標(biāo)出現(xiàn)異常波動(dòng)時(shí)，這些技術(shù)指標(biāo)將作為關(guān)鍵的診斷工具，幫助我們定位問題的根源。具體的技術(shù)歸因指標(biāo)包括但不限于：

3.3 C端Web和Native緊密結(jié)合

在移動(dòng)端互聯(lián)網(wǎng)時(shí)代無(wú)論是H5還是動(dòng)態(tài)化頁(yè)面，與客戶端的緊密結(jié)合是性能優(yōu)化的關(guān)鍵路徑。這主要包括兩個(gè)核心方面：一是充分利用和結(jié)合已有的客戶端能力，以提升頁(yè)面加載速度；二是實(shí)施端側(cè)頁(yè)面的動(dòng)態(tài)化改造，利用動(dòng)態(tài)化的優(yōu)勢(shì)進(jìn)一步提升性能表現(xiàn)。

3.3.1 結(jié)合已有的客戶端能力

針對(duì)H5頁(yè)面，常見的優(yōu)化手段包括預(yù)加載、預(yù)建連、離線包、code cache等，而對(duì)于KRN頁(yè)面，則采用包預(yù)置、業(yè)務(wù)包預(yù)加載、code cache、預(yù)請(qǐng)求等策略。

這些優(yōu)化手段可能有著不同的名稱，但其核心理念相通的。在快手內(nèi)部，Yoda和KDS兩個(gè)端側(cè)基礎(chǔ)團(tuán)隊(duì)提供了性能優(yōu)化SOP。基于這些SOP，我們梳理出一系列適合商業(yè)化的優(yōu)化手段，并推動(dòng)了核心端內(nèi)頁(yè)面的接入工作。實(shí)踐證明，這些端側(cè)的優(yōu)化方案取得了顯著的效果。在接入后，端內(nèi)單項(xiàng)目的FMP時(shí)間平均減少500ms+

3.3.2 端側(cè)頁(yè)面動(dòng)態(tài)化改造

對(duì)于web技術(shù)棧而言，由于瀏覽器底層架構(gòu)設(shè)計(jì)、JS的解析和執(zhí)行效率等原因，在渲染性能和交互流暢度上很難突破瀏覽器限制。相較而言，采用類RN技術(shù)棧開發(fā)的頁(yè)面由于核心渲染層 & 組件基于原生實(shí)現(xiàn)，整體性能體驗(yàn)?zāi)軌蛱嵘粋€(gè)臺(tái)階，且付出的開發(fā)效率/發(fā)版效率代價(jià)相對(duì)而言較小。

舉個(gè)例子，快手商業(yè)化大前端團(tuán)隊(duì)以磁力建站落地頁(yè)作為試點(diǎn)，完成動(dòng)態(tài)化改造后的性能收益提升35%以上，性能提升也帶來了顯著的業(yè)務(wù)CVR和預(yù)期消耗增長(zhǎng)。因此，如下圖所示，我們搭建了一套端內(nèi)頁(yè)面的技術(shù)選型標(biāo)準(zhǔn)，完善動(dòng)態(tài)化技術(shù)基建，持續(xù)推動(dòng)端內(nèi)項(xiàng)目完成動(dòng)態(tài)化改造。

值得一提的是，在探索Web和Native緊密結(jié)合過程中，我們也在思考一套漸進(jìn)式增強(qiáng)方案。以商業(yè)化磁力金牛和粉條為例，這兩個(gè)項(xiàng)目主要流量在端內(nèi)，且有很強(qiáng)的B端屬性，歷史包袱較重。經(jīng)過與業(yè)務(wù)同學(xué)共同評(píng)估，貿(mào)然地切換至動(dòng)態(tài)化技術(shù)棧的成本較高。因此，我們希望能在保留原有Web開發(fā)模式的同時(shí)，進(jìn)一步提供性能極佳的富交互組件來創(chuàng)建Hybrid應(yīng)用，讓這些Web應(yīng)用具有媲美Native的用戶體驗(yàn)。

如上圖所示，以磁力金牛和粉條的多Tab場(chǎng)景為例，我們的思路是基于Native實(shí)現(xiàn)多Tab容器，用于承載復(fù)雜的多Tab頁(yè)面結(jié)構(gòu)。主要能力如下：

• 容器能力：提供RN、TK、webview等渲染容器，并提供定制化的容器能力，如資源預(yù)加載、數(shù)據(jù)預(yù)請(qǐng)求、容器預(yù)熱等方案

• 配置化能力：支持自定義底部導(dǎo)航欄、底部Tab、骨架屏等配置化能力

• 框架交互能力：支持容器間數(shù)據(jù)共享&通信，可切換tab，控制元素展現(xiàn)等

四、階段性成果

經(jīng)過一系列的努力與優(yōu)化，我們?nèi)〉昧孙@著的階段性成果：

• 北極星達(dá)標(biāo)情況：性能優(yōu)秀達(dá)標(biāo)率提升61.63%，性能良好達(dá)標(biāo)率提升41.95%，這充分表明我們的性能優(yōu)化策略正在逐步顯現(xiàn)成效。

<!---->

• B/C端FMP月均值整體呈逐月下降趨勢(shì)，核心頁(yè)面的整體性能（P90分位）提升43.23%
• • B端業(yè)務(wù)：B端核心頁(yè)面整體性能提升45.74%，核心廣告投放平臺(tái)的卡頓率指標(biāo)均降低至20%以下
  • C端業(yè)務(wù)：C端核心頁(yè)面整體性能提升42.12%，C端核心頁(yè)面的觸達(dá)率提升10.16pp，C端核心頁(yè)面的秒開率提升31.62pp

綜上所述，無(wú)論是從北極星指標(biāo)的提升，還是從B/C端FMP月均值的下降，再到B端卡頓率和C端觸達(dá)率&秒開率等指標(biāo)的提升，都充分證明了我們的努力是值得的。

五、總結(jié)與展望

本篇文章主要基于大前端視角，解決不同領(lǐng)域場(chǎng)景下的頁(yè)面性能問題。展望未來，我們將繼續(xù)把性能體驗(yàn)作為重點(diǎn)關(guān)注領(lǐng)域，打造標(biāo)準(zhǔn)化、平臺(tái)化的性能優(yōu)化領(lǐng)域體系建設(shè)，推動(dòng)商業(yè)化大前端頁(yè)面性能水平達(dá)到業(yè)界領(lǐng)先，以確保商業(yè)化用戶在使用我們的產(chǎn)品時(shí)獲得流暢、快捷和滿意的體驗(yàn)，從而推動(dòng)業(yè)務(wù)的持續(xù)增長(zhǎng)和發(fā)展。