性能優化面試官想聽的是什麼？別再說那些老掉牙的性能優化了

這是我參與8月更文挑戰的第11天，活動詳情查看：8月更文挑戰html

網上性能優化的文章太多了，都說如何如何請求優化代碼優化之類的，全部人都知道的事，並且實際工做中根本不可能每一個項目都用到那些所有，而是應該對咱們的項目有針對性的優化，你說是嗎？前端

好比程序員

說一下前端性能優化？web

你平時是怎麼作性能優化的？面試

等等相似這樣的問題，不過就是換湯不換藥罷了npm

好吧，先上藥canvas

這性能優化呢，它是一個特別大的方向，由於每一個項目可能優化的點都不同，每一種框架或者每一種客戶端能夠優化的點也都不同小程序

總的來講，如今B/S架構下都是前端向後端請求，後端整理好數據給客戶端返回，而後客戶端再進行數據處理、到渲染將界面展現出來，這麼一個大體流程後端

那咱們優化就是要基於這一過程，說白了咱們可以優化的點，就只有兩個大的方向瀏覽器

一是更快的網絡通訊，就是客戶端和服務端之間，請求或響應時數據在路上的時間讓它更快

二是更快的數據處理，指的是

服務器接到請求以後，更快的整理出客戶端須要的數據
客戶端收到響應的數據後，更快的給用戶展現 以及 交互時更快的處理

而後！開始blablabla.....

更快網絡通訊方面好比：CDN作全局負載均衡、CDN緩存、域名分片、資源合併、雪碧圖、字體圖標、http緩存，以減小請求；還有gzip/br壓縮、代碼壓縮、減小頭信息、減小Cookie、使用http二、用jpg/webp、去除元數據等等，blablabla.....

更快數據處理方面好比：SSR、SSG、預解析、懶加載、按需引入、按需加載、CSS放上面、JS放下面、語義化標籤、動畫能用CSS就不用JS、事件委託、減小重排、等等代碼優化，blablabla.....

.....

請直接把上面的總結成一句話給面試官

請求優化、代碼優化、打包優化都是常規操做，像雅虎34條軍規，都知道的事就不用說了

由於每一個項目優化的點可能都不同，因此優化主要仍是根據本身的項目來

要麼跟人家聊一下框架優化，深刻原理也很不錯

具體要優化什麼主要仍是看瀏覽器(Chrome爲例)開發者工具裏的 Lighthouse 和 Performance

Lighthouse 是生成性能分析報告。能夠看到每一項的數據和評分和建議優化的點，好比哪裏圖片過大

Performance 是運行時數據，能夠看到更多細節數據。好比阻塞啊，重排重繪啊，都會體現出來，夠不夠細節

而後再去根據這些報告和性能指標體現出來的狀況，有針對性的去不斷優化咱們的項目

Lighthouse

直接在Chrome開發者工具中打開

或者 Node 12.x或以上的版本能夠直接安裝在本地

npm install -g lighthouse
複製代碼

安裝好後，好比生成掘金的性能分析報告，一句代碼就夠了，而後就會生成一個html文件

lighthouse https://juejin.cn/
複製代碼

不論是瀏覽器仍是安裝本地的，生成好的報告都是長的如出一轍的，一個英文的html文件，翻譯了一張給你們看看，如圖

如圖，分析報告內容一共五個大項，每一項滿分100分，而後下面是再把每項分別展開說明

仍是看一下英文版吧，一個程序員必需要養成這個習慣

如圖，五項分別是：

Performance：這個又分爲三塊性能指標、可優化的項、和手動診斷，看這一塊就能夠咱們就能夠優化不少東西了
Accessibility：無障礙功能分析。好比前景色和背景色沒有足夠對比度、圖片有沒有alt屬性、a連接有沒有可識別名稱等等
Best Practices：最佳實踐策略。好比圖片縱橫比不正確，控制檯有沒有報錯信息等
SEO：有沒有SEO搜索引擎優化的一些東西
PWA：官方說法是衡量站點是否快速、可靠和可安裝。在國內瀏覽器內核不統一，小程序又這麼火，因此好像沒什麼落地的場景

而後咱們知道了這麼多信息，是否是就能夠對咱們的項目診斷和針對性的優化了呢

是否是很棒

Performance

若是說 Lighthouse 是開胃菜，那 Performance 就是正餐了

它記錄了網站運行過程當中性能數據。咱們回放整個頁面執行過程的話，就能夠定位和診斷每一個時間段內頁面運行狀況，不過它沒有性能評分，也沒有優化建議，只是將採集到的數據按時間線的方式展示

打開 Performance，勾選 Memory，點擊左邊的 Record 開始錄製，而後執行操做或者刷新頁面，而後再點一下(Stop)就結束錄製，生成數據

如圖

概況面板

裏面有頁面幀速(FPS)、白屏時間、CPU資源消耗、網絡加載狀況、V8內存使用量(堆)等等，按時間順序展現。

那麼怎麼看這個圖表找到可能存在問題的地方呢

若是FPS(看圖右上角)圖表上出現紅色塊，就表示紅色塊附近渲染出一幀的時間太長了，就有可能致使卡頓
若是CPU圖形佔用面積太大，表示CPU使用率高，就多是由於某個JS佔用太多主線程時間，阻塞其餘任務執行
若是V8的內存使用量一直在增長，就可能由於某種緣由致使內存泄露
- 一次查看內存佔用狀況後，看當前內存佔用趨勢圖，走勢呈上升趨勢，能夠認爲存在內存泄露
- 屢次查看內存佔用狀況後截圖對比，比較每次內存佔用狀況，若是呈上升趨勢，也能夠認爲存在內存泄露

經過概覽面板定位到可能存在問題的時間節點後，怎麼拿到更進一步的數據來分析致使該問題的直接緣由呢

就是點擊時間線上有問題的地方，而後這一塊詳細內容就會顯示在性能面板中

性能面板

好比咱們點擊時間線上的某個位置(如紅色塊)，性能面板就會顯示該時間節點內的性能數據，如圖

性能面板上會列出不少性能指標的項，圖中左邊，好比

Main 指標：是渲染主線程的任務執行記錄
Timings 指標：記錄如FP、FCP、LCP等產生一些關鍵時間點的數據信息(下面有介紹)
Interactions 指標：記錄用戶交互操做
Network 指標：是頁面每一個請求所耗時間
Compositor 指標：是合成線程的任務執行記錄
GPU 指標：是GPU進程的主線程的任務執行記錄
Chrome_ChildIOThread 指標：是IO線程的任務執行記錄，裏面有用戶輸入事件，網絡事件，設備相關等事件
Frames 指標：記錄每一幀的時間、圖層構造等信息
.......

Main 指標

性能指標項有不少，而我使用的時候多數時間都是分析Main指標，如圖

上面第一行灰色的，寫着 Task 的，一個 Task 就是一個任務

下面黃色紫色的都是啥呢，那是一個任務裏面的子任務

咱們放大，舉個例子

Task 是一個任務，下面的就是 Task 裏面的子任務，這個圖用代碼表示就是

function A(){
    A1()
    A2()
}
function Task(){
    A()
    B()
}
Task()
複製代碼

是否是就好理解得多了

因此咱們就能夠選中有問題的，好比標紅的 Task ，而後放大(滑動鼠標就可放大)，看裏面具體的耗時點

好比都作了哪些操做，哪些函數耗時了多少，代碼有壓縮的話看到的就是壓縮後的函數名。而後咱們點擊一下某個函數，在面板最下面，就會出現代碼的信息，是哪一個函數，耗時多少，在哪一個文件上的第幾行等。這樣咱們就很方便地定位到耗時函數了

還能夠橫向切換 tab ，看它的調用棧等狀況，更方便地找到對應代碼

具體你們能夠試試～

Timings 指標

Timings 指標也須要注意，如圖

它上面的FP、FCP、DCL、L、LCP這些都是個啥呢

彆着急

上面說了 Timings 表示一些關鍵時間點的數據信息，那麼表示哪些時間呢，怎麼表示的呢？

FP： 表示首次繪製。記錄頁面第一次繪製像素的時間
FCP：表示首次內容繪製（只有文本、圖片(包括背景圖)、非白色的canvas或SVG時才被算做FCP）
LCP：最大內容繪製，是表明頁面的速度指標。記錄視口內最大元素繪製時間，這個會隨着頁面渲染變化而變化
FID：首次輸入延遲，表明頁面交互體驗的指標。記錄FCP和TTI之間用戶首次交互的時間到瀏覽器實際可以迴應這種互動的時間
CLS：累計位移偏移，表明頁面穩定的指標。記錄頁面非預期的位移，好比渲染過程當中插入一張圖片或者點擊按鈕動態插入一段內容等，這時候就會觸發位移
TTI：首次可交互時間。指在視覺上已經渲染了，徹底能夠響應用戶的輸入了。是衡量應用加載所需時間並可以快速響應用戶交互的指標。與FMP同樣，很難規範化適用於全部網頁的TTI指標定義
DCL: 表示HTML加載完成時間

注意：DCL和L表示的時間在 Performance 和 NetWork 中是不一樣的，由於 Performance 的起點是點擊錄製的時間，Network中起點時間是 fetchStart 時間(檢查緩存以前，瀏覽器準備好使用http請求頁面文檔的時間)
L：表示頁面全部資源加載完成時間
TBT：阻塞總時間。記錄FCP到TTI之間全部長任務的阻塞時間總和
FPS：每秒幀率。表示每秒鐘畫面更新次數，如今大多數設備是60幀/秒
FMP：首次有意義的繪製。是頁面主要內容出如今屏幕上的時間，這是用戶感知加載體驗的主要指標。有點抽象，由於目前沒有標準化的定義。由於很難用通用的方式來肯定各類類型的頁面的關鍵內容
FCI：首次CPU空閒時間。表示網頁已經知足了最小程度的與用戶發生交互行爲的時間

好了，而後根據指標體現出來的問題，有針對性的優化就好

結語

點贊支持、手留餘香、與有榮焉

感謝你能看到這裏，加油哦！