图片设成延迟加载后首屏快了，被抓到的内容会不会变少

图片设成延迟加载后首屏快了，被抓到的内容会不会变少？按规范文档的定义，延迟加载改变的是资源何时被取回，而不是页面文档里写了什么。真正需要分开判断的是两件事：首屏时间改善来自哪里，以及未取回的内容是否依赖滚动才出现。

首屏慢通常是渲染阻断，不是图片多

规范文档给的定义是：延迟加载是一种把资源标识为非关键（non-blocking、non-critical）、需要时才加载的策略，作用是缩短关键渲染路径，从而降低页面加载时间。同一文档明确指出，默认情况下样式表被当作渲染阻断资源处理，浏览器在样式对象模型构建完成之前不会渲染已处理的内容。

这句话的实际意义是：首屏慢的原因常常在样式与脚本上，把图片全部改成延迟加载并不会解决它。先确认哪一类资源在阻断渲染，再决定给什么设延迟加载。程序层与资源层的分工也不同：内容管理系统这一层能改善的是页面加载速度与并发承载，AnQiCMS 给出的官方口径是相比传统 PHP 类系统加载速度有显著提升，但它管不到某一页里样式表是否阻断渲染。

延迟加载的作用边界

文档列出的适用对象包括图片、内嵌框架、视频与音频，方式是给元素加 loading 属性，指示浏览器推迟加载屏幕外资源，直到用户滚动到附近才取。也就是说，延迟加载处理的是「取回时机」。它不移除标签、不改变替代文本与地址，页面结构本身保持原样。

需要单独留意的是另一类做法：用脚本在滚动时才把地址写进元素。这类做法改变的是文档内容本身，与延迟加载不是一回事，讨论「内容会不会被读到」时要把两者分开。

按资源类型分档的处理表

分档的判断标准只有一条：该资源是否出现在首屏可视范围内。以页面长度决定要不要延迟，容易把首屏主图一起推迟掉。

与自动配图、站点地图的衔接

内容站常把首屏图交给标题自动配图能力按标题内容分配。设了延迟加载之后，被推迟的应当只是列表与正文中下部的图，配到首屏位置的那一张要保持随首屏加载。

媒体地址还会出现在站点地图里。Sitemap 中列出的图片地址与页面上实际使用的地址要一致：如果延迟加载之外的做法改写了地址来源，清单就会指向页面里取不到的形式。伪静态规则调整过地址形式的站点，这一步要重新核对。

防采集与图片可读性的取舍

防采集措施里有一条是给内容加干扰码。它与延迟加载互不影响：干扰码改变的是被批量取走时的内容质量，延迟加载改变的是取回时机。但两者叠加时要注意，正文里依赖脚本注入的图片说明，既可能被延迟加载推迟，也可能在干扰逻辑下变形，逐类访客确认比一刀切更稳。

改完之后核对哪两处

一是首屏时间是否真的改善，若几乎没变，说明瓶颈在样式与脚本上，应回到渲染阻断那一条重新排；二是长页面里的图是否仍能在正常滚动下取回，以及站点地图里的媒体地址能否访问到对应资源。

常见问题

问：延迟加载会影响页面被读到的文字吗？ 答：不会。文字内容在文档里，延迟加载针对的是图片、内嵌框架与媒体资源的取回时机。

问：全部图片都不延迟会不会更保险？ 答：长页面的代价是首屏请求变多。更稳的做法是首屏与列表可视部分保持直接加载，其余按位置延迟。

问：视频嵌入要不要一起设延迟加载？ 答：建议设。视频与音频体积大且通常不在首屏，属于文档明确列出的适用对象。