性能优化
可能一直听到前端性能优化？然后就只想着如何优化！其实重要的是我们要想为什么优化？只是为了提高代码的质量？其实不仅仅；比如用户体验；比如经济利益…我们可以放大来看…
前端优化相关（目的）
主要有两个方面：企业资源和用户体验。很多企业在自己的服务器进行web开发，由于硬件资源有限，同时又有商业用途，怎样用有限的资源去满足企业网站商用化的目标，这成为了对Web前端优化的原动力。从用户的体验角度讲，必然希望自己浏览的网站文字、图片、视频动画，以及其他模块的加载是流畅的，从而获得好的浏览体验。
优化的追求可以主要分为以下四个方面
- 速度
优化肯定是速度越快越好。带宽1秒内传输的数据量越大；程序写得好对速度都有很大的影响 - 省钱
如果电商平台卖出一件商品需要的成本是3元；那如果经过优化将其将为一半的钱；比如；某宝。那是多大的一笔利润；还有后续网站的维护,性能优化有很大的帮助… - 抗压
也就是负载。比如鹿晗结婚导致微博崩溃；还有之前12306春节买票把系统挤爆；直接影响着我们的用户，同时也影响着产品本身。 - 回退
系统不正常如何才能减少损失，减少造成的影响；商业盈利是比较重要
一些共通的方法
请求数量—越少越好 --关键就是合并外部资源文件
80%的终端响应时间是耗费在前端上，大部分的时间是在加载页面上的组件:images, stylesheets, scripts, Flash…减少http请求这是加快页面速度的关键
- 合并外部文件；比如将js，css文件整合成一个
- 精灵图(CSS Sprites)可以减少图片的请求；
- . Image Maps： 也是将多幅图拼在一起，然后通过坐标来控制显示导航。这里有个经典的例子，选中图片中的某个人就会将你带到不同的链接。
- Inline images：也就是将图片转为base64位编码；一般是比较小的图片
- webpack帮我们做得很好了-- JavaScript 应用程序的静态模块打包器;它能将程序需要的每个模块;比如.css文件、.js文件、.png…打包成成一个或多个 bundle，能很好的减少二次请求
关于后端的一个问题：我们向后台请求数据；如果它的数据能够再减小；虽然对可读性优点影响；但是也能加快我们的速度
- 文件的体积–越小越好–关键是压缩
- 比如我们将我们的代码的注释去掉；空格去掉；换行去掉；使其体积减小
- 合理缓存
这不是纯前台；纯后台…能缓存的一定不要在让它读；能缓存的就不要再让它更新，还有缓存时间多久，都是根据用户的点击，访问，习惯来决定的… - 异步请求
- 提高响应速度：避免跳转；添加Expires 或 Cache-Control报文头使回复可以被客户端缓存;压缩回复内容
- 减少数据请求量–延迟加载
- 懒加载；比如用户看一眼就走，它不往下拉；所以我们可以使用懒加载；减少没必要的请求数据
- 增加数据请求量-提前加载
可能会觉得和懒加载冲突了–延迟加载；其实这些都是需要很综合的取分析的；
- 让一次请求的数据可以多一点；比如分页功能;用户浏览较快；很快就浏览完一页；那么我们需要先加载所有数据；减少响应时间
- 无条件提前加载：当前网页加载完成后，马上去下载一些其他的内容。例如google会在页面加载成功之后马上去下载一个所有结果中会用到的image sprite
- 预加载数据
有预期的的加载：这种情况一般发生在网页重新设计时，由于用户经常访问旧网页，本地对旧的网页内容缓存充分从而显得旧网页速度很快，而新的网页内容却没有缓存，设计者可以在旧网页的内容中预先加载一些新网页中可能用到的内容，这样新的网页就会生下来一些需要下载的资源。
看一下用户用不用的上这些数据；还有程序本身的复杂程度考虑
道理大家都懂；如何做到高效
数据说话、运营部分、用户访问习惯.概率问题…
如何监控这些数据
上面的方法都是根据用户的访问情况和我们的业务需求来决定的；并不一定是可行的；所以我们要检测这些数据来确定我们的方案；提高我们的性能
1 日志
2. 埋点：有些数据到后台是获取不到的；请求我们肯定是知道用户点击的；但是比如游戏的位置需要我们前端趣确定的;
3. 统计：靠样本推测大的数据大的方向
4. 性能测试的工具
- 百度智能云
- 阿里云pts
- gtmerix
- webpagetext
- Pingdom Website Speed Test
部署优化
- CDN
再次强调第一条黄金定律，减少网页内容的下载时间。提高下载速度还可以通过CDN(内容分发网络)来提升。CDN通过部署在不同地区的服务器来提高客户的下载速度。如果你的网站上有大量的静态内容，世界各地的用户都在访问，那CDN是必不可少的。
离你近的服务器肯定越快；可以CDN节约机房的带宽…
- p2p对等网络…在集中式网络中，服务器成为整个系统的屏颈，无论是容量，和计算机处理能力。但是在P2P网络是，这样的问都都不会出现。系统的资源，计算机能力和存储能力都是分布在所有的节点上的，理论上是这些能力是无限。也就是，客户端本身可以当做一个服务器使用
- 异构计算:不完全依赖于cpu；并不一定需要昂贵的服务器；比如廉价的电脑；专门的芯片
细讲前端性能优化
CSS
- 将样式表置顶;经样式表(css)放在网页的HEAD中会让网页显得加载速度更快，因为这样做可以使浏览器逐步加载已将下载的网页内容。这对内容比较多的网页尤其重要，用户不用一直等待在一个白屏上，而是可以先看已经下载的内容。
- 避免CSS表达式:这个很少用；注意即可
- 用
<link>代替@import - 避免使用Filters;这种滤镜的使用会导致图片在下载的时候阻塞网页绘制，另外使用这种滤镜会导致内存使用量的问题。
- 尽量少用复杂选择器尽量避免类似.a.b{}.list a{}以及其他一些复杂选择器，以提高整站整体CSS渲染。
- 记住这么个原则， 页面刷新载入的时候，应避免页面元素的晃动、位移等，这些都是额外的重绘，会让你的CPU和风扇兴奋的。—张鑫旭
- 图片设置宽高；外部容器没有定死高宽，则图片在首次载入时候，占据空间会从0到完全出现，左右上下都可能位移，发生大规模的重绘。可以参见新浪微博载入时候页面高度随着图片显示不断变高的问题，这些都让浏览器重绘了，一是体验可能不好，二是烧CPU的。
- **避免使用table布局。**即使一些小的变化将导致表格(table)中的所有其他节点回流。
- 动画效果应用到position属性为absolute或fixed的元素上,它们不影响其他元素的布局，所它他们只会导致重新绘制，而不是一个完整回流。这样消耗会更低。
10.避免设置多层内联样式 我们都知道与DOM交互很慢。我们尝试在一种无形的DOM树片段组进行更改，然后整个改变应用到DOM上时仅导致了一个回流。同样，通过style属性设置样式导致回流。避免设置多级内联样式，因为每个都会造成回流，样式应该合并在一个外部类，这样当该元素的class属性可被操控时仅会产生一个reflow。
Javascript
- 把脚本置底，这样可以让网页渲染所需要的内容尽快加载显示给用户。
- 使用外部Javascript和CSS文件可以使这些文件被浏览器缓存，从而在不同的请求内容之间重用。
- 精简;就是将Javascript或CSS中的空格和注释全去掉;JS使用封装或则继承使得代码重用
- localStorage本地存储与优化。两种实践。一是：大数据量交互，数据不怎么更新的，含版本控制机制，一次请求，之后高枕无忧；二是代替cookie实现某些功能，带过期时间管理，降低页面cookie大小
- 事件委托，避免过多的DOM元素的事件绑定,一般使用
e.target - 面向数据编程这样避免在document上直接进行频繁的DOM操作；可以减少回流和重绘。
HTML
- 不要在HTML中缩放图片
不要通过图片缩放来适应页面，如果你需要小图片，就直接使用小图片吧。 - 使用小且可缓存的favicon.ico;网站图标文件favicon.ico，不管你服务器有还是没有，浏览器都会去尝试请求这个图标。所以我们要确保这个图标
移动端
前端优化层出不穷，移动端大行其道的现在，我们可以说优化好移动端，PC端也将会更好。
- 长列表滚动优化
- 函数防抖和函数节流.设计到滚动等会被频繁触发的DOM事件，需要做好防抖和节流的工作。(节流可以想象一下，如果在做轮播图，下一张图片还没轮播过去，用户点击就开启了下一个定时器，在点击前两张图片还没轮播完。防抖上面说过，主要是避免额外的重绘)。它们都是为了限制函数的执行频次，以优化函数触发频率过高导致的响应速度跟不上触发频率，出现延迟，假死或卡顿的现象。
- 使用touchstart、touchend代替click，click有300ms点击的延迟；现在的tap事件大都是封装，可以代替click
- HTML的viewport设置；这是移动端的配置
- 开启GPU渲染加速；在3D渲染时，计算量较大，繁重，浏览器会开启显卡的硬件加速来帮助完成这些操作。所以，我们这里可以使用css中的translateZ设定，来欺骗浏览器，让其帮忙开启GPU加速，加快渲染进程。
总结
这篇文章可能写得不是很好；因为一些是我学习过程中遇到的；一些是查阅资料得来；不过都需要自己尝试，但是万变不离其宗:
- 数据层面的优化；根据用户习惯，行为，点击；还有网站的测试…具体情况具体分析
- 该压缩的压缩，该合并的合并
- DOM操作与渲染层面的优化
- 减少二次请求
简单粗暴
安全
等我理解的更透彻继续更…
学习的过程有着触手可及的清风；学习的路上将会成为一条绿道。
