四個HTML屬性，為什么老手能快30%

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

差距只是四個HTML屬性。每個添加時間不到30秒，每個都對真實用戶產生可測量的影響。

這聽起來反常識——性能優化不是應該很復雜嗎？不是需要構建工具、代碼分割、服務端渲染嗎？但瀏覽器已經內置了這些開關，只是大多數人沒打開。

懶加載：別讓用戶為看不到的內容買單

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

loading屬性改變這一點。

loading="eager"讓圖片立即加載。loading="lazy"則推遲請求，直到用戶滾動到該元素附近。如果用戶永遠不滾動到那里，請求永遠不會發生。iframe也支持這個屬性。

但有個陷阱：絕不要在首屏可見的圖片上用loading="lazy"。這些圖片應該立即加載，推遲它們會增加最大內容繪制時間，影響用戶體驗和搜索排名。

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

懶加載的圖片必須始終包含width和height。沒有它們，圖片到達時布局會偏移，對用戶造成干擾，并損害累積布局偏移分數。

優先級：告訴瀏覽器什么真正重要

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

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

fetchpriority讓你糾正這一點。

給首屏圖片加fetchpriority="high"，告訴瀏覽器這張圖片比其他圖片更重要。反過來，給非關鍵腳本加fetchpriority="low"，讓它等待。

這不是魔法。瀏覽器仍然在優化約束內運作，但你在給它更好的信號來做決策。

預連接：提前建立握手

瀏覽器連接第三方域名時，需要DNS查找、TCP握手、TLS協商。這些步驟在請求發出前就會發生，用戶等待時它們正在發生。

rel="preconnect"提前完成這些步驟。

把它放在文檔頭部，指向你即將請求的域名。當實際請求發生時，連接已經就緒。對字體CDN、分析服務、支付網關尤其有效。

但要注意：不要濫用。每個預連接都會占用資源并保持連接打開，用在你確定會請求的域名上。

預加載：關鍵資源的搶先加載

有些資源瀏覽器無法提前發現。CSS中引用的字體、由JavaScript注入的樣式、條件加載的模塊——這些在HTML解析時不可見，直到需要時才請求，造成延遲。

rel="preload"讓你顯式聲明這些資源。

關鍵字體是最常見的用例。沒有預加載，瀏覽器先解析CSS，發現字體聲明，然后請求字體，期間文本可能以備用字體顯示或不可見。預加載讓字體請求與CSS解析并行發生。

必須指定as屬性——font、style、script、image等。這告訴瀏覽器正確的優先級和請求頭。crossorigin對字體必需，即使同源。

只預加載當前頁面確定需要的資源。預加載不用的東西只是浪費帶寬。

為什么老手更快

這四個屬性沒有一個是新功能。loading="lazy"2019年已支持，fetchpriority2022年，preconnect和preload更早。但它們的組合使用仍然不普遍。

原因可能是認知成本。構建工具自動處理很多優化，開發者不再直接面對瀏覽器行為。當問題出現時，第一反應是加更多工具，而不是檢查HTML本身。

另一個原因是測量困難。這些屬性的影響在真實網絡條件下才明顯，開發環境的本地服務器或快速寬帶會掩蓋差異。需要刻意在慢速3G、低功耗設備上測試才能感知。

但數據是清晰的。Google的測試顯示，懶加載首屏以下圖片可減少10-40%的數據使用。預連接第三方域名可將首次請求時間減少100-500毫秒。預加載關鍵字體可消除字體加載期間的布局偏移。

這些數字不是理論值，是真實頁面在真實用戶設備上的表現。

判斷：性能優化的回歸

這件事的重要性在于它代表了一種回歸——從工具鏈的復雜性回到對基礎機制的精確控制。

過去五年，前端性能優化越來越依賴構建時處理。代碼分割、樹搖、壓縮、內聯關鍵CSS——這些都在構建階段完成，運行時是一個黑盒。開發者優化的是生成的產物，而不是直接指導瀏覽器行為。

這四個屬性重新打開了運行時優化的窗口。它們不需要構建工具支持，不需要改變開發流程，只需要在正確的元素上加正確的屬性。

這不是說構建工具不重要。復雜應用仍然需要它們。但存在一個優化層級，工具無法自動做好：只有開發者知道哪張圖片是首屏核心，哪個第三方服務必須立即響應，哪個字體對品牌識別至關重要。

瀏覽器提供了表達這些知識的機制，但知識本身仍在開發者手中。

更深層的改變是性能責任的重新分配。當優化完全依賴構建工具時，性能是"構建階段的問題"，由配置和插件解決。當優化通過HTML屬性實現時，性能是"標記階段的問題"，由編寫模板的人直接決定。

這縮短了決策鏈條。寫img標簽的開發者可以立即做出加載策略判斷，而不需要等待構建配置的修改。在大型團隊中，這意味著性能優化可以從專門的性能工程師擴散到所有前端開發者。

最終，這四個屬性之所以有效，是因為它們利用了瀏覽器已經具備的能力，而不是增加新的復雜性。懶加載、優先級提示、預連接、預加載——這些都是瀏覽器引擎的原生行為，屬性只是暴露控制接口。

在框架和工具層出不窮的今天，這種"原生優先"的優化策略反而更可持續。它不依賴特定工具鏈，不會隨版本升級失效，學習成本一次性投入，收益長期持續。

數據收束：根據HTTP Archive的監測，2024年仍有67%的頁面未對任何圖片使用loading="lazy"，81%的頁面未使用fetchpriority，92%的頁面未預加載關鍵字體。與此同時，核心指標不達標的頁面中，68%存在圖片加載策略問題。四個屬性的普及率與性能問題的相關性，比大多數構建工具配置更直接。