3,409
社区成员




download:NestJS 入门到实战 前端必学服务端新趋势
理论指南-前端性能提升 270%
当我们疲于开发一个接一个的需求时,很容易遗忘去关注网站的性能,到了某一个节点,猛地发现,随着越来越多代码的堆积,网站变得越来越慢。
本文就是从这样的一个背景动身,着手优化网站的前端性能,并总结出一套开发习气,让我们在日常开发时,也坚持高性能,而不是又一次回过头来优化性能。
指标称号 | 优化前 | 优化后 | 提升 |
---|---|---|---|
Lighthouse Performance 评分 | 29 | 81 | 279% |
FCP(First Contentful Paint 初次内容绘制) | 0.7s | 0.7s | |
LCP(Largest Contentful Paint 最大内容绘制) | 6.2s | 2.5s | 248% |
TTI(Time to Interactive 可交互时间) | 10.1s | 2.1s | 480% |
Speed Index(速度指数) | 5.6s | 1.8 | 311% |
TBT(Total Blocking Time 总阻塞时间) | 820ms | 120ms | 683% |
优化前后比照:
接下来就是引见下优化前我们要做哪些事情:
一开端我们只是感遭到网站的页面翻开时白屏时间较长,觉得性能是比拟差的,那么详细有哪些性能指标需求去关注呢?
这里我运用的是 Chrome devtools 内置的Lighthouse 是一种开源的自动化工具,用于进步 Web 应用程序的质量。
Lighthouse 会在一系列的测试下运转网页,比方不同尺寸的设备和不同的网络速度。它还会检查页面对辅助功用指南的分歧性,例如颜色比照度和 ARIA 最佳理论。
翻开 Chrome devtools Lighthouse 即可运用。
在比拟短的时间内,Lighthouse 能够给出这样一份报告。
这份报告从 5 个方面来剖析页面: 性能、辅助功用、最佳理论、搜索引擎优化和 PWA。像性能方面,会给出一些常见的耗时统计。
1.1 Performance
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
用于检测搜索引擎对网页内容的了解水平。
理解了关键的性能指标后,就能够丈量看看当前网站的性能了,
上面看到综合评分是十分低的,Lighthouse 给出了应该从哪些中央开端优化的倡议。
2.1 Performance
性能优化倡议主要包括以下几点:
Lighthouse 诊断出的网站存在的问题:
{passive: true})
,招致需求等候侦听器完成执行后再滚动页面;
2.2 最佳理论
最佳理论方面有以下问题:
2.3 SEO
SEO 有以下问题:
依据上面 Lighthouse 报告,捋一捋项目中影响性能最大的要素,包括以下几点:
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 倍。
1.1 图片懒加载
对非首屏的图片采用图片懒加载战略。
1.2 图片尺寸
运用图片时,设置图片的合理尺寸。
1.3 图片格式设置
优先运用 webp 格式图片。
优化项目内的图片分辨率。
细致的 meta description、keywords 能够加快 SEO。
<meta name="keywords" content="xx" /> <meta name="description" content="xx" />
<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 倍。同时也将性能指标落到监控平台,完成可视化的监控前端性能指标。