app shell model暗示应用程序外壳包含最低要求的HTML，JavaScript首先被加载，然后内容被动态加载。这似乎意味着使用JavaScript和API延迟加载内容。服务器端渲染和应用程序外壳模型
例如上述文章中提到的PWA Google I/O 2016。
但是，这种方法意味着您的内容仅适用于支持JavaScript的浏览器。
这也可能影响搜索引擎索引，例如在测试Google I/O 2016网站时，如果禁用JavaScript，则内容不可用。
什么是推荐的方法，因为这似乎违背了逐步增强的原则？
（警告：有很多实现服务器端呈现不同的方式。）
如果你做“正确”使用服务器端渲染，那么你的服务器应被发送任何导航请求作出回应通过一个完整的HTML文档，内容特定于URL。在这个模型中，尽管可能需要JavaScript来实现“交互式”功能，或者用于进行单页面应用风格的导航，但并不需要JavaScript来获取内容到屏幕上。
问题在于，一旦安装了服务工作器，并且如果您利用App Shell模型，浏览器将不再需要向服务器发送导航请求以获取响应。它可以使用先前缓存的App Shell HTML来完成请求，完全绕过网络。
不支持服务人员的浏览器或其他理论用户代理将继续向您的服务器发送导航请求，您的服务器将继续使用完整的HTML文档对其进行响应。
有我给了一个几年前的演讲的视频，说明这一点更详细：https://youtu.be/jCKZDTtUA2A?t=1428，并且在https://github.com/GoogleChrome/sw-precache/tree/master/app-shell-demo
在iFixit示例中，我是否正确地说，如果用户代理未启用JavaScript，它将正确加载服务器端数据，但如果用户代理启用了JavaScript，它将a）安装服务工作人员和缓存当前'索引'页面（可能已过时）b）从API中检索最新内容并覆盖'索引'页面上的内容。 –
有三种不同的行为：1）根本没有JS：SSR确保有所有导航响应的内容，并且链接触发真正的导航。 2）JS，但不支持SW（例如Safari）：SSR确保存在用于初始导航响应的内容，SPA风格的导航用于链接，DOM更新为新内容。 3）JS和一个注册的SW：通过快速的DOM更新来完成初始导航，并通过即时DOM更新来填充App Shell，然后使用SPA风格的导航用于链接。 –
采用这种技术的优势，我投票为关闭关闭这个问题一个示例应用程序因为它是关于搜索引擎优化，而不是编程。 SEO问题可能会在[Webmasters.SE]（// webmasters.stackexchange.com/）上询问 – Machavity
我相信您的评论不正确。问题在于编程 - 具体说明应用程序外壳模型体系结构和逐步增强的原则。 SEO被提及，因为它是通过JavaScript加载内容的缺点之一。 我编辑了这个问题来修改和删除对“SEO”的引用。 –