前端性能優化方案

為了確保事情或工作有序有效開展，通常需要提前準備好一份方案，方案屬于計劃類文書的一種。那么方案應該怎么制定才合適呢？下面是小編為大家收集的方案策劃范文，供大家參考借鑒，希望可以幫助到有需要的朋友。

前端性能優化方案篇一

上面的腳本計算了 head 中的第一個 js腳本執行后加載頁面所需的時間，但它沒有給出任何關于從服務器獲取頁面所需的時間，或是頁面初始化生命周期的信息。

由此我們可以計算舊文檔的卸載、重定向、應用緩存、dns lookup、tcp 握手、http 請求處理、http 響應處理、dom 處理、document加載完成等頁面性能打點。具體可以參考navigation-timing w3c的規范 和 幾個頁面關鍵指標是如何計算的

從上圖中我們可以看出document processing是 navigation timing 獨有的，后面我們也會介紹resource timing。整體而言 level 2 標準更加的全面，把web performance timing分成了各個 performance metric，看起來一目了然，然而各個主流瀏覽器還存在兼容性問題。

介紹完這兩個performance navigation timing api，我們順便再來看一下其余幾個主要的performance timing api：resource timing api 、 paint timing api 和 long task timing api，以及如何使用performanceobserver異步獲取性能數據。

performanceobserver 可以被動地訂閱與性能相關的事件，也就是說這個 api 通常不會干擾頁面主線程的性能，因為它的回調通常在空閑期間觸發。默認情況下，performanceobserver 對象只能在條目出現時觀察它們。如果想延遲加載性能分析代碼（不阻止更高優先級的資源），我們需要這么做：

設置buffered 為true，瀏覽器將在第一次調用 performanceobserver 回調時返回其性能條目 緩沖區中的歷史條目。

前端性能優化方案篇二

（下文以2024年2月a頻道頁面為例，均為dummy仿造后數據，也不代表整體情況）

.如何衡量性能問題嚴重性

衡量性能問題嚴重性，是為了讓大家意識到優化的必要性，以及急迫性

同.性能黑榜，不贅述

見下圖“可交互時長分布圖”，一個記錄代表一個用戶。

即使不去統計，我們都能很明顯的看出來，這個a頻道頁面：

和開發說明問題嚴重性時，這個會很有代入感，比如見下圖，10%的android用戶在以上，是不是可以認為他們大部分都跳失了？

下圖不用算都能明顯發現，秒開率和 整體數據差異實在太大

.分析性能瓶頸-分析思路

首先要明確，性能分析主要是給相關頁面的前端、開發同學看，給關心問題的測試同學看，所以我們可以拆分的更細節、更專業。可以先分前端、后端2個大類：

.分析性能瓶頸-前端環節

業務因素（具體不表），分終端是重點。

從可交互時長、秒開率、3秒+率、5秒+率，分別分析，都能論證--支付寶端問題更明顯。

下圖將t1~t9 每個階段打點情況可視化，并分析重點環節的差值（打點邏輯由前端定義）

見圖2可以明顯觀察到：

1、接口耗時太久，且后變差明顯（可以去追溯下發生了什么）； 2、lbs獲取耗時很久，高于平均1倍以上，而取lbs是a頻道頁的關鍵邏輯

我們根據手淘的高中低端機評判標準，埋點獲得數據。平均時長，高中低各自占比，以及低端時長分布（也可選中高端）。下圖可發現，低端機比例很低（需要思考是否有必要重點優化），但低端機超過3秒以上的比例遠高于其他的（和總體的完全時間分布對比） 。

包括：機型、系統等，可做參考

.分析性能瓶頸-后端環節

主要從后端維度來分析

這里可見，下圖盡管是開始發起請求-》收到請求的全過程，但也嚴重超標（幾乎是標準值的2倍）

前端性能優化方案篇三

通過線上用戶的真實采集，并制定能反應用戶體感的指標，進行性能黑榜和全局趨勢分析。

從重點單點角度，我們通過性能黑榜；從整體視角，我們通過整體趨勢分析。

.性能數據的采集

arms前端監控專注于對web場景、小程序場景的監控，從頁面打開速度（測速）、頁面穩定性（js診斷錯誤）和外部服務調用成功率（api）這三個方面監測web和小程序頁面的健康度。

sls日志服務為log、metric、trace等數據提供大規模、低成本、實時的平臺化服務。日志服務一站式提供數據采集、加工、查詢與分析、可視化、告警、消費與投遞等功能。

odps即maxcompute，是適用于數據分析場景的企業級saas模式云數據倉庫。

fbi是阿里內的智能大數據分析和可視化平臺，下面的所有截圖都是在fbi平臺配置圖表而成，還未對外開放。

arms-sdk結合前端的自定義埋點，在海量用戶訪問的同時，就會自動上報數據到sls日志庫，整體過程如下圖：

.性能指標的確定

所有前臺頁面，每個用戶每次瀏覽的有效數據（完全加載<15s 內有效）

指標的影響因子：從用戶視角，頁面流量越大，則對整體數據的影響越大（也就是權重越大）

這樣做的好處：流量越大數值越嚴重的，優化的效果（正反饋）越明顯，確定了治理性能問題的優先級。

結合淘系、以及集團其他部門的

.性能黑榜

為何要用性能黑榜來作為主要發現手段？我們通常可推理得：

（可根據各自業務，加個樣本量的篩選，如我們看每日pv 10w以上的）

.整體性能趨勢分析

整體趨勢分析，即是為在整體角度，看我們的頁面性能趨勢，它是重要的度量指標。 這里我們把所有的流量都納入，沒有頁面的區分，為的是基于用戶維度，流量大的頁面權重自然會更大。

從上圖看，1月初到2月中旬的數據正在持續惡化，必須要采取措施治理！

前端性能優化方案篇四

很多人都以為，前端性能優化，重點在“前端”優化，“測試”很難起到主導作用。試著換個角度，從整個研發團隊視角看，前端做運動員專項治理，測試做裁判員專項評測，這套機制，是否更能切實做到優化，達成的數據也更讓大家信賴？再者，測試不止局限于此，還可做隊醫、分析師。。。。

.可持續優化閉環

以下持續優化閉環，是我們摸索著實行了一年多，有效且高效的解法。

從上圖看，整個過程為：

step0、前端事先進行埋點，（一般前端做了sdk，直接引入即可）

step1、測試通過性能黑榜，發現最為突出的重點性能問題頁面（首屏平均時長&秒開率，pv&業務意義， 多項結合度量）

step2、協助前端一起專業分析問題頁面，找出性能瓶頸點

step3、前端更有策略地針對性治理

step4、查看性能趨勢變化，驗證優化效果

step5、假設已達到優化預期，或者有更糟糕的頁面把之前頁面擠下去，繼續關注黑榜前列的頁面（即跳到step1，繼續輪轉）

我們可以發現，測試通過發現、分析、驗證 三板斧，驅動推進頁面性能優化。

.效果明顯

從2024年10月份開始迭代以來，共發現了8類嚴重性能問題。

包括：端外（支付寶）性能問題，外投&跨端性能問題，pha架構性能問題，運營不規范配置導致、其他業務原因導致的性能問題等。

并且快速有效，在業務方或其他同學提過來之前，我們都已經發現并有了分析，在優化節奏上更具有主動性。

前端性能優化方案篇五

1、靜態資源的壓縮合并（js 代碼壓縮合并、css 代碼壓縮合并、雪碧圖）

2、靜態資源緩存（資源名稱加 md5 戳）

? ? ? 可以通過鏈接名稱控制緩存：通過前端構建工具為打包的文件添加md5后綴，這樣當打包上線時請求的鏈接發生改變，這樣可以防止由于緩導致靜態資源更新失效；

3、 使用 cdn 讓資源加載更快

二.優化頁面渲染

1、css 放前面，js 放后面

2、懶加載（圖片懶加載、下拉加載更多）

先將src賦值成一個通用的預覽圖，下拉時候再動態賦值成正式的圖片。如下，是預覽圖片，比較小，加載很快，而且很多圖片都共用這個，加載一次即可。待頁面下拉，圖片顯示出來時，再去替換src為data-src的值。（data-開頭的屬性瀏覽器渲染的時候會忽略掉，提高渲染性能）

3、減少dom 查詢，對 dom 查詢做緩存

4、減少dom 操作，多個操作盡量合并在一起執行（documentfragment）

dom 操作是非常耗費性能的，因此插入多個標簽時，先插入 fragment 然后再統一插入 dom。因為fragment文檔片段存在于內存中，并不在dom樹中，所以將子元素插入到文檔片段時不會引起頁面回流。

5、事件節流

在開發過程中會遇到頁面一些頻繁觸發的事件，比如mouseover、scroll、resize等事件。一秒可以執行很多次，這樣會造成嚴重的頁面性能問題，導致頁面c出現卡頓甚至瀏覽器崩潰。因此我們需要對事件進行節流，簡單的說就是控制其執行的次數。這里就涉及到了常用到的js的節流和防抖功能實現。 ? ? ? ?1.防抖（debounce）：在事件被觸發n秒后再執行回調，如果在這n秒內又被觸發，則重新計時。

? ? ?2、節流（throttle）：規定一個單位時間，在這個單位時間內，只能有一次觸發事件的回調函數執行，如果在同一個單位時間內某事件被觸發多次，只有一次能生效。

6、盡早執行操作（domcontentloaded）?