广告脚本必须用 data-src + IntersectionObserver 延迟加载，禁用 loading="lazy"；需预留尺寸防CLS，广告JS须异步加载且沙箱化，确保计费准确与性能兼顾。
广告脚本必须延迟加载，但不能靠 loading="lazy" —— 它对动态插入的广告 iframe 完全无效，还可能触发重复请求、布局抖动或被旧版 WebView 忽略。
为什么 loading="lazy" 对广告 iframe 基本没用
原生 loading="lazy" 在 Safari 15.4+ 才开始支持 ，而绝大多数广告 SDK（如 GAM、广点通）返回的是 JS 动态创建的 iframe，浏览器根本不会识别其 loading 属性。更关键的是：
- 广告 iframe 通常带跨域
src，一旦写死就可能被预加载或提前触发请求，浪费带宽甚至触发反爬风控 -
loading="lazy"只对 HTML 中静态书写的生效，不适用于 JS 插入或 SDK 渲染的广告位 - 旧版安卓 WebView、iOS 微信内置浏览器会直接忽略该属性，广告照常加载
- 若同时设置
src和 IntersectionObserver 监听，浏览器可能先加载src，再执行 JS 替换，导致两次请求
用 data-src + IntersectionObserver 控制真实加载时机
这是目前最可控、兼容性最好、且能配合广告计费逻辑的方案：先占位，等进入视口（或滚动到指定距离）再注入真实 src，并手动触发 SDK 刷新。
- 广告容器用
，不写，也不设src - 监听时用
threshold: 0.2（20% 可见即触发），避免用户快滑过去却没加载 - 触发后手动创建
并设sandbox="allow-scripts allow-popups"，防止广告脚本污染主页面 - 加载完成后必须调用广告 SDK 的
refresh()或display()方法（如 GAM 的googletag.pubads().refresh()）
必须预留尺寸防 CLS，且禁用内联广告脚本
广告位不预留高度/宽度，会导致图片或 iframe 加载后撑开区域，引发累积布局偏移（CLS），直接拉低 Core Web Vitals 分数。
- 用 CSS 固定容器高宽（如
height: 90px+aspect-ratio: 320/50），或通过min-height+padding-top实现响应式占位 - 绝对禁止把广告 JS 写成内联
<script></script>放在或顶部——它会同步阻塞 HTML 解析，造成白屏 - 第三方广告脚本必须走
<script async src="..."></script>或包裹进沙箱化，不能依赖 DOM 就绪顺序 - 落地页首屏广告素材（如 banner、激励视频入口）需配合
decoding="async"避免解码阻塞主线程
如何验证广告脚本是否真被延迟且未拖慢首屏
光看是否“没立刻加载”不够，得用 Performance API 看它是否影响了 FCP/LCP —— 很多广告脚本虽延迟，却因 DNS/TCP 卡顿或同步执行 longtask，依然拖垮体验。
- 用
performance.getEntriesByType('resource')过滤含doubleclick、taboola.com、amazon-adsystem.com的条目，确认initiatorType === 'script'或 URL 匹配 - 重点查三段耗时：
domainLookupEnd - domainLookupStart（DNS）、connectEnd - connectStart（TCP+TLS）、responseEnd - responseStart（body 下载） - 比对
responseEnd和first-contentful-paint：若早于 FCP 却拉低 LCP，说明它触发了重排或同步 DOM 注入 - 线上采集建议在
load后 1 秒执行，并只上报超阈值项（如总耗时 >2000ms 或 DNS 耗时 >50ms）
真正难的不是“怎么延迟”，而是“延迟后怎么确保广告计费准确、不漏刷、不重复、不干扰主线程”——这要求你清楚每个广告 SDK 的刷新契约，以及它在 iframe 沙箱里的行为边界。稍有偏差，性能数字好看，转化数据就失真。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
