前端晉升答辯-性能優化篇範式

本文力争為你參加晉升答辯時，提供一個論述性能優化相關工作的範式。簡單點兒來說，就是按照這個範式文來準備、闡述，就可以博得晉升評委的認可與喜愛。

癡迷寫頁面UI的前端千篇一律，懂得量化收益的前端萬裡挑一。

現在已經不是刀耕火種的前端原始時代了，能夠高保真實作頁面UI是每一個前端的基本技能，“沒有功勞還有苦勞”這句話也不再适用于前端晉升了。你辛苦的工作可能會看在直屬leader的眼裡，知道你為了業務天天熬夜加班，會讓你年終績效更好一些，但是在晉升答辯中，尤其是高職級同學的晉升，基本都是跨部門、或通道評委評審的，他們是不會認為這些重複性勞動、像流水線一樣的工作有什麼重要價值。

如何讓他們在短短時間内認識到你的工作價值呢，這是你在晉升之前要思考的問題！

為啥要選性能優化這一點來做範式呢，因為這個聽着高大上，每個前端同學晉升時都想提、都會提，但是經常看到很多同學答辯時因為這個反而被刷了下來。很多同學想不明白的是，明明我這個工作已經做了，頁面效果也很OK，leader和使用者都有正向回報了，但為啥還在這裡栽跟頭呢？

核心點 - 如何量化自己的工作，量化收益，讓工作看得見，看的明白。

以下會以五個方面來完整的描述你在性能優化方面所做的辛苦付出，展現出你的成果價值與思考。

一、需求來源

首先要想明白，有些需求是被安排的，有些需求是需要主動出擊的，這牽扯到一個主觀能動性和個人推動協調能力。

就性能優化而言，可能是使用者回報體驗卡頓，産品或老闆給安排過來。也可以是你細緻觀察監控資料，認識到性能有提升空間，然後将問題和解決方案擺到老闆面前。

在晉升答辯時，一定要把你主動發現問題，提出解決方案，推動PM确定為需求，排期、研發上線這個過程闡述出來。

誰推動，誰就是這個需求的最大受益者。

二、名額資料與标準錨定

if (沒有曆史名額資料) {
  return false;
  // 後面的工作将無任何意義！
}      

如果你在做性能優化之前，沒有曆史名額資料，那麼請你立刻停止性能優化工作。調轉頭來，現将現有相關性能名額資料收集起來。

當一個實驗組沒有對照組，這個實驗也沒有了存在的意義。如果你的性能優化工作沒有明确的可參考資料，可确定的标準，請你不要做！做了也沒有任何收益！因為沒有辦法展現出來！

標明業務場景

在做頁面性能優化時，不要把目光窄窄的聚焦于首頁加載性能優化，更多的可以是根據實際業務場景，選擇一個核心業務頁面，影響使用者的關鍵性節點，比如在可視化系統中看闆頁面（展示各種資料圖表）、電商系統中的商品搜尋、支付環節、資訊推送中的feed流等等。

有業務場景，做優化才有意義。

曆史名額資料收集：

選擇收集曆史名額資料是為了與進行性能優化後的的資料進行對比的，是以我們一定要選擇一種權威性的方式來收集這些資料。

1. 首推公司内部性能監控平台

   公司内部統一的，所有資料名額的定義、收集、口徑都是統一的，當一項資料耗時3s，降低到2s，所有公司内部的人都是必需得承認，這個優化是有效的。

2. 自行從Lighthouse和Performance檢測到的性能資料

   當我們從Lighthouse或者Performance中去收集資料時，可能會因為本身電腦原因，或是樣本資料量比較小，不能形成有效的資料支撐。

3. 第三方性能測試網站如Pingdom、SpeedTracker等。

   因為“牆”的原因，一些國外的網站，我們在進行測試時，資料不準确，而且自行測試時，樣本量資料小。

   某些業務資料因敏感性，不能傳遞到公司外部，這些都是要進行考量的。

是以說，有條件的一定要使用性能監控平台，次之選擇Lighthouse/Performance，再次之選擇一些第三方性能測試網站。

性能優化名額：

性能優化名額分為兩種：一種是前端常見核心性能名額，一種是業務自定義名額

前端常見核心性能名額：

名額名稱	全稱	描述
FP	First Paint	浏覽器第一次繪制時間，第一個像素時間
TTI	Time To Interactive	頁面渲染完畢，可以響應使用者輸入的時間
FID	First Input Delay	使用者與頁面輸入框等控件第一次可互動的時間
LCP	Largest Contentful Paint	最大内容繪制時間
FMP	First Meaningful Paint	首次有意義的繪制，頁面主要内容出現在螢幕的時間
FCP	First Contentful Paint	浏覽器第一次螢幕繪制内容時間
CLS	Cumulative Layout Shift	累計布局版式位移，頁面抖動，屏閃

自定義名額：根據實際業務需要，自定上報統計的關鍵業務節點時間，比如一個圖表從資料請求到繪制繪制完成的時間。

标準錨定：

在現有曆史性能名額資料的基礎上，遵循行業内優秀性能資料表現，或從實際業務出發，确定什麼樣的耗時是符合标準的，什麼是優秀的。

這個标準必需要提前确定下來，達成一緻。這樣在做性能優化時就有了參考點，知道往哪個目标方向走是正确的。

三、收益預期

性能優化是一件非常講究ROI（投資回報率）的事情，在這裡你一定要向你的老闆畫餅，表達出做這樣工作耗時短，收益高，在使用者體驗這塊兒有很大的飛躍。

沒有ROI的，可做可不做的事情，就一定不要做。

你不能說給我2個月的時間，我可以把現在頁面加載耗時10s降低到1s，先不說你1s能不能做到，就單2個月這個時間老闆基本就不會同意了。

在這裡一定要産出一個明确的目标數值，比如我們要把這個名額從10s降到5s，性能提升一倍。這個也是為了将來做收益對比的。

這裡還有一個套路就是，給出一個保守的目标值，然後做成之後會突破這個值，對于老闆來說也是個驚喜。

溫馨提示：吹牛有風險，裝B需謹慎！自己心裡一定要有譜，把性能耗時從2s降低到1s，遠遠要比從10s降低到5s困難的多得多。

四、性能優化政策

性能優化的政策有很多種，要根據自己的實際業務需求對症下藥。正常的一些如懶加載、分包政策、滾動加載、上Http2、Gzip壓縮等等，這裡不是文章的重點，不做過多描述。

在答辯時，這塊兒據實而說即可。

五、量化收益

重點來了！！！在進行性能優化後，一定要再次進行名額資料觀測、統計，做好收尾工作。沒有這一步，前面的工作也是白做了。

辛苦付出，一頓操作，究竟資料是不是達到了預期呢？

如果有性能監控平台，這事兒就特别好辦，檢視下對應的日、周、月次元的資料，觀察相應的耗時曲線是否降低。

在答辯時，一定要提供一些圖表，至少是表格的資料，将前後收集的關鍵性名額資料進行對比，凸顯所做出的的效果，讓評委直覺的看到資料的變化，一眼就感受到你所做的性能優化是非常好的。

如果某個重量級上司也肯定了你的該項成績，記得一定要在答辯時以或直白或委婉的形式想評委們透露出來，哪加分，不要不要的~

綜述

本文的重點在于為你提供一個晉升答辯時，向評委論述性能優化的範式，不是具體的性能優化政策實施。

通過五個環節的梳理，展示，評委會在短時間内非常系統、非常具象的看到你在性能優化方面做出的成果與價值，也會看到你的技術視野與思考。