共计 2827 个字符，预计需要花费 8 分钟才能阅读完成。
浏览器有一个重要的对象 performance，很多的和工夫节点无关的数据都能够从这个对象下来获取
渲染优化
布局和绘制
动画能够走复合的过程，不会触发回流和重绘；
复合是要害渲染门路中最初一个环节，次要的作用就是把页面拆解成不同的图层；应用 transform 和 opacity 能够把波及到的元素提取到一个图层，那么这些元素的产生视觉上变动的时候就只会触发复合，而不会触发布局和重绘。
高频事件防抖
比方滚动，这类事件在一帧里会触发屡次，咱们只关怀滚动到哪里，解决页面卡顿大利器 requestAnimationFrame（每一帧的布局和绘制之前）。
代码优化
- js 优化
同时 100kb 的文件，js 和图片加载工夫雷同，然而 js 之后要通过编译，解析，执行等等更耗时，尽管这个过程是跟浏览器解决引擎无关，但如果再代码层面进行配合，实际上能够优化这个过程
两种计划：代码拆分，按需加载，和 tree shaking（代码减重）；另外从解析和执行来看，应该缩小主线程的工作量，防止长工作，防止超过 1kb 的脚本，应用 raf 进行工夫调度 - html 优化
缩小 iframes 应用；防止节点深层次嵌套；防止 table 布局，开销很大；css js 尽量外链
资源优化
压缩与合并
缩小 http 申请数，缩小申请资源大小
html 压缩：应用 HtmlWebpackPlugin 的时候配置 minify
css 压缩：mini-css-extract-plugin
js 压缩：
uglifyjs：单线程压缩代码，也就是说多个 js 文件须要被压缩，它须要一个个文件进行压缩。所以说在正式环境打包压缩代码速度十分慢
webpack-parallel-uglify-plugin：w4
terser-webpack-plugin：w4 并行处理
TerserPlugin：w5
预计算：const day = 7 – 5；线上的话间接变成 const day = 2; 在编译器把一些能计算出后果的代码先计算出来，这样子就不会在运行时进行计算（terse 主动帮你做）
图片优化
抉择适合的图片格式
JPEG/JPG：首屏轮播图
png：做小的图标或者 logo
webp：不是规范 google
小图标能够用 iconfont 解决，字体文件十分小
适合的图片大小
图片资源优先级：重要的图片（首屏图片）先进行加载
懒加载
构建优化
webpack 的优化配置
Tree-shaking（前提是模块化）
w4 里设置 mode：production 会开启 tersePlugin
其简略的工作原理是找到入口文件，入口相当于树的根节点，去看入口文件援用了什么货色。又会进一步去剖析这些利用的包或者模块外面又援用了什么模块。一直地进行剖析之后把所有须要的货色保留下来，把那些引入了然而没有用到的 shaking 上来，最初打包生成的 bundle 只蕴含运行时真正须要的代码
然而有时候会波及到在全局作用域上增加或者批改属性，export 是体现不进去的，就会被 shaking 掉，把所有不须要被 shaking 掉的文件放在 sideEffect 数组里
webpack 依赖优化
第一种是利用 noParse 参数进步构建速度。noParse 的意思就是不解析，间接告诉 webpack 疏忽较大的库
第二种形式通过 DllPlugin 插件，防止打包时对不变的库反复构建进步构建速度。比方我的项目中引入的 react,react-dom
webpack 代码拆分
对于大型的 web 利用，如果咱们把所有的货色都打包到一起是非常低效和不可承受的。须要把 bundle 拆分成若干个小的 bundles/chunks。把大的文件拆分成小的文件扩散进行加载，先加载更重要的文件以缩短首屏加载工夫，可晋升用户体验。第一种形式在 entry 中增加其余入口，这样工程就会被拆分成多个不同的 bundle。这种形式比拟间接，然而须要手工去增加和保护。第二种形式通过 splitChunks 插件提取私有代码，拆分业务代码与第三方库。react 相干的独自提取；cra 的分包策略第一步把 webpack 运行时（runtimeChunks）的货色抽离进去，第二步就是把所有 react 相干的都给分离出来，他有个 chunks 写的是 all 是什么意思：initialChunk asyncChunk（异步 import 的那些货色，懒加载的那些）
webpack 长久缓存
w5：cache，w4：cache-loader
传输加载优化
启用 Gzip
Gzip 是用来进行网络资源压缩，缩小资源文件在网络传输大小的技术
插曲：Compression-webpack-plugin 不要应用，前端这边不须要做 gzip，如果前端做了 gzip，服务端那边也把 gzip 关上，他去和浏览器磋商，浏览器在申请头中会带上 Accept-Encoding 这个参数来阐明本人反对哪些内容编码方式，服务端返回的 Response Headers 中则存在一个 Content-Encoding，用来阐明数据的压缩办法，问浏览器支不反对 gzip，浏览器说我不反对，那代码就不能用了；所以前端不须要做 gzip，只有把没做过 gzip 的代码送到去送到服务器或者 proxy，而后这个代理去和浏览器磋商，gzip 这部分应该在 nginx 那边去做，或者在 cdn 或者 oss 这边去做，前端做会有协商失败的状况
启用 Keep Alive
对 TCP 连贯进行复用，http 1.1 开始这个参数就是默认开启的
http 资源缓存
index.html 走强缓存 当初风行的形式是文件 hash+ 强缓存的一个计划。比方 hash+ cache control: max-age= 1 年。
css js 文件走强缓存或者协商缓存
http 1.0 没有实现 Cache-Control，须要写上 pragma
高阶
服务端渲染：在服务端实现页面插值 / 数据组装，间接返回蕴含有数据的页面
客户端渲染：客户端别离申请页面动态资源和接口数据，而后操作 DOM 赋值到页面。
.net、jsp 前后端不拆散，直到 ajax 呈现，客户端渲染就开始
https://zhuanlan.zhihu.com/p/…
SSR：
长处：
1. 优良的 SEO
2. 首屏加载快
毛病：
1. 负载大：因为渲染工作都交由服务端进行，在高并发的状况下，对于服务端负载压力大。
2. 复用性能差：因为返回的是整个页面，对于每个路由都要从新进行页面刷新，复用性能 上不敌对。
3. 前后端耦合重大，前端开发依赖于后端，开发模式上不敌对。
传统 CSR：
长处：
1. 节俭服务器性能。
2. 部分刷新，无需每次都申请残缺页面，体验更好。
3. 前后端拆散开发。
毛病：
1. 因为页面显示过程要进行 JS 文件拉取和 React 代码执行，首屏加载工夫会比较慢。
2. 对于 SEO(Search Engine Optimazition, 即搜索引擎优化)，齐全无能为力，因为搜索引擎爬虫只意识 html 构造的内容，而不能辨认 JS 代码内容。
同构渲染：
长处：兼顾前端渲染的大部分长处和后端渲染 SEO 和首屏加载的长处
毛病：1. 须要额定的开发构建老本 2. 对服务器有肯定负载
