脚本审计要回答：谁在加载、为谁服务、在哪些页面运行、改动后会丢什么。脚本数量少不必然更快；下载过却暂时未执行的代码，也不一定可以删除。先把实际用途与证据对上，再处理重复、过时或无用的部分。
用源码、请求和配置一起建立清单
查看原始HTML中的script，再在Network记录动态请求和Initiator发起链，结合主题文件、应用区块、app embed、客户事件与标签管理配置。域名只是线索：同一供应商可能承载多个功能，某个应用也可能调用多个域名。访问权限列表不能独自证明某条前台请求归属。
| 记录项 | 为什么需要 |
|---|---|
| 完整请求及发起链 | 找到加载入口，识别多层注入 |
| 所属功能、配置位置与负责人 | 判断是否仍需使用和怎样回退 |
| 页面、市场、同意状态与触发动作 | 区分只在特定条件运行的代码 |
| 传输、执行和交互记录 | 区分网络体积与主线程工作 |
| 替代或移除后的功能验证 | 避免页面变快但事件、购买或客服失效 |
Coverage未使用，不等于全店无用
Shopify脚本审计建议要求在代表模板中检查Coverage；还应走实际交互。只录首页加载，无法据此判定产品评价、选规格或加购相关代码无用。Network阻断可帮助比较某个域名的影响，但阻断后功能可能不完整，不能把它当正式发布方案。
对仍需保留的代码，评估按页面或功能加载、避免无意义重复及减少长任务。async/defer不等于代码不占主线程，也不自动解决顺序依赖或同意要求。涉及客服、广告、统计和转化链路的修改，应连同真实功能与事件验收。
Web Pixels的同意状态，要按真实机制检查
Web Pixels文档区分应用像素的strict sandbox与自定义像素的lax sandbox。需要同意的地区，应用扩展回调在取得同意后执行，并回放此前注册的事件；默认允许且可退出的地区则按相应退出行为处理。不能据首次加载没有请求就宣布像素失效，也不能假设加一个固定延时便满足全部同意条件。
像素customerPrivacy标准API提供初始状态及visitorConsentCollected订阅。它与页面上的Customer Privacy API使用环境不同，不能直接把依赖window.document的传统代码搬入严格沙箱。实际核验应包含首次访问、允许、拒绝或退出，以及同一购买任务下的事件。
浏览器端与服务器端同时上报不必然重复计数。先核平台的事件标识、去重逻辑、时间和实际接收记录；同用途两条请求也可能承担不同任务。仅“请求200”既不证明平台计入，也不证明业务转化正确。
旧ScriptTag与app embed的当前边界
截至2026年10月22日，Shopify店面ScriptTag退役时间表写明：2026年10月1日起不能新建或更新ScriptTag，已有的继续运行；2027年3月1日起停止向店面注入。订单状态页使用另一时间表，不能混为同一截止日期。这针对ScriptTag集成，不是所有HTML script标签被禁用。
迁移到app embed后要按主题启用，并核发布主题及重复加载；应用安装存在不等于新主题已启用。卸载时的自动清理与手工残留按不同集成方式判断，不能一概当成残留脚本。
留下可复查的结果
记录每项保留、按条件加载、替换或移除的原因和实际检查范围，保存改动前后请求与功能结果。性能按同条件基线比较，选新应用时沿应用评估表预先核维护成本。没有现场INP或平台接收证据的项目，就保留为未验证，不能用本地一次跑分代替。