测一测 AI 做的页面会不会跳：版面位移实例
看起来没问题的页面，也可能在内容晚到时把读者正在看的东西推走。浏览器的 layout-shift 记录能量出这个位移，预算是 0.1。我们自己的网站就遇到过：一条来自 X 的嵌入内容让桌面端首页在生产环境测得 0.36。下面是怎么量、原因、怎么改，以及这些数字的局限。
发布于 2026-11-091. 怎么量
在真实的 Chrome 里加载页面，用 PerformanceObserver 收集 layout-shift 记录，把没有用户输入紧随其后的位移值加起来。输入之后 500 毫秒内的位移不计入，所以要像读者那样真的点开一张卡片、等内容到齐再看。我们的 tests/perf-lab.mjs 就是这样做的，它是单机的实验室数据，不是读者实际体验到的数据。
2. 我们的原因
灵感库里有来自 X 的帖子，打开后由 X 的官方嵌入组件加载完整内容。真实的嵌入约 1,270 像素高（含被引用的帖子），比它替换的那段文字高得多。「访问原站」按钮和加载提示排在它下面，嵌入到达时被整体推走。
2026-11-09 在生产环境的实验室测量（三次取中位数）：改动前桌面端首页 0.36，改动后 0.043；手机端 /browse/interaction 先后测得 0.16、0.059、0.085。最后两个手机数字说明真实嵌入的波动不小，所以它离预算并不远。
3. 怎么改
规则只有一条：会变高的东西放在最后，任何读者能看到的内容都不要排在它下面。我们把链接和提示移到帖子上方，帖子的存档文字和嵌入内容在同一帧里替换，弹层在桌面上改为靠近顶部对齐，这样变高时向下增长，而不是整体上移。
图片也是同一个道理：给它们写明 width 和 height，或者 aspect-ratio，浏览器才能在图片到达之前留出位置。
4. 用测试守住它
我们让测试用一个来得晚、又很高的假嵌入代替 X 的脚本，检查链接和提示的位置在嵌入到达前后没有变，并设了 0.1 的预算。把修复还原后，这个测试会失败，这是我们确认它真的在起作用的方式。
局限：假嵌入的高度是固定的，真实组件的高度和到达次数会变，所以生产环境的数字还要单独量，上面的数字也只是三次运行的中位数。