关于性能优化:实践指南前端性能提升-270

一、背景

当咱们疲于开发一个接一个的需要时，很容易遗记去关注网站的性能，到了某一个节点，猛地发现，随着越来越多代码的沉积，网站变得越来越慢。

本文就是从这样的一个背景登程，着手优化网站的前端性能，并总结出一套开发习惯，让咱们在日常开发时，也放弃高性能，而不是又一次回过头来优化性能。

先来看看优化的成绩，Lighthouse 的 Performance 评分共计晋升 279%：

优化前后比照：

二、优化前

接下来就是介绍下优化前咱们要做哪些事件：

1. 理解性能指标及测量工具
2. 剖析须要优化的中央

1. 理解测量工具及性能指标

一开始咱们只是感触到网站的页面关上时白屏工夫较长，感觉性能是比拟差的，那么具体有哪些性能指标须要去关注呢？

这里我应用的是 Chrome devtools 内置的 Lighthouse，Lighthouse 是一种开源的自动化工具，用于进步 Web 应用程序的品质。

Lighthouse 会在一系列的测试下运行网页，比方不同尺寸的设施和不同的网络速度。它还会查看页面对辅助性能指南的一致性，例如色彩对比度和 ARIA 最佳实际。

关上 Chrome devtools Lighthouse 即可应用。

在比拟短的工夫内，Lighthouse 能够给出这样一份报告。

这份报告从 5 个方面来剖析页面：性能、辅助性能、最佳实际、搜索引擎优化和 PWA。像性能方面，会给出一些常见的耗时统计。

1.1 Performance

Performance 评分统计，包含了以下指标：

1.1.1 FCP

FCP 测量在用户导航到页面后浏览器出现第一段 DOM 内容所破费的工夫。页面上的图像、非红色 <canvas> 元素和 SVG 被视为 DOM 内容；不包含 iframe 内的任何内容。

1.1.2 LCP

LCP 测量视口中最大的内容元素何时出现到屏幕上。这近似于页面的次要内容对用户可见的工夫。

须要留神的是 LCP 的计算是一个动静的过程，如下图最初的图片才是这个页面中的最大内容绘制的元素。

1.1.3 TTI

TTI 测量页面齐全交互所需的工夫。

TTI 是如何计算的呢，如下图首先沿时间轴正向搜寻时长至多为 5 秒的宁静窗口（宁静窗口是指没有长工作且不超过两个正在解决的网络 get 申请），而后沿时间轴反向搜寻宁静窗口之前的最初一个长工作，如果没有找到长工作，则在 FCP 步骤进行执行，TTI 就是宁静窗口之前最初一个长工作的完结工夫，如果没有找到长工作的话，则与 FCP 值雷同。

1.1.4 Speed Index

Speed Index 掂量页面加载期间内容以视觉形式显示的速度。Lighthouse 首先捕捉浏览器中页面加载的视频，并计算帧之间的视觉进度。

1.1.5 TBT

TBT 测量页面被阻止响应用户输出（例如鼠标点击、屏幕点击或键盘按下）的总工夫。

通过增加 First Contentful Paint 和 Time to Interactive 之间所有长工作的阻塞局部来计算总和。任何执行工夫超过 50 毫秒的工作都是长工作。

50 毫秒后的工夫量是阻塞局部。例如，如果 Lighthouse 检测到一个 70 毫秒长的工作，则阻塞局部将为 20 毫秒。

如下图淡红色区域的工夫总和就是这个页面的 TBT 分数。

1.2 最佳实际

用于检测 Web 应用程序整体代码健康状况，包含是否蕴含文档类型、图片宽高比是否正确等等。

1.3 SEO

用于检测搜索引擎对网页内容的了解水平。

2. 剖析须要优化的中央

理解了要害的性能指标后，就能够测量看看以后网站的性能了，

下面看到综合评分是非常低的，Lighthouse 给出了应该从哪些地方开始优化的倡议。

2.1 Performance

性能优化倡议次要包含以下几点：

• 缩小未应用的 JS；
• 正当应用图片的格局，webp 或者 avif 更快；
• 提早加载不在视图的图片；
• JS 压缩；
• 图片的尺寸大小应该适当；
• 缩小未应用的 CSS。

Lighthouse 诊断出的网站存在的问题：

• 须要加载的资源太多太大，有 147 个申请，共计 11mb；
• 有 40 个动态资源的缓存只有 1 小时
• 滚动事件没有增加标记{passive: true})，导致须要期待侦听器实现执行后再滚动页面；
• 图像元素没有设置明确的宽度和高度；
• JS 文件太多，主线程工作量太大、JS 执行工夫太长；

2.2 最佳实际

最佳实际方面有以下问题：

• 图片的分辨率太低，清晰度不够；
• 没有设置 CSP 策略。

2.3 SEO

SEO 有以下问题：

• 没有 meta description；
• 图片没有 alt 属性；
• robots.txt 是有效的。

三、优化 Performance

依据下面 Lighthouse 报告，捋一捋我的项目中影响性能最大的因素，包含以下几点：

• 体积太大，达 11mb；
• 图片太大，图片格式也有影响。

1. 体积优化

1.1 代码压缩

查看是否还有压缩空间，或者有无工具库未压缩的。

1.2 代码分包

通过 webpack-bundle-analyzer 插件剖析包体积，将一些大的 npm 包和 runtimeChunk 独立分包，减小包体积。

1.3 组件按需加载

React.lazy + Suspense 封装懒加载组件，路由级组件引入懒加载组件。
同时应用骨架屏作为懒加载的兜底组件，能够让用户感知加载更快。
在鼠标移入导航栏时预加载路由组件，能够放慢页面展现。

1.4 工具库按需加载

通过 import(‘xx’).then(xx) 按需加载工具库。

1.5 动态资源上传 CDN

我的项目内有一些 json 文件存储的静态数据，这部分文件上传至 CDN，改为 fetch 的形式按需引入。

1.6 删除不须要的资源

查看我的项目中引入的 mf、npm 资源，将没有应用到的删除。

1.7 防止反复的 npm 包引入

发现业务组件库通过 npm 引入的原子组件库，而我的项目自身又是通过 mf 引入的原子组件库，绝对于引入了 2 遍原子组件库。

这时就须要革新业务组件库，也改成用 mf 的办法引入。

1.8 防止 esm 依赖嵌套

因为 webpack 的按需加载是通过 import、export 来标记的，因而想要一个好的按需加载的成果，就须要防止依赖嵌套的问题。

1.9 图标按需加载

原子组件库 mf 裸露的形式会导致只用了 1 个 icon，就会加载组件库下所有 icon 对应的 chunk，导致资源节约。

新建一个 icon 的 npm 包用于 icon 的按需引入。

1.10 小结

通过以上优化伎俩，体积从 11.7mb 升高至 1.1mb，升高 10.6 倍。

优化前：

优化后：

2. 图片优化

1.1 图片懒加载

对非首屏的图片采纳图片懒加载策略。

1.2 图片尺寸

应用图片时，设置图片的正当尺寸。

1.3 图片格式设置

优先应用 webp 格局图片。

四、优化最佳实际

1. 设置 CSP 策略

2. 设置正当的图片的分辨率

优化我的项目内的图片分辨率。

五、优化 SEO

1. meta description、keywords 优化

具体的 meta description、keywords 能够放慢 SEO。

<meta name="keywords" content="xx" /> <meta name="description" content="xx" />

2. 图片加上 alt 属性

<img src="smiley.gif" alt="Smiley face" />

六、优化前后比照

再来回顾下前后比照：

优化前，显著的感知白屏工夫长：

优化后，在清缓存的状况下也能实现秒开：

整体性能晋升 270%：

七、性能监控

为了在后续的迭代过程中，放弃高性能，引入外部前端监控平台 – 烛龙，可视化的监控前端性能。

第一步，加载 cdn 插件：

<script
  defer
  src="https://h5static.m.jd.com/act/jd-jssdk/latest/jd-jssdk.min.js"
></script>

第二步，在入口文件中，初始化 cdn 插件：

useEffect(() => {
  // 初始化测速组件, 在这里能够关上一些管制的开关，如是否上报接口
  if (IS_PROD) {
    // @ts-ignore
    jmfe.profilerInit({
      flag: xxx, // 这是利用 ID，须要先在烛龙申请利用
      autoReport: true,
      autoAddStaticReport: true,
      autoAddApiReport: true,
      autoAddImageReport: false, // 反对所有图片上报, 如果图片多，切记敞开，否则存在性能问题
      performanceReportTime: 8000,
      profilingRate: 1,
    })
  }
}, [])

第三步，查看监控数据：

在烛龙平台，小工具性能评分达 96 分：

第四步，新增告警，实时监控

烛龙平台反对多维度的告警服务，减少性能指标相干的告警，在性能异动时，及时发现问题，优化性能。

小结

本文具体介绍了一个前端我的项目优化的具体过程，从优化前的问题剖析，到具体的优化措施，最终实现了前端性能晋升了近 3 倍。同时也将性能指标落到监控平台，实现可视化的监控前端性能指标。

心愿能对你有所帮忙，感激浏览～

参考资料

• 被删的前端游乐场 - 前端性能优化 - 演绎篇
• 前端缓存 API 申请数据的解决方案
• 网易云课堂 Service Worker 使用与实际
• PLUS 前端 H5 性能优化实际