🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

別再吹性能優化了:你的應用卡頓,純粹是因為產品設計爛🤷‍♂️

image.png

大家好!

最近面試,我發現一個很有意思的事情。幾乎每個高級前端的簡歷上,都專門開辟了一欄,叫性能優化

裡面寫滿了各種高大上的名詞😖:

使用Virtual List(虛擬列表)優化長列表渲染...
使用Web Worker把複雜計算移出主線程...
使用WASM重寫核心算法...

看著這些,我通常會問一個問題:

你為什麼要渲染一個有一萬條數據的列表?用戶真的看得過來嗎?

候選人通常會愣住,然後支支吾吾地說:“呃...這是我們產品經理要求的🤷‍♂️。”

這就是今天我想聊的話題:

在2025年的今天,前端領域90%的所謂性能瓶頸,根本不是技術問題,而是產品問題。

我們這群工程師,拿著最先進的前端技術(Vite, Rust, WASM),卻在日復一日地給一坨屎💩(糟糕的產品設計)雕花。


我們正在解決錯誤的問題

讓我們還原一個經典的性能優化現場吧👇。

場景:一個中後台的超級表格(默認大家應該比較熟悉🤔)。

產品經理說需求:這個表格要展示所有訂單,大概有50列,每頁要展示500條,而且要支持即時搜索,還要支持列拖拽,每個單元格裡可能還有下拉菜單...

image.png

開發者的第一反應(技術視角)

  • 50列 x 500行 = 25000個DOM節點,瀏覽器肯定卡死。
  • 快!上虛擬滾動(Virtual Scroll)!
  • 快!上防抖(Debounce)!
  • 快!上Memoization(緩存)!

我們為了這個需求,引入了複雜的 第三方庫,寫了晦澀難懂的優化代碼,甚至為了解決虛擬滾動帶來的樣式問題(比如高度坍塌、定位異常),又打了一堆補丁。

最後,頁面終於不卡了。我們覺得自己很牛逼,技術很強。

但我們從來沒問過那個最核心的問題:

人類的視網膜和大腦,真的能同時處理50列 x 500行的數據嗎?

答案是:不能。

當螢幕上密密麻麻擠滿了數據時,用戶的認知負荷已經爆表了。他根本找不到他要看的東西。他需要的不是高性能的渲染,他需要的是篩選搜索

我們用頂級的技術,去實現了一個反人類的設計。 這不是優化,這是叫作惡😠。


真正的優化,是從砍需求開始

我曾經接手過一個類似的項目,頁面卡頓到FPS只有10。前任開發留下了幾千行用來優化渲染的複雜代碼,維護起來生不如死。

我接手後,沒有改一行渲染代碼。

我直接去找了產品總監,把那個頁面投在大螢幕上,問了他三個問題:
1.你看這一列 訂單原始JSON日誌,平均長度3000字符,你把它全展示在表格裡,誰會看?
砍掉!改成一個查看詳情的按鈕,點開再加載。DOM節點減少20%。

2.這50列數據,用戶高頻關注的真的有這麼多嗎?
默認只展示核心的8列。剩下的放在自定義列裡,用戶想看自己勾選。DOM節點減少80%。

3.我就不知道為什麼🤷‍♂️ 要一次性加載500條?用戶翻到第400條的時候,他還記得第1條是什麼嗎?
趕緊砍掉!改成標準的分頁,每頁20條。DOM節點減少96%。

做完這三件事,我甚至把之前的虛擬滾動代碼全刪了,回退到了最樸素的<table>標籤。

結果呢?

  • 頁面飛得像樣快(因為DOM只有原來的1%)。
  • 代碼極其簡單(維護就更簡單了🤔)。
  • 用戶反而更開心了(因為界面清爽了,信息層級清晰了)。

這才是最高級的性能優化:不僅優化了機器的性能,更優化了人的體驗。


技術自負的陷阱

為什麼我們總是陷在技術優化的泥潭裡出不來呢?😒

因為我們有技術自負

作為工程師,我們潛意識裡覺得:承認這個需求做不了(或者做不好),是因為我技術不行。

產品經理要五彩斑斕的黑,我就得給他做出來!

產品經理要在這個頁面跑3D地球,我就得去學Three.js!

我們試圖用技術去彌補產品邏輯上的懶惰!(非常有觸感😖)

因為產品經理懶得思考信息的層級,所以他把所有信息一股腦扔給前端,讓你去搞懶加載。

技術不是萬能的。

瀏覽器的渲染能力是有上限的,JS的主線程是單核的,移動端的電量是有限的。更重要的是,用戶的注意力是極其有限的。

當你發現你需要用極其複雜的新技術才能勉強讓一個頁面跑起來的時候

請停下來!

stOpStopstopstOpstOp.gif

這時候,問題的根源通常不在代碼裡,而可能是在 PRD(需求文檔) 裡。


說了那麼多,該怎麼做呢?

下次,當你再面對一個導致卡頓的需求時,別急著打開Profiler分析性能。

請試著做以下幾步:
我們真的需要在前端處理10萬條數據嗎?能不能在後端聚合好,只給我返回結果?

這個圖表真的需要即時刷新嗎?用戶真的能看清1毫秒的變化嗎?改成5秒刷新一次行不行?

在這個彈窗裡塞個完整地圖太卡了。能不能改成:點擊縮略圖,跳轉到專門的地圖頁面?

你要告訴產品經理: 性能本身,也是個產品功能。

如果為了塞下更多的功能,犧牲了流暢度這個最核心的功能,那是丟了西瓜撿芝麻。


最好的代碼,是 沒有代碼(No Code)

同理,最好的性能優化,是沒有需求

作為高級工程師,你的價值不僅僅體現在你會寫Virtual List,更體現在你敢不敢在需求評審會上,拍著桌子說:
這個設計怎麼這麼反人類😠!我們能不能換個更好的方式?🤷‍♂️

別再給屎山💩雕花了。把那座山推了,才是真正的優化。

關於這個觀點你們怎麼看?


原文出處:https://juejin.cn/post/7573950036897038376


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝17   💬10   ❤️5
435
🥈
我愛JS
📝2   💬8   ❤️4
93
🥉
📝2  
21
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付