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

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

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

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

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

懶加載的原意其實(shí)很樸素：用到再加載，別提前浪費(fèi)資源。

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

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

“表面性能主義”的迷思

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

一邊拼命追 Lighthouse 分?jǐn)?shù)，仿佛是性能奧運(yùn)會(huì)；一邊又在項(xiàng)目里塞了 12MB 的初始 JS bundle。

就在這種矛盾之中，懶加載成了萬能貼——凡是能滾動(dòng)的組件，統(tǒng)統(tǒng)貼上 loading="lazy"，只因?yàn)樗奥犉饋怼焙芸臁?/span>

不管內(nèi)容是不是用戶一定要看的； 不管資源本身是不是才幾十 KB； 不管實(shí)際體驗(yàn)有沒有因?yàn)閼屑虞d變差……

“分?jǐn)?shù)高就行，用戶先忍忍吧。”

當(dāng)“懶”變成了“懶得思考”

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

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

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

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

為什么會(huì)這樣？因?yàn)槟澄婚_發(fā)者在 next/image 里打開了懶加載開關(guān)，然后就沒再看效果。

Lighthouse 分?jǐn)?shù)確實(shí)滿格，但體驗(yàn)像開著延遲油門的電車。

開發(fā)者不是用戶

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

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

用戶想要的，其實(shí)很簡(jiǎn)單：

• 頁面別抖；
• 點(diǎn)了別卡；
• 滾動(dòng)就加載，不要空白；
• 別讓圖片“蹦”出來嚇人。

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

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

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

這種懶加載：

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

而另一種呢？

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

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

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

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

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

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

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

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

因?yàn)椤?/span>沒腦子的懶加載，才是真正的懶。