
大家好!
最近面試,我發現一個很有意思的事情。幾乎每個高級前端的簡歷上,都專門開辟了一欄,叫性能優化。
裡面寫滿了各種高大上的名詞😖:
使用Virtual List(虛擬列表)優化長列表渲染...
使用Web Worker把複雜計算移出主線程...
使用WASM重寫核心算法...
看著這些,我通常會問一個問題:
你為什麼要渲染一個有一萬條數據的列表?用戶真的看得過來嗎?
候選人通常會愣住,然後支支吾吾地說:“呃...這是我們產品經理要求的🤷♂️。”
這就是今天我想聊的話題:
在2025年的今天,前端領域90%的所謂性能瓶頸,根本不是技術問題,而是產品問題。
我們這群工程師,拿著最先進的前端技術(Vite, Rust, WASM),卻在日復一日地給一坨屎💩(糟糕的產品設計)雕花。
讓我們還原一個經典的性能優化現場吧👇。
場景:一個中後台的超級表格(默認大家應該比較熟悉🤔)。
產品經理說需求:這個表格要展示所有訂單,大概有50列,每頁要展示500條,而且要支持即時搜索,還要支持列拖拽,每個單元格裡可能還有下拉菜單...

開發者的第一反應(技術視角):
我們為了這個需求,引入了複雜的 第三方庫,寫了晦澀難懂的優化代碼,甚至為了解決虛擬滾動帶來的樣式問題(比如高度坍塌、定位異常),又打了一堆補丁。
最後,頁面終於不卡了。我們覺得自己很牛逼,技術很強。
但我們從來沒問過那個最核心的問題:
人類的視網膜和大腦,真的能同時處理50列 x 500行的數據嗎?
答案是:不能。
當螢幕上密密麻麻擠滿了數據時,用戶的認知負荷已經爆表了。他根本找不到他要看的東西。他需要的不是高性能的渲染,他需要的是篩選和搜索。
我們用頂級的技術,去實現了一個反人類的設計。 這不是優化,這是叫作惡😠。
我曾經接手過一個類似的項目,頁面卡頓到FPS只有10。前任開發留下了幾千行用來優化渲染的複雜代碼,維護起來生不如死。
我接手後,沒有改一行渲染代碼。
我直接去找了產品總監,把那個頁面投在大螢幕上,問了他三個問題:
1.你看這一列 訂單原始JSON日誌,平均長度3000字符,你把它全展示在表格裡,誰會看?
砍掉!改成一個查看詳情的按鈕,點開再加載。DOM節點減少20%。
2.這50列數據,用戶高頻關注的真的有這麼多嗎?
默認只展示核心的8列。剩下的放在自定義列裡,用戶想看自己勾選。DOM節點減少80%。
3.我就不知道為什麼🤷♂️ 要一次性加載500條?用戶翻到第400條的時候,他還記得第1條是什麼嗎?
趕緊砍掉!改成標準的分頁,每頁20條。DOM節點減少96%。
做完這三件事,我甚至把之前的虛擬滾動代碼全刪了,回退到了最樸素的<table>標籤。
結果呢?
這才是最高級的性能優化:不僅優化了機器的性能,更優化了人的體驗。
為什麼我們總是陷在技術優化的泥潭裡出不來呢?😒
因為我們有技術自負。
作為工程師,我們潛意識裡覺得:承認這個需求做不了(或者做不好),是因為我技術不行。
產品經理要五彩斑斕的黑,我就得給他做出來!
產品經理要在這個頁面跑3D地球,我就得去學Three.js!
我們試圖用技術去彌補產品邏輯上的懶惰!(非常有觸感😖)
因為產品經理懶得思考信息的層級,所以他把所有信息一股腦扔給前端,讓你去搞懶加載。
技術不是萬能的。
瀏覽器的渲染能力是有上限的,JS的主線程是單核的,移動端的電量是有限的。更重要的是,用戶的注意力是極其有限的。
當你發現你需要用極其複雜的新技術才能勉強讓一個頁面跑起來的時候
請停下來!
這時候,問題的根源通常不在代碼裡,而可能是在 PRD(需求文檔) 裡。
下次,當你再面對一個導致卡頓的需求時,別急著打開Profiler分析性能。
請試著做以下幾步:
我們真的需要在前端處理10萬條數據嗎?能不能在後端聚合好,只給我返回結果?
這個圖表真的需要即時刷新嗎?用戶真的能看清1毫秒的變化嗎?改成5秒刷新一次行不行?
在這個彈窗裡塞個完整地圖太卡了。能不能改成:點擊縮略圖,跳轉到專門的地圖頁面?
你要告訴產品經理: 性能本身,也是個產品功能。
如果為了塞下更多的功能,犧牲了流暢度這個最核心的功能,那是丟了西瓜撿芝麻。
最好的代碼,是 沒有代碼(No Code)。
同理,最好的性能優化,是沒有需求。
作為高級工程師,你的價值不僅僅體現在你會寫Virtual List,更體現在你敢不敢在需求評審會上,拍著桌子說:
這個設計怎麼這麼反人類😠!我們能不能換個更好的方式?🤷♂️
別再給屎山💩雕花了。把那座山推了,才是真正的優化。
關於這個觀點你們怎麼看?