web前端性能优化方法

作为一个前端工程师，性能优化是很有必要的。好的用户体验能一定程度上决定产品的命运。而提升用户体验有很多方面，比如，界面设计，操作设计，网页加载性能等。。。
提升性能我们可以从如下几个方面考虑：

减少http请求合理设置 HTTP缓存

在动态网页中，我们难免会与后台服务器交互，减少http请求的数目在性能提升上是十分明显的。比如我们可以：

1. 简化步骤，将请求数据尽可能的封装在少的接口中，当然这是不破坏程序可扩展性及健壮性的情况下。

2. 合并压缩css与JS等文件，图片较多的页面也可以使用 lazyLoad 等技术进行优化。

3. 为不常变化的请求数据设置http缓存

合理放置CSS与JS的位置

浏览器会在下载完成全部CSS之后才对整个页面进行渲染，因此最好的做法是将CSS放在页面最上面，让浏览器尽快下载CSS。如果将 CSS放在其他地方比如 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了，这就导致页面由无 CSS状态跳转到 CSS状态，用户体验比较糟糕，所以可以考虑将CSS放在HEAD中。
       Javascript则相反，浏览器在加载javascript后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此javascript最好放在页面最下面。但如果页面解析时就需要用到javascript，这时放到底部就不合适了。
       Lazy Load Javascript（只有在需要加载的时候加载，在一般情况下并不加载信息内容。）随着 Javascript框架的流行，越来越多的站点也使用起了框架。不过，一个框架往往包括了很多的功能实现，这些功能并不是每一个页面都需要的，如果下载了不需要的脚本则算得上是一种资源浪费 -既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的 mini版框架，另一种则是 Lazy Load。

减少重排与重绘

当DOM的变化影响了元素的几何属性（宽或高），浏览器需要重新计算元素的几何属性，同样其他元素的几何属性和位置也会因此受到影响。浏览器会使渲染树中受到影响的部分失效，并重新构造渲染树。这个过程称为重排。完成重排后，浏览器会重新绘制受影响的部分到屏幕，该过程称为重绘。
重排何时发生？
很显然，每次重排，必然会导致重绘，那么，重排会在哪些情况下发生？
1、添加或者删除可见的DOM元素
2、元素位置改变
3、元素尺寸改变
4、元素内容改变（例如：一个文本被另一个不同尺寸的图片替代）
5、页面渲染初始化（这个无法避免）
6、浏览器窗口尺寸改变
这些都是显而易见的，或许你已经有过这样的体会，不间断地改变浏览器窗口大小，导致UI反应迟钝（某些低版本IE下甚至直接挂掉），现在你可能恍然大悟，没错，正是一次次的重排重绘导致的！

重排和重绘是DOM编程中耗能的主要原因之一，平时涉及DOM编程时可以参考以下几点：
1、尽量不要在布局信息改变时做查询（会导致渲染队列强制刷新）
2、同一个DOM的多个属性改变可以写在一起（减少DOM访问，同时把强制渲染队列刷新的风险降为0）
3、如果要批量添加DOM，可以先让元素脱离文档流，操作完后再带入文档流，这样只会触发一次重排（fragment元素的应用）
4、将需要多次重排的元素，position属性设为absolute或fixed，这样此元素就脱离了文档流，它的变化不会影响到其他元素。例如有动画效果的元素就最好设置为绝对定位。

javascript代码优化

1、减少dom访问
对DOM操作的代价是高昂的，这在网页应用中的通常是一个性能瓶颈。

天生就慢。在《高性能JavaScript》中这么比喻：“把DOM看成一个岛屿，把JavaScript(ECMAScript)看成另一个岛屿，两者之间以一座收费桥连接”。所以每次访问DOM都会教一个过桥费，而访问的次数越多，交的费用也就越多。所以一般建议尽量减少过桥次数。
解决办法：

修改和访问DOM元素会造成页面的Repaint和Reflow，循环对DOM操作更是罪恶的行为。所以请合理的使用JavaScript变量储存内容，考虑大量DOM元素中循环的性能开销，在循环结束时一次性写入。
减少对DOM元素的查询和修改，查询时可将其赋值给局部变量。

2、减少作用域链查找
作用域查找也是消耗一定时间的，所以我们可以将要使用的对象用变量保存在局部变量中，避免作用域的全局查找。此外，要减少作用域链查找还应该减少闭包的使用。

3、慎用 with　
with(obj){ p = 1}; 代码块的行为实际上是修改了代码块中的执行环境 ，将obj放在了其作用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，如果没有再依次按作用域链向上查找，因此使用 with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的，过长的作用域链会导致查找性能下降。  
　　因此，除非你能肯定在 with代码中只访问 obj中的属性，否则慎用 with，替代的可以使用局部变量缓存需要访问的属性。
4、 避免使用 eval和 Function
每次 eval 或Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。  
　　eval 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。  
　　Function 构造函数比 eval略好，因为使用此代码不会影响周围代码 ;但其速度仍很慢。  
　　此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。
　　
5、优化循环，妙用算法
减少循环的次数对性能的提升效果也是显著的。特别是在循环次数很多的时候，优化循环次数是很有必要的。有些时候算法可以取到事半功倍的效果。

作为一个前端工程师，性能优化是很有必要的。好的用户体验能一定程度上决定产品的命运。而提升用户体验有很多方面，比如，界面设计，操作设计，网页加载性能等。。。
提升性能我们可以从如下几个方面考虑：

减少http请求合理设置 HTTP缓存

在动态网页中，我们难免会与后台服务器交互，减少http请求的数目在性能提升上是十分明显的。比如我们可以：

1. 简化步骤，将请求数据尽可能的封装在少的接口中，当然这是不破坏程序可扩展性及健壮性的情况下。

2. 合并压缩css与JS等文件，图片较多的页面也可以使用 lazyLoad 等技术进行优化。

3. 为不常变化的请求数据设置http缓存

合理放置CSS与JS的位置

浏览器会在下载完成全部CSS之后才对整个页面进行渲染，因此最好的做法是将CSS放在页面最上面，让浏览器尽快下载CSS。如果将 CSS放在其他地方比如 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了，这就导致页面由无 CSS状态跳转到 CSS状态，用户体验比较糟糕，所以可以考虑将CSS放在HEAD中。
       Javascript则相反，浏览器在加载javascript后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此javascript最好放在页面最下面。但如果页面解析时就需要用到javascript，这时放到底部就不合适了。
       Lazy Load Javascript（只有在需要加载的时候加载，在一般情况下并不加载信息内容。）随着 Javascript框架的流行，越来越多的站点也使用起了框架。不过，一个框架往往包括了很多的功能实现，这些功能并不是每一个页面都需要的，如果下载了不需要的脚本则算得上是一种资源浪费 -既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的 mini版框架，另一种则是 Lazy Load。

减少重排与重绘

当DOM的变化影响了元素的几何属性（宽或高），浏览器需要重新计算元素的几何属性，同样其他元素的几何属性和位置也会因此受到影响。浏览器会使渲染树中受到影响的部分失效，并重新构造渲染树。这个过程称为重排。完成重排后，浏览器会重新绘制受影响的部分到屏幕，该过程称为重绘。
重排何时发生？
很显然，每次重排，必然会导致重绘，那么，重排会在哪些情况下发生？
1、添加或者删除可见的DOM元素
2、元素位置改变
3、元素尺寸改变
4、元素内容改变（例如：一个文本被另一个不同尺寸的图片替代）
5、页面渲染初始化（这个无法避免）
6、浏览器窗口尺寸改变
这些都是显而易见的，或许你已经有过这样的体会，不间断地改变浏览器窗口大小，导致UI反应迟钝（某些低版本IE下甚至直接挂掉），现在你可能恍然大悟，没错，正是一次次的重排重绘导致的！

重排和重绘是DOM编程中耗能的主要原因之一，平时涉及DOM编程时可以参考以下几点：
1、尽量不要在布局信息改变时做查询（会导致渲染队列强制刷新）
2、同一个DOM的多个属性改变可以写在一起（减少DOM访问，同时把强制渲染队列刷新的风险降为0）
3、如果要批量添加DOM，可以先让元素脱离文档流，操作完后再带入文档流，这样只会触发一次重排（fragment元素的应用）
4、将需要多次重排的元素，position属性设为absolute或fixed，这样此元素就脱离了文档流，它的变化不会影响到其他元素。例如有动画效果的元素就最好设置为绝对定位。

javascript代码优化

1、减少dom访问
对DOM操作的代价是高昂的，这在网页应用中的通常是一个性能瓶颈。

天生就慢。在《高性能JavaScript》中这么比喻：“把DOM看成一个岛屿，把JavaScript(ECMAScript)看成另一个岛屿，两者之间以一座收费桥连接”。所以每次访问DOM都会教一个过桥费，而访问的次数越多，交的费用也就越多。所以一般建议尽量减少过桥次数。
解决办法：

修改和访问DOM元素会造成页面的Repaint和Reflow，循环对DOM操作更是罪恶的行为。所以请合理的使用JavaScript变量储存内容，考虑大量DOM元素中循环的性能开销，在循环结束时一次性写入。
减少对DOM元素的查询和修改，查询时可将其赋值给局部变量。

2、减少作用域链查找
作用域查找也是消耗一定时间的，所以我们可以将要使用的对象用变量保存在局部变量中，避免作用域的全局查找。此外，要减少作用域链查找还应该减少闭包的使用。

3、慎用 with　
with(obj){ p = 1}; 代码块的行为实际上是修改了代码块中的执行环境 ，将obj放在了其作用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，如果没有再依次按作用域链向上查找，因此使用 with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的，过长的作用域链会导致查找性能下降。  
　　因此，除非你能肯定在 with代码中只访问 obj中的属性，否则慎用 with，替代的可以使用局部变量缓存需要访问的属性。
4、 避免使用 eval和 Function
每次 eval 或Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。  
　　eval 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。  
　　Function 构造函数比 eval略好，因为使用此代码不会影响周围代码 ;但其速度仍很慢。  
　　此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。
　　
5、优化循环，妙用算法
减少循环的次数对性能的提升效果也是显著的。特别是在循环次数很多的时候，优化循环次数是很有必要的。有些时候算法可以取到事半功倍的效果。

Das obige ist der detaillierte Inhalt vonweb前端性能优化方法. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!