誰沒用過那種優化到“滿身傷痕”的產品？

點開頁面，空空如也。滾一下，還是沒有反應。于是開始像賭氣一樣猛拉頁面——終于，有三張圖片加載出來：一張掛了，兩張糊成一團。頁面卡得像正在短暫休克。這，就是所謂的“懶加載”。

或者說，有人“以為”是懶加載。

懶加載如果用得好，是性能的救星；但用得爛，就是用戶體驗里的“推門卻要拉”的經典反例。

理論很美好，現實很離譜

懶加載的原意其實很樸素：用到再加載，別提前浪費資源。

就像餓了再熱飯一樣，聽起來非常合理。尤其在早期網絡又慢、設備又卡的年代，這種節制式加載確實救過不少頁面。

問題是，這份“節制”后來被誤解了、濫用了、甚至被神化了。

“表面性能主義”的迷思

現在的前端圈，有點“人格分裂”。

一邊拼命追 Lighthouse 分數，仿佛是性能奧運會；一邊又在項目里塞了 12MB 的初始 JS bundle。

就在這種矛盾之中，懶加載成了萬能貼——凡是能滾動的組件，統統貼上 loading="lazy"，只因為它“聽起來”很快。

不管內容是不是用戶一定要看的； 不管資源本身是不是才幾十 KB； 不管實際體驗有沒有因為懶加載變差……

“分數高就行，用戶先忍忍吧。”

當“懶”變成了“懶得思考”

曾經審過一個項目，連頁面首屏內容都被懶加載了。

沒開玩笑，Hero 區（就是用戶進來第一眼看到的地方）：

• 圖片延遲半秒才出現；
• 然后標題渲染出來；
• 接著按鈕加載；
• 最后點擊事件才掛上。

整個頁面像分章節播放，簡直是交互災難。

為什么會這樣？因為某位開發者在 next/image 里打開了懶加載開關，然后就沒再看效果。

Lighthouse 分數確實滿格，但體驗像開著延遲油門的電車。

開發者不是用戶

這個道理講過無數遍，卻還是被忘得干干凈凈。

頁面是為用戶服務的，而不是為調試工具服務的。

用戶想要的，其實很簡單：

• 頁面別抖；
• 點了別卡；
• 滾動就加載，不要空白；
• 別讓圖片“蹦”出來嚇人。

懶加載用得不好，就像是把“內容延遲加載”誤解成了“內容隨機跳出來嚇你一跳”。

懶加載分兩種：聰明的，和懶得優化的

用得聰明的懶加載，確實能提升首屏速度，甚至讓應用“感覺”更快。

這種懶加載：

• 會預加載用戶即將看到的內容；
• 會判斷網絡狀況適時調整策略；
• 不會拿用戶交互來賭性能；
• 不會犧牲體驗去博取指標分數。

而另一種呢？

默認打開開關，啥都懶加載； 組件一層套一層，圖片、按鈕、內容全加懶； 以為這樣叫“極致性能”； 其實只是“懶得優化”。

結語：別折騰了，直接展示吧

有時候，最好的性能優化就是——去掉你以為的優化。

內容是為了展示的，就別藏著掖著； 圖片是為了看的，就別非得等用戶滾動才露頭。

真正優秀的懶加載，用戶甚至察覺不到它的存在。

一旦用戶開始“感受到”懶加載的存在——那它，基本就失敗了。

所以下次寫下 loading="lazy" 之前，先想清楚：

“到底是在提升性能，還是在回避真正的工作？”

因為——沒腦子的懶加載，才是真正的懶。