cls是浏览器自动计算的视觉稳定性指标，需结合layout instability api（通过performanceobserver监听layout-shift、启用buffered和includesources）与chrome devtools的layout shift regions可视化工具，定位图片、字体、广告等三类高频肇事资源并从html/css层修复。

CLS（Cumulative Layout Shift）不是靠 HTML5 标签“开启”的性能指标，而是浏览器自动计算的视觉稳定性分数。它本身不监控、也不修复偏移——真正能识别和定位问题资源的，是结合 Layout Instability API 与 Chrome DevTools 可视化工具 的组合方案。

用 PerformanceObserver 捕获真实偏移来源

Layout Instability API 是唯一能获取原始偏移数据的浏览器原生接口，关键在于正确配置：

• 必须设置 entryTypes: ['layout-shift']，否则监听器不会触发
• 务必启用 buffered: true，否则页面初始加载阶段的偏移会被丢弃
• 要看到具体是哪个元素在抖，必须加 includeSources: true（Chrome 支持）
• 只关注 hadRecentInput === false 的条目——这类偏移才计入 CLS，也最影响用户体验

从 sources 定位肇事资源

每条 layout-shift 条目里的 sources 数组，就是破案线索：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• sources[0]?.node 通常指向直接引发偏移的 DOM 元素，比如一张没设尺寸的 <img> 或一个异步插入的广告 <div> <li>若 <code>node 为 null 或 #document，大概率是跨域 iframe 或第三方脚本注入导致，需配合 Network 面板查其加载时机和响应头
• 对比 previousRect 和 currentRect，可算出高度突变值——比如图片加载后 height 从 0 跳到 400px，就是典型资源加载抖动

用 Chrome DevTools 实时高亮抖动区域

光看代码不够直观，DevTools 提供了零门槛可视化手段：

• F12 → Rendering 面板 → 勾选 “Layout Shift Regions”，滚动或交互时，所有偏移区域会以红色半透明框实时高亮
• Performance 面板录制操作后，在时间轴上右键表头 → 勾选 “Layout Shift Regions”，再点击某次偏移 → 查看 “Related Node” 直接跳转到问题元素
• 选中该元素 → Computed 标签页搜索 width、height、aspect-ratio，确认是否为 auto 或 none——这是资源未预留空间的铁证

聚焦三类高频肇事资源并针对性处理

90% 的 CLS 问题集中在以下资源类型，修复动作应落在 HTML/CSS 层：

• 图片与 iframe：必须带内联 width 和 height 属性（仅 CSS 无效）；响应式可用 style="aspect-ratio: 16/9; width: 100%"，但需注意 Safari 15.4+ 兼容性
• 自定义字体：用 font-display: swap 配合 @font-face 中的 size-adjust 或 ascent-override，防止换字后行高突变
• 第三方嵌入内容（广告、评论、社交按钮）：HTML 源码中就写好占位容器，如 <div id="ad-slot" style="min-height: 250px"></div>，而非等 JS 插入空 div