前端性能分析及提升方案

怎样评价一个网页的性能好坏？

首先我们能想到的就是：够快，秒开
但是其实还有另一个点，那就是稳定性。

什么是网站的稳定性呢？
比如你操作一个页面，用久了会卡顿，甚至会崩溃，这就是稳定性差的表现

也就是说，页面要打开的够快，操作时响应的也要够快，并且能长时间稳定运行不卡顿，页面性能就算是正常的。

页面的“快”

93年的时候尼尔森（Jakob Nielson）就提出：

• 小于100毫秒加载速度才是爽的
• 一秒钟大概是用户思路不被打断的极限。用户会感觉到延迟，但还可以接受
• 10秒左右是用户注意力的极限。 大多数用户会在10秒后离开你的网站

当然这是说的是互联网页面
但是对于c端或者b端页面来说，都是客户不得不用，秒开是很少见的，基本上都是2-3秒，为什么？
原因就是很多时候开发压根就不考虑性能，就只顾时埋头写业务代码
那网页要快，都有哪些东西会影响呢？
这个时候很多前端er会想起一到经典面试题了：提高页面性能有哪些？
并且回答：

1. 减少http请求
2. 图片压缩、雪碧图
3. js、css压缩
4. 开启gzip
5. 使用DNS缓存策略
6. 使用cdn缓存（如果跟别人共用，那就快乐你我他了）
7. 懒加载
   …

找到的几个前端性能测试工具

Chrome 自带的 LightHous

Pingdom Website Speed Test

在线的平平无奇的工具
地址： https://tools.pingdom.com/

WebPagetest

也是在线的，功能更强一些，能选多种模式。
地址：https://www.webpagetest.org/

GTmetrix

会提一些建议
在线地址：https://gtmetrix.com/

Keycdn Tool

会详细说明每个资源的加载时间和 HTTP 头
在线地址：https://tools.keycdn.com/speed

GiftOfSpeed

平平无奇
在线地址: https://www.giftofspeed.com/

Pagelocity

说是能跟竞争对手的页面对比，其实也没啥卵用
在线地址：https://pagelocity.com/

Sucuri Loadtime Tester

只能测速度，没啥卵用
在线地址：https://performance.sucuri.net/

GEEKFLARE

用于测试网站的 DNS、安全性、性能、网络和 SEO 等问题。
在线地址：https://gf.dev/

Dotcom-monitor

可以顺带测一下屏幕兼容
在线地址：https://www.dotcom-tools.com/website-speed-test

Dareboost

会对比不同浏览器上的表现
在线地址：https://www.dareboost.com/en

性能分析工具有什么用？

其实就是想通过工具，说明一下业内关注的页面性能的具体指标：

1. 打开速度
2. 页面文件大小
3. 请求速度
4. 阻塞时间
5. 请求数量
6. dns解析时间
7. 其它的增强性功能

这些工具除了LightHouse，其他在线工具的对我们定位问题有点用，但作用不是特别大，尤其是现在基本上都是hi单页面应用。
不用过多关注，它们的唯一作用就是某些客户认同的时候可以当测试报告。
个人推荐按F12看network，排序一下看文件大小，加载时间，自己分析一下，怎么分析往下看

使用network需要关注的指标

1. 看加载了多少东西，哪些东西没有必要加载，哪些文件过大
2. 文件加载的时间其实受网络影响及服务器带宽影响，一般看时间是看接口
3. response header看缓存的配置，过期时间设置是否合理
4. 上图没开gzip
5. 接口可合并也可拆分，有些接口慢只是个别数据慢，可以要求后端单独拆开，正常情况应该是接口都很快，尽量合并通业务的接口，减少http请求实际上也包括接口合并
6. 文件过大再去看webpack分析
7. 缓存策略看这两篇

• https://blog.csdn.net/qq_38217940/article/details/125360427
• https://blog.csdn.net/qq_38217940/article/details/125349105

使用webpack的webpack-bundle-analyzer来分析打包出来的文件

怎么使用看npm https://www.npmjs.com/package/webpack-bundle-analyzer

怎么拆分js？
1、使用路由懒加载

import( /* webpackChunkName: "login" */ '@/layout')

2、组件懒加载（动态组件）

<template>
    <div class="full-container container-wrap">
        <component v-bind:is="currentComponent" @change-page="changePage">
        </component>
    </div>
</template>

<script>
const Home = ()=>import(/* webpackChunkName: "organize-conpenents-home" */ "./components/home");
export default {
    
    
    data() {
    
    
        return {
    
    
            currentComponent: Home,
            currentComponentName: 'Home',
        };
    },
}

3、js动态加载

// 懒加载js
var loadScript = async (url) => {
    
    
    return new Promise((resolve, reject) => {
    
    
        const script = document.createElement('script');
        script.src = url;
        script.onload = resolve;
        script.onerror = reject;
        const head = document.getElementsByTagName('head')[0];
        head.appendChild(script);
    });
};

4、关闭vue预加载（看加载跟缓存的时候很有必要关掉，不然全都预加载了影响判断）
预加载长这样(prefetch属性)

<link href=./css/app.02a07d15.css rel=prefetch>

关闭的方法

   chainWebpack: config => {
    
    
        // 移除 prefetch 插件
        config.plugins.delete('prefetch');
        // 移除 preload 插件
        config.plugins.delete('preload');
    },

5、webpack合并js
webpackChunkName写成一样就行

import( /* webpackChunkName: "login" */ '@/login')
import( /* webpackChunkName: "login" */ '@/layout')

使用webpack的speed-measure-webpack-plugin看打包速度

怎么使用看npm https://www.npmjs.com/package/speed-measure-webpack-plugin

怎么提升打包速度？（只讲方案，根据方案自己百度一下）

1. 改用vite（实际上用webpack也可以配置出来差不多的效果，另外vite主要提升的是开发体验，分包什么的要自己配置）
2. 根据入参按需打包，如传入page=login，那就只运行login路由，可以参考多页的配置
3. 使用缓存，就是cache-loader，但是这玩意会有坑，有时候会导致修改了页面不更新
4. 指定入口，webpack的入口查找时间是很久的
5. 去掉不必要的loader，比如本地跑可以不用babel来转es5，浏览器版本高本身支持es6
6. 静态文件不参与打包，静态文件有一个复制的操作，想一下，几百兆的静态文件复制，可能就要好几秒了，虽然命令行执行会快很多。本地启动的时候也可以配置成不参与打包，需要修改devSever的静态文件指向，略复杂。
7. 关掉eslint，用vscode插件检查格式，美化格式其实也挺好，只要大家都统一起来
8. 多进程构建，如经典的HappyPack

图片处理

cdn

需要找一家云服务器厂商租用，如阿里云
https://www.aliyun.com/?utm_content=se_1011952919

压缩

1. 使用 https://tinypng.com/ 在线压缩图片
2. 按需修改webpack的url-loader，默认是10k以下转base64，如可以改成5k

module: {
    
    
  rules: [
       {
    
    
        test: /\.(jpeg|jpg|png|svg|gif)$/,
        use: {
    
    
          loader: 'url-loader', // 默认使用的是es6模块
          options: {
    
     // 配置 
            esModule: false, // 使用common.js规范
            outputPath: 'images', // 输出的文件目录
            name: 'images/[contenthash:4].[ext]',
            limit: 20*1024 // 小于20k转为base64
          }
        }
      }
  ]
}

3. 谨慎使用background-image,需要快速展示的才写入，因为会阻塞加载。最过分是还会被转成base64打包到js里面。大图片可以使用定位+zindex设置为背景，img标签是异步加载（ps：此条针对低版本浏览器，高版本background-image也是异步）
4. 可视区外的图片懒加载

页面的“稳”

什么原因会造成页面卡顿、崩溃？
很多人章口就来：内存泄漏。
我只想说
肤浅
内存泄漏只是页面卡顿的原因之一，造成页面卡顿的原因还包括：

• dom节点过多
• 页面回流频繁（在dom节点较多的情况下，回流才会造成卡顿，如大屏页面要素就很多）
• 页面监听过多，没有及时关闭，监听会占用cpu，不用就清理
• 页面定时器过多、请求过多造成js频繁计算
• 内存泄漏，但是其实内存泄漏爆了会被强制回收，其实影响并没那么大，实际上造成卡顿的是垃圾没有及时回收，如挂在window上的对象过多，window上的对象不属于垃圾（即使你不用它）
• 10万级以上的数据计算，性能差点的电脑几十万就会导致页面崩溃
• 大量的数据存放在winodw上，其实跟上一条是一个原因，包括JSON.parse、JSON.stringify一个很大的对象这种也会崩溃，不过有些浏览器版本会报错

根据以上，可以简单说几条避免性能变差的写法

1. 元素里面少用style，尽量用class或者是其它选择器
2. 动画使用position避免回流
3. 能给死宽高可以给死，不要什么都自适应flex
4. css层级尽量不要超过三层，因为回流的时候又会解析css生成渲染树，写less就经常套娃，其实是不对的
5. 动画多的时候用GPU加速，使用transform的时候可以用Z轴，这样会开启GPU，如translate可以用tranlate3d，translate用CPU，tranlate3d用GPU
6. dom节点过多可以考虑用canvas实现，或者尽量删除不可视的dom
7. 监听成对出现，用on就有off，如vue的beforeDestroy
8. window上的东西，用完及时赋值null清空
9. 大量计算交给后端，不然就放到web worker里面
10. 定时器也是，有set就要用clear

使用Performance观察页面变化

1. Nodes曲线看页面dom变化，如果一直增长不减，那就会卡，dom没及时回收
2. listeners监听器跟Nodes一样的分析方式
3. heat曲线，三次持续上升然后立即暴跌，连续出现三次可以判定为内存泄漏（看阮一峰博客说的）
4. 其他的指标比较细，需要实操才能理解，这里不细讲

使用Memory观察页面内存使用情况

这个有用，页面崩溃，用久了卡顿，基本上页面上存了很多东西，存了dom跟listener，一些大对象没及时清理是最常见的原因，比如一个很大的json文件
最严重的是winodw，100M的json直接存放到window最外层，有可能就直接崩溃了

想到在补充，持续更新中

详细的懒加载策略、拆包策略等，有空再写。