采用标准化加载属性的经验教训
我撰写这篇博文的目标是说服 CMS 平台开发者和贡献者（即 CMS 核心的开发者）现在是实现对浏览器级图片延迟加载功能的支持的好时机。此外，我还将分享有关如何在实现延迟加载时确保优质用户体验和启用其他开发者的自定义功能的建议。这些准则源自我们在向 WordPress 添加支持以及帮助 Joomla、Drupal 和 TYPO3 实现该功能的经验中。
无论您是 CMS 平台开发者还是 CMS 用户（即使用 CMS 构建网站的人员），都可以通过这篇博文详细了解 CMS 中浏览器级延迟加载的优势。请参阅后续步骤部分，了解如何鼓励 CMS 平台实现延迟加载。
背景
在过去的一年中，使用 loading 属性延迟加载图片和 iframe 已成为 WHATWG HTML 标准的一部分，并且越来越多地采用这种技术。不过，这些里程碑仅为构建更快速、更节省资源的 Web 奠定了基础。现在，分布式网络生态系统中可以利用 loading 属性。
内容管理系统为大约 60% 的网站提供支持，因此这些平台发挥着至关重要的作用，有助于推动网络采用现代浏览器功能。一些常用的开源 CMS（例如 WordPress、Joomla 和 TYPO3）已经实现了对图片 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 标记或上下文或内容中的特定 HTML 元素跳过 loading 属性。
改造现有内容
概括来讲，您可以通过以下两种方法在 CMS 中向 HTML 元素添加 loading 属性：
- 从后端的内容编辑器中添加属性，并将其永久保存在数据库中。
- 在前端渲染来自数据库的内容时即时添加该属性。
建议 CMS 在呈现时选择实时添加该属性，以便将延迟加载优势也应用于任何现有内容。如果只能通过编辑器添加该属性，则只有新内容或最近修改过的内容才会受益，从而大大减少 CMS 对节省网络资源的影响。此外，如果浏览器级延迟加载功能得到进一步扩展，即时添加该属性可轻松实现将来的修改。
不过，即时添加该属性应满足元素上可能存在的 loading 属性，并让此类属性优先考虑。这样，CMS 或其扩展程序也可以实现编辑器驱动的方法，而不会造成与重复属性冲突。
优化服务器端性能
使用（例如）服务器端中间件将 loading 属性即时添加到内容时，速度是一个需要考虑的因素。该属性可以通过 DOM 遍历或正则表达式添加，具体取决于 CMS。为了提高性能，建议使用后者。
应尽量减少对正则表达式的使用，例如，单个正则表达式会收集内容中的所有 img 和 iframe 标记（包括其属性），然后根据情况向每个标记字符串添加 loading 属性。例如，WordPress 甚至使用一个常规正则表达式来对特定元素执行各种即时操作，其中添加 loading="lazy" 只是其中之一，使用一个正则表达式来实现多个功能。此外，这种优化形式也是我们建议在 CMS 核心中采用延迟加载而非扩展程序的另一个原因，因为延迟加载可以更好地优化服务器端性能。
后续步骤
查看是否有针对 CMS 中相应功能支持的功能请求工单；如果没有，则创建新的工单。请根据需要参考此博文来为您的提案提供依据。
如有问题或意见，请发 Twitter 微博 (felixarntz@)；或者将您的 CMS 列在此页面（如果已添加对浏览器级延迟加载的支持）。如果您遇到了其他挑战，我也很想深入了解这些挑战，希望能找到解决方案。
如果您是 CMS 平台开发者，不妨了解一下其他 CMS 是如何实现延迟加载的：
您可以运用从研究中总结出来的经验教训以及本博文中的技术建议，开始向 CMS 贡献代码（例如以补丁请求或拉取请求的形式）。
主打照片，由 Colin Watts 拍摄，位于 Unsplash 网站。