性能優化例子：使用Performance工具分析性能瓶頸，解決頁面卡頓！
對于前端的性能優化，優化手段其實是非常多的，但是不能盲目的進行優化，一定要先分析出項目的性能瓶頸，否則只會做無用功。那么如何才能更好的分析出項目的瓶頸呢？其實最關鍵的就是要分析頁面的整個加載過程，找出有問題的地方再進行優化。使用谷歌瀏覽器自帶的 Performance 工具可以幫我們解決這個問題，下面通過一個例子來進行分析優化！
在優化之前，我們先要了解一些知識，比如瀏覽器的渲染幀、Performance 工具的使用，這樣才有助于更好地理解優化的過程！
瀏覽器的渲染幀
對于渲染，我們首先需要了解一個概念：設備刷新率。設備刷新率是設備屏幕渲染的頻率，通俗一點就是，把屏幕當作墻，設備刷新率就是多久重新粉刷一次墻面?；疚覀兤匠＝佑|的設備，如手機、電腦，它們的默認刷新頻率都是 60FPS，也就是屏幕在 1s 內渲染 60次，約 16.7ms 渲染一次屏幕。這就意味著，我們的瀏覽器最佳的渲染性能就是所有的操作在一幀 16.7ms 內完成，能否做到一幀內完成直接決定著渲染性，影響用戶交互。
瀏覽器的 fps 指瀏覽器每一秒的幀數，fps 越大，每秒的畫面就越多，瀏覽器的顯示就越流暢。
圖片
標準渲染幀：在一個標準幀渲染時間 16.7ms之內，瀏覽器需要完成 Main 線程的操作，并 commit 給 Compositor 進程
圖片
丟幀：主線程里操作太多，耗時長，commit 的時間被推遲，瀏覽器來不及將頁面 draw 到屏幕，這就丟失了一幀
圖片
在瀏覽器的一個渲染幀（16.7ms）里，會存在一段時間，叫做空閑時間（idle period），如果完成各種任務的執行以及頁面渲染的工作等的時間少于 16.7 ms，那么這一幀就會存在空閑時間，可以把一些耗時操作拆分開來，然后在每一幀的空閑時間中去執行。
圖片
所謂的頁面卡頓、首屏加載慢，根本原因都是執行長任務，使得頁面的渲染時機推后，在每一幀里得不到渲染，從而造成用戶的不好體驗。要想解決用戶體驗差的問題，那么就需要知道瀏覽器渲染過程中的每一幀都干了些啥任務，是啥原因導致渲染時機推后，這個時候我們就需要借助瀏覽器性能檢測工具 Performance 來進行分析，然后再做針對性的優化，下面我們來了解下該工具的具體使用。
Performance工具的使用
圖片
簡單的使用教程：
在 Chrome 瀏覽器中，按下 F12 鍵或右鍵點擊頁面并選擇 "檢查"，打開開發者工具面板。
在開發者工具中，切換到 "Performance"（性能）選項卡，你會看到一個記錄性能數據的界面。
圖片
點擊頁面頂部的 "Record"（錄制）按鈕，開始記錄性能數據，刷新頁面或執行你想要分析的操作。
圖片
在你完成操作后，點擊 "Stop"（停止）按鈕，停止記錄性能數據。此時，會看到一個包含了各種性能數據的時間軸圖表。
圖片
時間軸圖表將顯示頁面加載期間的各種事件，如 JavaScript 執行、網絡請求、繪制等?？梢钥s放和選擇特定時間段來深入分析。
圖片
性能優化分析的例子
谷歌官方提供的一個 Demo：googlechrome.github.io/devtools-sa…[2]
左側有一些按鈕，點擊 Stop 小球停止運動，點擊 Add、Subtract 可以控制小球數量的增減，比較有意思的一個點是，當小球的數量越來越多，頁面會越來越卡頓，如果點擊 Optimize（優化），那么頁面就會恢復正常。
優化前的效果展示
當小球數量很多時，頁面會非?？D：
圖片
使用工具分析性能
接下來借助 Performance 來分析頁面卡頓的原因：
圖片
錄制大概 4 秒鐘，可以看到該頁面的性能確實存在很大的問題，我們首先分析這張圖里面的一些內容：
總覽區： 可以看到每個階段的具體耗時，這里很明顯是渲染占據了 90% 的時間，而 JS 腳本的執行、頁面繪制并不耗時，現在已經可以定位到是渲染存在問題。
圖片
幀： 綠色代表該幀正常，黃色表示丟幀
圖片
主線程：
圖片
以其中的一個 Task 為例：標紅代表該任務是長任務（一般認為超過 50ms 的任務是長任務），往下是該任務具體的細節，比如這個 Task 里主要執行了 Animation Frame Fired 方法，它里面調用了 Function Call，Function Call 里面調用了 app.update 的方法，一層一層往下調用執行，然后在 app.update 下面我們可以看到很多紫色的線條，紫色代表回流重繪。
圖片
現在可以初步下結論：頻繁的回流重繪導致頁面卡頓，后面還要再進行分析才能確定。
接下來點擊其中的一個任務，觀察 Call Tree，每個方法的執行時間都能看到，以及時間的占比
圖片
我們的分析目標主要是尋找花費時間長的任務，依次點開，可以發現 90% 的時間是花費在 Layout，點擊右側進入源碼：
圖片
圖片
分析這段代碼我們已經可以知道問題出在哪里了，讀取offsetTop會觸發回流重繪，這里用了個 for 循環，所以當小球的數量越來越多的時候，不斷的讀取 offsetTop 屬性，導致頻繁的觸發回流重繪，最終頁面卡頓。
頻繁的回流重繪導致卡頓
我們需要解答兩個問題：
- 為什么頻繁的回流重繪會導致卡頓？
計算復雜度： 回流涉及到重新計算元素的位置和幾何屬性，這可能需要遍歷整個DOM樹，并重新計算樣式。這個計算過程比較復雜，尤其是在大型、復雜的頁面上。
渲染的停頓： 當發生回流時，瀏覽器可能需要停止渲染，重新計算布局，然后再重新繪制，這可能導致頁面的停頓或閃爍。
頻繁觸發： 如果在用戶與頁面交互的過程中頻繁地觸發回流和重繪，可能會導致性能問題。比如，在滾動頁面時，如果頻繁改變元素的樣式，可能會引起多次回流和重繪，從而影響流暢度。
也就是說，頻繁的回流重繪可以看做是耗時嚴重的任務，阻礙了頁面的渲染，從而導致卡頓！
- 為什么讀取 offsetTop 屬性會觸發回流重繪？
這與瀏覽器的優化機制有關：由于每次回流與重繪都會帶來額外的計算消耗，為了優化這個過程，大多數瀏覽器采用了隊列化修改并批量執行的策略。瀏覽器會將修改操作添加到隊列中，直至一定時間段過去或操作達到閾值時，才會清空隊列。
然而，當需要獲取布局信息時，瀏覽器會強制刷新隊列。這意味著，當你讀取元素的布局信息如 offsetTop、offsetLeft 等時，需要返回最新的布局信息，因此瀏覽器不得不清空隊列，觸發回流和重繪操作以返回正確的值。
如何進行優化
那么如何進行優化呢？知道是 offsetTop 的問題后，不用這個屬性就行了，我們看下這個例子的處理方式：
圖片
使用 style.top 屬性取代 offsetTop 即可，當然這兩個屬性也有一定的區別，這里不再展開，這樣就能完美的解決頁面卡頓的問題！
總的來說，其實優化方法很簡單，最關鍵的是要找出頁面的性能瓶頸，到底是哪里影響了性能。因此，前端開發者想要提升自己的能力、提升自己對性能優化的理解，就必須具備熟悉瀏覽器的渲染原理、使用 Performance 工具、分析項目的性能瓶頸等方面的能力！
