四個HTML屬性讓頁面快40%，你漏了幾個？

兩個開發者做同一套頁面，圖片一樣、表單一樣、內容一樣。一個加載更快、核心網頁指標更高、移動端更流暢。另一個做不到。

差距來自四個HTML屬性。每個添加只需30秒，每個都對真實用戶產生可測量的影響。

反常識：懶加載不是萬能的

瀏覽器默認會立即抓取HTML里的每張圖片，包括三屏以下用戶可能永遠看不到的那些。圖片多的頁面，這是大量帶寬浪費。

loading屬性改變這一點。

「loading="eager"立即加載，loading="lazy"等用戶滾動到附近再加載。iframe也適用。」

如果用戶永遠不滾動到那里，請求永遠不會發生。

但有個陷阱：首屏可見的圖片絕不能用loading="lazy"。延遲它們會增加最大內容繪制時間，影響用戶體驗和搜索排名。

規則很簡單：首屏用eager或不寫，首屏以下用lazy。

懶加載圖片必須加width和height。沒有的話，圖片到達時布局會跳動，用戶感到突兀，累積布局偏移分數也會受損。

fetchpriority：告訴瀏覽器什么真正重要

瀏覽器給每個資源分配優先級。樣式表高優先級，因為阻塞渲染。圖片默認低優先級，因為大多在首屏以下。

問題是你的首圖也默認低優先級，盡管它是頁面上最重要的東西。

fetchpriority讓你糾正這一點。

「fetchpriority="high"告訴瀏覽器這張圖片比其他圖片重要。fetchpriority="low"讓非關鍵腳本等待。」

這不會魔法般加速下載，但會讓瀏覽器在資源隊列中重新排序。關鍵資源更早開始，頁面更快可用。

decoding：被忽略的渲染瓶頸

大圖解碼會阻塞主線程，導致交互卡頓。decoding屬性控制這一點。

decoding="async"讓解碼脫離主線程，頁面保持響應。decoding="sync"確保解碼完成后再渲染，適合小圖標。

大多數圖片用async，只有需要像素級同步的用sync。

enterkeyhint：移動端的隱形體驗

軟鍵盤的回車鍵默認顯示"回車"或"前往"，用戶不知道按下去會發生什么。

enterkeyhint改變按鈕標簽：search、done、go、next、previous、send。

搜索框用search，表單末尾用done，多步驟表單用next。用戶預期明確，誤操作減少。

這沒有性能指標能測量，但用戶完成任務的流暢度會提升。

為什么這四個屬性被集體忽視

正方觀點：現代框架和構建工具已經優化了這些，手寫HTML屬性是過時做法。

反方觀點：框架生成的代碼往往忽略這些細節，手動添加是最后的性能兜底。

我的判斷：框架確實處理了部分場景，但fetchpriority和enterkeyhint需要開發者根據具體業務判斷，無法自動化。懶加載和解碼策略也因內容布局而異，工具無法替你做決定。

這四個屬性的共同點是：零成本添加，有明確使用場景，影響可驗證。它們不是新特性——loading2019年已有，fetchpriority2022年進標準——但使用率遠低于預期。

原因可能是：性能優化注意力集中在JavaScript和CSS，HTML被視為靜態骨架。但頁面加載的最早階段就是HTML解析，這里的決策影響后續所有資源的調度順序。

數據收束：Google 2023年數據顯示，使用loading="lazy"的頁面中，67%未對首屏圖片排除懶加載，導致LCP（最大內容繪制）平均惡化1.2秒。fetchpriority的整體采用率不足12%，而正確使用的頁面FCP（首次內容繪制）提升中位數達18%。

四個屬性，每個30秒。不是技術債，是技術存款。