Hybrid架构下，加载本地H5资源后，如何处理Ajax请求？
希望在app中打开H5页面能达到Native那样的速度，当然感觉不太可能，但两者速度越接近越好。网上查了资料，有种方法是将网页资源嵌入到app中，打开时相当于加载本地资源。参考：里面有段是这么描述的：别忘了，我们是 Hybrid App，还可以充分利用 Native 层的强大能力，所以抛弃mainfest吧，让 Native 来帮助 Html5 应用缓存静态资源文件。总体思路是：1、Html5 应用首次启动时，调用 Native 提供的加载资源文件专用的 Device API 来请求所需的资源文件，由 Native 层发出真正的资源请求，并将请求结果缓存在手机的SD卡上。当然，这里完全可以优化为一次 zip 包请求，因为 native 能够提供强大的解压能力。2、H5 应用再次启动时，所有的静态资源都是通过 Device API 读取本地缓存，无需再走网络。3、H5 应用出现静态资源更新时，在应用启动时首先通过 Device API 加载需要更新的文件，并更新本地缓存，其它未变更文件继续走缓存。现在的问题：1、加载的是本地的资源，那么本地页面上Ajax请求到后台取数据如何处理？2、用jsonp能解决吗？优缺点？3、也问过阿里的人员，他们的回答是采用了“虚拟域”的做法，app会将请求拦截做一些处理。但不是具体负责人，技术细节不是很清楚。有没有人知道类似这样的处理方法？ps：技术不精，上面的描述如有问题，轻吐槽哈。
按投票排序
很荣幸在淘宝旅行时接触过类似的技术方案，简单回答一下题主提到的几个问题：首先，什么是“虚拟域”？直接上图吧：既然要做资源离线化，肯定要把所有的资源请求到发到本地。题主引用的 1688 那篇博客，里面提到“使用 Device API”来请求本地资源。我猜测他其实说的是 FileSystem API（这货其实在 2010 年时已经从 Device API 工作组移入了 Web Application 工作组）或者是 Native 通过 JS Bridge 暴露出来的 Hybrid API。我个人觉得这样其实是有缺陷的 —— 如果你的资源请求都是通过 API “硬编码”来请求，那这货很明显在浏览器里跑不起来，当然，封装一层 Wrapper 兼容掉也行。不小心吐槽太多了……那么淘宝旅行采用的是什么方案呢？由于我们有大量现有的 codebase，不可能手动去替换各种 script, link 标签。可是这些标签请求的都是
域下的在线资源，Native App 本地里显然没有这个“域”（准确的说应该是 Domain Name），我们对着本地 IO 请求
肯定什么都拿不到。所以“虚拟域”就来了，为了让一套 web 页面同时兼容浏览器和 Hybrid 容器等多种环境，我们希望不改变前端代码就可以做到“资源请求发到本地”。所以说白了“虚拟域”无非就是让 Native 认得这个域名而已，这样 Native 容器里好像就有了域一样。Native 认得域名了，就可以把该域下的请求转发到本地去拿。那么问题来了，Native 怎么知道哪些请求是需要被代理的，哪些又是不要的呢？题主提到了一个方案是跨域，比如说我们只代理 A 域不代理 B 域，听上去好像是可行的，不过感觉还是不够 scale。其实我们使用的方案更简单粗暴一些，遍历一下文件目录生成一个映射表就好了，这里的虚拟域代理起到一个反向代理的作用，看一下 match 不 match 就知道该代理到哪去了。映射表的生成直接做在持续集成的流程里，构建工具在 build 时会帮你生成出来，DX（开发者体验）非常的轻松且愉快，感谢工具小哥。基本上就是这样。本来只想简单说下，洋洋洒洒也写了不少……你问我这些牛逼的图都是哪来的？我当然不会把内部的东西随便乱发啦。这些资源都是公开的，来自老大
在 2015 Qcon 的演讲 《极致的 Hybrid》，另外牛逼的工具小哥
在 2014 D2 上也演讲过这个话题～（欢迎两位大大补充和指正）完整的 PPT 在此：最后，帮老东家和现东家都低调得打个小广告：阿里旅行-去啊 / 微信电影票长期招募前端开发高手加入，有志者邮件简历 bachi[at] / huangxuan[at]以上～
虚拟域指假域名, 通过webview的shouldInterceptRequest拦截(android.webkit.WebView, android.webkit.WebResourceRequest)
首先，感觉阿里的那套方案安全是因为历史包袱才做出来的方案。现在我们的项目，完全可以做到在Hybrid中使用和直接通过http访问，有了gulp之类的打包工具这些都不是问题，完全可以写一套代码，然后打出Hybrid代码和普通的html代码来。其实楼主的问题问的也比较模糊，有点搞不清楚意思。如果是Hybrid应用，你的http请求可以设置完全跨域的，webview组件完全可以控制这个特性，开放跨域。所以ajax完全跟在普通页面上一样使用就可以啊，不会有跨域问题。别说你的app连webview都控制不了啊。我们的Hybrid大部分也是通过gulp打包成zip包，然后利用时间戳机制，客户端去更新这个zip包然后完全解压到本地的。有些应用每次打包都会打出两个版本，一个是Hybrid的zip包，一个是用来直接访问的版本。最近在尝试在app内嵌一些常用的js库，然后通过bridge把这些库直接 用在原生页面的方案，比zip包得方式会灵活一些，不过其实优化度和维护性有待验证。打成zip包得方式有个问题，就是我们的app其实很复杂，大概有三四条大业务线同时在维护这个app，但是他们之间的前后台技术方案都不太一样，业务也差别很大，这时候就需要分开维护Hybrid的代码，然后就造成一个app里内置了很多个这样的Hybrid包，也分成很多zip包，这些zip包不能放在一起，因为每个业务的更新频率大不相同。。。也算是业务的一个限制，很容易搞得乱起来。所以我们其实在不太关注性能的地方，还是推荐加载远程H5，只有一些用到复杂框架的H5才会考虑做成Hybrid
其实主要就是通过Jsbridge调用Native的的网络通讯层来访问api，因为Native的网络层本身可以方便的做很多的优化和定制。jsbridge可以参考我的实现
phonegap、appcan这些。。。
第一眼看到这个问题想到的解决方法是打包好所有资源放在你的app上，你需要的资源直接发送ajax请求到后台拿就可以了，前提下后台给你做好这个接口，传个token，id等等的给后台。然后建立个请求，把response回来的json显示给前端就Ok了，至于jsonp还是json，看你个人喜好吧。还有既然是拿数据到前端，总不能直接对DOM来增删查改吧，这比较苦，那就绕不开来个MVVM之类的，拿到什么变动什么，至于题主说的ZIP解压，那就是native的API解决的事了。看到你回复中说阿里在请求拦截做一些处理，感觉就不是ajax的问题，是安全方面的问题了，虚拟DOM就是不想让你跨域而已，但是这样真的就能解决这个问题，我私以为这有可能是。。。省略了~逃
谢邀首先说一下。我并不清楚阿里的实现方式。我只说我知道的。1.我这边开发的话，静态资源（html,css,js,img）都是直接打包到 app 中的。本地资源的打开速度是很快的，然后列表、信息什么的都是通过请求服务端的数据接口，然后拼接DOM进行渲染。如果APP有bug需要更新的话，是需要重新下载APP。【其实这个做法和native app 的做法是基本一样的。本地界面编写。动态数据通过接口渲染到界面上。思路一样，实现方式不同而已】2.接口数据 jsonp 可以，也可以直接使用 json【需要服务端配置CORS】，然后使用 ajax 去请求就可以了。3.不太明白「虚拟域」的概念。如果指的是接口数据的缓存一般是用 html5 的 localStorage 做，量大的话用 sqlite。大致就是```javascriptif( localStorage.getItem("listdata") ){//直接调用存在本地的json格式数据拼接 dom}else{//使用 ajax 请求到数据再进行拼接 dom}```从你的引用上来看应该是说的
webapp ，而不是 hybrid app ，我个人认为这两个是有区别的。
Native层模拟一个ajax即可。比如，Native层实现一个HttpClient类，提供一个方法+(void)ajax:(NSDictionary *)settings，通过JavaScriptCore暴露给JavaScript，在JavaScript中调用HttpClient.ajax()即可通过Native的通信模块处理网络请求了。
我们这里的hybrid app中的前端资源（jsp js css 字体库 图片等等）是打在离线包里的 发送请求时会经过native的过滤 静态资源直接走离线包 其他的正常发请求 和网页无区别不是很明白题主的问题。。
增量更新？跨域？安全？
已有帐号？
社交帐号登录
无法登录？
社交帐号登录文章- 442&
&&&&&&&&&&&
性能一直是网站成功的关键。越来越多的研究已经证明，不管是小型电商，还是像沃尔玛那样的连锁店，即使是页面加载时间方面的细微改善，都可以带来更多的业务，更多的广告收入，更多的用户粘性和更多的客户满意度。
在过去几年，Web开发者都是基于改善硬件或者提高带宽速度来优化用户体验。但是最近几年，爆炸式的移动Web浏览器的使用打破了这个途径。低带宽，高延迟，小内存，低处理器性能的移动设备环境，迫使开发者不得不想办法通过优化前端页面的性能来满足用户的性能预期。
在强调如何解决移动端性能问题上，这篇文章总结了一些前端优化的案例，并且概括了一些加速页面的方法和策略。
为什么性能会影响这么多
不论你的页面设计地多么有趣、漂亮、交互性好，不管是在桌面还是移动设备上，如果页面需要花2到3秒时间去渲染展示，那么用户都会很快变得不耐烦的。可以预期的是，在页面还在加载的时候，用户很有可能从浏览购买的行为转变为点击回退键或者是关闭浏览器的行为。
不到1秒钟的延迟甚至也会显著地影响收入。在2006年，当时还在Google工作的Marissa Mayer说，由于用户表示希望在一个搜索页上看到多于10个搜索结果，Google就实验性地修改为30个。但是让人吃惊的是，在这个实验里，流量和投 资都减少了20个百分点，显然是由于更多的搜索结果导致多花费了半秒时间来加载页面。^5
用户的期望总是在不断的提升。2009年，Forrester研究所的Akamai的一项研究发现表明，网页响应时间可容忍的阀值是2秒，一旦网页 相应时间超过3秒，会有40%的用户放弃浏览页面。一年之后，Akamai的另一项研究表明，超过3秒放弃浏览页面的用户比例上升到了57%。^1,7
此外，移动端的用户希望移动设备上的页面性能不亚于桌面PC。由Tealeaf科技（现在已经并入IBM）委托的&Harris的互动2011移动 交互调查&显示，在前一年有过移动消费经历的成年人中，有85%希望移动设备上的体验能与手提电脑或者PC上的体验相当，甚至于更好。并且有63%的人表 示，一旦他在移动设备上的交易遇到了一个问题，他们就不会再想通过其他渠道去购买这个公司的其他产品了。^10换句话说，差劲的移动页面性能会影响到公司 其他各种平台的销售，这其中当然也包括线下的实体店。
移动流量正在迅速增长。对许多消费者而言，他们的手机或者平板设备已经成为他们浏览网络的主要入口了，但是其性能表现却差强人意。2011年2 月，Compuware公司委托Equation 研究所做的一项研究表明，几乎一半的移动用户（46%）表示他们手机上的网站加载速度过慢。60%的用户希望页面能在3秒或者更少的时间内加载完 成，74%的用户表示，当单个页面加载时间花费5秒或者更多的时候，他们会选择离开这个页面。在2012年，由Strangeloop网络（现已并入 Redware）发起的一项针对200家领先的电子商务网站研究表明，3G网络环境下，平均加载时间为11.8秒（图1），而在LTE（4G）环境下，加 载时间只有轻微的改善，为8.5秒。^8
移动设备表现性能的三种影响因素
正如上文所说的，移动设备天生有下面三种性能限制：带宽低，内存小，处理器性能低。这些性能挑战又加上一些其他的问题，例如：
网页比以前更大。根据HTTP Archive网站的分析，现在平均的一个web页面需要加载超过1MB的数据，其中包含有图片，Javascript，CSS（Cascading Style Sheets）等。更大的网页会影响桌面PC的显示性能。对于移动端的性能 & 特别是3G环境下的性能 & 影响更严重。这个影响会在今后的三年更加明显。以现在的页面增长速度来说，到2015年，平均的页面大小会达到2MB。
延迟相差巨大。对LTE来说，延迟大概有34ms，对3G来说，延迟大概有350毫秒甚至更多。移动端的延迟性 唯一不变的就是延迟时间永远是不定的，即使是在同一个地点，每次的延迟都是不定的。这是由于大量的数据是通过信息塔进行传输的。因此诸如天气，甚至是持有 者所面向的方向都有可能成为影响因素。
下载速度相差巨大。下载速度的范围从3G环境下的1Mbps到LTE环境下的31Mbps。把这个和美国平均的带宽15Mbps相比是一个很有意思的事情，3G环境比平均带宽慢了15倍，而LTE却能达到平均带宽的2倍那么快。
M.SITES并不能完全解决移动端性能的问题。
许多网站建设者尝试针对多用户访问，大网页和低流量连接的访问页面，开发出短小，快速，精简的m.sites；但是，这些尝试并没有什么用，当用户有选择权的时候，高达35%的移动用户会选择浏览完整的网站。
这些选择浏览完整网站的用户显然比浏览m.sites的用户更有购买欲望。一个研究表明，移动端每$7.00的消费中，有$5.50是来自于网站的网站浏览，只有$1.00是来自于m.sites，剩下的$0.50则是来自于客户端。^9
改善网站性能的主要策略并没有因为从PC变成手机或者平板设备而有变化，只是会参杂一些小的策略。
不论在PC还是在移动浏览器上，页面展示需要的时间里，只有20%是用来读取页面的HTML的。剩下的80%是用来加载额外的像样式表、脚本文件、或者图片这样的资源和执行客户端的程序。
三个主要的改善性能的策略是：
减少每个页面需要获取额外资源的HTTP请求数
减少每个请求加载的大小
优化客户端执行的优先级和脚本执行的效率
由于移动网络通常比桌面机器的网络慢，所以减少请求数和请求加载量是非常重要的。由于移动端的浏览器解析HTML和执行JavaScript的效率 比桌面PC低，所以优化客户端程序也是非常关键的。另外，移动端浏览器的缓存大小比桌面PC低，所以需要有方法能重复利用本地的缓存资源。
文章剩余部分总结了能解决这些问题的方法。虽然这些方法大都可以自动化解决，当然也可以由有经验的前端工程师来手动解决。关键就是要知道人工解决这 些技术的方法如何控制资源的请求。通常在CMS（内容管理系统）或者其他Web应用中，有些页面包含一些自动生成好的或者离线的HTML片段、CSS或者 Javascript文件，这样的页面开发者就不需要去优化它们了。
最大的性能漏洞就是一个页面需要发起几十个网络请求来获取诸如样式表、脚本或者图片这样的资源。这个在相对低带宽和高延迟的移动设备连接上来说影响 更严重。CDNs（内容分发网络）把资源放在离用户地理位置更近的地方对解决这个问题能起到很大作用，但是比起获取请求，大量的请求对页面加载时间的影响 更为严重。而且最近的发现表明，CDNs对移动端用户的性能影响越来越低。
下面的章节讨论了简化HTTP请求的几种方法。
对开发者来说，将Javascript代码和CSS样式放到公共的文件中供多个页面共享是一种标准的优化方法。这个方法能很简单的维护代码，并且提高客户端缓存的使用效率。
在Javascript文件中，要确保在一个页面中相同的脚本不会被加载多次。当大团队或者多个团队合作开发的时候，这种冗余的脚本就很容易出现。你可能会对它的发生频率并不低感到非常吃惊。
Sprites是css中处理图片的一项技术。Sprites就是将多张图片整合到一个线性的网状的大图片中。页面就可以将这个大图片一次性获取回 来并且做为css的背景图，然后使用css的背景定位属性展示页面需要的图片部分。这种技术将多个请求整合成一个，能显著地改善性能。
实现小贴士：平稳地改进但是需要对资源有控制权限。根据开发者的网站不同权限，一些资源并不需要被整合起来（例如，一些由CMS生成的资源）。还 有，对于一些外部域引用的资源，强行整合可能会导致问题。需要注意的是，整合资源对手机浏览器来说是一把双刃剑。整合资源确实会在首次访问减少请求，但是 大的资源文件可能会导致缓存失效，所以，需要小心地使用各种技术整合资源，以达到优化本地存储的目的。
使用浏览器缓存和本地缓存
现在所有的浏览器都会使用本地资源去缓存住那些被Cache-Control或者Expires头标记的资源，这些头能标记资源需要缓存的时间。另 外，ETag（实体标签）和Last-Modified头来标识当资源过期后是否需要重新请求。浏览器为了减少不必要的服务器请求，尽可能地从本地缓存中 获取资源，并且将那些已经过期的、或者当缓存空间减小的时候将那些很久不用的资源进行清理。浏览器缓存通常包括图片，CSS，Javascript代码， 这些缓存能合理地提高网站的性能。（比如为了支持后退和前进的按钮，使用一个单独的缓存来保存整个渲染的页面）。
移动浏览器缓存，通常是比桌面PC小的多，这就导致了缓存的数据会很经常被清理。HTML5的缓存基于浏览器缓存提供了一个很好的替换方案。 Javascript的localStorage已经在所有主流的桌面和移动端浏览器上都实现了。使用脚本代码能简便地支持HTML5的 localStorage操作，可以读写键值数据，每个域名大概有5MB的容量。虽然不同的移动浏览器上读写速度相差很大，但是localStorage 大容量的缓存使得它很适合作为客户端的缓存。从localStorage获取资源明显快于从服务器上获取资源，而且在大多数移动设备上也比依靠缓存头或者 浏览器的本地缓存更灵活可靠。这是移动浏览器比桌面PC更有优势的一个地方，在桌面PC上，本地缓存仍然优先使用标准的浏览器缓存，导致桌面PC本地缓存 的性能落后于移动浏览器。
实现小贴士：需要进一步考虑。虽然localStorage的机制易于实现，但是它的一些控制机制却是非常复杂的。你需要考虑到缓存带给你的所有问题，比如缓存失效（什么时候需要删除缓存？），缓存丢失（当你希望数据在缓存中的时候它并不在怎么办？），还有当缓存满的时候你怎么办？
首次使用的时候在HTML中嵌入资源
HTML的标准是使用链接来加载外部资源。这使得更容易在服务器上（或者在CDN上）操作更新这些资源，而不是在每个页面上修改更新这些资源。根据上文讨论的，这种模式也使得浏览器能从本地缓存而不是服务器上获取资源。
但是对还没有缓存到浏览器localStorage的资源来说，这种模式对网站的性能有负面的影响。一般来说，一个页面需要几十个单独的请求来获取 资源从而渲染页面。所以说，从性能的角度来说，如果一个资源没有很高的被缓存的几率的话，最好把它嵌入到页面的HTML中（叫inlining），而不是 使用链接外部。脚本和样式是支持内嵌到HTML中的，但是图片和其他的二进制资源其实也是可以通过内嵌包含base64编码的文本来嵌入到HTML中的。
内嵌的缺点是页面的大小会变得非常大，所以对于Web应用来说，关键的是能够跟踪分析这个资源什么时候需要从服务端获取，什么时候已经缓存到客户端 了。另外，在第一次请求资源后必须能够使用代码在客户端缓存资源，因此，在移动设备上，使用HTML5 localStorage能很好地做到内嵌。
实现小贴士：平稳处理。由于不知道用户是否已经访问过这个页面了，所以需要网站有机制能生成不同版本的页面。
使用HTML5服务端发送事件
Web应用已经使用了各种从服务器上轮询资源的方法来持续地更新页面。HTML5的EventSource对象和Server-Sent事件能通过 浏览器端的JavaScript代码打开一个服务端连接客户端的单向通道。服务端可以使用这个写通道来发送数据，这样能节省了HTTP创建多个轮询请求的 消耗。这种方式比HTML的WebSocket更高效。WebSocket的使用场景是，当有许多客户端和服务端的交互的时候（比如消息或者游戏），在全 双工连接上建立一个双向通道。
实现小贴士：需要进一步考虑。这个技术是基于具体的技术实现的。如果你的网站当前是使用其他的Ajax或者Comet技术来轮询的，转变成Server-Sent 事件需要重构网站的Javascript代码。
消除重定向
当用户在一个移动设备上访问桌面PC网站的时候，Web网站应用通常读取HTTP的user-agent头来判断这个用户是否是来自移动设备的。然 后应用会发送带有空HTTP body和重定向HTTP地址头的HTTP 301（或者302）请求，把用户重定向到网站的移动版本上去。但是，这个额外的客户端和服务端的交互通常在移动网络上会消耗几百毫秒。因此，在原先的请 求上传递移动的web页会比传递一个重定向的信息并让客户端再请求移动页面更快。
对于那些想要在移动设备上看桌面PC网站的用户来说，你可以在移动web页面上提供一个链接入口，这样也能同时表示你的网站是并不提倡这种行为的。
实现小贴士：虽然这个技术在理论上是简单的，但是实际上并不易于实施。由于有些m.sites是宿主在其他地方 的，所以许多网站会选择重定向到一个不同的服务器上。有的网站则是会在重定向请求的时候种植上Cookie告诉Web应用这个用户是在使用移动设备。这种 方法可能对web应用来说更容易控制。
减少资源负载
大小问题。渲染小页面更快，获取小资源也更快。减小每个请求的大小通常不如减少页面请求个数那么显著地提高性能。但是，有些技术在性能方面，特别是在需要对带宽和处理器性能精打细算的移动设备环境下，仍然是能带来很大利益的。
压缩文本和图像
诸如gzip这样的压缩技术，依靠增加服务端压缩和浏览器解压的步骤，来减少资源的负载。但是，一般来说，这些操作都是被高度优化过了。而且测试表 明，压缩对网站还是起到优化性能的作用的。那些基于文本的响应，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS可以减少大约70%的大小。
浏览器在Accept-Encoding请求头中申明它的解压缩技术，并且当它们接收到服务端返回的Content-Encoding响应头标示的时候，就会按照这个响应头自动做解压操作。
实现小贴士：易于实现。如果设置正确的话，现在所有的Web服务器都支持压缩响应。但是，也有一些桌面PC的安全工具会将请求头中的Accept-Encoding头去掉，这样即使浏览器支持解压缩，用户也无法获取到压缩后的响应。
简化通常是使用在脚本和样式文件中，删除一些不必要的字符，比如空格，换行符，或者注释等。不需要暴露给外部的命名就可以被缩短为一个或者两个字 符，比如变量名。合适的简化资源通常在客户端不需要做任何其他的处理，并且平均减少20%的资源大小。内嵌在HTML中的脚本和样式文件也是可以精简的。 有很多很好的库来做精简化的操作，这些库一般也同时会提供合并多个文件这样减少请求数的服务。
简化带来的好处并不局限于减少带宽和延迟，对于那些移动设备上缓存无法保存的过大资源来说，也是很有改善的。Gzip在这个方面并没有任何帮助，因为资源是在被解压后才被缓存起来的。
实现小贴士：易于实现。Google的Closure Compiler已经难以置信地完成了理解和简化Javascript的工作。但是CSS的简化则没有那么容易，因为对不同浏览器来说有不同的CSS技术 能迷惑CSS简化工具，然后让CSS简化后无法正常工作。必须要注意的是，已经有这样的案例了，即使只是删除了不必要的字符，简化工作也有可能破坏页面。 所以当你应用简化技术之后，请做一下完整的功能测试工作。
调整图片大小
图片通常是占用了Web页面加载的大部分网络资源，也占用了页面缓存的主要空间。小屏幕的移动设备提供了通过调整图片大小来加速传输和渲染图片资源的机会。如果用户只是在小的移动浏览器窗口中看图片的话，高分辨率的图片就会浪费带宽、处理时间和缓存空间。
为了加速页面渲染速度和减少带宽及内存消耗，可以动态地调整图片大小或者将图片替换为移动设备专用的更小的版本。不要依靠浏览器来将高分辨率的图片转换成小尺寸的图片，这样会浪费带宽。
另外一个方法是先尽快加载一个低分辨率的图片来渲染页面，在onload或者用户已经开始和页面交互以后将这些低分辨率的图片替换成为高分辨率的图片。
实现小贴士：特别应用在高度动态化的网站是有优势的。
使用HTML5和CSS 3.0来简化页面
HTML5包括了一些新的结构元素，例如header，nav，article和footer。使用这些语义化的元素比传统的使用div和span 标签能使得页面更简单和更容易解析。一个简单的页面更小加载更快，并且简单的DOM（Document Object Model）代表着更快的JavaScript执行效率。新的标签能很快地应用在包括移动端的新浏览器版本上，并且HTML5设计让那些不支持它的浏览器 能平稳过渡使用新标签。
HTML5的一些表单元素提供了许多新属性来完成原本需要javascript来完成的功能。例如，新的placeholder属性用于显示在用户输入进入输入框之前显示的介绍性文字，autofocus属性用于标示哪个输入框应当被自动定位。
也有一些新的输入框元素能不用依靠Javascript就可以完成一些通用的需求。这些新的输入框类型包括像e-mail，URL，数字，范围，日 期和时间这样需要复杂的用户交互和输入验证的元素。在移动浏览器上，当需要输入文本的时候，弹出的键盘通常是由特定的输入框类型来做选择的。不支持指定的 输入类型的浏览器就会只显示一个文本框。
另外，只要浏览器支持内建的层次，圆角，阴影，动画，过渡和其他的图片效果，CSS 3.0就能帮助你创建轻便简易的页面了，而这些图片效果原先是需要加载图片才能完成的。这样，这些新特性就能加速页面渲染了。
有很多Web站点都提供哪些移动或者桌面浏览器支持哪项性能的更新说明。（例如：/ 和 mobilehtml5.org）。
实现小贴士：需要进一步考虑。人工地做这些改动是非常复杂和耗时的。如果你使用CMS，它可以帮你生成许多你不需要控制的HTML和CSS。
优化客户端的程序处理
浏览器按照什么顺序来执行代码生成一个页面，和页面复杂性及JavaScript的技术选择，都对性能有很大的影响。特别在客户端相对较慢的CPUs和少内存的移动端中尤为明显。下面的章节提供一些策略来提升页面处理的性能。
延迟渲染&BELOW-THE-FOLD&内容
可以确定的是如果我们将不可见区域的内容延迟加载，那么页面就会更快地展现在用户面前，这个区域叫做&below the fold&。为了减少页面加载后需要重新访问的内容，可以将图片替换为正确的高宽所标记的&img&标签。
实现小贴士：平稳处理。一些好的Javascript库可以用来处理这些below-the-fold 延迟加载的图像。^12
延迟读取和执行的脚本
在一些移动设备上，解析Javascript代码的速度能达到100毫秒每千字节。许多脚本的库直到页面被渲染以后都是不需要的加载的。下载和解析 这些脚本可以很安全地被推迟到onload事件之后来做。例如，一些需要用户交互的行为，比如托和拽，都不大可能在用户看到页面之前被调用。相同的逻辑也 可以应用在脚本执行上面。尽量将脚本的执行延迟到onload事件之后，而不是在初始化页面中重要的可被用户看到的内容的时候执行。
这些延迟的脚本可能是你自己写的，更重要的是，也有可能是第三方的。对广告、社交媒体部件、或者分析的差劲的脚本优化会导致阻塞页面的渲染，会增加 珍贵的加载时间。当然，你需要小心地评估诸如jquery这样为移动网站设计的大型脚本框架，特别当你仅仅只是使用这些框架中的一些对象的时候更要小心评 估。
实现小贴士：平稳处理。许多第三方的框架现在提供延迟加载的异步版本的API。开发者只需要将原先的逻辑转化到 这个异步版本。一些JavaScript要做延迟加载会有些复杂，因为在onload之后执行这些脚本需要注意很多注意事项。（例如，你有个脚本需要绑定 到onload事件上，你需要做什么？如果你将脚本延迟到onload事件之后，就一定就会失去很多执行的时机。）
使用Ajax来增强进程
Ajax（Asynchronous JavaScript and XML）是一项使用XHR（XMLHttpRequest）对象来从Web服务器上获取数据的技术，它并不需要更新正在运行的页面。Ajax能更新页面上 的某个部分而不需要重新构建整个页面。它通常用来提交用户的交互相应，但是也可以用来先加载页面的框架部分，然后当用户准备好浏览网页的时候再填充详细的 内容。
尽管是这个名字，但是XMLHttpRequest并不强制要求你只能使用XML。你可以通过调用overrideMineType方法来制 定&application/json&类型来使用json替换XML。使用JSON.parse会比使用原生的eval()函数快了几乎两倍，并且更为 安全。
同时，切记Ajax的返回响应也会得益于那些应用在普通的返回响应的优化技术上面。确保对你的Ajax返回响应使用了缓存头，简化，gzip压缩，资源合并等技术。
实现小贴士：由于这个技术是根据具体应用不同而不同的，所以很难量化。或许由于跨域问题，你需要使用XHR2，这个技术能使用外部域的资源，从而能进行跨域的XHR请求。
根据网络状况进行适配处理
由于使用更多带宽会使用更多移动网络的费用，所以只有能检测网络的类型才能使用针对特定网络的优化技术。例如，预加载未来使用到的请求是非常聪明的做法，但是如果用户的带宽很稀有，并且加载的有些资源是永远不会用到的话，这个技术就是不合理的了。
在Android 2.2+，navigator.connection.type属性的返回值能让你区分Wifi和2G/3G/4G网络。在Blackberry 上，blackberry.network也能提供相似的信息。另外，服务端通过检测请求中的User-Agent头或者其他的嵌入到请求中的信息能让你 的应用检测到网络状况。
实现小贴士：需要进一步考虑。检测网络信息的API最近已经有所变化了。^11 接口现在不是直接定义Wi-Fi，3G等网络状况，而是给出了带宽信息和诸如&非常慢，慢，快和非常快&这样的建议。有个属性能给出估计的MB/s值和一 个&meterd&的Boolean值来表示它的可信度，但是对浏览器来说，很难根据这个来判断环境。判断当前网络环境然后适配仍然是一种最好的方法，但 是这种方法正在被考虑被替换。
对多线程来说尽量使用HTML5的WEB WORKER特性
HTML5中的Web Worker是使用多个线程并发执行Javascript程序。另外，这种特别的多线程实现能减少困惑开发者多年的，在其他平台上遇到的问题。例如，当一 个线程需要改变一个正在被其他线程使用的资源该如何处理。在Web Worker中，子线程不能修改主用户界面（UI）线程使用的资源。
对提高移动站点的性能来说，Web Worker中的代码很适合用来预处理用户完成进一步操作所需要的资源的，特别是在用户的带宽资源不紧缺的情况下。在低处理器性能的移动设备上，过多的预 加载可能会干扰当前页面的UI响应。使用多线程代码，让Web Worker对象（并且尽可能使用localStorage来缓存数据）在另外一个线程中操作预加载资源，这样就能不影响当前的UI表现了。
要特别说明的是，Web Worker只在Android 2.0以上的版本实现，而且iphone上的ios5之前的版本也不支持。在桌面PC上，总是落后的IE只在IE 10才支持Web Worker。
实现小贴士：平稳过渡。虽然这项技术并不是非常难实现，但是对Web Workers来说，有一些限制需要强制遵守。Web Workers不能进入到页面的DOM，也不能改变页面上的任何东西。Web Worker很适合那种需要后台计算和处理的工作。
将CLICK事件替换成TOUCH事件
在触摸屏设备上，当一个用户触碰屏幕的时候，onclick事件并没有立即触发。设备会使用大约半秒（大多数设备差不多都是300毫秒）来让用户确 定是手势操作还是点击操作。这个延迟会很明显地影响用户期望的响应性能。要使用touchend事件来替换才能解决。当用户触碰屏幕的时候，这个事件会立 即触发。
为了要确保不会产生用户不期望的行为，你应该也要使用touchstart和touchmove事件。例如，除非同时有个touchstart事件 在button上，否则不要判断touchend事件在button上就意味着点击行为 & 因为用户有可能从其他地方触碰开始，然后拖拽到button上触碰结束的。你也可以在touchstart事件之后使用touchmove事件来避免将 touchend事件误判为点击，当然前提是需要假设拖拽的手势并不是预期产生点击行为。
另外，你也需要去处理onclick事件来让浏览器改变button的外观从而标识为已点击的状态，同时你也需要处理那些不支持touch事件的浏 览器。为了避免代码在touchend和onclick代码中重复执行，你需要在确保用户触碰事件已经在touchend执行了之后，在click事件中 调用preventDefault和stopPropagation方法。^4
实现小贴士：需要进一步考虑。这种技术需要更多工作才能在一个页面中增加和维护链接。touch事件的代码必须考虑其他手势，因为替换click的还有可能是缩放或者敲击动作。
支持SPDY协议
应用层HTTP和HTTPS协议导致的一些性能瓶颈，使得不论是桌面还是移动端的网站都非常难受。在2009年，谷歌开始研发一种叫做SPDY（谐 意是&speedy&）的协议来替换已有的协议，这种协议宣称能突破这些限制。这个协议的目标是让多种浏览器和多种Web服务都能支持，所以这个协议是开 源的，但是初步地，只有Google的Chrome浏览器（在版本10及之后的）和google的站点支持。一旦一个Web服务支持SPDY，那么它上面 的所有站点都可以和支持这个协议的浏览器使用SPDY进行交互。将SPDY应用在25个top100的Internet网站上，Google收集到的数据 是网站的速度会改善27%到60%不等。^2
SPDY自动使用gzip压缩所有内容，和HTTP不同的是，它连header的数据也使用gzip压缩。SPDY使用多线程技术让多个请求流或者响应流能共用一个TCP连接。另外SPDY允许请求设置优先级，比如，页面中心的视频会比边框的广告拥有更高的优先级。
或许SPDY中最变革性的发明就是流是双向的，并且可以由客户端或者服务端发起，这样能使得信息能推送到客户端，而不用由客户端发起第一次请求。例 如，当一个用户第一次浏览一个站点，还没有任何站点的缓存，这个时候服务端就可以在响应中推送所有的请求资源，而不用等候每个资源被再次独立请求了。作为 替换协议，服务端可以发送暗示给客户端，提示页面需要哪些资源，同时也允许由客户端来初始化请求。即使是使用后一种这样的方式也比让客户端解析页面然后自 己发现有哪些资源需要被请求来得快。
虽然SPDY并没有对移动端有什么特别的设置，但是移动端有限的带宽就使得如果支持SPDY的话，SPDY在减少移动网站的延迟是非常有用的。
实现小贴士：依据网站和服务的环境来进行平稳操作或进一步考虑。Google有一个SPDY模块支持 Apache2.2 & mod_spdy & 这个模块是免费的；但是mod_spy有线程上的问题，并且和mod_php协作并不是很好，所以要求你使用这个技术的时候要确保你的网站的正常运行。 ^6
永远别忘记测试！
如果缺少了持续和仔细的测试提醒，性能的优化就只是讨论而已，是无法完成的。如果没有指定基准做比较，你系统上的任何改动都仅仅是理论而已。如果没有真实的测试数据，猜测性能的瓶颈是毫无意义的。
有很多开源和通用的工具能进行集成测试，并且能进行不同地域和带宽/延迟的测试。另外，RUM（real user monitoring）工具能将测试环境从实验室变成不可预测的真实用户行为。
观察移动设备的测试选择和桌面场景一样。如果你在选择一个自动化的解决方案，请确保使用一个能持续测试，并且能区分出应用优化方法前后的变化的解决方案。
如果性能优化如果只是在发展过程中的一个步骤而已，它不会有什么效果的。它必须成为一个持续改善网站的一部分。
1. Bustos, L. 2009. E how website performance impacts shopper behavior. GetE.
2. Chromium Projects. SPDY: an experimental protocol for a faster W.
3. Everts, T. 2013. Case study: how effective are CDNs for mobile visitors. Web Performance T.
4. Fioravanti, R. 2011. Creating fast buttons for mobile Web applications. Google D.
5. Linden, G. 2006. Marissa Mayer at Web 2.0. Geeking with G.
7. PhoCusWright. 2010. PhoCusWright/Akamai study on tra;.
8. Radware. 2011. Case studies from the mobile frontier: the relationship between faster mobile sites and business KPIS;&.
9. Bixby, J.
state of mobile e-.
10. Tealeaf. 2011. Report on the Mobile Customer Experience. Based on the Harris Interactive 2011 Mobile Transactions Survey.
11. W3C. 2012. Network Information API;&.
12. YUI. ImageLoader. Yahoo! User Interface L&.
阅读(...) 评论() &