Lighthouse PWA 审计

一句话： 据 Chrome for Developers，Lighthouse 是一个开源的自动化工具，它针对给定 URL 运行一系列审计并生成报告，涵盖性能、无障碍、SEO 等方面。其 PWA 类别已不再是报告的一部分： 据 Chrome 关于重新审视可安装性标准的博文，Lighthouse 的 PWA 检查与这些标准直接相关，因此 Chrome 决定把该类别从 Lighthouse 中移除。

支持情况

据 Chrome for Developers，你可以在 Chrome DevTools 中、从命令行、作为 Node 模块，或通过 网页界面运行 Lighthouse；其中 CLI 与 Node 两种方式要求你的机器上已安装 Google Chrome。 在 DevTools 中，Lighthouse 有自己的面板：打开要审计的页面，切换到 Lighthouse 标签页， 然后运行审计。

从命令行运行一次审计

据 Chrome for Developers，Node 模块通过 -g 标志以全局方式安装，然后指向一个 URL；lighthouse --help 会列出全部选项：

npm install -g lighthouse
lighthouse https://example.com
lighthouse --help

据 Chrome for Developers，你还可以使用 Lighthouse CI 来防止站点出现回归。

改为在页面内检测可安装性

PWA 类别消失后，浏览器认为页面可安装的运行时信号是 beforeinstallprompt 事件。据 MDN， 该事件在浏览器检测到网站可以作为 Progressive Web App 安装时触发；典型用法是显示你自己的 应用内安装界面——据 MDN，该界面应默认隐藏，因为并非所有浏览器都支持安装。据 MDN，处理函数 会保留对 BeforeInstallPromptEvent 的引用，并在用户操作该界面时调用它的 prompt() 方法：

const installButton = document.querySelector('#install');

if ('onbeforeinstallprompt' in window) {
  window.addEventListener('beforeinstallprompt', (event) => {
    installButton.hidden = false;
    installButton.addEventListener('click', () => event.prompt(), { once: true });
  });
} else {
  // 不支持该事件：保持应用内安装界面隐藏，由浏览器自行提供它已有的安装方式。
  installButton.hidden = true;
}

实践清单

• 不要把工作流建立在 PWA 审计之上。 据 Lighthouse 审计参考文档，Lighthouse 中的 PWA 测试已废弃；据 Chrome 博文，该类别已被移除——你记忆中旧报告里的分数，当前工具不再产出。
• 改用 DevTools 检查可安装性。 据 Chrome 博文，针对可安装体验的优化与调试检查仍然可以 在 DevTools 中找到。
• 旧的 Service Worker 要求已经变化。 据 Chrome 博文，Chrome 已移除“从菜单安装需要一个 实现了 fetch() 的 Service Worker”这一要求，移动端自 108 版、桌面端自 112 版起生效；该 博文同时说明，在撰写时，显示安装提示的算法仍然要求存在 fetch() 处理函数。因此“没有 fetch 处理函数就不能安装”这一旧印象，对菜单安装路径已不再准确。
• Service Worker 依然重要。 据 Chrome 博文，它仍是核心 Web 技术，对良好的缓存策略、 通知和自定义离线体验等都是必要的——标准变化不是删掉它的理由。
• beforeinstallprompt 不是可移植的检测手段。 据 MDN，它的可用性有限，并非 Baseline， 因此应把它的缺失理解为“该浏览器不提供这个钩子”，而不是“该页面不可安装”。
• CLI 需要一个浏览器。 据 Chrome for Developers，CLI 与 Node 方式要求你的机器上已经 安装了 Google Chrome 实例。

下一步

• 可安装性标准 —— 浏览器在提供安装 之前究竟要求什么。
• 安装提示 —— 上面这个事件的独立参考条目。
• Core Web Vitals —— 本站另一篇独立的性能 参考条目。