一、背景介紹

1.1 頁面性能優化的價值與意義

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

在快手商業化團隊，我們深知頁面性能對提升用戶體驗的重要性。因此，我們基于快手內部動態化技術的特點，并參考了Google的性能標準，制定了快手商業化頁面性能達標的北極星指標（如下）

1.2 核心頁面性能現狀

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

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

我們借助雷達平臺（快手內部的性能監控平臺），對各核心頁面的性能數據進行了全面且細致的整理與分析，包括靜態資源、接口等維度，并得出以下結論：

• 僅有18.42%的頁面即7個頁面達到了“性能優秀”的基線標準，且其中有4個頁面只是略優于基線標準。有15個頁面其性能被判定為“較差”。

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

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

1.3 核心性能問題分析

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

1.3.1 靜態資源加載和渲染耗時過長

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

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

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

3. 頁面渲染結構較復雜：以廣告投放平臺為首的核心業務的頁面首屏渲染結構非常復雜；

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

1.3.2 接口請求耗時較長

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

二、面臨的挑戰

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

挑戰一：統一推進各核心系統治理的難度較高

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

挑戰二：B端業務核心鏈路體驗度量模型缺失

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

挑戰三：C端業務Web和Native結合不夠深入

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

三、治理思路與落地實踐

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

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

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

• C端Web和Native緊密結合：搭建端內頁面的技術選型標準，推動端內項目接入已有的端上能力&進行動態化改造，同時，持續探索Web&Native緊密結合的可能性，進一步輸出體系化的方案，從而提升端內動態化頁面的流量占比。

下面我們進一步拆解上述三大核心建設方向下的關鍵技術實現方案：

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

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

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

1. 事前-數據置信

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

2. 事中-推進治理

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

3. 事后-防劣化

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

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

3.1.1 事前-數據置信

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

如上圖所示，FMP/T3數據置信過程主要包括三個核心步驟：

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

如上圖所示是當前FMP置信能力的效果圖，FMP置信能力的實現僅是起點，更重要的是產品化能力的落地。如下方的時序圖所示，我們在破曉平臺（快手內部的性能評測平臺）實現FMP置信的產品化能力：

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

3.1.2 事中-推進治理

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

• 靜態資源優化：圖片資源、腳本打包優化等

圖片資源優化：

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

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

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

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

• 能根據端內網絡環境智能加載不同質量的圖片，并根據設備像素比自動調整圖片裁剪尺寸，確保圖片資源的高效利用和優質顯示

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

腳本資源打包優化：

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

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

<!---->

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

<!---->

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

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

• 網絡請求優化：HTTP/2+域名收斂、數據預請求等

升級HTTP/2+域名收斂

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

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

數據預請求

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

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

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

3.1.3 事后-防劣化

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

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

為了更好地監控B端系統的用戶操作體驗和流程完成情況，我們建設以【操作卡頓率】和【任務達成率】為核心指標的B端核心鏈路體驗度量模型。其中操作卡頓率關注核心路徑的操作響應體驗，任務達成率則關注核心任務流程的完成情況。

3.2.1 操作卡頓率：核心路徑的操作響應體驗

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

在操作卡頓率的核心思路中，我們為核心鏈路上的主要操作設定了明確的響應閾值，一旦超出此閾值，即視為一次卡頓。針對B端用戶多樣化的操作場景，我們進一步細化了操作場景，并制定了相應的細分指標和閾值，以確保評估的準確性和針對性。

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

• 卡頓率能夠客觀、準確地反映用戶體驗的流暢度，不會跟產品形態強耦合，也不會因業務需求的迭代而產生大幅波動；

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

3.2.2 任務達成率：核心任務流程的完成情況

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

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

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

• 提交轉化率：關注用戶在填寫完廣告屬性后點擊提交按鈕的轉化率

• 提交成功率：記錄提交操作成功的情況，并通過訪問ID進行細致區分，以確保統計的準確性

為了分析任務達成率的異常現象，我們還會收集一系列技術指標進行監控。當任務達成率的細分指標出現異常波動時，這些技術指標將作為關鍵的診斷工具，幫助我們定位問題的根源。具體的技術歸因指標包括但不限于：

3.3 C端Web和Native緊密結合

在移動端互聯網時代無論是H5還是動態化頁面，與客戶端的緊密結合是性能優化的關鍵路徑。這主要包括兩個核心方面：一是充分利用和結合已有的客戶端能力，以提升頁面加載速度；二是實施端側頁面的動態化改造，利用動態化的優勢進一步提升性能表現。

3.3.1 結合已有的客戶端能力

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

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

3.3.2 端側頁面動態化改造

對于web技術棧而言，由于瀏覽器底層架構設計、JS的解析和執行效率等原因，在渲染性能和交互流暢度上很難突破瀏覽器限制。相較而言，采用類RN技術棧開發的頁面由于核心渲染層 & 組件基于原生實現，整體性能體驗能夠提升一個臺階，且付出的開發效率/發版效率代價相對而言較小。

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

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

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

• 容器能力：提供RN、TK、webview等渲染容器，并提供定制化的容器能力，如資源預加載、數據預請求、容器預熱等方案

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

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

四、階段性成果

經過一系列的努力與優化，我們取得了顯著的階段性成果：

• 北極星達標情況：性能優秀達標率提升61.63%，性能良好達標率提升41.95%，這充分表明我們的性能優化策略正在逐步顯現成效。

<!---->

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

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

五、總結與展望

本篇文章主要基于大前端視角，解決不同領域場景下的頁面性能問題。展望未來，我們將繼續把性能體驗作為重點關注領域，打造標準化、平臺化的性能優化領域體系建設，推動商業化大前端頁面性能水平達到業界領先，以確保商業化用戶在使用我們的產品時獲得流暢、快捷和滿意的體驗，從而推動業務的持續增長和發展。