Question

我打算创建一个网站，其中包含大约不同的20个浏览/页面主要用于手机。

如果我想专注于在页面之间切换时使用户体验非常敏感（如快速），那么将网站创建为单页应用程序是一个好主意吗？

我知道您可以采取许多提示来提高移动网站的整体效果：

http://www.slideshare.net/blazeio/mobile-web-performance-optimization-tips-and-tricks

但我主要担心的是，与创建传统HTTP请求相比，客户端JavaScript（例如AngularJS）实际上会降低性能，当它需要执行AJAX请求然后动态显示/隐藏/创建元素时获取页面及其内容并直接显示。

任何有助于我了解哪种架构更适合移动网站的资源或评论？

Answer 1

TL; DR：单页应用程序需要更多关注其架构，特别是如果您正在迁移现有网站的功能（噢，棕色地带项目很难）。

常见的pro-SPA论点侧重于较少下载的内容。虽然技术上是正确的，但它与具有高延迟的蜂窝连接的关联性较低。扰流板警报：所有蜂窝连接都是高延迟。

下载10KB和15KB之间的区别可以忽略不计，连接建立开销会从移动体验中消除所有欢乐。
您很少影响latency（尽管在云中使用CDN和托管可以），但您可以抵消其影响。资源bundling and minification是有效的，无论使用何种环境，基础概念都适用。
无论如何，你应该正在对你的内容进行解压缩，the way it works进一步缩小（haha）size参数。基本上它专注于重复字符序列，并且对于诸如膨胀 HTML标记而不是精简 JSON之类的东西更有效。这对于clojure编译的javascript来说是荒谬的。
始终是一个好的提示，但请确保您的内容使用有效的Content-Length标题to allow persistent connections投放。

另一方面，一个常见的反SPA论点是这样的： ZOMG这么多javascript 。当然，您再也不能像传统网站上的“可以”那样有内存泄漏（大部分内容都会在导航到不同页面后立即得到补救），但是写好javascript会得到回报。

在移动网站上使用jQuery有时是必要的恶魔。不妨使用它properly。
你拥有的javascript越多，每次“页面加载”时不重新执行它的相对动机就越大。您在页面上包含的任何框架都必须在可以使用之前进行初始化，并且需要解析并执行其代码... 在每个使用它的页面上。 SPA只需要执行一次此步骤（但是，这不是缺乏/缺少依赖关系管理的借口）。
这也适用于CSS。当在用户交互之后将新内容添加到DOM时，将会产生比新负载更少的重新流动和重新绘制;浏览器也无需再次解析样式表。

单页应用程序的真正优势在于其感知性能。你和我都知道点击链接不是即时解决，但用户不必。通过添加触摸状态和适时的悸动使网站响应用户交互将大大改善用户体验。当然，您可以随时加倍努力并预先获取某些内容。也许在当前的一个准备就绪后立即在背景中加载下一页/项目/照片是有意义的吗？

不要放弃SPA既热又时尚的事实，再加上玩一些引人入胜的框架的动机因素。当然，最终用户不会关心这些事情，但是你可以学习一些新的东西，而成熟的MVVM框架可以让你忘记让这个该死的ajax工作，让你专注于应用程序的其他方面。

Answer 2

有两种方法可以让SPA路线为您提供机会，让您可以利用这些机会改善用户体验：

下载内容较少

如果您的应用程序中的每个页面都有不同的HTML页面，则必须完整地下载每个页面。如果您的站点在页面之间共享共同标记，则将为每个页面重新下载它。将其与SPA进行比较，至少您只下载从当前页面到下一页面所需的更改。在某些情况下，几乎没有什么改进，在其他情况下，这将是非常重要的。

如果您将构建标记和数据的逻辑分开，那么SPA可以提高效率的另一种方式。考虑一个包含100个名称和分数的列表的示例：

传统：

<ul id="myList">
  <li><strong>Name 1</strong> score 1</li>
  <li><strong>Name 2</strong> score 2</li>
  <li><strong>Name 3</strong> score 3</li>
  ...
  <li><strong>Name 100</strong> score 100</li>
<ul>

SPA：

<ul id="myList"></ul>

var myData = { 
  "Name 1" : "score 1",
  "Name 2" : "score 2",
  "Name 3" : "score 3",
  ...  
  "Name 100" : "score 100"
}
var html = '';
for (var name in myData) {
  var html += '<li><strong>' + name + '</strong> ' + myData[name] + '</li>';
}
document.getElementById('myList').innerHTML = html;

即使在构建DOM时，SPA模型也可以节省字节。此外，逻辑是可重用的，因此如果您需要使用更多内容重新构建列表，您只需要向对象添加内容并调用方法。

确定下载大小和所需处理之间的完美平衡是一个非常困难的问题，它取决于许多问题，包括应用程序的特殊性，设备，可以完成的其他技巧等。幸运的是，常识方法给出了大部分时间都是足够好的结果。

<强>转换

除了一些IE实验，您无法对浏览器中不同页面之间的转换进行任何更改。这是SPA的一个重要卖点，因为即使在网站不那么快的情况下，通过巧妙的过渡，您也可以提供速度的外观。即使没有过渡，SPA也更适合在加载时向用户提供比常规站点更多的反馈。

有一点需要注意的是，您应该尽可能地关注初始页面加载（通过仅加载最小值）并在该批次请求之后尽可能地进行。移动延迟的一个大问题是，如果设备暂时不需要使用无线电，它将被关闭。再次打开它会产生很大的开销，因此请尽可能对请求进行批处理。

我个人的建议是，如果你能去SPA，你应该。为提高常规HTML网站的效率，几乎没有什么可以做的，而我怀疑SPA将来会继续不断改进。至少，您可以期望通过精心构建的SPA获得与常规HTML相似的性能，潜在的机会可以带来丰厚的回报。

Answer 3

TL; DR：是的，这是可行的，但你需要受到纪律处分，并且好处是对绩效的看法

过去几个月，我一直致力于将传统的以服务器为中心的“桌面”Web应用程序转换为响应式SPA。具体来说，我们选择了一个由中介路由器支持的MV *设计，与AMD进行解耦。我们正在探索将其转移到RVP。

我在下面列出了一些设计原则：

尽早确定您的平台支持渐进增强的程度。需要的脚本越少越好。我们依靠构建过程来确保我们可以支持动态生成但静态提供的HTML和其他内容
尽早构建工具链（缩小，图像处理或精灵等）
使用本地存储和预取或预测提取等技术，尽可能地从用户操作中取出。
确保您衡量用户正在做什么，这样您就可以（如果有意义的话）逐步获取应用程序逻辑或内容
非常挑剔哪些框架支持您的架构的其余部分（而不是指示它）。
非常挑剔您使用的第三方组件和实用程序。避免使用不使用大部分功能集的框架（任何你不使用的是重量，延迟，设备上处理等额外成本）

您可能会发现此framework comparision有用

Answer 4

保持简单 -

是单页应用程序非常适合移动开发。 SPA框架，如Durandal，Angular，Backbone，Ember等......只需要一个JavaScript引擎即可有效运行。它们具有跨浏览器兼容性，无需特殊操作即可在每个屏幕尺寸，分辨率或设备上运行，并充分利用移动设备强大的引擎。

是什么让他们非常适合？

使用单页面应用程序，您可以将所有钩子放在适当位置，以便与Knockout，Handlebars或Angular等库进行声明性双向数据绑定，这些库将替换您在传统中使用的所有jQuery DOM操作网站。这将促进可重用的组件，如指令和自定义绑定处理程序，减少所需的代码量并允许更容易的测试，因为绑定将在整个应用程序中重复使用。

是什么让他们对移动设备不那么好？

单页应用程序通常可以开始设计难以恢复的路径（就像任何其他开发一样）不同之处在于很难找到伟大的路径创建可扩展的应用程序，并且通常是SPA开发人员首次做出假设。这可以通过利用资源（例如付费支持，StackOverflow等等）或在SPA的基础上预先执行繁重的代码审查来缓解

表现怎么样？

在大多数情况下，单页应用程序是闪电般快速的。基本思想是使用依赖注入，像Require.js这样的库加载AMD模块允许开发人员只需要客户端在发生更改时很少下载HTML和JavaScript文件。通过从缓存加载，您实际上减少了对服务器到数据调用的命中。这遵循RESTful Web开发技术。

Answer 5

SPA是移动网站的不错选择。以下模板似乎在移动SPA网站上表现良好

Hottowel
(Overview)

响应时间越短，您就能获得出色的性能。我已经尝试了上面的模板来创建支持移动浏览器和Web浏览器的网站。

使用jquery进行动态处理
使用ajax调用根据需要快速调用数据
MV架构将为您提供实现概念的清晰画面
HTML5将是前端的更好选择
使用单独的API处理可提高性能的数据流程

Answer 6

简短的回答是肯定的。

Every second counts，如果加载的时间超过一秒，人们就会开始放弃您的服务。所以只加载你需要的东西。

此外，谷歌还提供了这套精彩的guidelines ，以帮助您针对移动设备进行优化。

我使用像RequireJS这样的工具来加载我需要的部分（和组织！），取得了相当大的成功。这可以与您选择的框架配对，例如BackboneJS，AngularJS，EmberJS ...那里有很多很棒的人。

我见过的最有趣的框架是Famo.us，他们在手机，电脑和电视上声称40-60 fps。他们的演示在移动设备上完美运行。

Answer 7

这一决定的转折点是发展的复杂性。基于Web服务器的常规应用程序更容易开发，因为有更多的开发人员知道如何使这样的应用程序以最高效率执行的所有技巧。另一方面，SPA可以在所有领域实现更好的性能1）更快的数据传输，2）更快的GUI（DOM）操作，3）更智能的UX，但所有这些都需要更有经验（昂贵）的开发人员，他们可以快速实现可靠。那些开发者更少。如果你打算自己做所有事情，那么对你来说意味着更长的学习曲线，而对于试验/错误则意味着更多这主要是因为与常规WWW相比，SPA是新的。

要创建有效的SPA，您需要非常了解连接/套接字部分，了解瓶颈，如何选择协议，哪些平台（设备）支持哪些连接协议。选择您喜欢的解决方案并不容易：Engine，IO，Socket.IO，SockJS等。

你需要在动态性能方面很好地了解DOM操作，明智地选择div / tables / canvas。

您需要有效地使用浏览器端功能来存储数据，即Cookie，缓存，本地数据存储设施（文件/数据库），以便在会话期间和会话之间存储数据。

这些天的JavaScript在iOS / Android上非常快，所以语言本身的速度无论如何都应该不是问题。最大的好处是使用Node.js，以便您可以使用客户端和服务器端的相同语言进行编程。无需跨两种（或多种）语言同步hashThisPassword()个功能。

Answer 8

接受的答案非常好，我同意，我开发的最新应用程序主要是使用SPA制作的。

但我想补充一点，SPA并不是所有应用程序的神奇解决方案，特别是在谈论＆＃34;关键路径渲染＆＃34; 时。

<小时/>

简史

实现快速＆＃34; time to first tweet＆＃34;处理整个框架（如AngularJS）可能是个问题。

我们意识到使用Angular更难实现客户的需求。所以我们没有它就构建了应用程序。该应用程序广泛使用了AJAX请求和其他优化实践。最后，渲染主页面的时间减少了近1秒。在部署后的两个月内，客户的销售额增长了30％！好吧，这是一个具有简单功能的应用程序，并没有SPA通常具有的丰富性。

<小时/> 同样，我并不是说问题出在SPA上，但我认为并不是所有移动应用程序的最终答案。

SPA（单页应用程序）是否适用于针对移动设备的站点？

8 个答案:

是什么让他们非常适合？

是什么让他们对移动设备不那么好？

表现怎么样？

简史