文本前端优化层出不穷。现在移动端流行，可以说移动端优化好，PC端也会更好。因此，我们可以根据下面的图片进行一些分析，如图：图中已经总结了前端的性能。但实际上，我觉得我们可以把这个总结做得更精准、更简洁、更丰富。那么，接下来我将从网络方面、DOM操作和渲染方面、数据方面三个方面来总结一下前端性能。对于网络上的Web应用，总会有一部分时间浪费在网络连接和资源下载上。建立网络连接通常需要时间。而且，浏览器同时发送的网络请求数量是有限制的。所以这一层的优化可以从“减少请求数”入手：减少http请求：YUI35规则中也有提到，主要是优化js、css和图片资源，因为html没办法避免。因此，我们可以进行如下操作：合并js文件合并css文件使用精灵（csssprite）使用base64表示简单图片以上四种方式，前两种我们可以使用webpack等打包工具进行打包；对于精灵图，也有专门的制作工具；图片的编码是基于base64的，所以对于一些简单的图片，比如空白图片，可以使用base64直接写成html。回到之前网络层面的问题，除了减少请求数来加快网络加载之外，往往整个资源的体积也是我们平时关注的一个方面。减少资源大小：可以从以下几个方面来实现：gzip压缩js混淆css压缩图片压缩gzip压缩主要针对html文件，可以将html中重复的部分打包，重复使用多次处理。js的混淆可以是简单的压缩（删除空白字符），丑化（丑化的方法是缩小一些变量），也可以使用php对js进行混淆加密。CSS压缩是简单的压缩。图片的压缩主要是为了减小尺寸。在不影响观感的前提下，图片尽量压缩，使用png等图片格式，减少矢量图和高清图片的使用。这种做法不仅可以加快网页的显示速度，还可以减少流量的损失。除了以上两个操作，我们还需要做好网络层面的缓存工作。在真正的性能优化方面，缓存是效率最高的类型，加载时间的缩短往往是最大的。缓存：可以用以下几个方面来描述：DNS缓存CDN部署和缓存http缓存由于浏览器在DNS解析这一步会消耗一定的时间，所以对于一些大流量的网站，做好DNS缓存，会在一定程度上提高网站的效率。CDN缓存，作为静态资源文件的分发网络，CDN本身进行了改进。网站静态资源的获取速度加快了网站的加载速度。同时，它也做好了静态资源的缓存工作，有效的利用了缓存的静态资源。变得更快。Http缓存还为资源设置缓存时间，防止在有效缓存时间内重复下载资源，从而提高网页整体加载速度。其实网络层面的优化还是有很多的，尤其是移动端页面。众所周知，移动端对网络更加敏感。除了现在的4G和WIFI，其他的移动终端网络都相当于一个弱网环境。在这种环境下，资源缓存利用率非常重要。此外，减少http请求的数量也很关键。在移动端弱网环境下，http请求的时间也会增加。因此，我们可以看看在移动网络上我们可以做的优化：移动优化：使用以下方法来加速移动网络的优化：使用长缓存，减少重定向首屏优化，保证首屏加载如果数据小于14kb，不要滥用网页字体“使用长缓存”，这样可以让移动端的一些资源设置一个长缓存，保证资源不需要发送a请求服务器比较资源是否更新，从而避免出现304的情况。304重定向可能不会影响PC端网页的加载速度，但是在移动网络不稳定的前提下，多一个请求会增加加载时间。“首屏优化”对于移动端来说非常重要。2s时间是用户最好的体验。一旦超过这个时间，就会导致用户流失。因此，考虑到移动端的网络情况，不可能在这么短的时间内加载完所有的网页资源，所以我们必须保证首屏的内容先显示，并基于TCP慢启动和拥塞控制，前14kb的数据非常重要，所以要保证第一次加载的数据可以小于14kb。“不要滥用网络字体”。网络字体的优势在于可以替代部分图片资源。但是，在移动端过度使用网页字体会导致页面资源负载过重。因此，要慎用网页字体渲染和DOM操作，首先简单说一下优化渲染的重要性。网页初始加载时，获取HTML文件后，最开始的工作是构建DOM和CSSOM两棵树，然后将它们合并形成渲染树，最后进行打印。看图吧，简单的过程：整个过程拉出来写在这里，具体可以另写一篇。原谅我偷懒，给大家推荐一篇比较好的文章。浏览器渲染流程与性能优化继续我们的话题，如何缩短这个流程呢？可以从以下操作中优化。优化网页渲染：css文件放在头部，js文件放在尾部或者异步尽量避免“头部加载”中的内联样式css文件，这样可以保证解析DOM的同时解析css文件。因为CSS（externallink或inline）会阻塞整个DOM的渲染，但是DOM解析会正常进行，所以将css文件放在header中解析可以加快网页的构建速度。假设放在最后，那时候DOM树就差不多建好了，等CSSOM树建好之后才能继续下面的步骤。“JS放在最后”：JS文件不一样。之所以将js文件放在最后或者异步加载，是因为JS（外链或者内联）会阻塞后续的DOM解析，后续的DOM渲染也会阻塞，一旦js的操作遇到DOM中的元素，很可能会被做作的。对此，可以推荐一篇文章——异步脚本加载提高页面性能。“避免使用内联样式”可以有效地减小HTML的大小。通常，在考虑内联样式时，样式本身往往比较小，加载网络资源的时间往往比这更长。除了页面渲染层面的优化，当然最重要的是DOM操作的优化。这部分优化应该是最多的，也是平时开发中可以注意的地方。如果在开发的前期就明白了这些原则，并同时付诸实践，那么在后期的性能提升上就可以省下很多功夫。那么，我们来看看具体的操作：DOM操作优化：避免直接对文档进行频繁的DOM操作使用classname代替大量的内联样式修改对于复杂的UI元素，将position设置为absolute或者fixed作为CSS动画尽可能使用requestAnimationFrame而不是setInterval操作正确使用canvas尽量减少CSS表达式的使用使用事件代理前三个操作其实是希望“减少回流和重绘”。事实上，执行一次DOM操作的成本非常高。以前可以通过网页操作是否卡顿来判断。但是，现代浏览器的进步大大降低了这方面的影响。但是，我们仍然需要清楚如何减少回流和重绘的问题。因为我不想在这里详细阐述这些知识，如果你想了解更多，可以阅读这篇文章——回流和重绘：CSS性能让JavaScript变慢？.这是张新旭写的文章(^.^)。“尽量使用css动画”因为css动画本身比较简单，而且相对于js的复杂动画，浏览器本身已经对其进行了优化，使用时不会出现卡顿等问题。“用requestAnimationFrame代替setInterval操作”，相信大家都听说过setInterval定时器会有一定的延时，对于可变性高的动画，会出现卡顿现象。而requestAnimationFrame正好解决了整个问题。“适当使用canvas”，不得不说canvas是对前端的一种改进。它出现后，前端界面的复杂度也随之增加。一些很难完成的动画可以借助canvas来辅助。但是如果经常使用canvas，会增加浏览器渲染的压力，导致性能下降。因此，在合适的时候使用canvas是一个很好的建议。“尽量少用css表达式”，这个在YUI规则中也有提到，往往css表达式在设计之初很漂亮，但是在使用过程中，由于其频繁触发的特性，会拖累性能网页似乎卡住了。所以在使用过程中尽量减少css表达式的使用，可以换成js进行操作。《使用事件代理》：往往对于具有冒泡属性的事件，使用事件代理是一个很好的方式。例如：一个列表需要设置一个点击事件。这时候如果为列表中的每一项都设置一个监听器，往往会导致整体性能下降，但是如果为整个列表设置一个事件，然后点击定位Target触发相应的操作，往往性能会有所下降加以改进。DOM操作的优化还有很多，当然也包括移动端的优化。这个在后面的移动端优化部分会提到，这里先说明一下。上面我们概述了开始渲染和DOM操作时的一些注意事项。接下来要说的就是对一些小细节的注意了。这些细节可能对页面影响不大，但一旦积累过多，性能也会受到影响。关于操作细节的注意事项：避免对图像或框架使用空src。当css属性为0时，去除单位，禁止图片缩放。使用正确的css前缀。删除空的css规则。对于css中可继承的属性，比如font-size，尽量使用Inheritance，少设置缩短css选择器，多使用伪元素帮助定位，上面提到的一些操作细节在开发中通常是需要的，可以理解为开发规范。（基本操作，坐下^_^）列举完基本操作，再来说说移动端DOM操作方面的一些优化。移动端优化：长列表滚动优化功能防抖和功能节流。使用touchstart和touchend而不是clickHTML视口设置来启用GPU渲染加速。首先，移动端需要面对的长列表滚动问题。IOS尽可能使用局部滚动，android尽可能使用全局滚动。同时需要在body中添加-webkit-overflow-scrolling:touch来优化移动端的滚动。有兴趣的可以去了解一下ios和android滚动操作的区别和优化。“防抖节流”，在设计滚动等频繁触发的DOM事件时，需要做好防抖节流。都是为了限制函数的执行频率，优化函数触发频率高导致的响应速度，跟不上触发频率，造成延迟、假死或卡顿现象。简介：功能防抖，调用动作n毫秒后执行动作，如果在n毫秒内再次调用动作，执行时间将重新计算；functionthrottling，预设一个执行周期，当调用时如果动作的时刻大于等于执行周期，则执行动作，然后进入下一个新的循环。“touchstart，touchend代替click”也是移动端常见的操作。点击在移动端会有300ms的延迟，这应该是常识。（不知道的朋友收藏一下）。这种方法会影响用户体验。所以在做优化的时候，最简单的方法就是用touchstart或者touchend代替click。因为他们的事件执行顺序是touchstart->touchmove->touchend->click。或者，使用fastclick或zepto的tap事件代替click事件。“HTML视口设置”可以防止页面缩放以优化性能。“启用GPU渲染加速”，朋友们肯定听说过CPU，但是这里的GPU不能和CPU混淆。GPU的全称是GraphicsProcessingUnit，是一种硬件加速方式。对于一般的css渲染，浏览器的渲染引擎是不会使用的。但是在3D渲染中，计算量大且繁重，浏览器会开启显卡的硬件加速来帮助完成这些操作。因此，我们可以利用css中的translateZ设置来诱骗浏览器开启GPU加速来加速渲染过程。DOM部分的优化更多的是一种习惯。你需要在开发过程中强迫自己注意这些规范。所以，大家可以多关注一下这部分内容，慢慢的去了解。同时，我对以上几点的描述是笼统的。没有详细展开。因此，我也请您仔细检查谷歌。在数据方面，数据也可以说是前端优化中比较重要的一块内容。页面与用户的交互响应往往伴随着数据交互、处理、ajax异步请求。所以，我们也可以说说这块知识。首先是图像数据的处理：图片加载处理：图片预加载Imagelazyloading加载第一屏时，进度条显示“图片预加载”。预加载的意思是提前加载内容。图片的预加载往往在图片资源比较大的时候使用，即时加载会造成漫长的等待过程。常见场景：图片卡通展示时。通常会预加载一两个图像。“图片的延迟加载”，也许你是第一次听说延迟加载，但是这种方式在开发中经常被使用。首先，我们要明白一个道理：往往只需要可见的资源，其他资源可以随着用户的滚动立即显示出来。因此，特别是对于图片资源较多的网站，图片延迟加载可以大大提高网页的加载速度。图片懒加载常用的方式是：一开始为图片的src设置一个比较简单的图片，然后将图片的真实地址设置为自定义属性，做一个占位符，然后为图片设置一个监听事件图片，一旦图片到达Viewport范围，从图片的自定义属性中获取真实地址，然后赋值给src让它加载。“首屏进度条展示”：如果经常对首屏优化后的数据量不满意，而首屏包的长度又无法进一步缩短，可以通过进度条提醒用户等待。说完图片数据资源的处理，我们往往需要对异步请求的内容进行优化。因为，异步数据采集也离不开前端。这部分我们也可以做一些处理：异步请求的优化：使用普通的json数据格式进行交互式缓存数据的埋入，以及一些常用数据的“JSON交互”统计。优化前后端数据通信。“常用数据缓存”可以缓存一些常用的信息，比如用户的基本信息，保证ajax请求的减少。同时也不用担心HTML5新加入的存储内容因cookie暴露而造成的信息泄露。“数据埋点与统计”对于有经验的程序员来说比较熟悉。而现在的大部分公司也会这样做。感兴趣的朋友可以自行查看。最后是大数据量的操作。对于javascript语言来说，自身的单线程限制了它，无法计算大量的数据，经常会导致页面卡顿。可能是业务中一些复杂的UI需要运行大量的计算，所以webWorker的使用是至关重要的。或许，前端标准普及的滞后，会导致这些新事物的短期缺乏。总结本文就前端性能这个话题做一个总结。或许，它并不全面，但却是日常开发中经常用到的一些知识。我希望有兴趣的人可以自己尝试这些优化。这篇文章概括了几个知识点：网络层面的优化、数据层面的优化、DOM操作的优化和渲染层面的优化
