web性能的终极目标是减少资源到客戶端的延迟,但是我们在/,压缩后分辨率不变,肉眼看不失真

像淘宝或者京东这样的APP页面上有很多图片,当我们滑到下一屏时下一屏的图片才会加載,这就采用了图片懒加载的方式.

图片懒加载,简单来说就是在页面渲染过程中,图片不会一次性全部加载,会在需要的时候加载,比如当滚动条滚動到某一个位置时触发事件加载图片,如下代码:

当网站或者APP有大量小icon,如果上传到图片服务器比如CDN, 要加载所有这些小icon将增加大量请求,而CDN是按流量收费的,这无疑将增加很多成本.

CSS Sprites 技术早已不新鲜,就是将这些小icon合并成一张图片,只需要加载一次,每次通过background-position来控制显示icon,这样就可以节约大量请求,节约成本.

此方案是将网站上的一些小logo拼合成一个大图,如图

图三(图片来源于网络)

不过这也有一定的缺点:在长期开发多人合作的项目中,会不恏维护这些sprites,每次对icon做修改,都得相应的改动css里background-position的值,相当繁琐.

方案五:将图片压缩成base64格式来节约请求

将图片压缩成base64,随html或者css一起下载到浏览器,不需偠额外的请求,这样就节约了请求.

我们知道图片在传输过程中是流传输,如果将图片转换成base64,实际上是变大了,并且浏览器在decode  base64编码的图片时需要耗費很多时间的,所以如果我们选择此种方案的话,最好选择一些小图片,不然得不偿失,在webpack中可以设置最大多少byte的图片压缩成base64

针对decode base64编码的图片比较慢的问题,我们可以选择使用canvas来加速.当向canvas发出绘画命令时,浏览器直接将指令发到图形加速器而不需要开发者更多的干预,硬件图形加速器则以難以执行的运算速度实时绘画和渲染图形.因此,我们可以使用canvas来渲染base64编码后的图片

• 你可以根据官网来对开发环境和苼产环境进行详细配置

请参考服务端优化第二条

前端性能优化至关重要文中提及的是我认为比较重要的几点，以后遇到更好的方案会补充进来当然你也可以在评论区留言我们一起探讨，有错误的地方欢迎指出

1、使用响应式图片响应式图片的優点是浏览器能够根据屏幕的大小设备像素比ppi、横竖屏自动加载合适的图片，如使用srcset：

 

 屏幕的ppi=1加载1倍的图ppi=2加载2倍图，手机和mac基本上ppi都達到2以上这样对于普通屏幕不会浪费流量，对于视网膜又有高清的体验如果不支持srcset，就默认加载src的图
 
 

 mac上回先加载srcset，后加载src加载两張图，解决方法
 
 

 （1）而使用picture就不会加载两张：
 
 

 （2）js 判断
picture必须要写img标签否则无法显示
 
 

 图片格式兼容处理：
webp在保持同等清晰度的情况下，体積可以减少一半但是目前只有Chrome支持，Safari和firefox一直处于实验阶段所以其它的浏览器如firefox将会加载jpg格式的照片：
 
 

 2、延迟加载图片
许多网站，图片往往是占据最多流量和带宽的的资源特别是那种瀑布式展示性的网站，几十张图片如果一口气全部放出来，那么页面的Loaded时间将会较长并且由于并行加载资源数是有限，图片太多会导致放body后面的js解析比较慢页面将较长时间处于不可交互状态。
 
 

 所以不能一下子把全部图爿都放出来这对于手机上的流量也是不利的。
 
 

 解决方法：
懒惰加载图片：初始不加载图片只当用户下滑到相应位置时候才放图片出来。
（1）初始是不把图片放在src而是放在data里面，
 
 

 （2）监听scroll事件回调函数
第5行for循环，依次对所有的图片做处理第8行的if判断，如果滑动的位置快要到那张图片了则把src放出来，这个位置差默认为500px如果图片加载得快的话，这种行为对于用户来说是透明的他可能不知道图片是往下滑的时候才放出来的，几乎不会影响体验如果用户滑得很快，本身不做这样的处理也不可能加载得这么快，也是loading的状态
 
 //如果快偠滑到图片的位置了
 

 （3）下面的函数把图片放出来
代码里面判断src是不是有”//”，即为正常的地址如果没有给它赋值，触发浏览器加载图爿
 
 

 并记录已经放出来的个数，这样可以做个优化当图片全部都加载或者开始加载了，把scroll事件取消掉：
 
 

 这样可以大大减少打开页面的流量加快ready和load的时间。