基于sw-toolbox的Service Worker缓存后CSS响应耗时过长原因咨询

这是个很值得深究的问题，结合我使用sw-toolbox做Service Worker开发的经验，总结几个可能的原因：

• CSS的渲染阻塞特性导致统计差异
  浏览器对CSS的处理是阻塞渲染的，当Service Worker返回缓存的CSS资源后，浏览器会立刻启动CSS解析、构建CSSOM，再结合DOM生成渲染树——这些同步执行的步骤都会被计入CSS的“加载耗时”统计中。而JS如果是异步加载（比如用async/defer属性），资源获取完成后并不会立即执行，后续的解析执行会被延后，所以统计到的“加载耗时”仅包含缓存读取和传输的时间，自然接近0。

• 缓存策略配置差异
  检查下你给CSS和JS设置的sw-toolbox缓存策略是否一致：

  • 如果CSS用了staleWhileRevalidate或networkFirst策略，即使缓存命中，Service Worker也会在后台发起缓存校验请求（哪怕不会更新缓存），这个后台请求的开销会被算进处理耗时；
  • 若JS用的是cacheFirst且完全命中缓存，没有额外的网络校验步骤，耗时就会几乎为0。
    另外，缓存存储位置也有影响：JS可能被存在内存缓存中，读取速度极快；而CSS可能被存在磁盘缓存，读取时的IO耗时会拉高总耗时。

• 资源本身的特性差异

  • 看看CSS文件是否比JS文件大很多？或者未开启gzip/brotli压缩？sw-toolbox从缓存读取并传输更大的文件到主线程，耗时会明显增加；
  • 如果CSS中包含@import同步引入其他资源，浏览器在解析主CSS时还要处理这些依赖，这部分额外耗时也会被计入当前CSS的加载统计，而JS通常没有这类同步依赖。

• Service Worker线程的调度优先级
  Service Worker运行在独立线程，浏览器会给CSS请求更高的优先级，所以Service Worker会优先处理CSS请求，但如果此时线程有其他待处理任务，可能会产生轻微调度延迟；而JS请求优先级较低，可能在空闲时处理，但因为缓存读取本身很快，所以耗时显示为0。不过这个因素通常是和前面几点共同作用才会产生明显的耗时差异。

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