使用Performance對頁面進行分析優化(實戰篇)
這篇文章將介紹下實際使用performance對頁面進行優化的過程。總的來說，chrome performance工具讓我們更方便的發現在程式碼執行過程中的問題在哪裡，便於對一些可能注意不到的問題進行定位、分析和優化。
渲染優化
首先，我們對進入整個詳情頁進行分析，整個頁面的結構大致如下，主要包含三個部分：基本資訊，視覺化圖和時間軸。時間軸內部包含時間軸的詳情資訊，包括表格和幾種型別的視覺化圖等，內部比較重。如圖所示：
我們點選錄製，檢視進入頁面的效能圖：
優化點1
可以看到，渲染當前頁面的耗時將近1.5s，我們看看到底是哪裡出現了問題。對渲染部分進行放大，我們發現在渲染時間軸的過程中，大部分時間耗費在了每個時間節點詳情內容的展示上面，但是預設狀態下，他們是進行隱藏的。也就是說，我們進行了N個節點的不必要的渲染，只需把他們幹掉就好了。
檢視程式碼，發現是以下位置導致的，我們進行了一個展開盒子的封裝，類似這樣:
<Box data={data} border collapse loading={loading}>
<AlertDetail/>
</Box>
在非展開狀態下，我們依然對內容進行了渲染，只是使用樣式進行了隱藏，但是這樣React仍然會進行虛擬dom的渲染和計算，在這裡我們對其進行改造，讓其只在展開時進行渲染，並儘量快取渲染的結果。修改完成後，我們會發現，Scripting由之前的880+ms變成了670ms減少了200ms左右：
優化點2
我們繼續看，會發現頁面初始化時，詳情部分會有大量的Evaluate Script耗時，主要是耗費在告警詳情右側的分類及各分類下的可檢視及詳情引起的。
我們可能會想，這裡在初始化時並沒有進行渲染，為什麼仍然會耗費時長進行計算呢？繼續追查我發現原因在這裡：
在整個詳情元件中，我們對包括http,tcp等所有型別的元件進行了引用，然後根據其型別進行元件的匹配，在各個元件中可能包含了每個型別對應的定義、分類和計算等等等等，不僅增加了載入時間，更延長了初始化時間，顯然我們這麼做是不對的。
在此，我們可以使用 懶載入 方式對其進行優化，僅展示其對應型別的圖，避免了不必要的資源浪費和計算時間。
修改之後，我們再次進行效能測試，發現在進入頁面時，詳情元件的耗費時長由260ms變為不到2ms：
而Scripting由之前的670+ms變成了415ms減少了250ms左右：
