前言

對于網頁的卡頓性能優化，我們首先想到的肯定是從JavaScript開始。但這個鍋js表示不背😂，但不是js的原因又會是什么原因了？文章內容不多，只要你能仔細看完，相信一定能對你有所幫助。

在實際項目中React、Vue、Angular三大框架都有使用過，其在開發效率上是毋庸置疑的，但在某些場景上其性能確是差強人意的。如果大家有遇到此類場景，歡迎在下方留言討論。

下面我們一起來了解一下實際項目中遇到的此類性能瓶頸是如何處理的!

背景

項目基于VUE，由于業務要求需要長列表渲染(不能做動態加載和虛擬列表)， 列表數據過多時滾動條的scrollTop達到5w+ , 同時頁面中每一列的一些元素通過websocket實時更新。 在首屏加載、頁面滾動、篩選等交互時，頁面發生比較嚴重的卡頓問題

首先還是著手優化js的相關部分

1. 篩選部分使用服務端渲染 2. 低頻使用的隱藏元素全部v-if 3. 列表每列的元素標簽盡可能減少 4. 部分交互方法優化，部分使用了jquery 原生化 5. Vue computed 中高頻觸發的方法寫到vuex中按需觸發(服務端渲染時也需要使用) 6. 每列的懸浮組件前置（提升到列表父級組件） 7. 事件委托（減少每列的事件綁定） ...

優化過后整體性能有所提升，但是當列表數量較多時，滾動列表還是能感受到明顯的卡頓。

---

兩句css 搞定頁面滾動時的卡頓問題

其實頁面卡頓就是一種用戶體驗，怎樣評判這種體驗的好壞了，根據FPS(frame per second)，即一秒之間能夠完成多少次重新渲染，顯示器的刷新頻率一般是60Hz(在
電腦的顯示設置中可查)，瀏覽器會自動按照這個頻率刷新動畫。每幀渲染的時間不能超過16.66ms(1000ms/60), 在實際開發中30fps-60fps 頁面都會比較流暢。

下面通過 chrome devtool 排查卡頓問題，在Performance 面板記錄了操作10s 的耗時：

在瀏覽器中通過 frames可以非常清晰的看到每幀的用時，用時最長的一幀將近1s(遠大于16.67ms)。

如上圖，update layer tree和Paint 占用了71.2%的時間， 這個是啥？為什么會這么耗時了？從字面上看意思是更新層樹和繪制，實際上就是我們前端程序猿耳熟能詳的重排和重繪。

非常需要注意的一點是：一個元素的重排通常會帶來一系列的反應，甚至觸發整個文檔所有元素的重排和重繪，性能代價是非常高昂的。

如何查看元素是否有連鎖的重繪？如何避免了？

我們可以通過如下設置后再操作頁面，重繪的區域在頁面中會有綠色邊框高亮顯示。

經過排查后發現主要有兩種情況會引起頁面的連鎖重繪和重排，導致該頁面滾動時卡頓：

case1: box-shadow的陰影區域和固定定位有交叉關系時。

如左側導航是固定定位，右側是列表部分，列表的外層元素添加了box-shadow，
其陰影區域和固定定位有交叉時。滾動時固定定位會觸發重繪，通過box-shadow，
間接的使右側列表上所有元素都發生了重繪。

修復：去掉該box-shadow屬性后滾動列表非常順暢。

case2: websocket實時更新列表中某行中某個元素的數據時，整個列表發生重繪。

解決這個問題，要先了解web頁面的層次問題。

有兩個因素造成了這個問題，其一是因為數據變化時使用了animation導致了同一層次的元素重繪

修復方案一：刪除該animation屬性（因業務要求不可以取）

修復方案二：在該元素上增加相對定位，設置一個唯一的z-index值。使元素有獨立的層次，在瀏覽器渲染該元素時不會觸發連鎖重繪。

在問題排查中可以通過如下設置降低CPU的速度測試問題：

總結

在性能優化上我們往往忽視了css的重要性，使得在優化的路上越走越遠，最后不了了之。如果你也有這樣的經歷，歡迎留言討論。

總之在開發過程中嚴謹的把控好自己的每一行代碼，在面對復雜的問題時，多分析和查閱資料，當遇到性能瓶頸問題時，可以多用chrome devtool上的相關設置進行快速定位。

如果發現文章中有誤的地方歡迎指出。如果覺得有幫助，不妨點贊、關注支持一下，真心希望能和大家一起成長，一起進步，非常感謝！

作者：tager
鏈接：https://juejin.cn/post/7020416550154797064
說明：稀土掘金同步更新
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

總結

以上是生活随笔為你收集整理的两句css 搞定页面滚动时的卡顿问题？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。