性能优化能力
快速优化过程
- 在一个目标浏览器上测量首次运行的行为。
- 削减 content scripts 与后台处理器中的同步启动工作。
- 把可选 UI 功能延后到初始渲染之后再加载。
- 复核构建产物的体积并冒烟测试关键流程。
Content scripts
- 让入口文件保持小巧，把非关键工作延后。
- 避免在
document_start进行重的同步 DOM 扫描。 - 对 observer 和事件监听器划定作用域；在重新挂载/卸载时清理。
- 把可复用逻辑拆到共享模块，但避免脆弱的动态 import 模式。
后台/service worker
- 启动时尽量少做事；在事件到达时再懒初始化。
- 在安全的情况下缓存稳定的计算状态。
- 避免在事件处理器中执行长时间的同步任务。
- 在活跃开发期间关注 service worker 依赖的频繁变化。
UI 界面(popup / options / 新标签页 / sidebar)
- 让初始渲染路径保持轻量。
- 按需加载较大的可选 UI 功能。
- 在本地调试会话中按需使用框架的 dev tools。
- 让样式模块化，避免巨大的全局 CSS。
资产与资源
- 按目标用途优化图标/图片大小。
- 把 web-accessible resources (WAR) 的暴露范围限制到必需的资产。
- 让 public 资产保持有意而为；移除过期文件。
- 定期检查生成的
dist/<browser>产物体积。
精简发布的内容
dist/<browser> 里的每一个字节，都是每位用户在安装时和每次更新时要下载的字节，而 content script 的资产会随它一起进入每个匹配的页面。下面说明 extension build 已经排除了什么、剩余的体积来自哪里，以及到哪里读取这个数字。
构建排除了什么。 产物从 manifest.json 出发并沿着引用走。它会发布 manifest 指名的条目(background、content script、页面、图标、locale)、这些条目导入的模块和资产，以及 public/ 下的全部内容。src/ 里没有任何东西引用的文件不会被输出。一个笔记文件、一个未使用的模块、一个 fixture 文件夹，或者图标旁边的一张多余图片，永远不会进入 dist/。你不需要为它们准备忽略列表。
public/ 与导入的资产。 这两条路径的行为不同，而这个差异正是多余字节的常见来源：
public/会原样复制到产物根目录，连同文件夹结构，并且不做任何检查。那里的过期文件也会被发布。请把这个文件夹当作你决定要发布的文件清单，并修剪它。- 从 JavaScript 导入的资产会落在
assets/<name>.<hash>.<ext>，只发布一次，而且只在导入存在时才发布。 - 从 HTML 页面引用的资产会写两份：一份在
assets/<relative path>下，一份在它的源路径上，这样脚本代码里的引用仍然可用。一个既被 HTML 页面引用又被 JavaScript 导入的文件会发布三份。请从 JavaScript 导入共享图片，或者把它移到public/并按根路径引用，这样它只会写一份。
web_accessible_resources 的范围。 在 Manifest V3 上，构建会在你所有 content script 的 matches 并集之下，把两类文件加入 web_accessible_resources：content script 通过 import() 加载的每个 chunk，以及 assets/ 下每个非脚本文件，无论是哪个页面或脚本把它放在那里的。从 public/ 复制的文件不会被加入。由此有两个结论。让 matches 保持在功能允许的最窄范围。把只给页面用的图片放在 assets/ 之外(从 public/ 按根路径引用它们)，这样 content script 的 matches 就不会暴露它们。参见让网页能读取扩展文件。
读取体积。 extension build 会打印产物的树形结构及每个文件的大小，并以总计收尾：
--zip 时，第二行会给出压缩包的名字和压缩后的大小。压缩包只包含 dist/<browser> 的内容，别无其他，位于 dist/<name>-<version>-<browser>.zip，其中 name 是 manifest 的 name 转为小写并去掉标点：
extension build --output json 会返回 total_bytes、largest_asset_bytes 以及 zip_artifacts 中每一项的大小，同样的摘要还会写到 dist/extension-js/<browser>/build-summary.json。在 CI 里跨提交比较 total_bytes，就能在商店审核发现之前抓住体积回归。参见 build。
性能预算
当某个 bundle 超出其分类的体积预算时，生产构建(build) 会输出警告。预算仅为警告(它们绝不会让构建失败)，并在生产模式下默认启用。
在
extension.config.js 中通过 perfBudgets 覆盖任一分类(值以字节计)：
运维检查
- 在 CI 中运行多浏览器构建检查。
- 跟踪端到端 (E2E) 运行时长随时间变化的回归信号。
- 为关键扩展流程(安装、打开 UI、content script 激活) 添加冒烟测试。
常见的性能陷阱
- 大量 content-script bundle 在每个匹配页面上加载
- 没有守卫条件就在
document_start做重活 - service worker 处理器进行非必要的同步初始化
- 即便只使用部分功能，UI 仍发布了庞大的全局 CSS/JS
下一步
- 查阅 Playwright E2E。
- 查阅安全检查清单。