ExtendableEvent.waitUntil重试频率能否提高？PWA弱网同步方案咨询

关于Background Sync重试速率的问题 #

无法自定义提高waitUntil的重试速率。Background Sync的重试策略完全由浏览器内核控制，属于用户代理的内置规则，主流浏览器普遍采用指数退避的重试逻辑，你观察到的5分钟只是首次失败后的重试间隔，后续如果持续失败间隔还会进一步拉长，开发者没有权限修改这个间隔参数。

当前策略合理性与Background Sync的适用场景 #

你当前用Background Sync做高频同步的策略完全不合理。
Background Sync的设计定位是解决页面关闭/切后台后，离线操作的补触达问题，比如用户离线时提交的表单、上传的文件，在网络恢复后即使页面已经关闭，也能由Service Worker完成后续请求，从设计上就不是用来做高频轮询的。
它相比你直接在页面主进程调用更新函数，只有两个不可替代的优势：

• 同步任务不绑定页面生命周期，即使用户关闭了标签页，只要浏览器进程还在运行，就能完成预设的同步任务
• 浏览器自动管理网络状态判断，只有网络可用时才会触发同步事件，不需要你自行兼容网络状态监听的逻辑
  如果你的使用场景是员工仅在页面打开时需要更新待办数据，页面关闭后不需要后台刷新，那完全没必要用Background Sync，直接在主进程写同步逻辑反而更简单可控。

适配需求的替代方案 #

根据你的场景可以选择两种方案：

• 若仅页面前台运行时需要30秒同步一次：直接在主进程实现定时器逻辑即可
  • 监听navigator.onLine事件，网络可用时启动setInterval，每30秒请求一次服务端接口，拿到数据后更新IndexedDB同时触发页面视图刷新
  • 可额外增加短重试逻辑，单接口请求失败时不用等满30秒，间隔10秒即可重试，降低偶发网络波动带来的同步延迟
• 若需要页面切后台/关闭后仍要高频同步：可采用静默Web Push触发同步，由后端在有新待办数据时向客户端推送静默通知，Service Worker收到通知后直接触发数据拉取逻辑，相比轮询更省流量、实时性也更高。如果是企业内部场景可以统一管控设备权限，也可以将PWA添加到桌面并开启后台活动权限后，在Service Worker中用递归setTimeout实现定时同步，但需要注意大部分浏览器的后台节能策略会自动降频定时器，无法100%保证30秒的间隔精度。

不管采用哪种同步方案，你原本的「页面优先读取IndexedDB本地数据」的逻辑都可以保留，两者互不冲突。

内容的提问来源于stack exchange，提问作者rhoward