採用標準化 loading 屬性的學習心得
這篇文章的目標是說服 CMS 平台開發人員和貢獻者 (也就是開發 CMS 核心的人員)，現在是時候導入瀏覽器層級圖片延後載入功能的支援。我也會分享如何確保高品質使用者體驗，以及在實作延遲載入時讓其他開發人員自訂的建議。這些規範是根據我們為 WordPress 新增支援功能，以及協助 Joomla、Drupal 和 TYPO3 實作這項功能的經驗所制定。
無論您是 CMS 平台開發人員，還是 CMS 使用者 (也就是使用 CMS 建構網站的使用者)，都可以透過這篇文章進一步瞭解 CMS 中瀏覽器層級延後載入的優點。請參閱「後續步驟」一節，瞭解如何鼓勵 CMS 平台實作延後載入功能。
背景
過去一年，使用 loading 屬性延後載入圖片和 iframe 已成為 WHATWG HTML 標準的一部分，且各瀏覽器的採用率也持續上升。不過，這些里程碑只是更快、更省資源的網路基礎。目前分散式網際網路生態系統可使用 loading 屬性。
內容管理系統可為約 60% 的網站提供動力，因此在網路採用新式瀏覽器功能時，這些平台扮演著重要角色。WordPress、Joomla 和 TYPO3 等熱門開源 CMS 已實作圖片的 loading 屬性支援功能，讓我們一起來看看這些方法，以及在其他 CMS 平台中採用這項功能的相關心得。延遲載入媒體是網站應大規模採用的關鍵網頁效能功能，因此建議在 CMS 核心層級採用這項功能。
立即實作延遲載入的理由
標準化
在 CMS 中採用非標準化瀏覽器功能，有助於進行廣泛測試，並找出潛在的改善空間。不過，CMS 普遍認為，只要瀏覽器功能未標準化，就應以擴充功能或外掛程式的形式實作，以便在各個平台上使用。只有經過標準化後，才能考慮在平台核心中採用該功能。
瀏覽器支援
瀏覽器支援這項功能也是類似的疑慮：大多數 CMS 使用者應該都能從這項功能中受益。如果有相當比例的瀏覽器尚未支援這項功能，則該功能必須確保至少不會對這些瀏覽器造成不良影響。
可視區域距離門檻
延遲載入實作方式的常見疑慮是，由於載入週期會在較晚的階段開始，因此在使用者的可視區域中顯示圖片時，圖片不載入的可能性會增加。與先前的 JavaScript 解決方案不同，瀏覽器會以保守的方式處理此問題，並且可以根據實際使用者體驗資料微調處理方式，盡量減少影響，因此 CMS 平台應可安全採用瀏覽器層級的延後載入功能。
使用者體驗建議
要求元素具有維度屬性
為避免版面配置移位，我們一直建議嵌入的內容 (例如圖片或 iframe) 應一律包含尺寸屬性 width 和 height，這樣瀏覽器就能在實際載入這些元素前推斷其顯示比例。無論元素是否為延遲載入，這項建議都適用。不過，由於圖片在檢視區中未完全載入的可能性增加了 0.1%，因此在採用延遲載入功能後，適用性會稍微提高。
CMS 應盡量為所有圖片和 iframe 提供尺寸屬性。如果無法為每個元素執行這項操作，建議略過未提供這兩種屬性的圖片。
避免延後載入頂層元素
目前建議 CMS 只在位於下方圖片和 iframe 中加入 loading="lazy" 屬性，以免 Largest Contentful Paint 指標延遲，因為在某些情況下，這項指標在 2021 年 7 月的表現相當出色。不過，請注意，在轉譯程序前，要評估元素相對於檢視區的位置相當複雜。這項建議特別適用於以下情況：CMS 使用自動化方式新增 loading 屬性，但即使是手動介入，也必須考量多個因素，例如不同的檢視區大小和顯示比例。不過，我們仍強烈建議您不要為可能出現在可視區域頂端的首要圖片和其他圖片或 iframe 使用延遲載入功能。
避免使用 JavaScript 備用方案
雖然 JavaScript 可用於為尚未 (或不) 支援 loading 屬性的瀏覽器提供延遲載入功能，但這類機制一開始都會移除圖片或 iframe 的 src 屬性，這會導致支援該屬性的瀏覽器出現延遲。此外，在大型 CMS 的前端推出這類以 JavaScript 為基礎的解決方案，會增加潛在問題的表面積，這也是為何在瀏覽器功能標準化之前，沒有任何主要 CMS 在核心採用延遲載入的原因之一。
技術建議
預設啟用延遲載入功能
對於實作瀏覽器層級延後載入的 CMS，整體建議是預設啟用這項功能，也就是說，loading="lazy" 應加入圖片和 iframe，最好只針對包含維度屬性的元素。預設啟用這項功能，可節省更多網路資源，比起必須手動啟用 (例如針對個別圖片) 更為省力。
loading="lazy" 應盡可能只新增至可能出現在折疊下方的元素。由於缺乏用戶端感知和各種檢視區大小，因此在 CMS 中實作這項規定可能會很複雜，建議您至少使用近似的推論法，略過可能會顯示在折疊區的元素，例如主圖片，以免延遲載入。
允許個別元素修改
雖然 loading="lazy" 應預設加入圖片和 iframe，但在某些圖片上省略屬性十分重要，例如為了針對 LCP 進行最佳化。如果 CMS 的目標對象平均來說都算是科技達人，那麼這項功能可以是針對每張圖片和 iframe 公開的 UI 控制項，讓使用者選擇不使用該元素的延後載入功能。或者，您也可以將 API 公開給第三方開發人員，讓他們透過程式碼進行類似變更。
舉例來說，WordPress 允許略過 loading 屬性，無論是針對整個 HTML 標記或內容，或是針對內容中的特定 HTML 元素。
改裝現有內容
大致來說，有兩種方法可在 CMS 中的 HTML 元素中新增 loading 屬性：
- 從後端內容編輯器中新增屬性，並將其持續儲存在資料庫中。
- 在前端算繪資料庫中的內容時，即時新增屬性。
建議 CMS 在算繪時選擇隨時新增屬性，以便將延後載入的優點運用於任何現有內容。如果只能透過編輯器新增屬性，只有新內容或最近修改的內容才能獲得好處，大幅降低 CMS 對網路資源的影響。此外，如果瀏覽器層級延後載入功能的功能進一步擴大，即時新增屬性就能輕鬆允許日後的修改。
不過，動態新增屬性時，應考量元素上可能存在的 loading 屬性，並讓這類屬性具有優先順序。如此一來，CMS 或 CMS 的擴充功能也能實作由編輯器主導的方法，而不會與重複的屬性產生衝突。
改善伺服器端效能
當您使用伺服器端中介軟體 (例如) 在內容中即時新增 loading 屬性時，速度就會成為考量因素。視 CMS 而定，您可以透過 DOM 檢索或規則運算式新增屬性，建議為提升效能使用後者。
請盡量減少使用規則運算式，例如單一規則運算式可收集內容中的所有 img 和 iframe 標記 (包括其屬性)，然後視需要將 loading 屬性新增至每個標記字串。舉例來說，WordPress 會使用單一一般規則運算式，對特定元素執行各種即時作業，其中新增 loading="lazy" 只是其中之一，使用單一規則運算式可促進多項功能。這也是為什麼我們建議在 CMS 核心中採用延遲載入功能，而非擴充功能，因為這類最佳化功能可改善伺服器端效能。
後續步驟
請查看是否有現有的功能要求支援單，以便在 CMS 中新增功能支援，如果沒有，請開立新的支援單。視需要引用這篇文章，以佐證您的提案。
如有任何問題或意見，歡迎透過 Twitter 與我聯絡 (felixarntz@)。如果您已新增瀏覽器層級延後載入功能的支援，也歡迎將您的 CMS 列入本頁。如果你遇到其他問題，我也想進一步瞭解這些問題，希望能找到解決方法。
如果您是 CMS 平台開發人員，請研究其他 CMS 如何實作延後載入：
您可以運用研究過程中學到的知識，以及這篇文章中的技術建議，開始為 CMS 提供程式碼，例如以修補程式或提取要求的形式。
主頁橫幅相片由 Colin Watts 提供，取自 Unsplash。