Safari 现在支持 Service Workers：这意味着什么（至少对我而言）

苹果最新的发布说明表明了他们对 Service Workers 的支持。

Safari 11.1 的亮点

• 服务工作者。为离线 Web 应用程序和更快的网页执行后台脚本。
• 付款请求。使用基于标准的 API 在 Safari 中提供一致的用户付款体验。
• 安全改进。增强了对内存损坏和代码执行攻击的防护。
• Web Inspector 更新。网络选项卡和元素选项卡中样式侧栏的全新设计。

Service Worker API 充当浏览器的网络代理，使 Web 开发者能够更好地控制请求。这意味着在糟糕的网络条件下也能获得更好的体验，并且开发者可以访问某些应用架构概念，从而改善所有条件下的用户体验。

Safari 的支持将极大地改善“Can I Use ”的统计数据。这对我和我的团队来说意味着，我们可以更加自信地投入更多时间和精力，开始使用 Service Workers。我们仍然需要构建能够逐步增强现有浏览器功能的应用程序，但现在我们可以证明这种额外的复杂性是合理的。对于一些团队来说，他们本可以更早地做到这一点，但在我看来，在主流浏览器支持之前，Service Workers 必须被视为更具实验性。

App Shell 架构

Service Workers 支持的一种应用设计被称为App Shell 架构，其中网页的布局和复用资源会被缓存以供重复使用，而网络请求则更侧重于传递的数据，以便将页面内容作为二次请求进行渲染。类似的页面构建方案在 Web 开发领域已经相当流行，但在我看来，如果没有这个缓存层，它们未必是一个好的选择。如果您无法缓存 Shell，我真不建议仅仅为了渲染第一个内容而进行如此多次的调用。您需要的是更低的延迟，而不是更高的延迟。

我们目前还没有使用这种架构，所以这次 Safari 更新非常重要。我认为它帮助我们克服了困难，让我们能够将这些想法放在首位。它为我们提供了足够的浏览器支持，让我们能够构建可在用户设备上（无论是桌面设备还是移动设备）存储页面布局的路径。

我们当然是网页优先的，目前还没有原生的dev.to选项，我不想本末倒置，但这或许能给我们一个借口，让我们在移动端也暂时保持完全网页化。但我不想在这个方向上投入太多。如果强大的浏览器 API 能够提升用户体验，那么只开发一个应用程序的开发优势就非常显著了。

边缘逻辑

我们的应用程序已经通过 CDN Fastly在边缘使用了网络逻辑，而借助 Service Workers 则为我们提供了额外的边缘层。从未被 Service Workers 处理过的请求仍然有可能在边缘节点得到处理。

如果您居住在新西兰，我们并不指望您为了内容而长途跋涉来到犹他州。Service Worker 意味着大部分 HTML（当然还有其他资源）可以保留在您的浏览器中，这样您下次访问时就能更快地看到布局，并减少传输的字节数。我们仍然希望在没有 Service Worker 的情况下提供同样清晰的加载速度，但我们拥有相应的工具，可以为稳定用户提供真正良好的整体网络体验。

感谢苹果

这一举措或许能缓解Safari 带来的一些痛点。我很高兴我们尝试了 Service Workers，现在不仅赶上了，也庆幸一年前我们没有一头扎进去，最终只为了维护更复杂的跨浏览器兼容性而只支持了三分之二的功能。

编码快乐❤️