脚本审计的产出应该是一张归属表：谁加载了什么、什么时候加载、能不能关掉、关掉会丢什么。没有归属表就动手删脚本，下一次装应用又会回到原样，删错的部分还很难查回来。
先把清单拉出来
两条路一起走。页面源码里搜 script 标签，能拿到直接写在 HTML 里的那部分；Network 面板按域名分组看请求，能拿到由其它脚本再插入的那部分。两边对不上是常态，后者才是容易漏的。
没有清单就没法判断取舍（光算 · 示意图）
每个脚本至少记四样东西：域名、加载时机（首屏就有、空闲时、交互后）、所属应用或平台、后台有没有对应开关。域名是最有用的线索，同一个供应商的多个脚本通常共用域名，看到陌生域名先按域名归类再谈处置。
归属判断上，Shopify 应用的机制可以帮你缩小范围：应用要读写店铺数据需要访问令牌，而令牌能做什么由商家批准过的访问范围决定（Shopify 应用认证文档）。所以从后台的已安装应用列表和各自批准的权限出发对照脚本域名，大多数归属能对上。对不上的通常属于两类：平台自身注入的统计与像素，以及已经卸载但残留的代码，后者按卸载插件后的残留清理处理。
判断顺序：必需、延迟、合并替换、移除
| 判断项 | 通过才继续 | 常见反例 |
|---|---|---|
| 是否解决一个具体问题 | 能说清它在解决什么问题 | 「先装上看看数据」 |
| 是否影响首屏可用 | 不阻塞首屏的浏览与加购 | 客服组件挡在加购按钮前面 |
| 能否延迟加载 | 能等到空闲或用户交互后 | 必须立即上报的转化事件 |
| 能否被现有工具替代 | 已有工具覆盖同一需求 | 同时装了几个热图工具 |
| 卸载是否干净 | 主题里没有它的残留代码 | 卸载后主题还挂着它的 script |
这张表的作用是让每一步都有依据，而不是「感觉它也挺占资源」。它还有个用法：让你能停在任何一步。如果一段脚本确实必需、也没法延迟加载，那「保留」就是一个有依据的结论，审计到这一步可以结束，不必硬找点东西来删。功能重叠是最常见的浪费：几个应用做同一件事，脚本同时加载还会互相干扰，选插件时要看什么讲的就是这类判断。
像素与统计最容易重复
同一家广告平台可能有多代像素，统计工具可能有浏览器端和服务器端两条上报路径，客服组件往往还自带一套会话统计。它们单独看都能工作，放在一起就会重复计数或者互相覆盖，数据对不上的时候很难判断是哪一层的问题。审计时给「同一用途有几个脚本」单独记一栏，比只看脚本总数有用得多。
按必需性与替代成本判断（光算 · 示意图）
还有个现实问题：脚本之间会互相触发。A 加载完之后动态插入 B 的情况在第三方脚本里很常见，所以你在页面源码里数 script 标签得到的数字，通常小于实际执行的脚本数量，最终必须以 Network 面板的请求为准。
归属表怎么写才用得下去
记录不用做得多正式，关键是能让人在半年后看懂。每个脚本留一段固定格式的说明，比存在脑子里可靠：
域名: cdn.example.com
用途: 会话回放
加载时机: 首屏内，与客服组件同批
归属: 应用 A（已授权读取订单数据）
开关位置: 后台应用设置 - 关闭会话回放
备注: 关闭后需回归加购流程把域名放在第一行是因为它是最好用的检索键：下次在 Network 面板看到陌生请求，先按域名查表，查不到才需要重新判断归属。
审计范围先缩小，再逐个处理
不要一上来就铺全站。先审首屏路径上的几类页面：首页、主要集合页、产品页，以及从加购到结账这一段会经过的页面，其他页面按实际访问量排优先级。理由是这些页面占了大部分会话，脚本在这里对购买路径的影响也最直接。范围小还有个好处：改动可控，出问题能定位到是哪一次改动引起的。
每做一次删除或延迟，留一份回归清单：加购能不能成功、客服入口能不能打开、统计有没有继续收到数据、公告条和弹窗是不是还在。清单不用长，但每次都要走一遍，因为脚本之间的依赖经常是隐性的——删掉一个统计库，可能让另一个组件失去工具函数而报错。
它到底拖慢了哪一段
别笼统地说「脚本多所以慢」，要分清是主线程、网络还是渲染。主线程的阻塞看 Performance 面板里的长任务落在哪个文件，一次点击延迟的构成和测量方式见INP 与主线程。网络层面的表现是第三方域名数量、请求数量和加载完成时间，很多脚本是串行的，A 加载完才插入 B，链条越长后面的越晚。
渲染层面则看脚本注入的元素有没有把已有内容推走。同一段脚本可能只影响其中一项：一个弹窗既不占主线程也不发请求，但它弹出时把内容推下去了，那属于布局偏移问题，排查方式见应用注入与字体切换的排查。三类分开记录，处置方式才不会错配。
同意管理与统计脚本的关系
这两样经常被当成两件事，实际是一个加载顺序问题。同意管理工具必须先执行，而且要真正控制住被管脚本的加载。如果两边各自独立注入，同意还没拿到，统计脚本已经开始跑了，同意管理就形同虚设。
可执行的检查点有三个。一是未同意状态下，被管的脚本是否真的没有发出请求，要在 Network 面板里看，不看界面上的提示。二是用户给出同意后，是否只加载了授权范围内的脚本，而不是把全部脚本一次放行。三是用户撤回同意后，行为是否与未同意状态一致。
至于哪些脚本在哪些地区需要事先取得同意，这属于合规判断，不在本文结论范围内，要以目标市场的法规和你的专业顾问意见为准。技术上能保证的只有一件事：你的加载逻辑和你的政策文本说的是同一件事。
处置时的代价
延迟加载要写清「延迟到什么事件」。把转化上报延迟到用户点击之后才加载，可能漏掉那些没有点击的转化，这个代价要按你自己的统计口径去核实，别人给的方案不一定适用你的场景。
移除之前留档：域名、用途、后台开关位置、谁决定装的，都写进记录。半年后有人问「数据怎么和去年对不上」，这份记录能省下很多时间。
由应用注入的脚本，卸载或撤权是唯一彻底的办法，撤权前要确认不会中断正常的订单流程，权限范围的核对见应用权限审计。这一步容易被跳过，撤权影响的是应用能不能读数据，比它加载了什么更值得先看清楚。
边界：不要为分数删业务组件
统计和客服组件常常是第三方脚本里最「重」的，但它们往往也是业务必需的。这种情况下正确的做法是把它单独列出、写清归属和影响，交给能改它的一方去处理，而不是为了让分数好看直接删掉。删完之后数据断层，代价比几个分数大得多。
平台自身注入的脚本不在你的可控范围，主题文件里找不到它们不代表它们不存在。同样，主题层改不了应用注入的代码，这一点决定了审计的终点通常是「决定留不留这个应用」，而不是「把它的代码改快」。
审计也不是一次性的工作。装了新应用、应用升级、同意管理上线或者更换、换主题，这几种情况下脚本清单都会变。新应用的脚本往往在你没注意的时候进入首屏路径，几个月后再回头看，当初那张表已经和现实对不上了。复查不用全部重做，按域名比对就行：新增的逐个确认归属，消失的从表里删掉，留下的只看加载时机有没有变。
本文讲的是技术层面的落地与检查点，不构成法律意见。Cookie、跟踪脚本与个人数据处理的适用范围要按目标市场的法规和你的专业顾问意见判断，我们能保证的只是加载逻辑与政策文本一致，并且这件事可以被验证。
不承诺删除脚本之后分数一定到某个值。单次测试受设备、网络、地区影响，真实用户数据要单独看，方法见Core Web Vitals 基线的建法。还有一层：如果你的站点内容主要靠脚本渲染，要知道 Googlebot 虽然会执行 JavaScript，但被 robots 挡住的资源它用不了，渲染出来的页面会缺内容（Google 关于 JavaScript SEO 的说明）。脚本策略和收录策略是连在一起的，抓取与收录层面的排查属于我们做谷歌收录时的工作；把站点从 Shopify 换成自建方案也不会自动解决这类问题，两边的可控范围差别见Shopify 与 WordPress 的 SEO 差别。