我公司的网站主要是服务器渲染的(我们使用了一些结构化页面片段),但我们想研究构建一个渐进式 Web 应用程序。
通过为服务器呈现的页面实现服务工作者缓存来构建渐进式 Web 应用程序是否有意义?或者,我们是否应该探索转向客户端渲染?
请注意,我们希望在服务器上进行尽可能多的渲染,因为我们支持许多非常慢的设备。
我公司的网站主要是服务器渲染的(我们使用了一些结构化页面片段),但我们想研究构建一个渐进式 Web 应用程序。
通过为服务器呈现的页面实现服务工作者缓存来构建渐进式 Web 应用程序是否有意义?或者,我们是否应该探索转向客户端渲染?
请注意,我们希望在服务器上进行尽可能多的渲染,因为我们支持许多非常慢的设备。
服务器呈现的页面意味着您的网站上有某种程度的动态或个性化内容——否则,您只会提供静态 HTML。
我鼓励您从在线和离线时如何处理动态内容的角度开始考虑它。通读 Jake Archibald 的离线食谱将使您对可以实施的不同策略有一个很好的概述。
为动态内容设置缓存策略后,下一步就是实施它。“黄金标准”方法是使用App Shell + 动态内容架构,但可能需要进行一些重构才能将现有应用程序放到此架构上,尤其是服务器返回的初始 HTML 包含动态/个性化元素的应用程序。
如果重构任务太艰巨,或者如果仅服务器渲染是一项硬性要求,那么您仍然可以使用服务工作者缓存,但您最终可能会将您的潜在外壳视为动态内容. 这意味着纯粹的缓存优先策略可能不是“安全的”,但缓存/网络竞争可能会起作用,或者至少是网络,回退到缓存。
使用这两种策略,您最终会得到一个可以离线工作的网络应用程序,但您最终可能会缓存重复的数据(即,如果/page1
并/page2
共享一些常见的 HTML 结构,您最终会缓存两次)。您还会受到性能和带宽消耗的影响,因为您必须比使用 App Shell 更频繁地访问网络,但这可以通过适当的 HTTP 浏览器缓存标头来缓解。(无论如何,对于缺乏 Service Worker 支持的浏览器,您都应该考虑这一点。)
是的,服务人员绝对不限于客户端渲染。
你可以缓存任何你想要的东西。例如,这个 WordPress 插件缓存 WordPress 内容。