web前端开发中的性能优化 前端性能优化之路——图片篇。

在平时的学习生活当中，对于前端开发一定都很关心，今天我爱编程网小编为大家整理了web前端开发中的性能优化 前端性能优化之路——图片篇。，希望能够帮助到大家。

Web前端新手要掌握的性能优化

今天小编要跟大家分享的文章是关于Web前端新手要掌握的性能优化知识。本文将分享一些前端性能优化的常用手段，包括减少请求次数、减小资源大小、各种缓存、预处理和长连接机制，以及代码方面的性能优化等方面。下面来和小编一起看一看吧！





base64：尤其是在移动端，小图标可以base64(webpack)，大图片慎用(如果加载速度过于慢的，而且很重要的图片，可以用base64)


1、减少HTTP的请求次数和传输报文的大小


「CSSSprite(雪碧图、图片精灵)技术」


使用字体图标(IconFont)或者SVG等矢量图


+减少HTTP请求次数或者减少请求内容的大小


+渲染更快：因为它们是基于代码渲染的，而对于位图(png/jpg/gif)是需要先把图片编码在渲染


+不容易是帧变形


+也可以使用webp格式图片，这种格式要小一些(但是需要服务器端支持这种格式的请求处理)


「图片懒加载(延迟加载)技术」


+第一次加载页面的时候不去请求真实的图片，提高第一次渲染页面的速度，请求图片的额外消耗尽可能不要处理


+当页面加载完，把出现在用户视野区域中的图片做真实加载，没有出现的先不加载(节约流浪，也能减少对服务器的请求压力)


o对于数据我们也尽可能分批加载(不要一次请求过多的数据，例如分页技术)


音视频文件取消预加载(preload='none')，这样可以增加第一次渲染页面的速度，当需要播放的时候在加载


客户端和服务器端的数据传输尽可能基于JSON格式完成，XML格式比JSON格式要大一些(还可以基于二进制编码或者文件流格式，这种格式比文件传输好很多)


「把页面的css/js等文件进行合并压缩」


合并：争取css和js都只导入一个(webpack可以实现并合并压缩哦)


压缩：基于webpack可以压缩，对于图片自己找工具先压缩，可以使用服务器的GZIP压缩


图片BASE64(用BASE64码代表图片，减少HTTP，增加浏览器渲染速度，所以真是项目中，尤其是移动端，如果图片加载缓慢，BASE64一下就好了，;但是base64会导致文件中心的代码超级恶心，不利于维护和开发，所以减少使用);webpack中科院配置图片


2、设置各种缓存、预处理和长连接机制


不经常更改的静态资源做缓存处理(一般做的是304或者ETAG等协商缓存)


「建立Cache-Control和ExpiresHTTP的强缓存」


DNS缓存或者预处理(DNSPrefetch)，减少DNS的查找


设置本地的离线存储(manifest)或者把一些不经常更改的数据做本地临时存储(webstorage，indexdb)等


有钱就做CDN(地域分布式服务器)，或者加服务器


「建立Connection：keep-aliveTcp长连接」


使用HTTP2版本协议(现在用的一般都是http1.1)，可以多条tcp通道共存=>管道化链接


一个项目分为不同的域(不同的服务器)，例如：资源web服务器、数据服务器，图片服务器，视频服务器等，合理利用服务器资源，但是导致过多的DNS解析


Cache-Control的优先级高于Expires


基于本地存储，做数据的存储


3、代码方面的性能优化


减少对闭包的使用(因为过多使用闭包会产生很多不销毁的内存，处理不好的话，会导致内存溢出“栈溢出”)，减少闭包的嵌套(减少作用域链的查找层级)


对于动画来说：能用css解决的不用js(能够用transform处理的，不用传统的css样式，因为transform开启硬件加速，不会引发回流，或者使用定位的元素也会好很多，因为定位的元素脱离文档流，不会对其他元素的位置造成影响)，能用
requestAnimationFrame解决的不用定时器


+用requestAnimationFrame还有一个好处，当页面处于休眠无访问状态，动画会自己暂停，知道回复访问才开始，而定时器是不论什么状态，只要页面不管，就一直处理


避免使用iframe(因为iframe会嵌入其他页面，这样父页面渲染的时候，还要同时把子页面也渲染了，渲染进度会变慢)


减少直接对DOM的操作(原因是减少DOM的回流和重绘...)，当代项目基本基于mvvm，mvc数据驱动视图渲染的，对DOM的操作框架本身完成，性能要好很多


低耦合高内聚(基于封装的方式：方法封装，插件，组件，框架，类库等封装，减少页面中的冗余代码，提高代码使用率)


尽可能使用事件委托


避免出现死循环或者嵌套循环(嵌套循环会成倍增加循环的次数)


项目中尽可能使用异步编程来模拟出多线程的效果，避免主线程阻塞(异步操作基于Promise设计模式来管理)


JS中不要使用with


避免使用css表达式


函数的防抖和节流


减少使用eval(主要原因是防止压缩代码的时候，由于符号书写不合规，导致代码混乱)


图片地图：对于多次调取使用的图片(尤其是背景图)，尽可能把它提取成为公共的样式，而不是每一次重新设置background


减少filter滤镜的使用


尽可能减少选择器的层级


尽可能减少table布局


手动回收堆栈内存(赋值为null)


「栈溢出：死递」


functionfunc(){


func();


}func();


解决方案：


functionfunc(){


setTimeout(func,0);


}func();


相互引用：引用类型之间的相互调用，形成嵌套式内存


letobj1={


name:'obj1',};


letobj2={


name:'obj2',


x:obj1}


obj1.x=obj2;


以上就是小编今天为大家分享的关于Web前端新手要掌握的性能优化知识的文章，希望本篇文章能够对正在从事web前端工作的小伙伴们有所帮助，想要了解更多web前端知识记得关注北大青鸟web培训官网，最后祝愿小伙伴们工作顺利，成为一名优秀的web前端工程师。

如何对前端性能进行优化

前端开发代码优化、可维护性、浏览器兼容性是非常重要的课题。从实际的工程应用角度出发，最常遇见的前端优化问题。前端性能进行优化规则，基本可以涵盖现在前端大部分的性能优化原则了，很多更加geek和精细优化方法都是从这些原则里面延伸出来的。

前端性能进行优化都有哪些规则

1. 减少HTTP请求次数

   尽量合并图片、CSS、JS。比如加载一个页面有5个css文件的话，把这个5个文件合成一个的话，就只需要发出一次http请求，节省网络请求时间，加快页面的加载。
   

2. 使用CDN

网站上静态资源即css、js全都使用cdn分发，包括图片

3. 避免空的src和href

当link标签的href属性为空、script标签的src属性为空的时候，浏览器渲染的时候会把当前页面的URL作为它们的属性值，从而把页面的内容加载进来作为它们的值。所以要避免犯这样的疏忽。

4. 为文件头指定Expires

Exipres是用来设置文件的过期时间的，一般对css、js、图片资源有效。 他可以使内容具有缓存性，这样下回再访问同样的资源时就通过浏览器缓存区读取，不需要再发出http请求。如下例子：

新浪微博的这个css文件的Expires时间是2016-5-04 09:14:14.

5. 使用gzip压缩内容

gzip能够压缩任何一个文本类型的响应，包括html，xml，json。大大缩小请求返回的数据量。

6. 把CSS放到顶部

网页上的资源加载时从上网下顺序加载的，所以css放在页面的顶部能够优先渲染页面，让用户感觉页面加载很快。

7. 把JS放到底部

加载js时会对后续的资源造成阻塞，必须得等js加载完才去加载后续的文件 ，所以就把js放在页面底部最后加载。

8. 避免使用CSS表达式

举个css表达式的例子

font-color: expression( (new Date()).getHours()%3 ? “#FFFFFF" : “#AAAAAA" );

这个表达式会持续的在页面上计算样式，影响页面的性能。并且css表达式只被IE支持。

9. 将CSS和JS放到外部文件中

目的是缓存文件，可以参考原则4。 但有时候为了减少请求，也会直接写到页面里，需根据PV和IP的比例权衡。

10. 权衡DNS查找次数

减少主机名可以节省响应时间。但同时，需要注意，减少主机会减少页面中并行下载的数量。

IE浏览器在同一时刻只能从同一域名下载两个文件。当在一个页面显示多张图片时，IE 用户的图片下载速度就会受到影响。所以新浪会搞N个二级域名来放图片。

下面是新浪微博的图片域名，我们可以看到他有多个域名，这样可以保证这些不同域名能够同时去下载图片，而不用排队。不过如果当使用的域名过多时，响应时间就会慢，因为不用响应域名时间不一致。

11. 精简CSS和JS

这里就涉及到css和js的压缩了。比如下面的新浪的一个css文件，把空格回车全部去掉，减少文件的大小。现在的压缩工具有很多，基本主流的前端构建工具都能进行css和js文件的压缩，如grunt，glup等。

12. 避免跳转

有种现象会比较坑爹，看起来没什么差别，其实多次了一次页面跳转。比如当URL本该有斜杠（/）却被忽略掉时。例如，当我们要访问  baidu.com 时，实际上返回的是一个包含301代码的跳转，它指向的是  baidu.com/ （注意末尾的斜杠）。在nginx服务器可以使用rewrite；Apache服务器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash来避免。

另一种是不用域名之间的跳转， 比如访问  baidu.com/bbs 跳转到  bbs.baidu.com/ 。那么可以通过使用Alias或者mod_rewirte建立CNAME（保存一个域名和另外一个域名之间关系的DNS记录）来替代。

13. 删除重复的JS和CSS

重复调用脚本，除了增加额外的HTTP请求外，多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存，它们都存在重复运算JavaScript的问题。

14. 配置ETags

它用来判断浏览器缓存里的元素是否和原来服务器上的一致。比last-modified date更具有弹性，例如某个文件在1秒内修改了10次，Etag可以综合Inode(文件的索引节点(inode)数)，MTime(修改时间)和Size来精准的进行判断，避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用，可取后两个参数。使用ETags减少Web应用带宽和负载

15. 可缓存的AJAX

异步请求同样的造成用户等待，所以使用ajax请求时，要主动告诉浏览器如果该请求有缓存就去请求缓存内容。如下代码片段, cache:true就是显式的要求如果当前请求有缓存的话，直接使用缓存

$.ajax({      url : 'url',      dataType : "json",      cache: true,      success : function(son, status){                  }

16. 使用GET来完成AJAX请求

当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。因此使用GET获取数据时更加有意义。

17. 减少DOM元素数量

这是一门大学问，这里可以引申出一堆优化的细节。想要具体研究的可以看后面推荐书籍。总之大原则减少DOM数量，就会减少浏览器的解析负担。

18. 避免404

比如外链的css、js文件出现问题返回404时，会破坏浏览器的并行加载。

19. 减少Cookie的大小

Cookie里面别塞那么多东西，因为每个请求都得带着他跑。

20. 使用无cookie的域

比如CSS、js、图片等，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名的影响。

21. 不要使用滤镜

IE独有属性AlphaImageLoader用于修正7.0以下版本中显示PNG图片的半透明效果。这个滤镜的问题在于浏览器加载图片时它会终止内容的呈现并且冻结浏览器。在每一个元素（不仅仅是图片）它都会运算一次，增加了内存开支，因此它的问题是多方面的。

完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替，这种格式能在IE中很好地工作。如果你确实需要使用AlphaImageLoader，请使用下划线_filter又使之对IE7以上版本的用户无效。

22. 不要在HTML中缩放图片

比如你需要的图片尺寸是50* 50

那就不用用一张500*500的大尺寸图片，影响加载

23. 缩小favicon.ico并缓存

前端性能优化之路——图片篇。

本人是一名前端开发者，在公司负责目前负责信息流服务，为五大手机厂商和各大App提供服务，每天的请求就是以亿计算，加上我们又做了SSP和DSP，就是类似于百度广告联盟，腾讯广点通这种。接触过的应该知道，所以前端优化一直是我头痛的问题，不仅要注重用户体验，同时要兼顾收益，有时候必须牺牲一些用户体验，但是作为一名有思想的前端，还是努力规避掉，希望能和从事相同业务的同学一起学习交流一下，话不多说，就来分享我的性能优化之路，有什么不对的知识点，麻烦大家指出批评。

yahoo军规把大部分的前端优化都提到了，而在js优化这一块如果有兴趣的额，推荐大家去看《 高性能javascript 》,书里讲的非常详细。

Media Queries 调用高清背景图

通过 devicePixelRatio的值，就可以区分普通显示屏和高清屏，当devicePixelRatio值等于1时（也就是最小值），那么它普通显示屏，当devicePixelRatio值大于1(通常是1.5、2.0)，那么它就是高清显示屏。这时候我们可以让UI准备2套图片，甚至是3套图片，不同像素的图利用媒体查询结合 devicePixelRatio 可以区分普通显示屏和高清显示屏，并给出了如下CSS设计方案：

也可以用less或者sass

如果省时间通用性高，就像我们是服务端用nginx对图片进行处理，想要什么样尺寸的图片自己裁切,我们提供了按比例缩放和自定尺寸的裁切方法，地址后拼接字符串就行。 我爱编程网

与其他图片格式相比，在肉眼无法分辨图片质量差异的情况下，WebP的空间占用是最小的，目前国内外各大互联网公司都已经开始应用这一图片格式。比如美团

想实现首先是判断，即识别单次访问的来源浏览器是否支持 webp 格式，其次是执行，如果该浏览器支持，则将原图替换为 webp 格式，并返回。如果不支持，则显示原格式图片。

在识别阶段，我们有两种方法：

1. Server 处理

只要有请求，服务端就能拿到你的User-Agent信息，通过对浏览器进行分类，支持webp放在白名单里，不支持的则为黑名单。判断为白名单，则直接调用，返回webp格式图片；反之，则显示原图。这种方式的优点在于，只需定期维护白名单即可，逻辑简单；缺点则在于不可扩展、不可测试、UA判断会出现不准确的情况。

Server处理中的另一种方式是通过读取 JavaScript 种下的 cookie来实现判断。这种方式的优点是表现稳定，访问速度更快，切换无压力。但缺点是，页面静态化会导致用户切换浏览器时不能自主更新，图片服务失效。比如用户用支持webp的浏览器A请求页面，这时缓存的静态页面均使用webp图片，但当该用户使用不支持webp的浏览器B时，访问网页则会出现请求不到图片的报错。

Client 处理，是美团云为美团主站提供的处理方式。在这种处理方式中，浏览器端发送的beacon webp 请求后，通过检测其加载情况来判定 webp 支持情况，然后浏览器写一个cookie。之后通过读取浏览器cookie判断是否支持webp，就可以进行下一步替换操作了。

2.替换图片过程中也是有两种处理方式：

在 server 端处理的优点是对下游开发者透明，缺点是静态页面的缓存数量会翻倍。

替换方式如下：

在 client 端处理可以比较好地应对页面静态化的情况，主要针对懒加载（非首屏）的图片进行处理，直接通过修改懒加载器来实现。
对非懒加载的图片暂时没有特别好的办法。目前，可用替换路径的方式来处理。

Client 处理实际上效果也是不错的，美团页面里90%以上的图片都是懒加载的，基本上都可以满足需求。对于大多数用户来说，采用Client 处理实现webp转换是个不错的选择。

既然提到图片这一块，我有忍不住想扯写些题外的tracking Pixel（像素追踪），几乎所有网站都会做数据的采集，上报统计。特别是我们做SSP、DSP广告这块需要获取例如

数据永远说的是实话，数据证明一切可能。如facebook广告投放的跨境电商朋友都会使用facebook Pixel(像素追踪)以获得各环节的精准数据。这样追踪数据后，我们才能投放广告后销量上去了，哪个才是效果最好的，哪个效果不好，进而通过多个数据对比，对广告进行合理的调整优化。

国内搜狗、百度、360、新浪都是用这种 tracking Pixel 方法，实际就是利用1px 的图片，在图片地址后缀拼接你需要的信息参数，浏览器在请求任何资源的时候会发送当前系统的数据，比如浏览器信息，操作系统信息，作为http请求头送过去，他们就能统计了。

为什么不用js请求统计？

并不是所有的页面都支持JS的！NoJSStats的实现机制就是网站分析中点击流数据获取的方式之一——Web Beacons，即在页面中嵌入一个1像素的透明图片，当该页面被浏览时，图片就会被请求加载，于是在后端的服务器日志中就会记录该图片的请求日志，这样就可以获得日志记录。

例如百度：

本文引用@美团云 提供的webP方法，感谢。

以上就是关于web前端开发中的性能优化 前端性能优化之路——图片篇。的全部内容了，如果需要了解更多相关资讯敬请关注我爱编程网。