让我们来看看最流行的SPA网站之一，GMail。

1. SPA非常适合响应性非常强的网站:

Server-side rendering is not as hard as it used to be with simple techniques like keeping a #hash in the URL, or more recently HTML5 pushState. With this approach the exact state of the web app is embedded in the page URL. As in GMail every time you open a mail a special hash tag is added to the URL. If copied and pasted to other browser window can open the exact same mail (provided they can authenticate). This approach maps directly to a more traditional query string, the difference is merely in the execution. With HTML5 pushState() you can eliminate the #hash and use completely classic URLs which can resolve on the server on the first request and then load via ajax on subsequent requests.

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

The number of pages user downloads during visit to my web site?? really how many mails some reads when he/she opens his/her mail account. I read >50 at one go. now the structure of the mails is almost the same. if you will use a server side rendering scheme the server would then render it on every request(typical case). - security concern - you should/ should not keep separate pages for the admins/login that entirely depends upon the structure of you site take paytm.com for example also making a web site SPA does not mean that you open all the endpoints for all the users I mean I use forms auth with my spa web site. - in the probably most used SPA framework Angular JS the dev can load the entire html temple from the web site so that can be done depending on the users authentication level. pre loading html for all the auth types isn't SPA.

3.还有其他的优势吗?别再听别人说了。

现在，您可以放心地假设客户机将拥有支持javascript的浏览器。 网站只有一个入口。正如我之前提到的，状态维护是可能的，你可以有任意数量的入口点，但你应该有一个确定的入口点。 即使在SPA用户只看到他有适当的权利。你不需要一次注射所有的东西。加载不同的html模板和javascript async也是一个有效的SPA的一部分。

我能想到的优点是:

rendering html obviously takes some resources now every user visiting you site is doing this. also not only rendering major logics are now done client side instead of server side. date time issues - I just give the client UTC time is a pre set format and don't even care about the time zones I let javascript handle it. this is great advantage to where I had to guess time zones based on location derived from users IP. to me state is more nicely maintained in an SPA because once you have set a variable you know it will be there. this gives a feel of developing an app rather than a web page. this helps a lot typically in making sites like foodpanda, flipkart, amazon. because if you are not using client side state you are using expensive sessions. websites surely are extremely responsive - I'll take an extreme example for this try making a calculator in a non SPA website(I know its weird).

来自评论的更新

It doesn't seem like anyone mentioned about sockets and long-polling. If you log out from another client say mobile app, then your browser should also log out. If you don't use SPA, you have to re-create the socket connection every time there is a redirect. This should also work with any updates in data like notifications, profile update etc An alternate perspective: Aside from your website, will your project involve a native mobile app? If yes, you are most likely going to be feeding raw data to that native app from a server (ie JSON) and doing client-side processing to render it, correct? So with this assertion, you're ALREADY doing a client-side rendering model. Now the question becomes, why shouldn't you use the same model for the website-version of your project? Kind of a no-brainer. Then the question becomes whether you want to render server-side pages only for SEO benefits and convenience of shareable/bookmarkable URLs

SPA - SEO的一个主要缺点。直到最近谷歌和Bing才开始通过在爬行过程中执行JavaScript来索引基于ajax的页面，但在许多情况下，页面仍然被错误地索引。

在开发SPA时，您将被迫处理SEO问题，可能是通过后渲染所有站点和创建静态html快照供爬虫使用。这将需要对适当的基础设施进行坚实的投资。

更新19.06.16:

自从前段时间写了这个答案，我在单页应用(即AngularJS 1.x)方面获得了更多的经验——所以我有更多的信息可以分享。

In my opinion, the main disadvantage of SPA applications is SEO, making them limited to kind of "dashboard" apps only. In addition, you are going to have a much harder times with caching, compared to classic solutions. For example, in ASP.NET caching is extreamly easy - just turn on OutputCaching and you are good: the whole HTML page will be cached according to URL (or any other parameters). However, in SPA you will need to handle caching yourself (by using some solutions like second level cache, template caching, etc..).

对于谷歌、亚马逊等公司来说，他们的服务器在24/7模式下以最大容量运行，减少流量意味着真正的金钱——更少的硬件、更少的能源、更少的维护。将cpu使用从服务器转移到客户端是有回报的，spa大放异彩。到目前为止，利大于弊。 所以，SPA与否很大程度上取决于用例。

只是为了提到另一个可能不那么明显(对于web开发人员)的spa用例: 我目前正在寻找一种在嵌入式系统中实现gui的方法，基于浏览器的架构似乎对我很有吸引力。传统上，嵌入式系统中的ui没有太多的可能性——Java、Qt、wx等或适当的商业框架。几年前，Adobe试图通过flash进入市场，但似乎并不成功。

如今，由于“嵌入式系统”与几年前的大型机一样强大，基于浏览器的UI通过REST连接到控制单元是一种可能的解决方案。这样做的好处是，为用户界面提供了大量的工具，而且是免费的。(例如Qt需要20-30美元/销售单位的特许权使用费加上3000-4000美元/开发者)

对于这样的架构，SPA提供了许多优势——例如，桌面应用程序开发人员更熟悉的开发方法，减少服务器访问(通常在汽车行业，UI和系统混乱是分开的硬件，其中系统部分有一个RT操作系统)。

由于唯一的客户端是内置的浏览器，上面提到的js可用性、服务器端日志记录、安全性等缺点都不再重要。

如果没有首先定义如何在服务器端解决安全性和API稳定性问题，就不要考虑使用SPA。然后，您将看到使用SPA的一些真正优点。具体来说，如果您使用实现OAUTH 2.0的rest式服务器来实现安全性，那么您将实现两个基本的关注点分离，从而降低开发和维护成本。

这将把会话(以及它的安全性)转移到SPA上，从而减轻服务器的所有开销。 您的API变得既稳定又易于扩展。

前面曾暗示过，但未明确;如果您的目标是部署Android和Apple应用程序，那么编写一个JavaScript SPA，它由本地调用包装，以在浏览器(Android或Apple)中托管屏幕，从而消除了同时维护Apple代码库和Android代码库的需要。

在我的发展过程中，我发现使用SPA有两个明显的优势。这并不是说在传统的web应用程序中不能实现以下功能，只是我看到了增量收益而不会引入额外的缺点。

Potential for less server request as rendering new content isn’t always or even ever an http server request for a new html page. But I say potential because new content could easily require an Ajax call to pull in data but that data could be incrementally lighter than the itself plus markup providing a net benefit. The ability to maintain “State”. In its simplest terms, set a variable on entry to the app and it will be available to other components throughout the user’s experience without passing it around or setting it to a local storage pattern. Intelligently managing this ability however is key to keep the top level scope uncluttered.

在我看来，除了需要JS之外(这对web应用程序来说并不是一件疯狂的事情)，其他的缺点要么不是SPA特有的，要么可以通过良好的习惯和开发模式来缓解。

我想说明的是，SPA最适合数据驱动应用程序。gmail当然是关于数据的，因此是SPA的一个很好的候选。

但是，如果您的页面主要用于显示，例如，服务条款页面，那么SPA就完全多余了。

我认为最好的地方是拥有一个混合了SPA和静态/MVC样式页面的站点，这取决于特定的页面。

例如，在我正在构建的一个站点上，用户访问了一个标准的MVC索引页。但当它们进入实际应用程序时，它会调用SPA。这样做的另一个好处是，SPA的加载时间不在主页上，而是在应用程序页面上。首页的加载时间可能会让第一次访问网站的用户分心。

这个场景有点像使用Flash。经过几年的经验，由于加载因素，只使用Flash的网站数量几乎为零。但作为页面组件，它仍在使用中。