前端资源优化--资源的合并与压缩
前端优化
资源的合并与压缩
web前端是bs架构
web访问是动态增量的过程，通过不断请求远程服务器加载资源
优点：减少http请求，减少请求资源的大小
1.资源合并与压缩-压缩
a.html压缩
方法：
1.使用在线网站进行压缩
2.nodejs提供了html-minifier工具
3.后端模板引擎渲染压缩
b.css压缩
1.无效代码删除
2.css语义合并
c.js压缩与混乱
1.无效字符的删除
2,剔除注释
3.代码语义的缩减和优化
4.代码保护（代码压缩，可读性底，有利于保护代码不被看懂或复制）
方法
1.使用在线网站进行压缩
2.nodejs提供了html-minifier工具
3.使用uglifyjs2对果进行压缩
资源合并与压缩-合并
文件合并存在的问题
首屏渲染问题（文件合并成一个文件，首次加载时间会比较长）
缓存失效问题（修改其中一处内容，整个文件变动，在浏览器的缓存失效，又要重新加载整个文件）
文件合并建议
公共库合并
不同页面的合并（vue的异步加载组件）
见机行事，随机应变
方法
1.使用在线网站进行合并
2.使用nodejs或webpack等框架实现文件合并
2.图片相关优化
png8/png24/png32之间的区别
png8 -- 256色（2^8） 支持透明--适用于颜色种类较少的png图片
png24 -- （2^24） 不支持透明
png32 -- （2^24） 支持透明--适用于颜色种类丰富的png图片
不同图片常用的业务场景
jpg有损压缩，压缩率高，不支行透明
png支持透明，浏览器兼容好
webp压缩程序更好，在ios webviewe有兼容性问题
svg矢量图，代码内嵌，相对较小，图片样式相对简单的场景
进行图片压缩
针对真实图片情况，舍弃一些相对无关的色彩信息
css雪碧图
优点：减少Http请求
缺点：当雪碧图过大时，加载过慢，在雪碧图上的所有图片就会都没有加载出来
image inline
把图片转成base64格式，然后内嵌在html中
优点：减少http请求
缺点：代码体量过大
使用矢量图
使用svg进行矢量图绘制
使用iconfont解决icon问题
与jpg相比，更小，加载更快
缺点：颜色比较单调，复杂的图片不适合使用矢量图
在安卓下使用webp
webp压缩率更高，大小更小，但是并不所有浏览器兼容
图片压缩网址图片压缩
3. css和js的装载与执行
html,css,js加载过程
输入网站，发起请求，服务器返回一段html,浏览器html解析器解析，从上到下生成dom树，在这个过程中，解析到相应的link,script等外部资源，然后由浏览器发起请求，加载到相应的资源并解析，生成对应的css树，css树和dom树结合，生成render tree,然后布局，重绘，形成html页面
html渲染过程中的一些特点
顺序执行，并发加载(引入外部资源，并发加载)
是否阻塞（css,js加载是否阻塞后续dom加载）
依赖关系
引入方式
顺序执行，并发加载
词法分析--从上到下
并发加载--引入外部资源，并发加载
并发上限--并发加载资源，有上限
css阻塞
css head中阻塞页面的渲染
css阻塞js执行--js执行可能影响dom结构和css样式，执行前要求dom和css已经加载完成，有依赖关系
css不阻塞外部脚本的加载
js阻塞
直接引入的js阻塞页面的渲染
js不阻塞资源的加载
js顺序执行，阻塞后续js逻辑执行
依赖关系
页面渲染依赖于css加载
js的执行顺序的依赖关系
js逻辑对于dom节点的依赖关系
js引入方式
直接引入--会阻塞页面加载
defer--不会阻塞dom渲染，dom渲染完成后，按照从上到下，同步执行
async--不会阻塞dom渲染，dom渲染完成后，异步加载执行，不存在依赖关系
异步动态引入js
加载和执行的一些优化点
css样式表置顶
用link代替import--外部引用css样式完成后，再解析import，在css样式表内部执行,不会并发执行
js脚本置底
合理使用js的异步加载能力
4. 懒加载与预加载
原理
什么是懒加载：图片进入可视区域之后请求图片资源，如果网站图片很多，但是用户只看了几张就退出，后面的图片也没有必要加载，这时就是用到懒加载了，而且过多资源加载，会影响后面js的加载
1,监听scoll整件，当图片进入可视区域后，图片开始加载
什么是预加载：图片等静态资源使用前，提前加载，资源使用到时能从缓存中加载，提升用户体验
预加载的三种方法
1.直接在页面内通过img标签引入，默认隐藏
2.在js里文件new image对象，需要的时候直接引用
3.使用XMLHttpRequest对象加载图片，这个方法返回状态和回调函数，监听函数，更好控制整个过程，但是不同域名下的资源有跨域问题
4.使用preloadJS库
重绘与回流
css性能让javascript变慢？是的，这是因为ui是一个线程，js渲染也是一个线程，但这两个线程是互斥，当其中一个线程进行时，另一个是冻结的。频繁触发重绘与回流，会导致ui频繁渲染，最终导致js变慢
回流
当render tree中的一部分或全部，因为元素的规模尺寸，布局，隐藏等改变而需要重新构建。这就称为回流。当页面布局和几何属性（大小长宽）改变时需要回流
重绘
当render tree中的一些元素需要更新属性，在，而这些属性只是影响元素的外观，风格，而不影响布局的，比如背景，字体颜色，则称为重绘。
回流必将引起重绘，而重绘不一定会引起回流
触发页面重布局的属性
盒子模型相关属性会触发重布局
定位属性及浮动也会触发得布局
改变节点内部文字结构也会触发重布局
只触发重绘属性
浏览器存储
多种浏览器存储方式并存，如何选择？
cookie
因为HTTP请求无状态，所以需要cookie去维护客户端状态
cookier的生成方式
http response header 中的set-cookie,当客户端接收到http response header 中的set-cookie信息时，会自动在客户端生成相应的cookie,客户端再次发起请求时，这些cookie信息将被携带在request header中带给服务端，服务端可以从这些信息中判断用户的相关信息--用于浏览器端和服务端的交互
cookie属性httponly(服务端设置), 如果您在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击
js中可以通过document.cookie可以读写cookie--客户端自身存储信息
cookie存储的限制
作为浏览器存储，大小4kb左右
需在设置过期时间 expire
浏览器存储尽量用localstorage
Localstorage
HTML5设计出来专门用于浏览器存储
大小为5M左右
仅在客户端使用，不和服务端进行通信
接口封闭较好，有专门的api进行设置删除操作
浏览器本地缓存方案
sessionstorage
会话级别的浏览器存储（浏览器关闭，sessionstorage删除）
大小为5M左右
仅在客户端使用，不和服务端进行通信
接口封闭较好，有专门的api进行设置删除操作
对于表单信息的维护
IndexedDB
IndexedDB 就是浏览器提供的本地数据库，它可以被网页脚本创建和操作。IndexedDB 允许储存大量数据，提供查找接口，还能建立索引。这些都是 LocalStorage 所不具备的。就数据库类型而言，IndexedDB 不属于关系型数据库（不支持 SQL 查询语句），更接近 NoSQL 数据库。
service workers 产生的意义
大规模,多线程运行js
PWA
