端性能優化是指通過一系列的技術手段和優化策略，提高網頁的加載速率和用戶體驗。下邊是一些后端性能優化的方案：1.頁面渲染優化：-降低HTTP懇求：合并和壓縮CSS和JavaScript文件，使用CSSSprites技術來降低圖片懇求。-延后加載：將非關鍵資源（如圖片、視頻等）的加載延后到頁面其他內容加載完成后再進行加載。-使用CDN加速：將靜態資源布署到全球分布的CDN節點上，推進資源的加載速率。-使用懶加載：只加載當前可見區域的內容，延后加載其他區域的內容。2.打包優化：-代碼分割：將代碼根據功能模塊進行分拆，按需加載，降低首次加載的文件大小。-TreeShaking：通過靜態剖析，除去未使用的代碼，降低打包后的文件大小。-按需加載：依照路由或用戶操作，動態加載所需的模塊和組件，降低初始加載的資源。3.總體優化：-緩存優化：合理設置緩存策略，借助瀏覽器緩存、CDN緩存、本地緩存等，減輕重復懇求和數據傳輸。-壓縮資源：對CSS、JavaScript、HTML等靜態資源進行壓縮，降低文件大小，提升加載速率。-降低重畫和回流：通過優化CSS款式和DOM操作，降低頁面的重畫和回流，提升渲染性能。-使用WebWorkers：將一些歷時的任務放在WebWorkers中執行，防止阻塞主線程。

升商城系統的頁面加載速度與進行SEO優化是提高轉化率的關鍵策略。以下是一些具體的操作建議：

提升頁面加載速度

1. 優化圖像和媒體文件：壓縮圖片和視頻，使用正確的格式（如WebP），并利用懶加載技術，即僅在用戶滾動到可視區域時加載圖片。
2. 利用CDN：內容分發網絡（CDN）可以將網站內容緩存到全球各地的服務器，減少用戶訪問時的延遲。
3. 代碼和資源優化：合并CSS和JavaScript文件，減少HTTP請求；移除未使用的代碼和插件；使用GZIP壓縮減少文件大小。
4. 服務器優化：選擇合適的服務器配置，優化數據庫查詢，使用緩存技術如Redis或Memcached減輕服務器負載。
5. 減少重定向：過多的頁面重定向會增加加載時間，盡量減少不必要的重定向。

SEO優化

1. 關鍵詞策略：研究并選擇與商城產品相關的關鍵詞，將其自然融入頁面標題、描述、H1標簽和內容中。
2. 優化URL結構：使URL簡潔、易于理解，包含關鍵詞，并反映頁面內容。
3. 提高內容質量：提供獨特、高質量的產品描述，定期更新博客或新聞板塊，增加網站的權威性和價值。
4. 內鏈與外鏈：合理布置內部鏈接，引導用戶瀏覽更多頁面；爭取高質量的外部鏈接，提升網站的信譽。
5. 移動友好：確保網站設計響應式，適配各種設備，提高移動用戶的體驗，這同時也是Google排名的重要因素。
6. 提交網站地圖：創建并提交XML網站地圖至搜索引擎，幫助爬蟲更好地索引網站內容。
7. 利用結構化數據：通過Schema.org等格式標記商品、評價等信息，使搜索引擎更容易理解頁面內容，有機會獲得富片段展示。

綜合運用以上策略，不僅可以提升用戶在商城的瀏覽體驗，縮短頁面加載時間，還能通過SEO優化增加搜索引擎可見度，吸引更多潛在客戶，最終提升轉化率。

灝 大淘寶技術 2024年07月15日 18:04 浙江

最近做了一些移動端頁面的首幀優化的工作，有很多心得和感受，其中有很多共性的東西，總結成一篇文章希望可以幫助到更多業務，也希望引起讀者一起討論。

為何要做首幀優化

作為程序匠人，一直在努力追求做一款好的產品，打磨各個細節，做好用戶體驗，而首幀是用戶接觸到產品的第一個頁面，是體驗的重中之重。也正因是產品的第一個頁面，轉化率接近100%，從ROI的角度來說，做好首幀優化也是一個很劃算的deal。

做好首幀優化，至少可以帶來以下好處：

1. 建立用戶好感度：良好的第一印象，提升品牌形象
2. 提升業務轉化率：提升業務曝光率、點擊率、帶來更好的業務結果
3. 更小的資源消耗、減少成本：更長的首幀啟動時間意味著更多的資源消耗，更多的成本投入。優化首幀可以減少一些不必要的資源開銷和損耗，節省技術成本。

首幀口徑和衡量標準

?口徑

做優化前我們需要先想想，用戶對首幀體驗預期是怎樣的？首幀定義是什么，起始范圍是什么。不同的口徑會影響我們的指標，設計方案，工作量。定義了口徑之后，我們可以確定優化事項范圍以及邊界。

Loading圖：

即開始出現loading、展現灰底圖或是頁面框架圖，如果這頁面展示也比較久的話，則說明用戶交互出現卡頓、假死，遲遲沒收到反饋，用戶交互被阻塞，屬于嚴重影響用戶體驗的行為。所以建議在展示骨架圖之前，除了framework以外，不要有io、網絡等耗時的前置依賴，也不需要有中轉頁的行為邏輯。

內容主體呈現：

即頁面大部分的內容已經渲染出來，用戶可以得到足夠的信息，這是一個比較符合用戶體感的口徑，大多數業務選取的就是這個口徑。不過不同業務對于“大部分”，“主體”的定義有所不同，業務可以結合自身需求進行合理選擇：

• 對于“主體”定義：如頭圖、標題、相機取景器、
• 對于“大部分”定義：如按照展示“面積”計算的，完整度80%、90%、100%（有一些分頁加載策略的業務場景）

頁面可交互：

這個階段表示頁面已經完全渲染完成，并且用戶可以進一步交互，如點贊、分享、收藏、加購等行為。

?衡量標準

絕對耗時：

指定口徑下的絕對耗時時長，單位一般是ms，多是用于單機線下的驗證和比較，不同機型之間、不同場景下的差異較大，如高端機與低端機之間的差別可以相差好幾倍，如要反應樣本的整體性，多用分位值或者秒開率來衡量。

分位值/秒開率：

• 多用于線上觀測，反應樣本的整體性和趨勢，長尾數據、極端case不容易被忽略
• 應該讓P90P95分位值，接近于中位數，讓整體樣本的差異性小一些

取值標準：

• 按照經驗值：

• 絕對耗時<500ms，一般情況下頁面切換動畫300ms，所以頁面首幀500ms以內渲染完成，能夠有一個較好的體驗，google官方也建議頁面盡可能在500ms以內完成冷啟動。
• 秒開率>95%+，即95分位<=1000ms
• 
  

• 參考頭部競品：

• 能窺探出同等業務復雜度下，普遍用戶能接受的一個范圍
• 通過屏幕錄制方式可獲取
• 
  

• 標準也并不是一成不變的，隨著硬件性能不斷提升、framework不斷優化、亦或是業務形態的變化，而不斷調整。

如何分析排查性能問題（以Android為例）

?了解現狀

首先要掌握自身產品以及行業競品的首幀數據，了解在行業中的一個排名情況，再決策是否要進一步做優化，做到什么樣的程度。為了保證自身和競品采用的同一種口徑獲取首幀耗時，我們這邊采用了錄屏的方式。

錄屏分析方案：在同一臺手機上使用特定幀率錄屏（如30fps，即1幀33ms），再通過數幀數的方式來計算出首幀耗時的時間，錄屏的越高越精確。

自動化腳本方案：

通過自動化錄屏腳本工具、使用模擬點擊 + OCR文字識別/圖像識別的方案，識別首/尾幀、進而自動化生成耗時的中位數、平均值。

?了解原理

在分析問題之前，我們要搞清楚系統是如何將首幀繪制在屏幕上的，了解了這些我們才能針對性的分析問題。

• Activity啟動流程：https://juejin.cn/post/7063699032144609287
• View渲染流程：

• https://blog.csdn.net/u012216131/article/details/115704825
• https://www.cnblogs.com/mysweetAngleBaby/p/15549126.html

?使用性能分析工具

1. 官方工具：

從代碼、資源等細粒度的維度（如方法級別、事件級別），來定量分析程序對CPU、內存、網絡IO等核心計算資源的消耗情況，可以比較完整、全面的分析啟動過程，但這種方式得到的數據比較細碎、散點，需要經過一定的歸納、合并才能得到一個具體可實施的方案。

• TraceView：Instrumentation 模式下采用 AddListener 的方式注冊 MethodError、MethodExited、MethodUnwind 的回調來采集方法起止時間；Sampling 模式下使用一個 SamplingThread 定時主權線程堆棧，通過對此的堆棧對比近似確定函數的進入和退出時間；雖然是官方提供的工具，但兩種模式本身都存在比較大的性能損耗，可能帶偏優化方向。
• CPU Profiler：整體通過 JVM Agent 實現，具有完成方法調用棧輸出，且支持 Java、C/C++方法的耗時檢測，上手比較簡單，但其同樣存在性能損耗較大的問題，且一般僅用于 debug 包，release 包需要額外添加 debuggable 的配置。
• Systrace：基于 Android 系統層的 Atrace 實現，Atrace 又基于 Linux kernal 層的 ftrace 實現，ftrace 在內核中通過函數插樁獲取耗時；其自身性能損耗比較低、數據源豐富且具有較好的可視化頁面，但其默認監控點較少，在 APP 自有代碼中的監控點需要手動加入，比較麻煩。

2. 二方/三方工具：

如果我們的頁面是通過第二/三方的頁面框架所構建，如weex/rn/flutter等框架。我們可以通過第二方框架提供的性能分析工具、插件去分析和歸因。

• rn：https://reactnative.dev/docs/performance
• flutter：https://docs.flutter.dev/perf/ui-performance
• compose ui: https://developer.android.com/develop/ui/compose/performance
• 
  

3. 業務自定義工具：

有時為了彌補官方工具火焰圖太細碎、難以聚類、需要花費更多時間去分析和追蹤，我們可以根據業務視角、使用自定義的業務階段/流程，去粗粒度的去分析各個階段的耗時。

• 埋點/日志工具：核心鏈路節點performance日志，如：頁面視圖創建、網絡耗時、數據處理、渲染
• 切面/插裝代碼工具：面向常用對象/事務/流程，對業務無侵入式的觀測和統計

常見的優化方案和策略

分析完原因后，我們需要對不同原因給出優化方案，首幀優化的核心思想用一句話總結是：在盡可能在短的時間里準備好首幀渲染所需要最小的資源模型。圍繞“最短時間”和“最小的模型”兩個中心思想下，總結了一些常見的優化策略：

?預加載/緩存策略

在前置頁面的合理時機（一般是閑時）提前獲取數據、下載資源，并解析，然后緩存到內存或者磁盤里，以便后置頁面快速讀取數據和資源。

這個策略可能帶來以下副作用：

• 提前獲取的數據可能會引發服務端qps暴增，帶來額外資源開銷，和影響穩定性。
• 如果頁面點擊率不高的話，緩存命中率會比較低，造成資源浪費的問題。
• 可能會造成前置頁面的性能受損。
• 這個策略結合特定人群一起使用會更好一些。

?延遲初始化（懶加載）

與首幀無關的代碼邏輯、資源可以在首幀渲染后進行初始化，具體的初始化時機可以在使用時再初始化，如某些二級頁面的創建、多余tab的創建等。

?并行處理&異步化

并行處理：充分利用多核CPU，通過多線程并行處理耗時的任務，提升CPU的負荷。如容器初始化和數據請求解析可以同時進行。

異步化：一些比較耗時、IO任務，不要占用寶貴的主線程資源。

?View渲染優化

Android里面ViewTree構建和渲染是比較耗時過程的，如下：

• 將 xml 文件解析到內存中 XmlResourceParser 的 IO 過程；
• 根據 XmlResourceParser 的 Tag name 獲取 Class 的 Java 反射過程；
• 創建 View 實例，最終生成 View 樹；
• View渲染：layout、measure、draw
• 
  

優化方案：

• 層級優化/布局優化 （merge嵌套），減少布局層級，減少遞歸深度
• 使用ViewStub，延遲按需inflate，降低inflate耗時
• x2c：xml轉code構建
• 異步inflate，異步ui構建

?數據借用

為了加快數據獲取，我們可以從前一個頁面借用一部分數據過來將主體內容做填充，隨后再用真實數據刷新。這個方案多適用于列表進入詳情的場景。

這里的數據不僅包含文字和圖片，也可以延伸到媒體播放器、camera取景器等其他一些文件流、數據流，甚至可以是widget組件（共享元素動畫）。

?分塊渲染

如果頁面元素比較多，數據量比較大，一次性請求加載的時間比較長，這個時候我們可以通過分塊的方式，將大頁面拆成若干個小頁面模塊、將服務端接口拆成若干個小接口，各個頁面模塊獨立渲染。可以有效降低服務端RT耗時，以及頁面渲染耗時。

?骨架圖優化

使用骨架圖作為打底圖和純白底圖相比，有了布局樣式等信息，更加接近于首幀的效果，正式數據刷新時，頁面也不會出現明顯刷新，體驗比較好。

線上驗收

線下的優化，并不意味著線上真實用戶也能同步看到優化的結果，因為業務路徑的差異、機型的差異，你線下的優化可能不具備普遍性，所以需要線上真實結果的反饋。

1. 較全面信息的數據大盤建立：

包含：版本、設備分、業務場景、機型、時間等盡可能多的數據維度的數據大盤，可以盡量還原優化or劣化的信息全貌，提供更多的歸因信息。

2. 分位值（數據聚合類別）：

長尾數據、小眾case往往容易被整體數據給覆蓋，不足以引起重視，為了我們應該分別分析中位數、分位數。

3. AB實驗：

這樣做不僅能控制變量確保優化項的嚴格有效，還能借此來觀察性能優化所帶來的業務指標收益，這些都可以作為規劃后續啟動優化方向的參考指導。

防劣化

人無完人，人都會失誤犯錯，絕對不能把系統性能交給某一個人身上，一個人犯錯概率高，一群人都犯錯的概率低，應該交給一群人共同協作的機制和流程。

防劣化相比于優化是更能持久有益的，所以更應該在較早期建立起防劣化機制：

• 準入機制：

• 禁止在啟動核心階段添加代碼，一切代碼添加需要走審查流程，啟動階段包含：
• Windvane.execute,
• Activity.onCreate,
• Fragment.onCreate/onCreateView
• 審查機制：提審/測試/核準/灰度/上線
• 
  

• 遵循嚴格規范

• 代碼約束
• 框架約束
• 檢查工具
• CR規范
• 
  

• 線上監控

• 大盤監控：趨勢分析
• 分階段監控：歸因分析
• 監控告警：及時止損

結語

?持續迭代

首幀優化并非一蹴而就，而是一個需要持續迭代與打磨的過程，在初期階段優化空間相對較大，只需要投入一些不多的資源，即可看到較大的收益，但隨著優化不斷深入，到了中期階段，就需要有相當程度的投入，去攻堅各個難點，聚少成多，才能看到收益。后期隨著業務越來越復雜，分支越來越多，要做防劣化工作，同時也要和業務一起做好精細化管理，將有限的資源，分配給最優先級的業務，要做好ab實驗管控、優先級管理、及時下線等。

?做好復雜度管理

為了將達到最優的啟動速度，我們運用了各式各樣的策略，將時間和空間塞得滿滿的，但是這改變了原來的常規流程，帶來了額外代碼復雜度提升，比如預加載策略，后面維護同學需要考慮，預加載失敗以及成功兩種情況，又或者是緩存策略，后面維護的同學需要考慮緩存命中、不命中的情況，如果不斷使用if堆積代碼，那代碼最終將無法維護。所以我們需要通過框架來管理復雜度，盡量讓業務層無感知。比如數據中間層，業務無需關心數據是否來自緩存還是實時請求，拿來使用即可。

?全局意識

通常我們以啟動速度來衡量啟動性能。為了提升啟動速度，我們可能會把一些原本在啟動階段執行的任務進行延后或者按需，這種方式能夠有效優化啟動速度，但同時也可能損害后續的使用體驗。比如，如果將某個啟動階段的后臺任務延后到后續使用時，如果首次使用是在主線程，則可能會造成使用卡頓。因此，我們在關注啟動性能的同時，也需要關注其他可能影響的指標。性能上我們需要有一個能體現全局性能的宏觀指標，以防止局部最優效應。

參考資料

• Profile性能追蹤工具集：
• https://developer.android.com/studio/profile
• Android Performance 指南：
• https://developer.android.com/topic/performance/overview
• RN Performance 指南：
• https://reactnative.dev/docs/performance
• Flutter Performance 指南：
• https://docs.flutter.dev/perf/ui-performance
• Android Activity的創建流程：
• https://juejin.cn/post/7063699032144609287
• View 的渲染機制：
• https://blog.csdn.net/u012216131/article/details/115704825
• Android 底層渲染原理：
• https://www.cnblogs.com/mysweetAngleBaby/p/15549126.html
• 抖音Android啟動優化之理論和工具篇：
• https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==&mid=2247491335&idx=1&sn=e3eabd9253ab2f83925af974db3f3072

團隊介紹

我們是淘天集團-內容技術團隊，專注于推動淘寶內容生態和電商體驗的深度融合。我們致力于為全球用戶提供豐富、多樣性、高品質的購物內容體驗，旨在通過技術創新，更好地連接用戶和商品，以提升用戶的購物滿意度和平臺的商業價值。通過尖端技術提升內容創作、分發與消費的效率，賦能內容創作者、商家與消費者，構建一個繁榮、健康、可持續發展的內容生態圈。