我公司的网站主要是服务器呈现（我们使用Structured Page Fragments），但我们想研究构建一个渐进式网页应用程序。
通过为服务器呈现的页面实现服务工作者缓存来构建Progressive Web App是否有意义？或者，我们是否应该探索转向客户端渲染？
请注意，我们希望尽可能多地在服务器上进行渲染，因为我们支持许多非常慢的设备。
答案 0 :(得分：2)
是的，服务工作者绝对不限于客户端呈现。
您可以缓存任何您想要的内容。例如，this WordPress plugin缓存WordPress内容。
答案 1 :(得分：2)
服务器呈现的网页暗示您的网站上存在某种程度的动态或个性化内容 - 否则，您只是在提供静态HTML。
我建议您从在线和离线时处理动态内容的角度来考虑它。通过Jake Archibald的Offline Cookbook阅读，可以很好地概述可以实施的不同策略。
为动态内容设置缓存策略后，下一步就是实现它。 “黄金标准”方法是使用App Shell + dynamic content architecture，但可能需要进行一些重构才能将现有应用程序放到此体系结构中，尤其是服务器返回的初始HTML包含动态/个性化元素的应用程序。
如果重构过于艰巨的任务，或者仅服务器渲染是一项艰难的要求，那么你仍然可以使用服务工作者缓存，但你可能最终会像对待它一样对待你想要的shell是动态内容。这意味着纯缓存优先策略可能不是“安全”，但cache/network race可能有效，或者至少network, falling back to cache。
使用这两种策略，您最终会得到一个可以离线工作的网络应用，但您可能最终会缓存重复数据（例如，如果/page1和/page2分享一些共同点HTML结构，你最终会缓存两次）。您还需要一个性能和带宽消耗，因为您必须比使用App Shell更频繁地访问网络，但这可以通过适当的HTTP浏览器缓存标头来减轻。 （无论如何，对于缺乏服务工作者支持的浏览器，您应该考虑哪些。）