一、资源的压缩与合并
1.为什么要压缩和合并
减少http请求数量
减少请求资源大小
2.HTML压缩
使用在线工具进行压缩
使用html-minifier等npm工具
3.CSS压缩
使用在线工具压缩
使用clean-css等npm工具
webpack配置
4.JS压缩和混淆
使用在线工具压缩
webpack有关配置
5.CSS、JS文件合并
若是若干个小文件，可以考虑合并
无冲突，服务相同的模块，建议合并
有利于首屏呈现的优先加载，其他的延迟加载 不建议合并
二、图片优化
1.图片格式优化
（一）JPEG/JPG
优点：很好的压缩比，画质也可以被很好的保存
使用场景：展示较大的图片并较好的保存画质，比如首页的轮播图
缺点：由于压缩比较高，若是比较追求纹理和边缘那就不太合适，比如说logo就不太会用JPG
压缩工具：github–imagemin
（二）PNG
优点：相对于JPG来说，能更好的处理纹理和边缘
使用场景：logo，图标等小图片
缺点：由于注重纹理等，体积会比较大，色彩与JPG不相上下
压缩工具：imagemin–pngquant
（三）SVG
优点:svg是矢量图形,改变大小不会失真
缺点：兼容性相对较差
使用场景：制作思维脑图等
2.图片加载优化
（一）图片懒加载
原理：一张图片就是一个img标签，浏览器是否发起请求图片是根据img的src属性，所以实现懒加载的关键就是，在图片没有进入可视区域时，先不给img的src赋值，这样浏览器就不会发送请求了，等到图片进入可视区域再给src赋值。
原生的图片懒加载方案
img的一个属性
<img loading = 'lazy' src='' width='' height=''>
第三方插件懒加载方案
比如lazyload
（二）使用渐进式图片（要求美工制作）
上面的是JPG默认的加载方式 从上至下加载
下面的是渐进式的加载方式，从低像素到高像素
渐进式图片的优点
优点：始终让用户看到图片的全貌，可能刚开始不太清晰，慢慢清晰
（三）使用响应式图片
所有屏幕尺寸进行适配
img的srcset属性
<img src="lighthouse-200.jpg" sizes="100vw" srcset="lighthouse-100.jpg 100w, lighthouse-200.jpg 200W, lighthouse-400.jpg 400w, lighthouse-800.jpg 800w lighthouse-1000.jgp 1000w" >
顾名思义是一个src的集合，100w 代表 宽度达到了100w 就使用light100.jpg这个src 以此类推
有一个注意点，刚开始浏览器不会把这些src都下载下来，而是浏览器会根据当前浏览器的宽度下载某个最合适的src资源
mg的sizes属性
100vw 窗口视图的100%
给了sizes值之后，srcset会根据实际的sizes值 选取最合适的src资源
三、字体优化
1.字体出现的两个问题
字体未下载完成时，浏览器隐藏或自动降级，导致字体闪烁
常见的两个问题：
FOIT:flash of invisible text 文字从看不到到看到闪烁的过程
FOUT:flash of unstyled text 文字从没有样式到有样式的闪烁过程
2.使用font-display控制浏览器的行为，属性较新会有兼容问题
五个属性
auto用浏览器自动进行选择，没有太大用处
block（阻塞）：3s等待，在前3s不显示，如果3s之后期望字体下载完了，就用下载好的期望字体，要是3s之后期望字体还没有下载完，就用默认字体，什么时候期望字体下载完了，在进行替换
swap（交换）：刚开始加载就用默认字体，什么时候期望字体下载完成，在对默认字体进行替换
fallback：其实是对block的一种优化，等待时间变为100ms，等待时间之后若期望字体下载完了，用期望字体，否则用默认字体，什么时候期望字体下载完什么时候进行替换
optional：手机端特别优化的，等待时间100ms，若100ms 期望字体下载完了就一直用期望字体，若没下载完就一直用默认字体，永不替换.
