前端性能优化-代码优化

一、JS开销和如何缩短解析时间

JS开销相比其他资源开销大的很多，js开销有加载，加载完成后需要编译解析、最后是执行。

如何缩短解析时间？
1.code splitting代码拆分，按需加载
2.tree shaking代码减重（webpack自动进行）
3.避免超过1kb的行间脚本
4.避免长任务
5.使用rAF和rIC进行时间调度

二、配合V8 有效优化代码

V8编译原理

1、分词／词法分析：
这个过程会将字符串分割为有意义的代码块，这些代码块称之为词法单元。例如变量的声明：
var a = 2;
这行代码会被分为以下词法单元：var、a、=、2(空格算不算词法单元取决于空格对于该编程语言是否具有意义)；这些零散的词法单元会组成一个词法单元流（数组）进行解析。

2、解析／与法分析：
这个过程会将词法单元流转换成一棵抽象语法树(Abstract Syntax Tree，AST）在线解析工具。
"var a = 2;"的词法单元流就会被解析为下面的AST：
var a = 2;对应的AST

3、代码生成：
将AST转化为可执行的代码。

V8的优化机制：
1、脚本流
2、字节码缓存
3、懒解析

三、函数优化.

V8这样的JS引擎，默认对函数进行懒解析（lazy parsing）：只有当这个函数真正被调用的时候，才会去解析函数体。这样的解析方式会对性能有很好的提升。但是实际开发中有的情况需要JS立即去执行，此时如果是懒解析的函数但是发现需要立即执行，于是又快速的进行了一个饥饿解析（eager parsing），这样的话会先进行了一次饥饿解析，然后又进行了一次懒解析，执行效率反而降低了。

那么如何告诉解析器某个函数需要立即解析:
只需加一对括号：

const add = ((a,b) => a+b)    // 这样的作用是告诉解析器，当看到这个函数的时候就对这个函数进行解析
const n1 = 1
const n2 = 2
add(n1,n2)

这样当后面需要调用的时候就可以直接调用了
有个问题：
当把代码进行压缩时（uglyfy），可能会把这对括号去掉
解决：Optimize.js。可以在压缩以后把括号加回来
uglyfy后来把这些问题也解决了，需要兼顾老版本的可以添加

避免反优化

performance.mark('start') //性能测量标记
add = (a,b) =>  a + b
 
const num1 = 0
const num2 = 2
 
for(let i = 0; i < 1000000; i++) {
  add(num1,num2)
}
 
add(num1,'1dsd')   // V8已经做了对于add的优化。如参数类型改变。所以要撤掉已做的优化，会造成一些延迟。反优化
 
for(let i = 0; i < 1000000; i++) {
  add(num1,num2)
}
performance.mark('end')

四、对象优化

1，以相同顺序初始化对象成员，避免隐藏类的调整

class RectArea { // HC0
    constructor(l, w) {
        this.l = l; // HC1
        this.w = w; // HC2
    }
}
 
const rect1 = new RectArea(3,4); // 创建了隐藏类HC0, HC1, HC2
const rect2 = new RectArea(5,6); // 相同的对象结构，可复用之前的所有隐藏类
 
const car1 = {color: 'red'}; // HC0
car1.seats = 4; // HC1
 
const car2 = {seats: 2}; // 没有可复用的隐藏类，创建HC2
car2.color = 'blue'; // 没有可复用的隐藏类，创建HC3

2，实例化后，避免添加新属性

const car1 = {color: 'red'}; // In-object 属性
car1.seats = 4; // Normal/Fast 属性，存储在property store里，需要通过描述数组间接查找

3，尽量使用Array 代替 array-like 对象。转成数组再进行操作。

Array.prototype.forEach.call(arrObj, (value, index) => { // 不如在真实数组上效率高
  console.log(`${ index }: ${ value }`);
});
 
const arr = Array.prototype.slice.call(arrObj, 0); // 转换的代价比影响优化小
arr.forEach((value, index) => {
  console.log(`${ index }: ${ value }`);
});

4，不要读取超过数组的长度

function foo(array) {
  for (let i = 0; i <= array.length; i++) { // 越界比较
    if(array[i] > 1000) { // 1.沿原型链的查找 2.造成undefined与数进行比较
        console.log(array[i]); // 业务上无效、出错
    }   
  }

5，避免元素类型的转换。eg：数组元素类型的统一

const array = [3, 2, 1]; // PACKED_SMI_ELEMENTS
array.push(4.4); // PACKED_DOUBLE_ELEMENTS

五、HTML优化

1.减少iframes使用
2.压缩空白符
3.避免节点深层级嵌套
4.避免table布局（开销大，维护麻烦）
5.删除注释
6.CSS&JS尽量外链（导致html过大，不好优化）CSS放在头部 JS放在body底部
7.删除元素默认属性

六、css 优化

1、选择器

.highlight-list
 .list:nth-last-child(1) > #box a

我们都建议定义一个单一的样式类来表示该元素，如上面的第一行
而不要使用伪类等各种选择器来确定元素
因为我们都知道CSS选择器解析从右到左进行的，读取到a的时候，会获取所有的a，然后根据nth-last-child（1）>这个条件进行过滤，得到满足条件的a ，然后再往左走根据.list这个条件过滤，得到最终的结果a
但是最新的浏览器的研究表明，两者性能相差并不大，可以说是完全一样，不是影响性能的主要因素

2、降低CSS对渲染的阻塞
低css的大小
提前对css文件进行下载
对首屏展示有关的css先加载，无关的进行延迟加载

3、利用GPU进行完成动画
will-change: transform; transform等之前讲过不会进行布局和重绘，会单独在一层，GPU直接进行干预

4.使用contain属性

.news li {
  padding: 10px;
  contain: layout;
}

为什么要使用这个contain属性呢
就比如一个ul 有多个li 实现一个新闻列表
当我们对第一个li插入一个新东西，浏览器并不知道这个操作会不会影响其他元素的布局，这时候浏览器会对其他元素进行重新的位置等方面的计算，这时候开销很大。但是我们开发者肯定这个操作不会对其他元素造成影响。
此时我们就可以利用contain：layout，与浏览器进行沟通。告诉浏览器我这个盒子的布局与外部没有任何关系。里面怎么变化不会影响到外面，同时外面怎么变化不会影响到里面。
这样浏览器就清楚了，会单独处理操作的元素，而不会对其他元素进行处理，减低了很大一部分开销。

font-display字体加载，显示方式