CDN接入后CLS升高？图片托管的3项检查标准

接入CDN后CLS升高，先找到发生位移的元素，再检查图片预留比例、实际返回的图片版本，以及延迟出现的其他内容。CDN改变的是资源分发路径；图片到得晚，只有在它引起可见内容意外移动时才会造成布局偏移。已经正确预留空间的慢图，仍可能拖累加载体验，却不一定增加CLS。

因此，图片托管不能只看节点数量或下载速度。下面三项标准分别回答：页面能否先留对位置、目标用户能否稳定取得正确文件、上线后能否确认配置真正生效。

标准一：图片转换后，布局仍能预留正确比例

按CLS定义，计分对象是可见元素的意外位置变化；当前指标取页面生命周期中得分最大的会话窗口，不是把所有位移无限相加。窗口内相邻位移间隔小于1秒，窗口最长5秒。良好目标为移动端、桌面端分别统计的第75百分位不超过0.1。

先对照实际图片，而不只看标签里有没有数字

1. 在浏览器开发者工具中选中图片，记录实际选中的currentSrc、固有宽高和页面显示宽高。
2. 核HTML中的width/height及CSS比例是否匹配所选资源。原图1200×800，CDN却返回正方形裁切版时，继续预留3:2就可能不对。
3. 切换手机和桌面断点，检查picture、srcset、sizes。手机可能选择另一张图，不能只核默认img src。
4. 模拟慢网络，观察图片、占位图、错误回退和图注出现时，下面的正文有没有被推走。

web.dev的CLS优化指南建议为图片和延迟组件预留空间。picture内的source也支持宽高属性，适合手机与桌面采用不同构图比例的情况。

下面是非首屏正文图的教学写法。文件名和尺寸均为示例，使用时必须换成真实资源；手机图为4:3，桌面图为16:9：

<picture>
  <source media="(max-width: 600px)"
          srcset="/images/example-mobile.webp"
          width="640" height="480">
  <img src="/images/example-desktop.webp"
       width="1200" height="675"
       style="width:100%;height:auto"
       loading="lazy" decoding="async"
       alt="按实际图片内容填写准确描述">
</picture>

如果图片是首屏LCP候选，就不要照搬这里的loading="lazy"。不同断点的实际呈现仍须测试；单独给标签补尺寸，不能证明整页CLS已经达标。

标准二：目标地区取得的是正确、稳定的文件

比较托管方案时，用同一页面、同一图片版本和可比测试条件观察目标地区。记录HTTP状态、重定向、连接准备、首包、下载时间和文件内容。一次IP查询不能证明用户访问了哪座边缘节点，也不能从节点总数直接推导速度。

浏览器缓存和CDN共享缓存是不同层。依据HTTP缓存说明检查实际响应和生效规则：no-cache允许存储但要求复用前验证，不等于no-store。缓存时间应配合内容更新方式，不能所有图片都统一延长后就不再考虑失效。

使用WebP等图片格式与压缩方法时，逐图核文字、边缘和透明区域；文件更小不代表源图更清楚，也不代表布局已经稳定。若问题主要是大图迟迟不出现，转到CDN接入后LCP变慢的排查。

标准三：能定位位移，并验证发布后的真实版本

用DevTools的Performance记录一次加载及后续阅读，在Layout Shifts相关记录中看位移时间和受影响节点。被标出的节点可能只是被推走的文字；真正原因可能是它上方的图片、广告、通知或字体变化。

先保留当前版本的记录，再只改有证据的问题：修图片比例、为异步组件预留位置、调整字体回退。不要为了让首屏截图不动，就隐藏必要内容或删除客服、同意管理与追踪功能。

• 冷、热缓存分别看：浏览器禁用缓存不等于清除了CDN缓存；记录实际命中情况。
• 走完真实阅读路径：滚动正文、等延迟模块出现，再操作必要控件。加载阶段CLS为0不能代表后续阅读都为0。
• 核发布一致性：源站HTML、新图片、CDN返回和浏览器选中的资源应对应同一版本；刷新缓存后再确认。
• 继续看现场数据：PSI有足够样本时显示CrUX数据，缺少数据应记为缺失，不能写成“真实用户无偏移”。

PSI说明将近期真实用户数据与本次实验室诊断分开。先用本地记录找原因，再看适用设备与时间窗口中的现场变化；更多指标边界见LCP、INP与CLS的SEO应用。选择图片托管服务的依据，应是正确文件、稳定布局和可复查的交付表现。