采用标准化 loading 属性的经验
我撰写本文的目的是说服 CMS 平台开发者和贡献者（即开发 CMS 核心的人员），现在是时候实现对浏览器级图片延迟加载功能的支持了。 我还会分享一些建议，介绍如何在实现延迟加载的同时确保优质的用户体验，并让其他开发者能够进行自定义。这些准则源自我们为 WordPress 添加支持以及帮助 Joomla、Drupal 和 TYPO3 实现该功能的经验。
无论您是 CMS 平台开发者还是 CMS 用户（即使用 CMS 构建网站的人员），都可以通过本文详细了解在 CMS 中进行浏览器级延迟加载的好处。请参阅后续步骤部分，了解如何鼓励 CMS 平台实现延迟加载。
背景
在过去一年中，使用 loading 属性延迟加载图片和 iframe 已成为 WHATWG HTML 标准的一部分，并且越来越多地被各种浏览器采用。
不过，这些里程碑只是为更快速、更节省资源的 Web 奠定了基础。
现在，分布式 Web 生态系统需要利用 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 公开一个界面控件，以便选择停用该元素的延迟加载。
或者，也可以向第三方开发者公开 API，以便他们通过代码进行类似的更改。
例如，WordPress 允许跳过
整个 HTML 标记或上下文
的 loading 属性，或跳过
内容中特定 HTML 元素的 属性。
改造现有内容
概括来讲，在 CMS 中向 HTML 元素添加 loading 属性的方法有两种：
- 在后端的内容编辑器中添加该属性，并将其永久保存在数据库中。
- 在前端呈现数据库中的内容时，动态添加该属性。
建议 CMS 选择在呈现时动态添加该属性，以便为任何现有内容也带来延迟加载的好处。如果只能通过编辑器添加该属性，那么只有新内容或最近修改的内容才能受益，这会大大降低 CMS 在节省网络资源方面的影响。此外，如果浏览器级延迟加载的功能进一步扩展，动态添加该属性将有助于未来轻松进行修改。
不过，动态添加属性应考虑到元素上可能存在的 loading 属性，并让此类属性优先。这样，CMS 或其扩展程序也可以实现编辑器驱动的方法，而不会与重复属性发生冲突。
优化服务器端性能
如果使用（例如）服务器端中间件动态向内容添加 loading 属性，则需要考虑速度。根据 CMS 的不同，可以通过 DOM 遍历或正则表达式添加该属性，出于性能考虑，建议使用后者。
应尽量少用正则表达式，例如，使用单个正则表达式收集内容中的所有 img 和 iframe 标记（包括其属性），然后根据需要将 loading 属性添加到每个标记字符串。例如，WordPress 甚至使用一个通用正则表达式对某些元素执行各种即时操作，其中添加 loading="lazy" 只是其中之一，它使用一个正则表达式来支持多种功能。此外，这种优化形式也是建议在 CMS 核心中采用延迟加载而非扩展程序的另一个原因，因为这样可以更好地优化服务器端性能。
后续步骤
查看是否有现成的功能请求工单，要求在您的 CMS 中添加对该功能的支持；如果没有，请提交新的工单。您可以根据需要引用此帖子，以支持您的提案。
如果您有任何问题或意见，或者您的 CMS 已添加对浏览器级延迟加载的支持，希望将其列在此页面上，请在 Twitter 上联系我 (felixarntz@)。如果您遇到其他挑战，我也很想了解更多信息，以便找到解决方案。
如果您是 CMS 平台开发者，请研究其他 CMS 如何实现延迟加载：
您可以利用研究成果和本文中的技术建议，开始为 CMS 贡献代码，例如以补丁或拉取请求的形式。