一、背景介紹

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

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

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

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

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

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

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

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

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

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

1.3 核心性能問題分析

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

1.3.1 靜態(tài)資源加載和渲染耗時過長

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

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

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

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

4. 腳本資源較大：腳本資源請求體積較大，JS覆蓋率較低，腳本解析時長占高，影響資源加載時長和渲染時長

1.3.2 接口請求耗時較長

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

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

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

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

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

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

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

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

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

三、治理思路與落地實踐

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

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

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

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

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

3.1 性能評估模型和防劣化機制

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

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

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

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

2. 事中-推進治理

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

3. 事后-防劣化

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

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

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

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

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

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

如上圖所示是當(dāng)前FMP置信能力的效果圖，F(xiàn)MP置信能力的實現(xiàn)僅是起點，更重要的是產(chǎn)品化能力的落地。如下方的時序圖所示，我們在破曉平臺（快手內(nèi)部的性能評測平臺）實現(xiàn)FMP置信的產(chǎn)品化能力：

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

3.1.2 事中-推進治理

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

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

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

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

同時，我們還針對性地提供了一個功能全面的圖片處理庫，支持以下特性：

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

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

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

盡管WebP已經(jīng)表現(xiàn)出色，但隨著技術(shù)的不斷進步，更高效的圖片格式如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)的圖片庫也增加了相關(guān)參數(shù)以支持這一格式。此外，快手還自主研發(fā)了KVIF格式，比AVIF和HEIF更優(yōu)。

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

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

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

<!---->

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

<!---->

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

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

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

升級HTTP/2+域名收斂

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

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

數(shù)據(jù)預(yù)請求

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

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

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

3.1.3 事后-防劣化

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

3.2 B端核心鏈路體驗度量模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 容器能力：提供RN、TK、webview等渲染容器，并提供定制化的容器能力，如資源預(yù)加載、數(shù)據(jù)預(yù)請求、容器預(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月均值整體呈逐月下降趨勢，核心頁面的整體性能（P90分位）提升43.23%
• • B端業(yè)務(wù)：B端核心頁面整體性能提升45.74%，核心廣告投放平臺的卡頓率指標(biāo)均降低至20%以下
  • C端業(yè)務(wù)：C端核心頁面整體性能提升42.12%，C端核心頁面的觸達(dá)率提升10.16pp，C端核心頁面的秒開率提升31.62pp

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

五、總結(jié)與展望

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