您所在的位置： &
案例学习：优化移动Web产品的四个要点
案例学习：优化移动Web产品的四个要点
世界范围内移动设备的使用数量在与日俱增。面对在跨越多个不同设备上创建良好web体验的挑 战，现在已经存在多种解决方案。但是对于任何一个给定的项目，这些解决方案中哪个是最合适的?为了回答这个问题，《移动优先》作者Luke以 Bagcheck应用作为案例(注：Bagcheck是一家从事搜索与发现业务的创新型企业)，解释了选择分别设计移动版和桌面版背后的原因，并通过对比 提炼出四个优化移动Web产品的建议。全文如下：
本人是响应式Web设计 (Responsive Web
Design)理念的拥护者和粉丝。但经常有人这样问我：为什么我们还要为Bagcheck单独构建一个独立的移动版本，而不使用流体网格(fluid
grids)，弹性图片(flexible images)和媒体查询(media
queries)等方法来为我们的移动用户提供一个响应式Web解决方案?
对于我们的 Bagcheck站点来讲，网站性能以及网站开发速度是两个至关重要的问题。我们所做的决定中，很多都是为了使网站性能和开发速度两者都尽可能的快(毕竟 我们是一家新成立的企业)。作为我们关注网站性能的一部分，我们也很注重&什么才是必须的&这样的理念。这意味着我们需要向不同设备或者用户呈现一些他们 需要的东西。我们乐于做一些优化工作。使用双重模板系统(dual template
system)我们就可以从以下多个方面进行优化，比如资源顺序(source order)，媒体(media)，URL结构以及应用程序设计。
最初我们以命令行接口(command-line
interface)的形式构建Bagcheck，在此基础之上我们创建了一个移动Web体验版的Bagcheck，接着很快就开发出了一个桌面Web体 验版的Bagcheck。这样的过程很可能也影响到了我们所使用的开发方法。
另外值得一提的是，虽然自己能够胜任编码工作，但我主要是一个设计师。因为我关注的焦点是设计要素，所以在这篇文章里会尽量多的包含一些技术层面的资源链接，如果你有更多的资源和实现想法，赶快发给我吧!
资源顺序(Source Order)
响 应式Web设计(Responsive Web
Design)最为核心的部分是,将相同的HTML代码应用到不同的设备上面来，并且根据具体设备自身的性能来动态调整(主要是通过CSS)外观显示。 HTML标记有一个资源顺序，这个资源顺序通常规定Web页面如何被浏览器渲染。尽管可以使用JavaScript和CSS技术来改变HTML元素的位置 布局，但想以一种可靠的方式在多种不同设备上面进行HTML元素重定位则非常具有挑战性。
就拿网站导航菜单这个简单的例子来说吧，对于那些拥有较大屏幕以及鼠标/键盘等输入的设备来说，将导航菜单放置到网页的顶部是很常见的做法，其原因有以下几个方面：
设备屏幕拥有足够多的空白区，页面实际内容不可能被挤出屏幕之外。
通常需要通过一些关键的类别和动作集合来决定在网站上显示什么内容。
当这些关键的分类和动作集合与屏幕/浏览器的边缘对齐时，访问他们的速度可能会更快一些。将网站的整体导航放在在网页顶部是很有意义的，所以标记资源顺序就成为首先得考虑的问题。
然而在那些有着校小屏幕并且触摸作为输入的设备，将网站的整体导航放在网页底部会更加合理一些，这是因为：
小屏幕设备没有足够多的空白区域，导致网页的实际内容被网站的整体导航按钮挤出屏幕之外。
对于小屏幕和低带宽的设备来说，相对于网站的导航功能，用户更关注的是网站内容的立即访问。
人类工程学的因素使得用户更容易在屏幕底部点击到他们感兴趣的目标。
所 以对于移动设备来讲，将网站的整体导航按钮放置在网页的底部是非常合理的做法，这样做就意味着菜单标记(menu
markup)在资源顺序中很可能是排在最后面的。当在不同设备上使用相同的HTML代码时，资源顺序不可能被改变。使用双重模板系统，我们在构建 Bagcheck的时候就可以提供不同的标记，因此在移动设备上就会有不同的资源顺序。下图展示的是我们为移动设备和桌面设备生成的两种不同的UI界面。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' alt="案例学习：优化移动Web产品的四个要点" src="/wyfs01/M00/1B/FE/wKioJlIu6rWTMg10AABw7qQWKwQ426.jpg" />
当 然你也可以使用其他解决方案，不用提供不同的HTML代码也可以达到相似的效果。Box-direction能够反转条目列表的顺序而不会影响到资源标记 顺序。你也可以尝试使用display：table的方法来根据设备屏幕的实际大小重新生成内容显示和网站导航。这些方法可能会更适合你，就看你的需求 了。
媒体(Media)
响应式Web设计另外一个方法是使用弹性图片(flexible images)和视频。当被设置为填充他们容器大小的格式的时候，弹性图像能够根据浏览器视图中的可用空白区来动态调整自己的大小。
在较大的浏览器视图中，弹性图片可以通过显示自身的原始大小来填充更多的空白区域。在较小的浏览器视图中，相同的图片可以缩放自身大小从而占用较少的空白区域。为了实现这样的效果，浏览器需要一些较大的图片，这些图片不管是在放大或者缩小的时候看起来都要有不错的效果。
现在的问题是，图像越大，文件的大小就越大。虽然并不是所有的Web浏览器都以他们的原始大小来显示图像，但浏览器需要下载整个图片文件，这样会很快导致低性能，除非这样做：
结合使用CSS Media Queries ,背景图片不显示，以及不要加载仅仅为较大浏览器视图准备的大图等方法。这种方法对于指定图片标签(image tags)的那些图片是无效的，仅仅对使用CSS图片背景的那些图片有效果，这样就限制了此方法的适用性。
你可以使用像响应式图片(Responsive Images)这样的解决方案，这种方法依赖Javascript语言来将HTML标记的小图片根据浏览器视图大小的增加替换成较大的图片。禁用Javascript和cookie功能的浏览器只能够显示相应的小图片。
尝试类似noscript tag这样的方法，来阻止不必要的图片加载。
使用服务器端的解决方案来检测访问你的站点的设备，并且只传递一些必要的东西。
隐藏在这些解决方案下面的相同理念是，使用media queries，背景图片，JavaScript或者服务器端的解决方案等方法来仅向设备呈现必要的东西。这种方法可以显著地减少文件传输大小并且提高网站性能。
举个例子来讲，
Bagcheck的移动优化模板为每个列表上的项目提供50&50像素大小的压缩图片(平均大小为3KB)，而Bagcheck桌面优化模板则为相应的列 表项目提供200&125像素大小的图片(平均大小为15KB)。拥有20个表项也就是300KB大小的差异外加少于20个http请求的页面对于网站性 能有非常大的影响。我们拥有独立的移动模板，所以就只需要在移动设备上显示列表的前10个表项，这样就可以另外减少30KB的负载。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' alt="案例学习：优化移动Web产品的四个要点" src="/wyfs01/M00/1B/FE/wKioJlIu6rijG6aWAACGLnCKmfo960.jpg" />
桌面设备上一个分类页面总共有360KB大小的图片，而相应地页面在移动设备上只有30KB大小，这确实是个非常大的差异。
但是优化图片不仅仅是文件大小的优化，你也可以为小屏幕设备精心设计一些显示图片，而不是通过缩放来适应屏幕的大小。当图片中的内容很重要的话，这样子做就显得尤其重要。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' alt="案例学习：优化移动Web产品的四个要点" src="/wyfs01/M00/1B/FE/wKioJlIu6rnx8DtcAACBmnq0DMs855.jpg" />
同样的系统可以用来优化视频显示。在所有设备上，我们希望通过简单的单击操作就能够完成视频回放。所以我们的桌面模板将视频文件直接嵌入到页面中，而移动模 板仅仅显示一个缩略图，两者都只需要通过简单的单击操作就可以开始播放视频。在移动设备上面使用缩略图可以使得视频加载速度更快，并且能够更好地控制页面 布局/像素尺寸。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' alt="案例学习：优化移动Web产品的四个要点" src="/wyfs01/M00/1C/00/wKioOVIu6sfiFK_3AAB7GID4Jr4046.jpg" />
URL结构(URL structure)
我们不仅仅只从资源顺序(Source order)和媒体(Media)两个方面来优化移动版本的Bagcheck。在某些情况下，独特的URL结构将会对站点性能以及小屏幕低速连接的设备的用户体验产生重大的影响。
例如，桌面版的Bagcheck在一个URL上面显示所有的内容列表，评论，更新和偏好。我们将这些部分或者模块捆绑在一个单一文件中，然后在无须刷新页面的情况下动态加载每个模块。这样做可以在桌面体验上产生一个平滑过渡，但在移动体验方面就会增加许多带宽负担。
所以移动Web版本的Bagcheck使用不同的URL结构。相同的URL加载相同的初始内容，但是每个子模块都拥有一个唯一的URL和一个独立的页面，如下图所示：
498)this.width=498;' onmousewheel = 'javascript:return big(this)' src="/wyfs01/M01/1B/FF/wKioJlIu6sjg6zfgAADGyyqUDtc332.jpg" alt="案例学习：优化移动Web产品的四个要点" />
在这个模型里，在移动设备和桌面设备上加载相同的内容，但是以下这些都是移动设备上才有的URL。使用这样的结构，我们通过将较大的文件分成小块就可以更进 一步地优化性能。另外值得注意的是，我们将这些移动设备特有的URL设置为&nofollow&，这样搜索引擎就不会对他们进行索引。
应用程序设计(Application Design)
URL结构也可以帮助优化移动设备上的扩展交互。将更长的任务或者多步/多模块的应用程序组织在不同的页面上，可以让用户一次只处理一种交互。在较大屏幕上，通过模态对话框或者模块/面板进行的交互，通常也可以达到在较小屏幕上使用独立页面的效果。
现代智能手机和桌面/手提电脑之间的设备性能千差万别。例如在移动设备上可以获得10-50m范围内的精确位置信息，而在桌面/手提电脑上却只能获得更小范围的信息。这种信息的获取能够显著地改变应用程序接口的设计。
我 们构建Bagcheck时使用的双重模板系统使得我们能够优化更长的交互,并且能够在我们的应用程序内部利用设备功能。在移动设备上我们启动了条形码扫描 功能，这样子用户就可以使用手机内置的摄像机来识别物品。我们也重新组织了非线性列表创建工具(non-linear list creation
tool)，使其成为手机上一系列更为专注和短小的任务。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' src="/wyfs01/M01/1C/00/wKioOVIu6syBQ2iMAABeAwZYYEw236.jpg" alt="案例学习：优化移动Web产品的四个要点" />【编辑推荐】【责任编辑： TEL：（010）】
关于&&&&的更多文章
越来越多的web设计师提出了移动优先的口号，而随着硬件设施的完
Windows Phone开发创建吸引人、带给人快乐并保留用户
作为Android开发人员，在开发项目的过程中，我们往往
BaaS是Backend as a Service的简称，意为后端即服务，
Java Web程序员直接在JSP页面中书写Java代码的做法，使得页面中混杂有JavaScript、HTML、Java等多种语言的程序代码，可读性差，
Windows Phone专家
Android开发专家
51CTO旗下网站PCweb开发与移动web开发区别在于什么？
我的图书馆
PCweb开发与移动web开发区别在于什么？
这篇文章只是我深入了解移动领域开发过程中的不断整理和总结，其中涉及到很多概念，观点，个人的看法，有不确切的地方，欢迎指正。首先要明确移动web和webapp是不同的1：移动web开发这部分跟web前端开发差别不大，使用的技术都是html+css+js。区别为手机浏览器是webkit的天下，pc端是三足鼎立IEfirefox &chorme。手机网页可以理解成pc网页的缩小版加一些触摸特性。因为是在浏览器中进行的网页开发，所有最终代码具有跨系统平台的特性。2：web App开发特指的是用html5技术开发，之所以叫web app是因为他比较接近客户端应用程序的用户体验，可以和系统深度融合，调用一些只有客户端才能调用的功能（比如在移动设备上利用html5开发出的网页可以访问电话、摄像头等本地功能）那么PCweb开发与移动web开发区别在于什么？1面向人群来说l &从用户角度:pc端主要使用鼠标，鼠标的操作尺度比较小，点击是一件准确的事情；而移动端web上主要是触屏，触屏的操作尺度就比较大，点击误差大，所以元素必须往大了做，也不支持hover事件。这一点淘宝网页的PC版和手机web版是个非常良好的例子。PC淘宝中有些小按钮能放下的功能，移动版就必须另弹界面让用户详细输入。ll & 从开发人员角度:UI（网页用户界面）设计师要考虑到移动端特点，便于触屏操作。至于代码实现效果时基本差不多。2MVCM：模型，即HTML代码，移动web会更关注meta标签，通过这些标签我们会定制我们移动web开发的一些行为和样式。V：即css语言，这两者会存在非常大的不同，进入移动web开发，会发现安卓设备和苹果设备的分辨率会存在分辨适配的问题，而pc上只需要写死一个宽度就差不多。PC端咱们最常用的就是固定宽度，但移动端就不能这么用了，因为很多网页都是可以横屏看，也可以竖屏看；很多屏幕的分辨率不一样；所以只要牵涉到移动端，就要牵涉到响应式（也叫自适应）；&&C：js，这个题主应该更详细一些，因为有没有canvas对js影响很大；第一、普通移动端网页（比如手机新浪网，手机淘宝，手机百度等）这个在js方面和PC端区别不是太大；主要的区别在于移动端没有了鼠标悬停（onmouseover）;点击（onclick）还可以用；多了触摸、滑动。第二、canvas相关游戏canvas相关的html5增加了好多js，不过我不做游戏方面，所以就不多废话了；移动 Web 应用性能的 5 个秘籍 - 技术翻译 - 开源中国社区
移动 Web 应用性能的 5 个秘籍
【已翻译100%】
英文原文：
推荐于 4年前 (共 20 段, 翻译完成于 08-07)
参与翻译&(9人)&: ,
最近我们听到一些关于移动HTML性能的一些秘籍，实际上它们并不是很准确。和好的“城市秘籍”一样，它们听起来令人信服的和可信。但是这些秘籍是基于，不正确的前提和对本地和网络软件栈之间关系的误解，以及曲解数据的散点。 我们认为重要的是，要对这些秘籍进行验证，使用用我们已经收集了多年来关于性能的数据和我们自己的做的移动 Web 应用程序性能的经验。
秘籍1：移动网络性能主要是由运行在CPU上的JavaScript性能决定
现实：大多数网络性能是由渲染管线的优化程度，GPU加速程度，DOM交互速度三者制约。更快的JavaScript总是有用的，但它很少是决定因素。
&翻译得不错哦！
秘籍2：因为硬件不停的升级，CPU越快，JavaScirpt执行的也会越快(又称摩尔定律)
事实上：在过去四年间，移动设备上的JavaScript的渲染提速都是通过软件的优化来实现的，而不是通过硬体的加速。尽管单线程渲染JavaScript的速度有所提升，但是大多数网络程序还是尽可能采用多线程来提升JavaScript整体性能。
秘籍3：移动设备浏览器已经优化的相当好了，没有多少提升的空间了
事实上：每一个移动设备浏览器都有自己的优势，有时甚至会超过对手10-40倍。Surface在SVG方面比iPhone好30倍。iPhone在DOM交互方面胜过Surface10倍。看来，和对手优点比较后还是有明显提升空间的。
&翻译得不错哦！
秘籍4: 未来的硬件提升不太可能转变为web app的性能增益
现实：过去三年中每一代硬件都带来了显著的JavaScript性能提升。手机上的单线程性能将会持续改进，浏览器开发人员也将会提升软件平台，通过减轻负载与多线程，充分利用增强的GPU速度， 与多核。许多浏览器已经能利用并行的优势，以减轻主UI线程的负载，例如：; C 以及 。
&翻译得不错哦！
秘籍 5: JavaScript 垃圾搜集对移动app是一个性能杀手
现实:这是真实的但有点过时。在2011年，Chrome已经。 。这缩减了GC停顿约200ms到10ms —— 或者说从一个掉帧 到一个明显的停顿。避免垃圾回收事件能对性能有显著的改进，但如果你主要使用的是桌面web开发模式或者用的是老的浏览器，它通常会成为一个杀手。在Fastbook（传享网），我们的移动HTML5版的Facebook克隆网站中，一个核心的技术就是循环利用一批DOM节点，以避免创建新节点的开支（以及对老节点GC回收的相关开支）。非常有可能写出一个糟糕的垃圾搜集器（参看老的Internet Explorers），但是并没有本质上限制垃圾搜集的语言，像JavaScript (或 Java)。
&翻译得不错哦！
总结一下：
首先，让咱看看一些基本常识。总而言之，浏览器是个运行在OS上有着非常复杂抽象层的程序。是用HTML，JavaScript和CSS创造抽象层的混合体。不同的抽象层会有不同的效果。有些抽象层运行的很快是因为它潜在调用OS调用或是用接近系统库的库(在MacOS上又称Canvas2D)。有些抽象层很慢因为他们很少用OS调用，而且他们本身太复杂(DOM树，或是原型链)。
有关Sencha，我们知道，优秀的程序员创造的程序会很快，甚至出乎我们意料之外，因为他们都用一些移动网络技术和一些流行的框架如Sencha Touch。
&翻译得不错哦！
很少有移动设备作为计算中心，就像没人会在iPhone上计算DNA序列。大多数移动应用程序都会合理响应用户操作。当用户有所操作时，移动应用程序会以每秒30帧或者更快的速度来予以响应，大概用数百毫秒来完成。只要程序达到用户的目标，不是说用更多的硅片就能达到的。这就像是我们突然转移话题说我们烹饪和饮食。
有关Sencha，我们知道，优秀的程序员创造的程序会很快，甚至出乎我们意料之外，因为他们都用一些移动网络技术和一些流行的框架如Sencha Touch。在过去的3年间我们以此而受到鼓舞。我们喜欢在此分享这些数据。
&翻译得不错哦！
我们的意思不是说移动网络应用程序
总比本地程序快，或是总和桌面网络应用程序做比较。这是不切实际的，移动设备的硬件要比桌面硬件设备慢5-10倍：CPU更弱，缓存等级更低，网络链接延迟更大。而且任何层次的程序(如浏览器)都有很大的消耗。这不是程序员的问题(我喜欢这一句，译者注)。iOS开发程序员会给你说iOS CoreGrapics在Retina iPad跑会很慢，因为他们都得直接用OpenGL进行开发。
&翻译得不错哦！
深入探讨秘籍
在多年为Sencha Touch的数据驱动的应用程序的性能优化工作中，我们可以满怀信心地说，我们很少有人被JavaScript性能优化所困扰。唯一的重大案件迄今为止是Sencha触摸布局系统,我们在发现界面切换到Flexbox后，JavaScript在Android 2. X运行过于缓慢。更多的时候，我们碰到的问题是与DOM交互，浏览器渲染引擎和垃圾事件有关。所有这些问题都是每个浏览器的架构师和开发人员创建的，与 Javascript或Javascript引擎的固有特性无关。作为一个例子，当我们与浏览器厂商在性能优化方面合作时，我们已经看到了在一个40倍的改善在浏览器一个操作（颜色属性变化操作），这个操作是我们的滚动列表实现的速度瓶颈，这只是其中的一例。
&翻译得不错哦！
JavaScript 在IOS和android上的性能
尽管我们说JavaScript在移动设备上的性能不是那么的重要，但是我们要反驳这段始终没有得到改善的神话。以下是通过IOS的模型和版本展示出了历史四年来SunSpider在IOS的数据得分（分数越低越好）。（幸运的是，SunSpider是一个用的非常广泛的测试工具，它记录了所有的IOS版本的网络数据）。在2009年， 最初运行IOS3的IPhone 3GS有得到一个已经超过了15000的分值——是如此低的性能，与2009年的桌面浏览器有20倍的差距。
然而，如果你把Iphone 3GS升级到了IOS4,5或者6，你将会在相同的硬件设备上提升4倍的JavaScript性能。（性能提高最大的是使用Nitro引擎的IOS4 和IOS5之间）SunSpider继续在性能不断提升的SunSpider上测试，但我们任低于那些NDA。与当今的桌面浏览器相比，边缘的移动浏览器的约慢5倍——与2009年相比却有30倍的提升
&翻译得不错哦！
想了解更多ISO软硬件方面的改进，参见。
Android平台也有类似层次的改进。在我们的实验室里，我们组建了一个过去的三年里Android平台的集合，我们认为它们代表了典型的高端配置。我们测试了四部手机：
Samsung Captivate Android 2.2 (2010年7月发布)
Droid Bionic Android 2.3.4 (2011年9月发布)
Samsung Galaxy Note 2 Android 4.1.2 (2012年9月发布)
Samsung Galaxy S4 Android 4.2.2 (2013年4月发布)
正如你在下面看到的，这是一张过去的四年里SunSpider得分曲线，一个戏剧性的改善。从Android 2.x到Android 4.x性能有3倍的改善。
在这两种情况下，改进都比我们依据摩尔定律预测的好得多。在过去的3年里，我们期待一个4倍的提升（2倍每18个月），所以软件肯定是导致性能的改善的要因。
&翻译得不错哦！
我们的翻译工作遵照 ，如果我们的工作有侵犯到您的权益，请及时联系我们
你好，Surface在SVG方面比iPhone好30倍。这个数据是从SVG基准测试得来的，从图片中可以看出，Surface绘制10000段SVG路径所花费的时间为大约300~500左右，而iphone5绘制10000段SVG路径所花费的时间大约为11000左右，30≈。iPhone在DOM交互方面胜过Surface10倍，从测试关键因素 第二部分的图表中可以看出IPhone5的Dromaeo测试得出的DOM指数IPhone指数为5.5左右而Surface得分为0.5左右，10≈5.5/0.5。H5缓存机制浅析-移动端Web加载性能优化【干货】 - 简书
H5缓存机制浅析-移动端Web加载性能优化【干货】
转载:作者：贺辉超，腾讯游戏平台与社区产品部 高级工程师目录1 H5缓存机制介绍2 H5缓存机制原理分析2.1 浏览器缓存机制2.2 Dom Storgage（Web Storage）存储机制2.3 Web SQL Database存储机制2.4 Application Cache（AppCache）机制2.5 Indexed Database （IndexedDB）2.6 File System API3 移动端Web加载性能（缓存）优化1 H5缓存机制介绍H5，即HTML5，是新一代的HTML标准，加入很多新的特性。离线存储（也可称为缓存机制）是其中一个非常重要的特性。H5引入的离线存储，这意味着 web 应用可进行缓存，并可在没有因特网连接时进行访问。H5应用程序缓存为应用带来三个优势：离线浏览 - 用户可在应用离线时使用它们速度 - 已缓存资源加载得更快减少服务器负载 - 浏览器将只从服务器下载更新过或更改过的资源。根据标准，到目前为止，H5一共有6种缓存机制，有些是之前已有，有些是H5才新加入的。浏览器缓存机制Dom Storgage（Web Storage）存储机制Web SQL Database存储机制Application Cache（AppCache）机制Indexed Database （IndexedDB）File System API下面我们首先分析各种缓存机制的原理、用法及特点；然后针对Anroid移动端Web性能加载优化的需求，看如果利用适当缓存机制来提高Web的加载性能。2 H5缓存机制原理分析2.1 浏览器缓存机制浏览器缓存机制是指通过HTTP协议头里的Cache-Control（或Expires）和Last-Modified（或Etag）等字段来控制文件缓存的机制。这应该是WEB中最早的缓存机制了，是在HTTP协议中实现的，有点不同于Dom Storage、AppCache等缓存机制，但本质上是一样的。可以理解为，一个是协议层实现的，一个是应用层实现的。Cache-Control用于控制文件在本地缓存有效时长。最常见的，比如服务器回包：Cache-Control:max-age=600表示文件在本地应该缓存，且有效时长是600秒（从发出请求算起）。在接下来600秒内，如果有请求这个资源，浏览器不会发出HTTP请求，而是直接使用本地缓存的文件。Last-Modified是标识文件在服务器上的最新更新时间。下次请求时，如果文件缓存过期，浏览器通过If-Modified-Since字段带上这个时间，发送给服务器，由服务器比较时间戳来判断文件是否有修改。如果没有修改，服务器返回304告诉浏览器继续使用缓存；如果有修改，则返回200，同时返回最新的文件。Cache-Control通常与Last-Modified一起使用。一个用于控制缓存有效时间，一个在缓存失效后，向服务查询是否有更新。Cache-Control还有一个同功能的字段：Expires。Expires的值一个绝对的时间点，如：Expires: Thu, 10 Nov :11 GMT，表示在这个时间点之前，缓存都是有效的。Expires是HTTP1.0标准中的字段，Cache-Control是HTTP1.1标准中新加的字段，功能一样，都是控制缓存的有效时间。当这两个字段同时出现时，Cache-Control是高优化级的。Etag也是和Last-Modified一样，对文件进行标识的字段。不同的是，Etag的取值是一个对文件进行标识的特征字串。在向服务器查询文件是否有更新时，浏览器通过If-None-Match字段把特征字串发送给服务器，由服务器和文件最新特征字串进行匹配，来判断文件是否有更新。没有更新回包304，有更新回包200。Etag和Last-Modified可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。另外有两种特殊的情况：手动刷新页面（F5)，浏览器会直接认为缓存已经过期（可能缓存还没有过期），在请求中加上字段：Cache-Control:max-age=0，发包向服务器查询是否有文件是否有更新。强制刷新页面（Ctrl+F5)，浏览器会直接忽略本地的缓存（有缓存也会认为本地没有缓存），在请求中加上字段：Cache-Control:no-cache（或Pragma:no-cache），发包向服务重新拉取文件。下面是通过Google Chrome浏览器（用其他浏览器+抓包工具也可以）自带的开发者工具，对一个资源文件不同情况请求与回包的截图。首次请求：200
缓存有效期内请求：200(from cache)
缓存过期后请求：304（Not Modified)
一般浏览器会将缓存记录及缓存文件存在本地Cache文件夹中。Android下App如果使用Webview，缓存的文件记录及文件内容会存在当前app的data目录中。分析：Cache-Control和Last-Modified一般用在Web的静态资源文件上，如JS、CSS和一些图像文件。通过设置资源文件缓存属性，对提高资源文件加载速度，节省流量很有意义，特别是移动网络环境。但问题是：缓存有效时长该如何设置？如果设置太短，就起不到缓存的使用；如果设置的太长，在资源文件有更新时，浏览器如果有缓存，则不能及时取到最新的文件。Last-Modified需要向服务器发起查询请求，才能知道资源文件有没有更新。虽然服务器可能返回304告诉没有更新，但也还有一个请求的过程。对于移动网络，这个请求可能是比较耗时的。有一种说法叫“消灭304”，指的就是优化掉304的请求。抓包发现，带if-Modified-Since字段的请求，如果服务器回包304，回包带有Cache-Control:max-age或Expires字段，文件的缓存有效时间会更新，就是文件的缓存会重新有效。304回包后如果再请求，则又直接使用缓存文件了，不再向服务器查询文件是否更新了，除非新的缓存时间再次过期。另外，Cache-Control 与 Last-Modified 是浏览器内核的机制，一般都是标准的实现，不能更改或设置。以QQ浏览器的X5为例，Cache-Control 与 Last-Modified 缓存不能禁用。缓存容量是12MB，不分HOST，过期的缓存会最先被清除。如果都没过期，应该优先清最早的缓存或最快到期的或文件大小最大的；过期缓存也有可能还是有效的，清除缓存会导致资源文件的重新拉取。还有，浏览器，如X5，在使用缓存文件时，是没有对缓存文件内容进行校验的，这样缓存文件内容被修改的可能。分析发现，浏览器的缓存机制还不是非常完美的缓存机制。完美的缓存机制应该是这样的：缓存文件没更新，尽可能使用缓存，不用和服务器交互；缓存文件有更新时，第一时间能使用到新的文件；缓存的文件要保持完整性，不使用被修改过的缓存文件；缓存的容量大小要能设置或控制，缓存文件不能因为存储空间限制或过期被清除。以X5为例，第1、2条不能同时满足，第3、4条都不能满足。在实际应用中，为了解决Cache-Control缓存时长不好设置的问题，以及为了”消灭304“，Web前端采用的方式是：在要缓存的资源文件名中加上版本号或文件MD5值字串，如common.d5d02a02.js，common.v1.js，同时设置Cache-Control:max-age=，也就是一年。在一年时间内，资源文件如果本地有缓存，就会使用缓存；也就不会有304的回包。如果资源文件有修改，则更新文件内容，同时修改资源文件名，如common.v2.js，html页面也会引用新的资源文件名。通过这种方式，实现了：缓存文件没有更新，则使用缓存；缓存文件有更新，则第一时间使用最新文件的目的。即上面说的第1、2条。第3、4条由于浏览器内部机制，目前还无法满足。2.2 Dom Storage存储机制DOM存储是一套在Web Applications 1.0 规范中首次引入的与存储相关的特性的总称，现在已经分离出来，单独发展成为独立的W3C Web存储规范。 DOM存储被设计为用来提供一个更大存储量、更安全、更便捷的存储方法，从而可以代替掉将一些不需要让服务器知道的信息存储到cookies里的这种传统方法。上面一段是对Dom Storage存储机制的官方表述。看起来，Dom Storage机制类似Cookies，但有一些优势。Dom Storage是通过存储字符串的Key/Value对来提供的，并提供5MB（不同浏览器可能不同，分HOST)的存储空间（Cookies才4KB)。另外Dom Storage存储的数据在本地，不像Cookies，每次请求一次页面，Cookies都会发送给服务器。DOM Storage 分为 sessionStorage 和 localStorage。localStorage 对象和 sessionStorage 对象使用方法基本相同，它们的区别在于作用的范围不同。sessionStorage 用来存储与页面相关的数据，它在页面关闭后无法使用。而 localStorage 则持久存在，在页面关闭后也可以使用。Dom Storage提供了以下的存储接口：
sessionStorage 是个全局对象，它维护着在页面会话(page session)期间有效的存储空间。只要浏览器开着，页面会话周期就会一直持续。当页面重新载入(reload)或者被恢复(restores)时，页面会话也是一直存在的。每在新标签或者新窗口中打开一个新页面，都会初始化一个新的会话。
当浏览器被意外刷新的时候，一些临时数据应当被保存和恢复。sessionStorage 对象在处理这种情况的时候是最有用的。比如恢复我们在表单中已经填写的数据。把上面的代码复制到session_storage.html（也可以从附件中直接下载）页面中，用Google Chrome浏览器（）的不同PAGE或WINDOW打开，在输入框中分别输入不同的文字，再点击“Save”，然后分别刷新。每个PAGE或WINDOW显示都是当前PAGE输入的内容，互不影响。关闭PAGE，再重新打开，上一次输入保存的内容已经没有了。
Local Storage的接口、用法与Session Storage一样，唯一不同的是：Local Storage保存的数据是持久性的。当前PAGE 关闭（Page Session结束后），保存的数据依然存在。重新打开PAGE，上次保存的数据可以获取到。另外，Local Storage是全局性的，同时打开两个PAGE会共享一份存数据，在一个PAGE中修改数据，另一个PAGE中是可以感知到的。
将上面代码复制到local_storage.html的页面中，用浏览器打开，pageLoadCount的值是1；关闭PAGE重新打开，pageLoadCount的值是2。这是因为第一次的值已经保存了。
用两个PAGE同时打开local_storage.html，并分别交替刷新，发现两个PAGE是共享一个pageLoadCount的。
分析：Dom Storage 给Web提供了一种更录活的数据存储方式，存储空间更大（相对Cookies)，用法也比较简单，方便存储服务器或本地的一些临时数据。从DomStorage提供的接口来看，DomStorage适合存储比较简单的数据，如果要存储结构化的数据，可能要借助JASON了，将要存储的对象转为JASON字串。不太适合存储比较复杂或存储空间要求比较大的数据，也不适合存储静态的文件等。在Android内嵌Webview中，需要通过Webview设置接口启用Dom Storage。
拿 Android类比的话，Web 的Dom Storage机制类似于Android的SharedPreference机制。2.3 Web SQL Database存储机制H5也提供基于SQL的数据库存储机制，用于存储适合数据库的结构化数据。根据官方的标准文档，Web SQL Database存储机制不再推荐使用，将来也不再维护，而是推荐使用AppCache和IndexedDB。现在主流的浏览器（）都还是支持Web SQL Database存储机制的。Web SQL Database存储机制提供了一组API供Web App创建、存储、查询数据库。下面通过简单的例子，演示下Web SQL Database的使用。
将上面代码复制到sql_database.html中，用浏览器打开，可看到下面的内容。
官方建议浏览器在实现时，对每个HOST的数据库存储空间作一定限制，建议默认是5MB（分HOST）的配额；达到上限后，可以申请更多存储空间。另外，现在主流浏览器SQL Database的实现都是基于SQLite。分析：SQL Database的主要优势在于能够存储结构复杂的数据，能充分利用数据库的优势，可方便对数据进行增加、删除、修改、查询。由于SQL语法的复杂性，使用起来麻烦一些。SQL Database也不太适合做静态文件的缓存。在Android内嵌Webview中，需要通过Webview设置接口启用SQL Database，同时还要设置数据库文件的存储路径。
Android系统也使用了大量的数据库用来存储数据，比如联系人、短消息等；数据库的格式也SQLite。Android也提供了API来操作SQLite。Web SQL Database存储机制就是通过提供一组API，借助浏览器的实现，将这种Native的功能提供给了Web App。2.4 Application Cache机制Application Cache（简称AppCache)似乎是为支持Web App离线使用而开发的缓存机制。它的缓存机制类似于浏览器的缓存（Cache-Control 和 Last-Modified）机制，都是以文件为单位进行缓存，且文件有一定更新机制。但AppCache是对浏览器缓存机制的补充，不是替代。先拿W3C官方的一个例子，说下AppCache机制的用法与功能。
上面HTML文档，引用外部一个JS文件和一个GIF图片文件，在其HTML头中通过manifest属性引用了一个appcache结尾的文件。我们在Google Chrome浏览器（点击查看浏览器支持详情）中打开这个HTML链接，JS功能正常，图片也显示正常。禁用网络，关闭浏览器重新打开这个链接，发现JS工作正常，图片也显示正常。当然也有可能是浏览缓存起的作用，我们可以在文件的浏览器缓存过期后，禁用网络再试，发现HTML页面也是正常的。通过Google Chrome浏览器自带的工具，我们可以查看已经缓存的AppCache（分HOST)
上面截图中的缓存，就是我们刚才打开HTML的页面AppCache。从截图中看，HTML页面及HTML引用的JS、GIF图像文件都被缓存了；另外HTML头中manifest属性引用的appcache文件也缓存了。AppCache的原理有两个关键点：manifest属性和manifest文件。HTML在头中通过manifest属性引用manifest文件。manifest文件，就是上面以appcache结尾的文件，是一个普通文件文件，列出了需要缓存的文件。
上面截图中的manifest文件，就HTML代码引用的manifest文件。文件比较简单，第一行是关键字，第二、三行就是要缓存的文件路径（相对路径）。这只是最简单的manifest文件，完整的还包括其他关键字与内容。引用manifest文件的HTML和manifest文件中列出的要缓存的文件最终都会被浏览器缓存。完整的manifest文件，包括三个Section，类型Windows中ini配置文件的Section，不过不要中括号。CACHE MANIFEST - Files listed under this header will be cached after they are downloaded for the first timeNETWORK - Files listed under this header require a connection to the server, and will never be cachedFALLBACK - Files listed under this header specifies fallback pages if a page is inaccessible完整的manifest文件，如：
总的来说，浏览器在首次加载HTML文件时，会解析manifest属性，并读取manifest文件，获取Section：CACHE MANIFEST下要缓存的文件列表，再对文件缓存。AppCache的缓存文件，与浏览器的缓存文件分开存储的，还是一份？应该是分开的。因为AppCache在本地也有5MB（分HOST）的空间限制。AppCache在首次加载生成后，也有更新机制。被缓存的文件如果要更新，需要更新manifest文件。因为浏览器在下次加载时，除了会默认使用缓存外，还会在后台检查manifest文件有没有修改（byte
by byte)。发现有修改，就会重新获取manifest文件，对Section：CACHE MANIFEST下文件列表检查更新。manifest文件与缓存文件的检查更新也遵守浏览器缓存机制。如用用户手动清了AppCache缓存，下次加载时，浏览器会重新生成缓存，也可算是一种缓存的更新。另外， Web App也可用代码实现缓存更新。分析：AppCache看起来是一种比较好的缓存方法，除了缓存静态资源文件外，也适合构建Web离线App。在实际使用中有些需要注意的地方，有一些可以说是”坑“。要更新缓存的文件，需要更新包含它的manifest文件，那怕只加一个空格。常用的方法，是修改manifest文件注释中的版本号。如：#
v1.0.0被缓存的文件，浏览器是先使用，再通过检查manifest文件是否有更新来更新缓存文件。这样缓存文件可能用的不是最新的版本。在更新缓存过程中，如果有一个文件更新失败，则整个更新会失败。manifest和引用它的HTML要在相同HOST。manifest文件中的文件列表，如果是相对路径，则是相对manifest文件的相对路径。manifest也有可能更新出错，导致缓存文件更新失败。没有缓存的资源在已经缓存的HTML中不能加载，即使有网络。例如：http://appcache-demo.s3-website-us-east-/without-network/manifest文件本身不能被缓存，且manifest文件的更新使用的是浏览器缓存机制。所以manifest文件的Cache-Control缓存时间不能设置太长。另外，根据官方文档，AppCache已经不推荐使用了，标准也不会再支持。现在主流的浏览器都是还支持AppCache的，以后就不太确定了。在Android内嵌Webview中，需要通过Webview设置接口启用AppCache，同时还要设置缓存文件的存储路径，另外还可以设置缓存的空间大小。
2.5 Indexed DatabaseIndexedDB也是一种数据库的存储机制，但不同于已经不再支持的Web SQL Database。IndexedDB不是传统的关系数据库，可归为NoSQL数据库。IndexedDB又类似于Dom Storage的key-value的存储方式，但功能更强大，且存储空间更大。IndexedDB存储数据是key-value的形式。Key是必需，且要唯一；Key可以自己定义，也可由系统自动生成。Value也是必需的，但Value非常灵活，可以是任何类型的对象。一般Value都是通过Key来存取的。IndexedDB提供了一组API，可以进行数据存、取以及遍历。这些API都是异步的，操作的结果都是在回调中返回。下面代码演示了IndexedDB中DB的打开（创建）、存储对象(可理解成有关系数据的”表“）的创建及数据存取、遍历基本功能。
将上面的代码复制到indexed_db.html中，用Google Chrome浏览器（点击查看游戏器支持详情）打开，就可以添加、查询数据。在Chrome的开发者工具中，能查看创建的DB、存储对象(可理解成表）以及表中添加的数据。
IndexedDB有个非常强大的功能，就是index（索引）。它可对Value对象中任何属性生成索引，然后可以基于索引进行Value对象的快速查询。要生成索引或支持索引查询数据，需求在首次生成存储对象时，调用接口生成属性的索引。可以同时对对象的多个不同属性创建索引。如下面代码就对name和email两个属性都生成了索引。
生成索引后，就可以基于索引进行数据的查询。
分析：IndexedDB是一种灵活且功能强大的数据存储机制，它集合了Dom Storage和Web SQL Database的优点，用于存储大块或复杂结构的数据，提供更大的存储空间，使用起来也比较简单。可以作为Web SQL Database的替代。不太适合静态文件的缓存。以key-value的方式存取对象，可以是任何类型值或对象，包括二进制。可以对对象任何属性生成索引，方便查询。较大的存储空间，默认推荐250MB(分HOST)，比Dom Storage的5MB要大的多。通过数据库的事务（tranction）机制进行数据操作，保证数据一致性。异步的API调用，避免造成等待而影响体验。Android 在4.4开始加入对IndexedDB的支持，只需打开允许JS执行的开关就好了。
2.6 File System APIFile System API是H5新加入的存储机制。它为Web App提供了一个虚拟的文件系统，就像Native App访问本地文件系统一样。由于安全性的考虑，这个虚拟文件系统有一定的限制。Web App在虚拟的文件系统中，可以进行文件（夹）的创建、读、写、删除、遍历等操作。File System API也是一种可选的缓存机制，和前面的SQLDatabase、IndexedDB和AppCache等一样。File System API有自己的一些特定的优势：可以满足大块的二进制数据（ large binary blobs）存储需求。可以通过预加载资源文件来提高性能。可以直接编辑文件。浏览器给虚拟文件系统提供了两种类型的存储空间：临时的和持久性的。临时的存储空间是由浏览器自动分配的，但可能被浏览器回收；持久性的存储空间需要显示的申请，申请时浏览器会给用户一提示，需要用户进行确认。持久性的存储空间是WebApp自己管理，浏览器不会回收，也不会清除内容。持久性的存储空间大小是通过配额来管理的，首次申请时会一个初始的配额，配额用完需要再次申请。虚拟的文件系统是运行在沙盒中。不同WebApp的虚拟文件系统是互相隔离的，虚拟文件系统与本地文件系统也是互相隔离的。File System API提供了一组文件与文件夹的操作接口，有同步和异步两个版本，可满足不同的使用场景。下面通过一个文件创建、读、写的例子，演示下简单的功能与用法。
将上面代码复制到file_system_api.html文件中，用Google Chrome浏览器打开（现在File System API只有Chrome 43+、Opera 32+以及Chrome for Android 46+ 这三个浏览器支持，）。由于Google Chrome禁用了本地HTML文件中的File System API功能，在启动Chrome时，要加上”—allow-file-access-from-files“命令行参数。
上面截图，左边是HTML运行的结果，右边是Chrome 开发者工具中看到的Web的文件系统。基本上H5的几种缓存机制的数据都能在这个开发者工具看到，非常方便。分析：File System API给Web App带来了文件系统的功能，Native文件系统的功能在Web App中都有相应的实现。任何需要通过文件来管理数据，或通过文件系统进行数据管理的场景都比较适合。到目前，Android系统的Webview还不支持File System API。3 移动端Web加载性能（缓存）优化分析完H5提供的各种缓存机制，回到移动端（针对Android，可能也适用于iOS）的场景。现在Android App（包括手Q和WX）大多嵌入了Webview的组件（系统Webview或QQ游览器的X5组件），通过内嵌Webview来加载一些H5的运营活动页面或资讯页。这样可充分发挥Web前端的优势：快速开发、发布，灵活上下线。但Webview也有一些不可忽视的问题，比较突出的就是加载相对较慢，会相对消耗较多流量。通过对一些H5页面进行调试及抓包发现，每次加载一个H5页面，都会有较多的请求。除了HTML主URL自身的请求外，HTML外部引用的JS、CSS、字体文件、图片都是一个独立的HTTP请求，每一个请求都串行的（可能有连接复用）。这么多请求串起来，再加上浏览器解析、渲染的时间，Web整体的加载时间变得较长；请求文件越多，消耗的流量也会越多。我们可综合使用上面说到几种缓存机制，来帮助我们优化Web的加载性能。
结论：综合各种缓存机制比较，对于静态文件，如JS、CSS、字体、图片等，适合通过浏览器缓存机制来进行缓存，通过缓存文件可大幅提升Web的加载速度，且节省流量。但也有一些不足：缓存文件需要首次加载后才会产生；浏览器缓存的存储空间有限，缓存有被清除的可能；缓存的文件没有校验。要解决这些不足，可以参考手Q的离线包，它有效的解决了这些不足。对于Web在本地或服务器获取的数据，可以通过Dom Storage和IndexedDB进行缓存。也在一定程度上减少和Server的交互，提高加载速度，同时节省流量。当然Web的性能优化，还包括选择合适的图片大小，避免JS和CSS造成的阻塞等。这就需要Web前端的同事根据一些规范和一些调试工具进行优化了。参考资料：浏览器缓存机制：http cache笔记http://imweb.io/topic/64b2cWeb缓存机制系列/2012/03/web-cache-1-web-cache-overview/Web SQL Database：A simple TODO List Using Web SQL Database/en/tutorials/webdatabase/todo/?redirect_from_locale=zhW3C:Web SQL Databasehttp://dev.w3.org/html5/webdatabase/HTML5:Web SQL Database/html5/html5_web_sql.htmDom Storage：浅谈Html5的Dom Storage/developerworks/cn/web/1107_gaoly_html5storage/Dom Storagehttps://developer.mozilla.org/zh-CN/docs/Web/Guide/API/DOM/StorageApplication Cache：Html5 Application Cache/html/html5_app_cache.aspUsing the application cachehttps://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cacheCommon Pitfalls to Avoid when Using HTML5 Application Cache/common-pitfalls-avoid-using-html5-application-cache/Application Cache is a Douchebag/article/application-cache-is-a-douchebagIndexedDB:Working with IndexedDB/tutorials/working-with-indexeddb--net-34673Working with IndexedDB -Part2/tutorials/working-with-indexeddb-part-2--net-35355IndexedDB:浏览器端数据库/bom/indexeddb.htmlW3C:Indexed Database APIhttp://www.w3.org/TR/IndexedDB/File System API:Debugging the FileSystem API/web/updates/2011/08/Debugging-the-Filesystem-APIBuilding an HTML5 Text Editor with the FileSystem APIs/building-an-html5-text-editor-with-the-filesystem-apisToying with the FileSystem API/tutorials/toying-with-the-html5-file-system-api--net-24719Exploring the FileSystem APIs/en/tutorials/file/filesystem/
梦幻人生--用技术来点缀自己的人生
github:/wa...}