有关采用标准化加载属性的经验
我撰写这篇博文的目的是为了让 CMS 平台开发者和贡献者（即开发 CMS 核心的人员）相信现在是时候实现对浏览器级图片延迟加载功能的支持了。我还会分享一些建议，帮助您在实现延迟加载的同时确保提供优质的用户体验，以及如何启用其他开发者的自定义功能。这些准则源自我们增加 WordPress 支持以及帮助 Joomla、Drupal 和 TYPO3 实现该功能的经验。
无论您是 CMS 平台开发者还是 CMS 用户（即使用 CMS 构建网站的人员），都可以通过本博文详细了解 CMS 中浏览器级延迟加载的优势。请查看后续步骤部分，了解有关如何鼓励 CMS 平台实现延迟加载的建议。
背景
在过去的一年里，使用 loading 属性延迟加载图片和 iframe 已成为 WHATWG HTML 标准的一部分，并且越来越多的浏览器被采用。不过，这些里程碑只是为打造更快速、更节约资源的 Web 奠定了基础。现在，分布式 Web 生态系统中已包含 loading 属性。
内容管理系统为大约 60% 的网站提供支持，因此这些平台在推动网络采用新型浏览器功能方面发挥着至关重要的作用。一些常用的开源 CMS（例如 WordPress、Joomla 和 TYPO3）已经针对图片实现了对 loading 属性的支持。接下来，我们来了解下它们在其他 CMS 平台上采用该功能的方法和要点。延迟加载媒体是一项关键的 Web 性能功能，网站大规模地应该受益于这一功能，因此建议您在 CMS 核心级别采用该功能。
目前实现延迟加载的情况
标准化
在 CMS 中采用非标准化浏览器功能有助于进行广泛测试，并发现潜在的改进领域。不过，跨 CMS 的一般共识是，只要浏览器功能未标准化，就最好通过相应平台的扩展程序或插件形式实现。只有某项功能标准化后，才有可能考虑在平台核心中采用。
浏览器支持
浏览器支持此功能也是一个类似的问题：大多数 CMS 用户都应该能够从该功能中受益。如果有相当一部分浏览器尚不支持该功能，该功能必须确保至少不会对这些用户造成不利影响。
与视口的距离阈值
延迟加载实现的一个常见问题是，从原则上讲，由于加载周期从较晚的阶段开始，图片在用户视口中变得可见时，会增加图片不加载的可能性。与之前基于 JavaScript 的解决方案相反，浏览器较为保守地使用此方法，并且更多可以根据实际用户体验数据微调他们的方法，最大限度地减少影响，因此 CMS 平台应该可以放心地采用浏览器级延迟加载。
用户体验建议
必须为元素提供尺寸属性
为了避免布局偏移，我们一直以来建议图片或 iframe 等嵌入式内容应始终包含尺寸属性 width 和 height，以便浏览器可以在实际加载它们之前推断这些元素的宽高比。无论元素是否处于延迟加载状态，此建议都适用。不过，由于某张图片在视口中一次未完全加载的可能性提高了 0.1%，因此使用延迟加载时，该方法更适用。
CMS 应最好在所有图片和 iframe 上提供尺寸属性。 如果无法对所有此类元素都做到这一点，建议他们跳过无法同时提供这两个属性的延迟加载图片。
避免延迟加载首屏元素
目前，我们建议 CMS 仅将 loading="lazy" 属性添加到位于非首屏的图片和 iframe，以避免 Largest Contentful Paint 指标出现延迟，而该指标在某些情况下可能会非常明显（如 2021 年 7 月所述）。不过，必须承认，在呈现过程之前评估元素相对于视口的位置十分复杂。这在 CMS 使用自动化方法来添加 loading 属性时尤其适用，但即使是基于人工干预，也必须考虑不同的视口尺寸和宽高比等因素。尽管如此，我们仍强烈建议您省略主打图片和其他可能显示在首屏的图片或 iframe，以免被延迟加载。
避免 JavaScript 回退
虽然 JavaScript 可用于为尚不支持 loading 属性的浏览器提供延迟加载，但此类机制始终需要先移除图片或 iframe 的 src 属性，而这会导致支持该属性的浏览器出现延迟。此外，在大型 CMS 的前端推出此类基于 JavaScript 的解决方案增加了潜在问题的发现区域，这也是为什么在标准化浏览器功能之前，没有主流 CMS 在其核心中采用延迟加载的原因之一。
技术建议
默认启用延迟加载
对于实现浏览器级延迟加载的 CMS，总体而言是默认启用该功能，也就是说，loading="lazy"应添加到图片和 iframe，最好仅针对那些包含尺寸属性的元素。
与必须手动启用相比，默认启用该功能可以节省更多网络资源，例如基于每个映像启用。
loading="lazy" 应尽可能仅添加到可能显示在非首屏的元素。由于缺乏客户端感知能力以及视口大小不一，因此对 CMS 实现这项要求可能比较复杂，但建议至少使用近似启发法来忽略某些元素，例如主图片，这类元素可能会显示在首屏，以免被延迟加载。
允许按元素修改
虽然默认情况下应向图片和 iframe 添加 loading="lazy"，但允许在某些图片上省略该属性至关重要，例如为了针对 LCP 进行优化。如果平均而言 CMS 的受众群体对技术更精通，那么此界面控件可以针对每张图片和 iframe 公开，允许为该元素停用延迟加载。或者，也可以向第三方开发者公开 API，以便他们通过代码进行类似的更改。
例如，WordPress 允许针对整个 HTML 标记/上下文或内容中的特定 HTML 元素跳过 loading 属性。
改造现有内容
大体上讲，您可以通过以下两种方法将 loading 属性添加到 CMS 中的 HTML 元素：
- 您可以在后端的内容编辑器中添加属性，并将其永久保存在数据库中。
- 从前端的数据库渲染内容时，即时添加该属性。
我们建议 CMS 在渲染时选择即时添加该属性，以便给任何现有内容也带来延迟加载的优势。如果只能通过编辑器添加该属性，则只有新内容或最近修改的内容可以获得好处，从而大大降低 CMS 对节省网络资源的影响。此外，如果浏览器级延迟加载的功能进一步扩展，动态添加该属性可轻松用于以后的修改。
不过，即时添加该属性应符合元素上可能存在的 loading 属性，并优先添加此类属性。这样一来，CMS 或其扩展程序也可以实现编辑器驱动的方法，而不会与重复属性发生冲突。
优化服务器端性能
使用（例如）服务器端中间件实时向内容添加 loading 属性时，速度是一个考量因素。根据 CMS，该属性可通过 DOM 遍历或正则表达式添加（建议选择后者，以提升性能）。
应尽可能减少对正则表达式的使用，例如使用单个正则表达式，它会收集内容（包括其属性）中的所有 img 和 iframe 标记，然后视情况将 loading 属性添加到每个标记字符串中。以 WordPress 为例，它使用单个常规正则表达式对某些元素执行各种即时操作，添加 loading="lazy" 只是其中一项操作，使用单个正则表达式来支持多项功能。此外，这种优化形式也是推荐在 CMS 核心中采用延迟加载而不是扩展程序的另一个原因，因为这样可以实现更好的服务器端性能优化。
后续步骤
查看 CMS 中是否存在功能请求工单，以便添加对相应功能的支持；如果还没有请求，可开立新的功能请求工单。请根据需要参考这篇博文，以便为您的方案提供支持。
如有疑问或想要发表评论，请通过 Twitter 微博 (felixarntz@) 联系我，或者让您的 CMS 显示在此页面上（如果添加了对浏览器级延迟加载的支持）。如果您遇到其他挑战，我也很想详细了解，希望能找到解决方案。
如果您是 CMS 平台开发者，请了解其他 CMS 如何实现延迟加载：
您可以利用从研究中学到的知识和本博文中的技术建议，开始为您的 CMS 贡献代码，例如以补丁或拉取请求的形式贡献代码。
主打照片由 Colin Watts 拍摄，来自 Unsplash 用户。