查看 serviceworker 耗时需通过 chrome devtools 的 performance 面板录制，并重点检查 network 请求与 worker 线程的交互。具体做法是开启 "record" 后触发页面加载或相关操作，停止录制后在 "main" 轨道下方找到 "serviceworker" 轨道，展开即可查看其处理生命周期事件（如 fetch、install）的具体耗时区间。
如何定位 Fetch 事件的响应延迟
定位 Fetch 事件延迟主要关注 Performance 面板中 Network 请求与 ServiceWorker 执行时间的重叠部分。开发者应检查 Network 标签页中对应请求的 "Waterfall" 列，若 "Waiting for ServiceWorker" 时间占比高，说明 Worker 处理逻辑阻塞了网络响应。此时需切换到 Performance 面板，定位到该请求对应的 Fetch 事件区间，分析内部脚本执行耗时。
const swCode = `
self.addEventListener('fetch', event => {
const start = performance.now();
// 模拟耗时操作
new Promise(resolve => setTimeout(resolve, 500)).then(() => {
console.log('SW fetch took: ' + (performance.now() - start));
return caches.match(event.request);
});
});
`;
// 注册 SW 后观察 Performance 面板
Install 阶段资源预取对启动时间的影响
Install 阶段的资源预取会显著影响 ServiceWorker 的激活时间和首次加载体验。如果缓存策略配置不当，大量资源的下载和解析会在 Install 事件中同步进行，导致主线程阻塞或网络带宽竞争。开发者需监控 Install 事件的持续时间，确保关键路径资源不被过度预取，避免延长用户等待时间。
设置基于 systemd 的看门狗，使 Node.js 长运行服务（如 Telegram 机器人、Express 仪表盘等）在 shell 退出、SSH 断开等情况下保持运行。
const installAssets = [
'/index.html',
'/styles/main.css',
'/scripts/app.js',
'/images/logo.png'
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open('v1').then(cache => cache.addAll(installAssets))
);
});
// 观察 Performance 面板中 Install 事件的总耗时
ServiceWorker 线程空闲时是否消耗 CPU
ServiceWorker 线程在非活跃状态下几乎不消耗 CPU 资源，仅在处理特定事件（如 push、sync、fetch）时被唤醒。当没有待处理的任务时，浏览器会将 ServiceWorker 挂起或终止以节省电量。开发者可通过 Performance 面板的 "CPU Usage" 图表确认，若无事件触发，ServiceWorker 相关的 CPU 峰值应为零或极低。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
