火狐浏览器网页加载瞬间CPU飙升90%以上，源于AI模块首帧抢占、未休眠脚本抢跑、WebRender GPU同步死锁或高负载扩展提前注入；需立即禁用browser.ml.chat.enabled和browser.tabs.groups.smart.enabled、启用后台休眠参数、关闭硬件加速并切换至Skia渲染、通过about:processes定位并禁用首帧高负载扩展。
火狐浏览器在网页刚加载的瞬间CPU占用突然冲到90%以上，页面卡顿、鼠标延迟、风扇立刻起转，根本不是缓慢爬升，而是毫秒级爆发——这通常不是网站本身问题，而是Firefox在首帧渲染前强行启动AI推理、执行未休眠脚本、或触发GPU同步死锁导致的瞬时计算洪峰。
立即切断AI模块的首帧抢占
Firefox 138+版本会在每个新标签页打开的第一毫秒就调用本地大模型做上下文预判，哪怕你从没点过AI按钮。这个操作独占一个物理核心，直接压爆CPU调度器。
第一步：地址栏输入 about:config → 回车 → 点击“我接受风险并继续”。
第二步：搜索 browser.ml.chat.enabled → 双击设为 false。
第三步：再搜索 browser.tabs.groups.smart.enabled → 同样双击设为 false。
第四步：关闭所有Firefox窗口 → 打开任务管理器 → 结束全部 firefox.exe 进程 → 重新启动浏览器。【不彻底退出进程，AI线程仍驻留内存，首帧抢占照旧】
阻止后台脚本在加载前就抢跑
很多广告监测脚本、分析SDK、甚至某些CDN优化器，会在DOM树还没构建完时就用 setTimeout(0) 或 requestIdleCallback 强行插入执行队列，造成CPU在页面真正开始渲染前就被填满。
方法一：启用强制标签页休眠开关（底层生效）
在 about:config 中搜索：
→ browser.tabs.unloadOnLowMemory 设为 true
→ browser.tabs.disableBackgroundZombieTabs 设为 true
→ dom.ipc.processCount.webIsolated 右键修改为整数 2（4核以下CPU适用）
方法二：禁用标签页预热（图形界面快捷操作）
菜单 → “设置” → 左侧选“标签页” → 关闭“在后台预加载已打开的标签页”选项。
绕过WebRender首帧GPU同步陷阱
当显卡驱动未正确暴露D3D11 Video Decoder或VA-API接口时，Firefox会在页面加载第一帧时反复尝试提交GPU解码指令，却收不到确认响应，形成CPU单核100%空转循环——这不是慢，是死锁。
第一步：菜单 → “设置” → “常规” → 滚动到底部点“性能”。
第二步：取消勾选“使用推荐的性能设置”，展开全部选项。
第三步：取消勾选“使用硬件加速” → 点击右下角“确定”保存。
第四步：地址栏输入 about:support → 点击“在疑难解答模式中重启” → 刷新后检查“Compositing”是否显示为“Skia”或“Basic”。若仍是“WebRender”，说明驱动未更新，需先升级显卡驱动。
第五步：若用Intel UHD 620/630等核显，必须在 about:config 中搜索 media.ffvpx.enabled → 双击设为 false ——否则Firefox会绕过系统GPU解码器，强行用CPU软解AV1/VP9帧，首帧即满载。
定位并干掉首帧高负载扩展
某些扩展（如旧版uBlock Origin、Tampermonkey含未优化脚本、Bitwarden自动填充逻辑）会在页面 document.readyState === "loading" 阶段就注入DOM监听器，比浏览器原生解析还早一步抢占CPU。
第一步：地址栏输入 about:processes → 打开内置进程监控器。
第二步：新开一个网页 → 观察“Process Type”列中“Extension”开头的进程 → 查看其“CPU %”是否在加载瞬间跳至30%以上。
第三步：记下对应扩展名称 → 返回 about:addons → 禁用该扩展 → 重新加载网页验证CPU峰值是否回落。
第四步：对多个可疑扩展重复上述操作，直到首帧CPU峰值稳定在15%以内。
