javascript - SPA(单页应用程序)是否适合针对移动设备的网站？

Question

我计划创建一个主要针对手机的网站，其中包含大约 20 个不同的 View /页面。

如果我想专注于在页面之间切换时让用户体验非常灵敏(如快速)，将网站创建为单页应用程序是个好主意吗？

我知道有很多技巧可以提高移动网站的整体性能:

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

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

有什么资源或意见可以帮助我了解哪种架构更适合移动网站？

Answer 1

TL;DR:单页应用程序需要更多地关注它们的架构，尤其是当您要迁移现有网站的功能时(哦，棕地项目很难)。

一个常见的支持 SPA 的论点集中在较少下载的内容。虽然在技术上是正确的，但它与具有高延迟的蜂窝连接的相关性较低。剧透警告:所有蜂窝连接都是高延迟。

• 下载 10KB 和 15KB 之间的差异可以忽略不计，正是连接建立开销耗尽了移动体验的所有乐趣。

• 您很少能影响 latency (尽管可以使用 CDN 和托管在云中)，但您可以抵消它的影响。资源 bundling and minification是有效的，无论使用的环境如何，底层概念都适用。

• 无论如何你都应该对你的内容进行 gzip 压缩，并且 the way it works进一步缩小(哈哈)大小参数。基本上，它专注于重复字符序列，并且对于诸如臃肿 HTML 标记之类的事情比精简 JSON 更有效。这对于 clojure 编译的 javascript 来说很荒谬。

• 始终是一个很好的提示，但请确保您的内容使用有效的 Content-Length header 提供 to allow persistent connections .

另一方面，一个常见的反 SPA 论点是这样的:ZOMG so much javascript。当然，您不能再像在传统网站上那样“可以”承受内存泄漏(大多数会在导航到不同页面后立即得到补救)，但是编写良好的 javascript 会有所返回。

• 在移动网站上使用 jQuery 有时是一种必要之恶。不妨用一下 properly .

• 您拥有的 javascript 越多，让它不在每次“页面加载”时重新执行的相对动机就越大。您在页面上包含的任何框架都必须在使用前进行初始化，这需要解析和执行其代码...在使用它的每个页面上。 SPA 只需执行一次此步骤(不过，这不是依赖管理不佳/缺失的借口)。

• 这也适用于 CSS。当用户交互后将新内容添加到 DOM 时，与新加载相比，重新流动和重新绘制的次数会更少；浏览器也不需要再次解析样式表。

单页应用程序的真正优势在于其感知性能。你我都知道点击链接不会立即解决，但用户不必这样做。通过添加触摸状态和适时的 throbber 使网站响应用户交互将显着改善用户体验。当然，您始终可以多走一步并预取某些内容。也许在当前页面准备就绪后立即在后台加载下一页/项目/照片有意义吗？

不要忽视 SPA 的热门和流行这一事实，以及尝试使用一些迷人框架的动机因素。当然，最终用户不会关心这些事情，但是您可以学到一些新东西，并且成熟的 MVVM 框架可以让您忘记让这个该死的 ajax 工作并让您专注于应用程序的其他方面。