在 Safari 中启用开发菜单并打开网络检查器，筛选 script.js 请求按耗时降序排列，重点关注发起者为 other 或空值、耗时＞800ms 的脚本，通过阻止资源或分析 Waterfall 时间轴验证其是否阻塞渲染。
你需要在 Safari 中快速揪出拖慢页面加载的第三方脚本，而不是靠猜测或逐个禁用扩展——真正的瓶颈往往藏在 network 请求里，且多数来自未声明来源的 script 标签。
启用开发菜单并打开网络检查器
这是所有后续分析的前提，跳过这步将无法看到任何请求详情。
点击顶部菜单栏【Safari】→【设置】→ 切换到“高级”标签页 → 勾选【在菜单栏中显示‘开发’菜单】。
关闭设置窗口后，确保 Safari 已完全重启（Command + Q 再重开），否则“开发”菜单可能仍不响应。
打开目标网页 → 点击菜单栏【开发】→【显示 Web 检查器】→ 切换至“网络”标签页。
筛选并识别可疑外部脚本
刷新页面（Command + R），让网络面板捕获完整加载链。此时列表会密集滚动，必须立刻过滤。
在右上角搜索框中输入 script，所有类型为 “script” 的资源立即高亮；再补输 .js 可排除内联模块和 wasm。
点击表头“持续时间”进行降序排列，排在最前面的 JS 文件大概率是罪魁祸首——尤其当耗时 >800ms 且状态码为 200 时，说明它不是失败请求，而是真正在拖慢主线程。
注意看“发起者（Initiator）”列：若某 script 的发起者是 other 或空值，说明它由 document.write、eval 或动态 import() 注入，极难被常规拦截器管控，需重点标记。
验证脚本是否真实阻塞渲染
方法一：暂停执行并对比白屏时间
在“网络”面板中右键任一可疑 script → 选择“阻止此资源”，刷新页面。若白屏时间显著缩短或首屏内容秒出，即确认该脚本为关键阻塞源。
方法二：查看 Waterfall 时间轴定位阻塞点
点击该 script 条目 → 切换到“时间轴（Waterfall）”子标签 → 观察“Start Time”与“DOMContentLoaded”之间是否存在长空白间隙；若 script 的“End Time”紧贴 DOMContentLoaded 之后，说明它虽未阻塞 HTML 解析，但严重延迟了交互就绪时间。
⚠️ 提示：不要只看“传输时间”，很多广告 SDK 脚本本身体积小（
追溯脚本真实来源域名
第一步：复制请求 URL 并提取根域
点击可疑 script → 在右侧“标头（Headers）”中找到“请求 URL”，全选复制 → 粘贴到备忘录，删去路径和参数，仅保留类似 https://cdn.adsrvr.org 或 http://metrics.yieldmo.com 的主域部分。
第二步：反查该域名是否被隐私报告拦截
回到页面，点击地址栏左侧锁形图标 → 选择“隐私报告” → 等待加载完成 → 在“已阻止的内容”下方查找该域名是否高频出现；若显示“已阻止 47 个来自 yieldmo.com 的跟踪器”，说明 Safari 已主动拦截其大部分行为，但残留的未声明 script 仍可能绕过规则执行。
第三步：用控制台确认是否全局污染
切换到“控制台”标签页 → 输入 Object.keys(window).filter(k => k.includes('yieldmo') || k.includes('adsrvr')) → 回车；若返回非空数组（如 ["YieldmoAPI", "AdServer"]），证明该脚本已完成全局挂载，即使后续被拦截，其初始化副作用已发生。
