最直观的就是通过 performance 与 lighthouse 来评判

最新推荐文章于 2025-06-28 09:18:39 发布

feidodo小程序

最新推荐文章于 2025-06-28 09:18:39 发布

阅读量589

点赞数

CC 4.0 BY-SA版权

文章标签：前端 javascript 服务器

本文链接：https://blog.youkuaiyun.com/feidodoxcx/article/details/127998497

本文探讨了如何评估前端应用的性能，重点关注通过performance和Lighthouse的指标。优化前，NextJS应用面临性能挑战，如FCP为1.8s，Lighthouse性能评分为55，TTI为7.3s。为提升用户体验，采取了gzip压缩、动态加载非首屏组件和next/script优化等措施。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

作为一名开发者，我们追求的不应该是应用能用就好，而是好用，那么如何评价我们的应用是否好用呢？

最直接的方案当然是通过收集用户反馈来评判
从开发层面，最直观的就是通过 performance 与 lighthouse 来评判

3.1 优化前

如你所见，由于应用模块的一个复杂性，我们的 NextJS 应用起初性能并不是很好，甚至谈得上是差

FCP: 首次内容绘制时间 1.8s
lighthouse: 性能评分报告 55 分，Time to Interactive (TTI) 可交互时间为 7.3s，通常是发生在页面依赖的资源已经加载完成。
network: 我们每次进行路由跳转都要按需加载资源，因此我们需要单个页面的 DomContentLoaded 尽可能快以保证页面 Dom 结构的渲染效率。
页面构建时间

这些指标都间接反馈出应用的体验问题亟待解决。

3.2 优化措施

优化用户体验
- 1. 开启 gzip 压缩
  通过 network 可以看到资源实际大小及 http 请求的 size，如果不开启压缩，二者基本是没有差异的。
  
  gzip 优化后可以看到，压缩效果还是很明显的开启 nginx 的 gzip 压缩
```
gzip                            on;
gzip_min_length                 100;
gzip_buffers                    4 16k;
# gzip_http_version               1.0;
gzip_comp_level                 9;
gzip_types                      gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png application/javascript;
gzip_vary                       on;
gzip_proxied                       any;
```
  通过 response header 判断压缩是否生效
- 2. 针对非首屏组件基于 dynamic 动态加载
  在页面加载过程中，针对一些不可见组件，我们应该动态导入，而不是正常导入，确保只有需要该组件的场景下，才 fetch 对应资源 , 通过 next/dynamic，在构建时，框架层面会帮我们进行分包
```
import dynamic from 'next/dynamic'
const Modal = dynamic(() => import('../components/mModal'));
export default function Index() {
  return (
    {showModal && <Modal />}
  )
}
```
  打开 Network。当条件满足时，你将看到一个新的网络请求被发出来获取动态组件 (单击按钮打开一个模态)。
- 3 . next/script 优化 script 加载时
  next/script 可以帮助我们来决定 js 脚本加载的时机
  
  strategy 描述
  beforeInteractive 可交互前加载脚本
  afterInteractive 可交互后加载脚本
  lazyOnload 浏览器空闲时加载脚本