前端性能优化的三个维度

前端性能优化可以分为三个level：静态资源优化、接口访问优化、页面渲染速度优化，在操控门槛上依次递增，优化效果上越发没有这么明显，所以很多小团队只会做到了第一个level
追求极致的前端性能体验，提升自己的level，come on ~

一、静态资源优化

这个level，主要是减少静态资源的加载时间，主要包括html、css、js和图片文件，静态资源的加载时间是前端性能最大的瓶颈（特别是图片），现如今优化的手段也很丰富，以下简要列举几种常用的方法

本文旨在提供一个清晰的优化思路，上述优化方法不做具体的说明，网上也能搜索到很多具体的教程，也可以留言、简信一起讨论

如果第一个level做得好，可以保证静态资源以一个较快的速度加载出来，然而，此时情况并没有完美，依然还存在两个明显的问题：

静态资源加载完成了，页面依然还在转菊花，用户依然还在等待。现如今web应用已经走过完全由php和jsp等后端脚本语言渲染界面的时代，ajax异步加载数据的方式已经成为主流，各种前端的mvc框架层出不穷，先加载静态资源，在执行js中的ajax请求到后台请求数据，重新渲染界面已经是一种通行的方案，这样便出现了静态资源加载完成，页面可见，然而用户还需要等待请求数据的进度条的情况（特别是接口访问速度慢的时候）
用户点击任意一个按钮，进度条加载了半天，也没有响应。很多复杂的功能需要并行或者串行的请求很多接口才能完成，前端的网络状况稍微差一点，给与用户的体验都极差。

以上两个问题在网络情况优异，接口请求速度快的情况下都不是问题，然而终端如果是一个手机，常常连wifi都不能保证，3g/4g的网络你能期待它有多快，所以优化的潜力是巨大的

对于上述的问题一，如果页面的初始化数据，在后端完成渲染，其它的用户交互使用ajax的方式完成，也就是传统意义上的首屏直出，就可以得到很好的解决

这种介于完全后端渲染和完全ajax渲染的方式是一个不错的思路，但是在node出现之前，很多人宁愿容忍首屏加载的菊花，也不愿意使用，为什么？因为前端和后端要维护两套模板，令人抓狂

node出来之后，前后端都都可以使用js语言，前后端同构（前端和后台公用模板代码）使得首屏直出重新拥有了生存的土壤，所以同构直出现在常常相提并论，形同一个成语

react在同构直出方面做得比较出众，更多相关知识，可以留言、简信讨论

一个交互需要请求多个并行或串行接口实属正常，前端使用3g/4g等弱网络也着实是不可抗因素，所以最好的办法就是通过接口合并的方式来提高接口访问速度

后台提供的接口有其既有粒度，强行合并不合时宜，提供一个新的合并的接口也缺乏机动性（前端发现一个新的合并需求，就要求后端提供一个接口，后端有开发工作量不说，还得没完没了的发版）

如果把接口合并的主动权交给前端，那情况将会好很多，前端是最接近战火的地方，最知道应该如何组合接口。基于代理服务的接口合并方案应运而生（这是本人第一个值得骄傲的原创方案，这其中还包含了node实现，想想还有点小鸡动~）

欢迎使用node实现的基于代理服务的接口合并框架，欢迎建议、拍砖，您的意见是我优化的动力

在页面不复杂、dom层次不深的情况下，完成以上两个level，就已经足够了。然而在复杂的页面上，却还有很大的优化空间，页面渲染速度的优化很大的程度上依托于程序员的个人编程素质，下面简要列举几点：

另外，新晋前端框架 vue、react，虚拟dom的渲染方案，在内存中进行 dom diff 比较，做到最小化的操作真实的 dom （操作真实的 dom 常常会成为性能瓶颈），能极大的提高渲染速度

使用一些页面性能分析工具给自己的页面跑分，可以帮助养成良好的编程习惯、提升编程素质，例如：WebPagetest、Yslow

极致的性能优化需要有清晰的step，这是理解以上三个维度的意义所在

干货不断，欢迎关注本专栏~~~