誰沒用過那種優(yōu)化到“滿身傷痕”的產(chǎn)品？

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

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

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

理論很美好，現(xiàn)實很離譜

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

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

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

“表面性能主義”的迷思

現(xiàn)在的前端圈，有點“人格分裂”。

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

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

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

“分數(shù)高就行，用戶先忍忍吧?！?/span>

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

曾經(jīng)審過一個項目，連頁面首屏內(nèi)容都被懶加載了。

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

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

整個頁面像分章節(jié)播放，簡直是交互災(zāi)難。

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

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

開發(fā)者不是用戶

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

頁面是為用戶服務(wù)的，而不是為調(diào)試工具服務(wù)的。

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

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

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

懶加載分兩種：聰明的，和懶得優(yōu)化的

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

這種懶加載：

• 會預(yù)加載用戶即將看到的內(nèi)容；
• 會判斷網(wǎng)絡(luò)狀況適時調(diào)整策略；
• 不會拿用戶交互來賭性能；
• 不會犧牲體驗去博取指標分數(shù)。

而另一種呢？

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

結(jié)語：別折騰了，直接展示吧

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

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

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

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

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

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

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