问题描述
我正计划创建一个主要针对手机的具有不同20个视图/页面的网站.
I am planning to create a website with around different 20 views/pages primary for mobile phones.
如果我想专注于使用户在切换页面时获得快速响应(快速)，那么将网站创建为单页面应用程序"是个好主意吗?
If I want to focus on a making the user experience very responsive (as in rapid) while switching between the pages, is creating the site as a Single Page Application a good idea?
我知道您可以采取许多技巧来提高移动网站的整体性能:
I know there are many tips you can do to increase the overall performance of a mobile website:
http://www.slideshare.net/blazeio/mobile-web性能优化提示和技巧
但是我主要担心的是，与创建传统的HTTP请求相比，当客户端JavaScript(例如AngularJS)需要执行AJAX请求然后动态显示/隐藏/创建元素时，实际上会降低性能.获取页面及其内容并直接显示.
But my primary concern is that the client-side JavaScript (such as AngularJS) would actually decrease the performance, when it needs to do AJAX-requests and then show/hide/create elements dynamically, compared to creating a traditional HTTP request to get page and its contents and showing that directly.
有什么资源或评论可以帮助我了解哪种架构更适合移动网站?
Any resources or comments that could help me understand what architecture would be more suitable for mobile sites?
推荐答案
TL; DR:单页应用程序需要更多地关注其体系结构，尤其是如果要迁移现有网站的功能时(d'oh，brownfield项目是艰难).
TL;DR: single page applications require more attention to their architecture, especially if you're migrating functionality of an existing website (d'oh, brownfield projects are tough).
一个常见的pro-SPA争论重点在于下载量较少的内容.尽管从技术上讲是正确的，但它与具有高延迟的蜂窝连接的相关性较小.剧透警报:所有蜂窝连接均处于高延迟状态.
A common pro-SPA argument focuses on less downloaded content. While technically correct, it holds less relevance on a cellular connection with high latency. Spoiler alert: all cellular connections are high latency.
-
下载10KB和15KB之间的差异可以忽略不计，这是连接建立开销消耗了移动体验的全部乐趣.
The difference between downloading 10KB and 15KB is negligible, it's the connection establishment overhead that drains all joy from a mobile experience.
您很少会影响延迟 (尽管可以使用CDN并在云中托管)，但是您可以抵消其影响.资源捆绑和缩小是有效的，并且无论什么基础概念都适用.使用的环境.
You can rarely influence latency (although using a CDN and hosting in the cloud can), but you can offset its impact. Resource bundling and minification is effective, and the underlying concepts are applicable regardless of the environment used.
无论如何，您都应该gzip压缩内容，并工作方式进一步贬低(哈哈)大小参数.基本上，它着重于重复字符序列，对于膨胀 HTML标记(而不是 lean JSON)而言，效率更高.对于Clojure编译的javascript，这太荒谬了.
You should be gzipping your content anyway, and the way it works further deflates (haha) the size argument. Basically it focuses on repeating character sequences and is more efficient for things like bloated HTML markup rather than lean JSON. This gets ridiculous for clojure-compiled javascript.
总是一个很好的提示，但请确保您的内容带有有效的Content-Length标头.
Always a good tip, but make sure that your content is served with valid Content-Length headers to allow persistent connections.
另一方面，常见的反SPA参数如下所示: ZOMG太多了javascript .当然，您再也负担不起传统网站上的可以"出现的内存泄漏(大多数情况都可以在浏览到其他页面后得到解决)，但是编写出色的JavaScript，您会得到回报的.
On the other hand, a common anti-SPA argument goes like this: ZOMG so much javascript. Sure, you can no longer afford to have memory leaks like you "can" on a traditional website (most are remedied as soon as a different page is navigated to), but write good javascript and you will be rewarded.
-
在移动网站上使用jQuery有时是必不可少的.最好正确使用.
您拥有的JavaScript越多，在每次页面加载"时重新执行 的相对动机就越大.您包含在页面上的任何框架都必须先初始化，然后才能使用，这需要解析并执行其代码... 在使用的每个页面上. SPA只需要执行一次此步骤(不过，这不是不良/缺失依赖管理的借口).
The more javascript you have, the bigger the relative incentive to have it not re-executed upon every "page load". Any framework you include on a page has to be initialized before it can be used, and that requires parsing and executing its code... on every page it's used. SPA only needs to perform this step once (still, this is not an excuse for poor/missing dependency management).
这也适用于CSS.当用户交互后将新内容添加到DOM时，重排和重画的数量将少于新负载.浏览器也无需再次解析样式表.
This also applies to CSS. When new content is added to DOM following a user interaction, there will be less re-flows and re-paints than a fresh load would incur; there is also no need for the browser to parse stylesheets again.
单页应用程序的真正优势在于其可感知的性能.您和我俩都知道，点击链接不会立即得到解决，但用户不必这样做.通过添加触摸状态和适时的跳动使站点对用户交互做出响应，将大大改善UX.当然，您总是可以加倍努力并预取某些内容.也许在当前页面/项目/照片准备好后立即在后台加载下一页/项目/照片是有意义的吗?
The real strength of a single page application is in its perceived performance. You and I both know that tapping on a link is not resolved instantaneously, but the user doesn't have to. Making the site responsive to user interactions by adding touch states and a well-timed throbber would dramatically improve the UX. Of course, you can always go the extra mile and pre-fetch certain content. Maybe it would make sense to load the next page/item/photo in the background right after the current one is ready?
不要抛弃SPA炙手可热的事实，再加上参与一些引人入胜的框架的动机因素.当然，最终用户不会在意这些事情，但是您会学到一些新知识，而成熟的MVVM框架可能会让您忘却使该死的ajax起作用并让您专注于应用程序的其他方面.
Don't discard the fact that SPAs are hot and trendy, plus the motivational factor of getting to play with some fascinating frameworks. Of course, end users wouldn't care about such things, but you get to learn something new and a mature MVVM framework could take your mind off getting this damn ajax to work and let you focus on other aspects of the app.
这篇关于SPA(单页应用程序)是否适合用于移动设备的网站?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！