让我们看一下最受欢迎的SPA网站之一，GMail。

1. SPA对于响应速度快的网站非常有用：

服务器端呈现的难度不像使用简单技术（例如在URL中保留#hash或最近在HTML5中pushState保留）那样困难。通过这种方法，Web应用程序的确切状态将嵌入到页面URL中。与每次打开邮件一样，在GMail中，特殊的哈希标签会添加到URL。如果复制并粘贴到其他浏览器窗口，则可以打开完全相同的邮件（前提是它们可以进行身份​​验证）。这种方法直接映射到更传统的查询字符串，不同之处仅在于执行。使用HTML5pushState（），您可以消除#hash和使用完全经典的URL，它们可以在第一个请求上在服务器上解析，然后在后续请求上通过ajax加载。

2.使用SPA，我们不需要对服务器使用额外的查询来下载页面。

用户访问我的网站时下载的页面数？当他/她打开他/她的邮件帐户时，实际上阅读了多少邮件。我一口气读了>
50。现在邮件的结构几乎相同。如果您将使用服务器端渲染方案，则服务器将在每个请求（典型情况）下对其进行渲染。-安全问题-您应该/不应为完全取决于您网站结构的管理员/登录页面保留单独的页面，以paytm.com为例，例如，制作网站SPA并不意味着您为所有网站打开了所有端点。用户，我的意思是我在我的spa网站上使用表单身份验证。-在可能最常用的SPA框架Angular
JS中，开发人员可以从网站上加载整个html模板，从而可以根据用户身份验证级别来完成。为所有身份验证类型预加载html是“

3.可能还有其他优势吗？ 什么都没听到

• 这些天，您可以放心地假设客户端将具有启用了JavaScript的浏览器。
• 网站的一个入口。正如我之前提到的，状态维护是可能的，您可以根据需要拥有任意数量的入口点，但是应该确定有一个。
• 即使在SPA用户中，也只能看到他具有适当的权限。您不必一次注入所有东西。加载差异html模板和javascript异步也是SPA的有效部分。

我能想到的优点是：

1. 现在，每个访问您网站的用户都在执行HTML渲染，因此显然需要一些资源。现在，不仅渲染主要逻辑都在客户端而不是服务器端完成。
2. 日期时间问题-我只是给客户端提供UTC时间是一种预设格式，甚至不关心我让JavaScript处理的时区。这对于我不得不根据用户IP派生的位置猜测时区是一个很大的优势。
3. 对我来说，状态可以更好地保存在SPA中，因为一旦设置了变量，便知道该变量将在那里。这给人一种开发应用而不是网页的感觉。这通常对制作类似foodpanda，flipkart，亚马逊之类的网站有很大帮助。因为如果您不使用客户端状态，那么您将使用昂贵的会话。
4. 网站肯定是非常敏感的-我将举一个极端的例子，尝试在非SPA网站（我知道它很奇怪）中制作计算器。

评论更新

似乎没有人提到套接字和长轮询。如果您从另一个客户端（例如移动应用程序）注销，则您的浏览器也应该注销。如果不使用SPA，则每次重定向时都必须重新创建套接字连接。这也应与通知，个人资料更新等数据中的任何更新一起使用

另一种观点：除了您的网站之外，您的项目是否还会涉及本机移动应用程序？如果是，那么您很可能将从服务器（即JSON）向该本地应用程序馈送原始数据，并进行客户端处理以呈现它，对吗？因此，有了这个断言，您已经在做一个客户端渲染模型。现在的问题是，为什么您的项目的网站版本不使用相同的模型？毫无疑问。然后，问题就变成了是否只为了SEO的好处和可共享/可标记URL的便利性而呈现服务器端页面