首先，我们这里优化对象为移动站点 。
移动开发具备了pc开发所有的特点，并且可以使用一些pc端无法使用的一些手段（主要还是为了兼容ie8及以下浏览器啦），pc端的优化手段都可以在移动端使用。但是移动有些地方就不如pc端了(网络慢，不稳定)，尤其2G网络，每秒按10kb来算，下载一个资源要耗很多时间。
HTML5页面优化点主要有以下几点：
1.redirect：重定向耗时
2.APP cache：读取缓存耗时
3.DNS：域名解析耗时
4.TCP：网络连接耗时
5.request和response：发起请求和接受响应时间
6.processing：接受到响应页面渲染时间
7.onload：渲染完毕，加载其他异步静态资源时间
优化思路可以针对以上每个点各个击破。
根据经验，优化重点主要放在静态资源加载和页面渲染，网络连接耗时和服务器响应时间不考虑在内。
随着Html5的正式定稿，移动前端步入APP世界的步伐也随之加速。目前主流的两大手机系统厂商（google、苹果）都是Html5的参与者，所以这两大系统在对html5的支持上基本是没什么问题的。然而对于很多开发者来说，也许仅仅是因为使用前的一番可行性分析便放弃这种方案。因为很多资料都叙述着Html5相比原生App的各种不足。其中最尴尬的一条莫过于“性能”问题。
前端性能问题与优势
因为这个问题，刚开始接触的时候我也有很强的抵触情绪。但后来慢慢的发现，其实很多时候性能本就不是问题。适当的调整Html和Css，我们的网页同样可以无限接近原生程序。而且个人认为，大多数时候程序是否流畅并非取决于某种编程语言，而是取决于写程序的人。相比通过各种代码填充来完成目标任务，我更喜欢把技术当做艺术，写代码也应该有所追求。（扯淡扯远了。）
其实，Html5相比原生App的开发有很多诱人的方面。
其一：可快速迭代。 最简单最直接的一个：IOS程序每次上传都需要通过漫长的审核时间，如果赶时间的话这是个问题，而且耐心等待之后未必就能得到一个我们想要的结果，审核不通也不是不可能。Html5开发完成之后也不用再次上传审核。（若与原生程序有交互变更，此项无效）
其二：跨平台。Html跨平台的特性早已不是一天两天的事了。IOS开发完成的同时，Android也基本完成。开发效率和成本上相比原生应用确实有较明显的优势。
其三：转发率高。现在打开微信朋友圈就能看到各种分享。如：文章分享，产品分享，XX店铺等。通过连接转发可以实现快速分享，提高流量。
谈完优势，再说说自身经历。本是一名老老实实的C#程序员，没事就学习各种程序优化（sql为主）的我在几个月前突然转向移动网页开发。在一个不算小的团队里前端工程师是一枚传统前端工程师。除能完成简单的手机布局外其他一窍不通，于是乎关于JavaScript、前端性能优化等各种重担都落到了我这里。由于前端所完成的仅仅是以html的形式展现出效果图的模样，很少涉及到性能问题。于是漫长的学习之路由此开始了。
究竟什么样的页面是需要优化的页面？
1、页面上下滑动时感觉卡顿不流畅或是基本不动；
2、动画效果卡顿，看上去感觉一帧一帧的跳动；
简单点说，就是感觉卡。也许iphone6不卡但是iphone4上会卡，也许iphone上不卡三星上感觉卡、魅族、小米、华为、联想？国内屌丝机各有个的长相各有各的特色，比如魅族的MX，其他手机都很正常的时候它就卡。Html兼容一直都不是一件容易的事。
上述问题该如何破？
解决问题的关键在于找到问题的所在。砍柴还得有装备，工具很重要。以前用chrome，是因为感觉这货比较好使（直到放弃多年来一直钟爱的IE）。几个月前才发现这是一个调试工具也很好使的浏览器（简直就是神器）。其实关于html性能问题，很多博客上都有解释重绘这个事。下面主要谈谈如何用chrome鉴别重绘元素。
打开chrome，开启开发者工具(F12)。打开模拟器，并选择需要模拟的设备，在Console中选择Rendering 选中第一条（Show paint rectangles）。若打开开发者工具后没看见下方Console这块可以按下Esc。
完成上述操作后，请将视线移动到左侧网页上的绿色矩形框上。
ps：一直都很喜欢淘宝的广告，创意从未间断过。
这个绿色框就是浏览器重绘的部分。这个框越大，说明重绘的区域也就越大。重绘并没什么问题，这很正常，不正常的是大面积重绘，比如上图中的时间跳动，如果仅仅是时间那个区域重绘并没有什么问题，要是整个页面都一直闪着个绿框框那就完蛋了。为何大面积重绘会出现性能问题，这个还得从浏览器渲染上谈起。那是一个很长的故事，有兴趣的朋友可以找些资料看看。简单的举例就是，浏览器把html文档解析成网页展现到我们面前，其中间是一个“漫长”的过程。再载入文档之后需要对html进行分割、读取并计算其样式大小、然后进行图层绘制、合并图层等一系列操作。整个过程其实使用最多的部件是CPU和GPU。
重绘的面积大小和回流（reflows）有关，关于回流其实可以这样理解，当改变一个元素后对其它节点元素产生影响。就如同可石子投入水中引起的波纹一样，波纹所到之处基本都会有所影响。而在Html中子节点的变化会引起祖先的回流，同时也会影响到部分兄弟节点，大部分的回流将导致页面的重新渲染。那么如何降低回流，减小重绘面积呢？淘宝时间不也只更新了一小块么！这里提供两种方法：
1、使用 position 属性的 fixed 值或 absolute 值。
2、创建独立的Layer（层）（为避免和div（层）产生混淆文中尽量同一使用Layer）。
继续看淘宝：
第一种方法已经很明显了就不再赘述。说说第二种方法吧。首先说说在Chrome中如何查看独立的Layer呢。如上图，选择Show composited layer borders后在页面上独立的Layer上回显示一个橘黄色边框。那么又要如何才能建立独立的Layer呢？
在Chrome中创建独立的Layer仅需要符合下述条件之一：
1.有3D元素的属性；
2.video标签并使用加速视频解码；
3.canvas元素并启用3D；
4.插件，比如flash；
5.CSS动画；
6.CSS滤镜；
7.有一个后代元素是独立的layer；
8.元素的相邻元素是独立layer。
看上去挺多挺复杂的，其实最简单、最容易理解、也最容易滥用的是第一条。实现第一条仅需要在元素的样式里加上。transform:translateZ(0);-webkit-transform:translateZ(0); 就可以了。我们将淘宝往下滑动一点，找一个元素试试看。
还是看淘宝：
当加上css样式后对应的元素上出现了橘黄色边框，事实证明这招是有效的。而在Chrome中这样做可以启用GPU硬件加速。初次看到加速两个字让人觉得无比兴奋，仿佛找到了克敌制胜的无敌神招。可是，首先这是在chrome下，其次大量使用真的好吗？
其实就算是在chrome下GPU也未必能排上用场，首先需要确定你的GPU驱动程序不在chromium的黑名单中。因为某些GPU驱动程序存在错误，可能会影响浏览器稳定，所以会被加入到黑名单里。在chrome地址栏里输入 about:gpu 可以查看相关的GPU信息。现在再说说GPU加速的事情吧，简单点解释就是通过GPU渲染的Layer，GPU会将图层信息缓存起来，到下次改变的时候就只需要重新渲染修改过的部分。这样固然是快，但是会加大系统RAM和GPU的内存开销。在配置参差不齐的移动设备上，过多的层不仅不能加速，反而会严重影响性能。很多时候我们在感觉到移动网页较卡的时候不防试试减少页面上的Layer试试。
通过Chrome我们还可以鉴别一些其他影响性能的方面。比如：
上面两幅图，左边一幅是百度.新闻的移动网页版，箭头指向的是这个页面的loading效果（就是一种一直一直转动的感觉）。右边是以前最常用的一种loading。在效果上两种方式都一样，一直不停的转动。而区别在于右边的loading是一个带有背景图片的div，通过css3使其产生转动效果；而右边则是一张Gif动态图片。虽然效果上一样，但在浏览其中我们可以看到右边的loading会有一个不停闪动的绿色框（频率相当高）。gif动画会导致浏览器不断的进行绘制、栅格化、合成，整个过程相当影响性能，所以最好干掉它。
简而言之言而简之：
布局
1、减少重绘，减小重绘面积（改良布局，创建独立的Layer），降低重绘频率。
2、合理使用GPU加速，避免过度依赖GPU而导致性能下降。
动画
说完布局，再简单谈谈动画吧。
常用的JavaScript动画在移动web上很多时候都显得心有余而力不足（不给力啊）。这个原因很多， JavaScript动画通常是通过定时改变元素样式属性的方式来实现，JavaScript的运行是在一个独立线程里完成的，作为单线程程序， JavaScript会因为某个耗时动作而影响下一帧动画的执行。而且，JavaScript的定时也并没有想象中的那么守时，如在setinterval中设置每毫秒输出一个数， 当输出到2000次的时候，当真就只需要2秒钟吗？相比之下更加推荐使用CSS3来完成相关动画效果。首先Css由独立线程完成，它和JavaScript的运行并不冲突， 其次Css3很多属性不会触发重绘（当然JavaScript里也可以是改变的css3的属性）。 从流畅度上来讲的话Css3基本上完胜JavaScript，而且操作较容易。关于Css3相关知识就不再赘述。
然而Css3的动画也并没有想象中那般完美。
首先，在动画控制上不够灵活，整动画过程不太好监控。
其次，其兼容性不太好。仅移动端而言，位移动画通常使用transform，但在某些浏览器中需要使用-webkit-transform（如微信里的浏览器）。
虽然Css3并非完美解决方案，但实际使用中大多数时候是完全可以解决我们所遇到的问题 （遇到复杂问题再解决吧，事在人为嘛，解决问题也是一种乐趣）。 且目前的移动应用上并不推荐过于复杂的效果设计。
