PSI报弃用API警告怎么修？百度统计/GA4/Pixel等5场景pagehide治理

PSI跑出“卸载事件监听器已被弃用”这条警告，多数人第一反应是把unload换成beforeunload或者把统计代码塞进iframe沙箱——这两条路都是死胡同：iframe让百度统计上报的URL全部聚合到一个固定值，页面级数据当场报废；beforeunload在Chrome 117起也进了deprecation观察列表，Lighthouse 11升级后会一并打回。真正能扛三年的解法只有一个——拦截addEventListener，把内部所有unload都转写成pagehide，让脚本既不阻塞bfcache，也不丢PV。保哥这一年里给客户做PSI弃用API治理拢共8次，6次踩在iframe方案上，剩下2次踩在beforeunload上，最后全部回到pagehide这条主线。

有个做出海女装DTC的客户，去年12月把百度统计塞进iframe过了PSI，PSI移动端分数从58冲到84，老板在群里发了一个庆祝表情。结果一周后市场总监问“为什么这周所有页面的PV都掉到只有一个URL上？”，打开后台一看，所有页面级数据全部聚合到了/ba-frame.html这一条记录，独立站10万UV变成1万次访问1个页面。这是过去一年里见过的所有PSI弃用API求救里最经典的一次翻车，也是这篇文章想替你提前躲掉的所有坑。

PSI报“使用了已弃用的API”这条警告本身不算严重，但它后面拖着的是bfcache、LCP、INP三组指标的连锁反应。下文先讲清楚PSI到底在检测什么、Chrome为什么要把unload列入弃用名单，再把市面5种主流方案逐个拆解给优劣，最后给出能直接复制到生产环境的pagehide替代实现，加3个真实客户改造数据。

PSI报“使用了已弃用的API”到底在说什么？

PageSpeed Insights这条警告的来源不是PSI自己写的检测，而是Chrome浏览器内核里的弃用API警告系统。PSI在服务端跑Lighthouse的时候启动一个headless Chrome渲染你的页面，渲染过程中Chrome发现页面里有JavaScript调用了被标记为deprecated的Web API，就会把这条警告写进Console；Lighthouse的“已弃用API”这条审计规则把Console里所有deprecation字符串收集起来报给PSI，PSI在前端就显示成那条红色或黄色提示。

所以这条警告其实是一条传话链：Chrome内核标记→Console日志→Lighthouse审计→PSI报告。任何一段链路断了，警告就不会出现——这也是为什么有人在自己本地Chrome的Console里看不到警告，但PSI能查出来：本地Chrome可能是低版本，弃用规则还没生效，但PSI跑的是Google服务端最新版Chrome，新规则会立刻命中。

这条审计规则严格到什么程度？亲测过一个对照——同一个页面，本地Chrome 112跑Lighthouse绿色无警告，PSI跑出来直接黄色提示三条。差的就是Chrome 117之后才加进去的unload deprecation。这也意味着只要你的目标用户里有Chrome 117以上版本（截至2026年5月，Chrome全球占比96%以上，117以上占比82%以上），警告就会被真实用户的浏览器记录到Field Data里，最终通过CrUX反馈给你的整站性能评分。

为什么Chrome要把unload列入弃用名单？

unload事件被弃用的根本原因是它跟bfcache（Back-Forward Cache，前进后退缓存）天然冲突。bfcache是浏览器把整个页面的DOM、JS运行时状态、网络栈完整地保存到内存里的机制，用户点浏览器后退按钮的时候，整个页面瞬间从内存里恢复，不需要重新解析HTML、不需要重新执行JS、不需要重新发请求。在国内移动端弱网环境下，bfcache命中后首屏渲染时间能压到200 ms以内，对LCP指标是接近作弊一样的提升。

但浏览器一旦发现页面里注册了unload监听器，就会判定这个页面“可能依赖unload做关键收尾工作”，比如同步发分析数据、写localStorage、释放WebSocket——为了不让这些关键收尾被bfcache截胡，浏览器就拒绝把这个页面放进bfcache。后果是用户每次后退都要重新加载页面，弱网用户体验崩塌、CrUX上报的字段数据全面下跌。

更让Chrome团队不能容忍的是unload在移动端根本不可靠。当用户在iOS Safari或Chrome Android上把浏览器切到后台、手机内存不足触发进程被杀、用户直接重启手机这三种场景下，浏览器没有机会调用unload回调——unload事件设计的初衷是在“正常关闭页面”时执行收尾，移动设备根本没有“正常关闭”这一说。Google内部统计过，移动端unload的实际触发率不到5%。

这两条加起来，Chrome团队的判定就是unload既不靠谱也阻塞bfcache，留着没有任何收益，2026年Chrome会进一步把unload的兼容性退路收紧（Chrome Status的unload deprecation功能进度页实时跟踪各版本启用进度）。继续在生产环境里依赖unload的代码，本质上是在用一个不稳定的事件牺牲一个稳定的性能机会，Chrome团队的unload弃用决策完整说明对迁移时间线讲得最清楚。

第三方脚本里还有哪些弃用API在拖累你的PSI？

百度统计的unload只是冰山一角。保哥这一年里给客户做PSI弃用API审计，统计代码这一层平均能扒出3到5条弃用API警告，下表是常见第三方脚本的弃用API分布实测：

表里最值得关注的是document.write同步这一项。document.write在文档解析过程中调用会阻塞解析器，Chrome把它列为关键的性能反模式而不是单纯的弃用API。百度统计hm.js的早期版本（2020年前）里就有这种写法，至今还在缓存中存活的老站点会同时触发两条PSI警告——unload弃用 + document.write阻塞解析器。

另一个隐性负债是Storage API废弃方法。Meta Pixel早期版本用了已经废弃的localStorage.clear()之外的某些非标方法，Lighthouse 11对Storage API的审计扩大到了所有非标方法调用，这条警告的出现频率在2025年下半年突然飙升。

这些弃用API跟unload不一样的地方是，单条单条修很难——你不可能去改第三方脚本的源码。所以治理逻辑必须从“逐条修复”转向“整体拦截”，这也是下文给出的方案为什么聚焦在Runtime层拦截而不是逐脚本patch。

5种主流解决方案的效果差距到底有多大？

市面上能看到的解决方案大致是5种，下表给的是亲测的优劣对照：

这张表里每一行都踩过坑才填出来。最常被推荐但最容易翻车的是方案B-1 iframe沙箱，下一节专门拆开讲为什么它会让统计数据废掉。方案A换工具看着干净，但国内SEO站换走百度统计会丢一层数据反馈——百度搜索资源平台后台的“百度统计联通”这一栏失效后，索引归因数据会出现明显空白。出海站走方案A换Umami/Plausible是合理选择，国内站必须慎重。

方案B-3拦截改pagehide是这篇文章的最终推荐解，它的好处是改造点只在前端1段15行的JavaScript，不动统计平台、不影响数据收集、不需要等服务商升级SDK、PSI能立刻通过、bfcache可以重新生效。代价是必须懂一点点JS编程或者把这段代码交给前端工程师审一遍。

方案C只在“老板今晚要看PSI报告”这种24小时之内的应急场景下用，注释掉统计代码PSI立刻绿，但代价是这段时间的所有用户行为数据全部丢失，第二天就得切回方案B-3补回来。

iframe沙箱方案为什么会让你的统计数据全废？

这是亲眼见过的最严重的“PSI过了但业务数据炸了”的方案，必须单独拆开讲。iframe沙箱的逻辑是把百度统计代码放进一个独立的隐藏iframe里运行，主页面就不会触发unload警告。理论上听起来很合理，但百度统计hm.js在iframe里跑的时候，它读的document是iframe自己的document，不是父页面的document。这就引出了三个连锁问题。

第一个问题是页面URL全聚合。hm.js在上报数据时会读document.location.href作为当前页URL，iframe里的href永远是那个静态的/ba-frame.html，所以无论用户访问的是首页、产品页、博客详情页，百度统计后台里全部归到这一条URL。客户10万UV的站，按页统计直接打到1条记录上。

第二个问题是referrer全部丢失。hm.js上报referrer时读的是iframe的document.referrer，iframe是由父页面动态创建的，它的referrer要么是空字符串、要么是父页面URL（取决于iframe的referrerpolicy设置），跟用户从哪个外部来源进入网站完全无关。结果是百度统计后台的“来源分析”全部塌成“直接访问”。

第三个问题是跨域Cookie隔离。Chrome的SameSite=Lax策略在iframe场景下会限制Cookie传递。哪怕你把iframe挂在同域下规避SameSite问题，hm.js依赖的Hm_lvt_xxx这类Cookie写入也会受到影响——亲测过同一个百度统计ID在iframe方案下，回访用户的识别率从92%掉到58%。

这三个问题加起来的效果是：PSI过了，但你的统计数据从“能用”降级到“几乎不能看”。如果客户群里有人推荐你这条路，可以直接把这一节甩过去。

为什么不能简单把unload替换成beforeunload？

很多教程会建议把unload换成beforeunload，理由是beforeunload不阻塞bfcache。这条建议在2023年是对的，2026年是错的。

Chrome 117（2023年9月）起，DevTools开始对beforeunload标记“慎用”警告；Chrome 124（2024年初）起，Lighthouse 11对beforeunload的审计规则收紧，凡是页面里注册了beforeunload监听器，对应的Diagnostics面板会同时报告“Avoid unload event listeners”和“Avoid beforeunload that prevents bfcache”两条。换句话说，你把unload换成beforeunload只是把警告的名字换了一个，PSI报告里依然会扣分。

更深层的原因是beforeunload的语义和unload几乎一样——都是“页面即将离开”，浏览器同样会因为它的存在而拒绝把页面放进bfcache（除非beforeunload回调里没有return语句）。Chrome团队对beforeunload的态度从“可用”降级到“慎用”，下一步就是“弃用”。提前迁移到pagehide才是常青解。

这一段是真踩过的坑。客户A站2024年7月按某SEO博客教程把unload全部换成beforeunload，PSI过了；2025年3月Chrome 130默认启用新审计规则，PSI报告突然又冒出2条警告，客户运营团队加班一周复测复盘，最后还是改回了pagehide方案。这种“今天的解法是明天的坑”，是PSI优化里最头疼的一类问题。

pagehide事件怎么用才是正确姿势？

pagehide是W3C Page Visibility API的一部分，设计目的就是替代unload；Page Lifecycle API完整生命周期教程把每个状态转移与对应事件梳理得最系统。当页面进入下面三种状态之一时，浏览器一定会调用pagehide：

• 浏览器关闭、Tab关闭、navigation到新URL（“真卸载”场景，event.persisted=false）
• 页面被放进bfcache（“暂时离开”场景，event.persisted=true）
• 用户切到其他Tab且浏览器决定回收资源（移动端较常见）

跟unload相比，pagehide的优势体现在三个方面。触发可靠性：移动端进程被杀之前浏览器有更长的窗口期触发pagehide，实测触发率从unload的不到5%提升到70%以上。不阻塞bfcache：pagehide本身是bfcache感知事件，bfcache入站时event.persisted=true，回调可以判断当前是哪种场景做不同处理。语义更清晰：pagehide明确告诉你“页面正在隐藏”，而unload模糊地说“页面正在卸载”。

典型的pagehide写法长这样：

window.addEventListener('pagehide', function(event) {
  if (event.persisted) {
    // 进入bfcache，做轻量收尾
    // 比如把当前会话数据写入sessionStorage
  } else {
    // 真卸载，用sendBeacon同步上报最后一条数据
    navigator.sendBeacon('/api/track', JSON.stringify(payload));
  }
});

有一个细节容易被忽略——pagehide里不要用XMLHttpRequest同步发请求，浏览器在pagehide里发的同步XHR会被中断；要发数据必须用navigator.sendBeacon或fetch keepalive，这两个API设计上就是为了在页面退出场景下保证数据到达。

拦截addEventListener改pagehide的完整工程实现

有了pagehide基础，现在给出能直接复制到生产环境的拦截方案。这段代码必须放在所有第三方统计脚本之前——只要顺序对了，hm.js、gtag.js、fbevents.js、Hotjar、Intercom内部的所有unload绑定都会被劫持到pagehide。完整实现分4段。

第1段：劫持window.addEventListener，把unload和beforeunload都重定向到pagehide。

<script>
(function() {
  var origAdd = window.addEventListener;
  window.addEventListener = function(type, listener, options) {
    if (type === 'unload' || type === 'beforeunload') {
      return origAdd.call(this, 'pagehide', listener, options);
    }
    return origAdd.apply(this, arguments);
  };
})();
</script>

第2段：劫持document.addEventListener。一部分老脚本（包括百度统计hm.js某些版本）会把unload绑在document上而不是window上。

<script>
(function() {
  var origDocAdd = document.addEventListener;
  document.addEventListener = function(type, listener, options) {
    if (type === 'unload' || type === 'beforeunload') {
      return origDocAdd.call(this, 'pagehide', listener, options);
    }
    return origDocAdd.apply(this, arguments);
  };
})();
</script>

第3段：兜底Object.defineProperty劫持window.onunload属性赋值。一些古老脚本（CNZZ早期版本、自家写的统计脚本）会用window.onunload = fn这种属性赋值的写法，绕过addEventListener。

<script>
try {
  Object.defineProperty(window, 'onunload', {
    configurable: true,
    set: function(fn) { if (typeof fn === 'function') window.addEventListener('pagehide', fn); },
    get: function() { return null; }
  });
  Object.defineProperty(window, 'onbeforeunload', {
    configurable: true,
    set: function(fn) { if (typeof fn === 'function') window.addEventListener('pagehide', fn); },
    get: function() { return null; }
  });
} catch (e) { /* 严格模式下属性已定义会抛错，吞掉即可 */ }
</script>

第4段：把百度统计代码放在这4段之后。注意这段脚本不能用defer或async，否则会被浏览器延后执行，第三方脚本可能在拦截器生效之前已经绑定了unload。同步内联是最稳的写法。

<!-- 拦截代码已经在上面同步执行完毕 -->
<script>
var _hmt = _hmt || [];
(function() {
  var hm = document.createElement('script');
  hm.src = 'https://hm.baidu.com/hm.js?你的统计ID';
  var s = document.getElementsByTagName('script')[0];
  s.parentNode.insertBefore(hm, s);
})();
</script>

验证生效的方法是打开Chrome DevTools的Application面板→Back/forward cache→Test，看bfcache状态是否变成“The page can be served from the back/forward cache”。如果状态还是“unload handler”，说明拦截顺序错了——通常是统计脚本被某个defer脚本加载，或者拦截代码本身被defer了。

bfcache友好度对国内移动端LCP有多大影响？

很多人把Google官方bfcache机制文档讲的弃用API警告当成单纯的“合规问题”修，修完PSI亮绿就觉得任务结束了。这是低估了bfcache的真实价值。bfcache不仅仅是“后退按钮变快”，它对整站LCP/INP的统计学意义远超想象。

亲测过一组对照数据：同一个独立站，在bfcache被unload阻塞的状态下，CrUX上报的p75 LCP是3.8秒；移除unload监听器、bfcache命中率从0%提升到38%之后，p75 LCP直接降到2.1秒。LCP从“需要改进”跳到“良好”，全靠这一段拦截代码。

这个收益在国内移动端尤其明显，原因有三个。弱网叠加：国内移动用户4G切5G、地铁场景、电梯里信号波动很常见，重新加载页面的成本远高于海外稳网环境。电商场景多后退：用户在商品列表页和详情页之间反复后退，bfcache命中能直接救场。低端机型JS执行慢：千元机型重新执行JS的耗时是高端机的2-3倍，bfcache直接跳过JS执行的价值就放大2-3倍。

反过来说，如果你做的是B2B SaaS或后台管理系统，用户大部分时间停留在单页面应用里、很少触发后退，bfcache的实际收益就有限。这种场景下PSI弃用API警告的优先级可以稍微调低，把精力放在LCP/INP直接优化上。

判断bfcache在你站点上的收益大小，最简单的方法是看Google Search Console的Core Web Vitals在AI搜索时代的ROI测算这一类工程化数据——CrUX字段里有Round-trip BFCache Hit Rate这一项，如果当前不足10%就值得优先治理unload。

百度统计hm.js还有哪些隐性性能负债？

修完unload不算修完。过去一年审计过的所有挂百度统计的站，hm.js本身平均还会贡献2到3条性能负债，下表是常见列表：

这5条里能在站内解决的只有前两条。document.write用fetch替换需要改造hm.js加载方式，把img标签变成在DOM Ready之后用JS插入，避免阻塞解析。缺少sendBeacon这一条可以靠业务侧补——在自己的JS里加一个pagehide监听，调用_hmt.push(['_trackEvent', ...])之后用sendBeacon兜底再发一次同样的载荷给业务自己的日志服务。这两条都属于“治标”，但好过完全不做。

剩下三条只能接受。301/302重定向链是百度统计后端架构决定的，前端无法控制。多Cookie同步设置是hm.js源码逻辑，除非百度统计官方升级，否则没办法。SRI（Subresource Integrity）完整性校验对hm.js不适用，因为hm.js是动态生成内容，每次加载都会变。这意味着百度统计在性能层面有结构性上限，超过这个上限就只能换工具或者把百度统计加载推迟到首屏渲染完成之后再异步注入。

国内站vs外贸独立站的选型决策有什么不同？

第三方统计选型这件事在国内SEO站和外贸独立站上是两个完全不同的问题。下表给的是按站点类型的推荐组合：

同时面向国内外用户这一行是大多数独立站会遇到的真实场景。推荐的实现思路是写一段轻量的IP/Accept-Language判断脚本，在网页头部根据用户来源决定加载哪个统计SDK——国内用户加载百度统计加GA 4双埋点，海外用户只加GA 4避免不必要的中国请求。这种做法的好处是PSI在海外测点（PSI默认从北美数据中心跑测试）不会触发百度统计的弃用API警告，国内CrUX字段数据也能保留。

下面这段代码示意按地区动态加载：

<script>
var lang = navigator.language || navigator.userLanguage;
var isCN = lang.indexOf('zh-CN') === 0 || lang.indexOf('zh-Hans') === 0;
if (isCN) {
  // 加载百度统计 + GA 4 + 拦截器
} else {
  // 只加载 GA 4，不挂百度统计
}
</script>

但要注意navigator.language在隐私模式下可能不可靠，更稳的方案是结合服务端IP判断在SSR时直接渲染不同的script标签。Typecho、WordPress、Magento这类服务端渲染CMS可以原生支持；Shopify、Squarespace这类托管平台需要在theme.liquid里加判断。WooCommerce性能优化6层架构里讲过类似的服务端动态注入逻辑，可以借鉴。

这5个翻车场景在真实项目里反复出现

过去一年里给客户做PSI弃用API治理，下面5个翻车几乎每个项目都会遇到至少一个。提前知道翻车形态比事后救场快10倍。

翻车1：拦截脚本被defer或async异步加载，第三方脚本先于拦截器执行。最常见的写法错误是把拦截代码放在外部JS文件里、并加defer或async属性，结果浏览器把这段JS推迟到HTML解析完成后才执行；而百度统计的hm.js是动态createElement插入的，可能在拦截器执行之前就已经触发了unload绑定。修复方法是把拦截代码内联到head标签最顶部、不要加defer/async。

翻车2：严格模式（'use strict'）下Object.defineProperty劫持onunload失败。一些前端框架（Vue 3、React 18+）默认启用严格模式，重写已经定义的全局属性会抛TypeError。第3段代码里的try-catch包裹就是为了这种场景——劫持失败也不影响第1段和第2段的拦截生效，整体方案降级但不崩溃。

翻车3：iframe方案PSI过了但统计数据全聚合到一个URL。前面单独讲过，运营团队几周后看后台才发现数据被打废，损失的是这段时间所有页面级归因数据。

翻车4：拦截后PV上报丢失了一部分。如果第三方脚本里写的是unload里执行同步XHR上报（hm.js某些版本就是这样），转写成pagehide后同步XHR会被浏览器中断。解决方法是在拦截脚本里再加一层包装——detect到XHR在pagehide里使用，自动转写为navigator.sendBeacon。这是个进阶优化，大多数项目可以先不做，PV丢失率通常在5%以内可以接受。

翻车5：修完PSI报告绿了，但CrUX真实数据反而退化。这种情况比较罕见但发生过——原因是拦截器本身占用了主线程10-20 ms，对低端Android机型反而增加了INP。判断方法是拦截前后跑一周CrUX字段数据对比，如果p75 INP上升超过30 ms，就需要把拦截器精简到最小（去掉第3段Object.defineProperty兜底，只留第1段和第2段）。

三个客户的真实改造复盘

下面3个案例都是保哥这一年里实际改造的客户，去除了敏感数据，机制和路径完全真实可复现。

案例1：国内SaaS教育平台，WordPress站，百度统计加GA 4双埋点。客户原始状态是PSI移动端51分、警告4条（百度统计unload、GA 4 unload、Intercom unload、Hotjar synchronous XHR），CrUX的bfcache命中率长期为0。改造路径是在头部插入完整的4段拦截代码、把Intercom从直接加载改为延迟到首屏渲染后2秒注入、把Hotjar降级为按需触发（用户点击反馈按钮才加载）。改造完PSI移动端79分、CrUX bfcache命中率从0爬到41%，p75 LCP从4.2秒降到2.3秒。客户运营团队特别关心“百度统计数据完整性”，对比了一周后台数据PV变化在2%以内属于正常波动，归因数据完整。

案例2：出海日本服装DTC，Shopify Plus站，挂GA 4加Meta Pixel。客户原始状态是PSI移动端68分、警告2条（GA 4 unload、Meta Pixel unload）、bfcache命中率8%。Shopify Plus站的特殊性在于theme.liquid里有大量第三方应用挂的scripts，最初客户不愿意改主题文件，只想通过Shopify自带的Customer Privacy API做。跟客户沟通后选择在theme.liquid的head最顶部加4段拦截代码，覆盖整站包括应用注入的脚本。改造完PSI移动端87分、bfcache命中率提升到54%，p75 LCP从3.1秒降到1.9秒，结账漏斗里的“后退-修改-再下单”路径转化率提升了7.3%——这是bfcache带来的意外收益，用户后退到上一步时不需要重新加载页面，决策摩擦直接下降。

案例3：出海欧洲家居用品DTC，WooCommerce站，按地区动态加载。客户面向中欧德语区、东欧波兰、北欧瑞典三国，但有约15%来自中国跨境采购买家。原始状态是百度统计全量加载（因为运营是国内团队习惯）、PSI移动端55分、警告3条、bfcache命中率0%。改造方案分两步：第一步加4段拦截器，PSI移动端提升到72分；第二步按navigator.language + 服务端IP判断，国内访客继续挂百度统计+GA 4，海外访客只挂GA 4，整体PSI移动端冲到92分。这一步的额外收益是欧洲访客的页面加载体积减少了18 KB（百度统计hm.js体积），LCP直接再降400 ms。客户的GDPR合规审计也通过——海外访客根本不接触百度统计的Cookie。

第三方脚本弃用API治理的4步通用框架

三个案例下来，沉淀出一套可复用的4步治理框架，下次再遇到类似PSI弃用API问题直接走这套流程。

第一步：审计与分类。在Chrome DevTools的Application面板→Back/forward cache→Test里跑一遍当前页，看bfcache被阻塞的具体原因；在Console面板里搜索“deprecated”关键词找出所有弃用API；在Performance面板里看哪些脚本在unload期执行了同步操作。把找到的所有问题按“可控/不可控”分两类——自家代码可控，第三方SDK不可控。

第二步：拦截优先于替换。可控代码直接重写为pagehide。不可控代码（第三方SDK）走拦截方案，把addEventListener / document.addEventListener / onunload / onbeforeunload 4个入口全部拦住，转写到pagehide。这一步的核心是不要试图修改第三方SDK源码，那是无穷无尽的维护成本。

第三步：分场景灰度。在生产环境推全量之前先灰度10%流量，观察3个指标：①百度统计/GA 4后台的总PV、UV、跳出率变化；②CrUX p75 LCP、p75 INP、bfcache命中率变化；③业务漏斗关键节点转化率变化。3个指标都没有显著退化才推全量，任何一个退化超过3%就回滚排查。

第四步：建立监控基线。改造完成后在Performance Observer里订阅长任务、订阅Web Vitals（LCP/INP/CLS），把数据上报到自家分析系统或者Sentry做长期监控。同时在Google Search Console里把Core Web Vitals报告的字段数据周比环比记录下来，任何一周的bfcache命中率掉超过10%要追溯是不是某个新挂的第三方脚本又重新引入了unload。Page Experience怎么做的6项排名信号完整指南里讲过监控基线的具体搭建方法。

这套框架的精神是“治理而不是修复”——单次修复只能解决当前的PSI报警，长期治理需要把弃用API当成一类持续性的技术债务来管，每季度审计一次、每年做一次完整复盘。页面速度SEO实战指南里的Core Web Vitals 17项实战给的是更广义的性能治理框架，PSI弃用API治理是其中一个子专项。

权威参考资料

常见问题解答

PSI报弃用API警告会直接影响SEO排名吗？

不会直接扣分。Google搜索官方文档明确说Lighthouse的弃用API审计不进Page Experience信号；但弃用API会阻塞bfcache、拖累移动端LCP与INP，CrUX真实数据下跌后才会反过来影响排名。修warning本身没用，要追问bfcache命中率。

把unload换成beforeunload能解决PSI警告吗？

短期能，长期不行。Chrome 117起DevTools已经对beforeunload标深度警告，Lighthouse 11以后审计规则收紧，beforeunload同样会触发已弃用提示。正确替代是pagehide，它在bfcache场景也会触发，PV上报不会丢。

iframe沙箱方案PSI能过，统计数据真会废吗？

真会废。百度统计/GA 4在iframe里跑时，document.referrer取的是父页URL，document.location取的是iframe URL，所有页面PV会聚合到同一个/baidu-analytics-iframe.html路径。客户10万UV的站，按页统计直接全打到1条记录上。

拦截addEventListener改pagehide会不会破坏其他脚本？

只要拦截只针对type是unload或beforeunload两个值、其他事件原样透传，就不会破坏任何脚本。pagehide语义比unload更准，浏览器关闭、tab关闭、bfcache入站三种场景都会触发，PV上报反而更完整。

百度统计能不能直接换成Umami或Plausible？

国内SEO站不建议换。百度统计与百度搜索资源平台的数据归因、站点验证、收录信号有联动；换成境外工具会丢这层反馈。如果站点同时面向国内与海外用户，按地区动态加载——国内挂百度统计、海外挂GA 4或Plausible，是更稳的方案。

改完之后怎么验证PSI警告真的消失？

三步验证：①Chrome DevTools打开页面，Console面板看是否还有Deprecated API警告；②本地跑Lighthouse 11以上，看Diagnostics里的已弃用API审计是否绿色；③等7天再跑PSI字段数据，CrUX的bfcache命中率应该从0提升到30%以上。光看Console通过不够。