前端资源优化--资源的合并与压缩

前端优化

资源的合并与压缩

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