作为一名开发者,我们追求的不应该是应用能用就好,而是好用,那么如何评价我们的应用是否好用呢?
-
最直接的方案当然是通过收集用户反馈来评判
-
从开发层面,最直观的就是通过
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 浏览器空闲时加载脚本
-