Vue 3 首屏白屏 3 秒：从性能定位到 Long Task、Web Worker 与虚拟列表

题目信息

• 领域：前端工程化、浏览器性能、Vue 3

• 难度：L2 基础应用（中级偏低）

• 题型：场景题

• 预计用时：10–15 分钟

• 考察方向：考察面对线上性能问题时，能否建立“测量、定位、优化、验证”的完整分析链路，而不是直接罗列优化手段。

面试题

一个 Vue 3 后台系统发布新版本后，部分用户反馈：

打开首页后会白屏约 3 秒，之后页面才完整显示；开发人员自己的电脑上不明显。

团队成员提出直接进行代码分包和图片压缩。

如果由你负责排查，请说明：

1. 首先会收集哪些信息，如何稳定复现问题？

2. 会使用哪些浏览器工具或性能指标定位瓶颈？

3. 如何区分问题主要来自以下哪个环节？

   • 网络或服务端响应

   • 静态资源加载

   • JavaScript 下载、解析和执行

   • Vue 渲染或浏览器布局绘制

4. 定位完成后，如何证明优化真正有效，而不是本地感觉“变快了”？

不要求编写代码，需要按照实际排查顺序口述。

我的回答

1. 收集用户使用的浏览器、浏览器版本和网络环境，然后模拟相似的用户环境复现问题。

2. 使用 Chrome DevTools 中的 Performance 进行性能测试，定位依赖、函数或方法中耗时最多的部分。

3. 通过 Network 查看静态资源和网络请求的加载时间，也可以观察 JavaScript 下载时间；通过 Performance 观察 JavaScript 的解析和执行，以及 Vue 渲染和浏览器布局绘制时间。

4. 完成定位和优化后，将修改部署到实际环境，并在模拟用户真实环境的条件下验证。

面试点评

• 总分：66 / 100

• 正确性：29 / 40

• 原理理解：12 / 20

• 工程应用：13 / 20

• 边界与权衡：5 / 10

• 面试表达：7 / 10

正确点

• 知道收集浏览器、版本和网络环境，避免只在开发机上判断。

• 能区分 Network 与 Performance 的基本用途。

• 知道从网络加载、JavaScript 执行、Vue 渲染和浏览器绘制几个阶段排查。

• 意识到优化必须部署后，在接近用户的环境中验证。

遗漏点

1. 没有通过指标定义问题

“白屏约3秒”只是用户描述，需要转换为可测量指标：

• TTFB：服务端开始返回 HTML 的时间。

• FCP：页面首次出现文本、图片等可见内容的时间。

• LCP：页面主要内容完成显示的时间。

• Long Task：主线程中持续时间较长、可能阻塞渲染和交互的任务。

2. 没有建立工具证据与瓶颈的映射

例如：

• HTML 的 TTFB 很长：优先排查服务端或网络链路。

• JS 文件下载时间很长：检查文件体积、带宽、压缩和缓存。

• 资源很快下载完成，但主线程长时间繁忙：排查 JavaScript 解析、执行和同步任务。

• Scripting 耗时不高，但 Layout、Paint 很高：排查 DOM 数量、样式计算和布局绘制。

• 定位到具体 Vue 组件时，可能还需要 Vue Devtools、User Timing 或业务埋点。

3. 验证方式不完整

除了模拟用户环境，还应该：

• 在相同网络、CPU和缓存条件下比较优化前后数据。

• 区分冷缓存和暖缓存。

• 进行多次测试，避免使用偶然结果。

• 上线后通过真实用户监控比较不同分位数的数据。

错误点

没有明显的方向性错误。

但“Performance 可以直接观察 Vue 的渲染时间”不够严谨。Performance 能看到主线程中的脚本、布局和绘制活动，但不一定能直接定位到具体 Vue 组件，组件级归因需要额外工具或性能埋点。

推荐答案与原理解析

我会按照“复现、测量、定位、优化、验证”的顺序处理。

1. 确认问题范围和复现条件

首先收集受影响用户的信息：

• 浏览器及版本

• 操作系统和设备性能

• 网络类型、带宽和延迟

• 用户所在区域

• 是否首次访问

• 冷缓存还是暖缓存

• 用户账号、权限和首页数据量

• 问题从哪个版本开始出现

然后通过 Chrome DevTools 的 Network throttling 和 CPU throttling 模拟用户环境，并分别测试冷缓存和暖缓存。

2. 用指标定义“白屏”

不能只依赖肉眼观察，需要记录：

• TTFB

• FCP

• LCP

• 主线程 Long Task

• JavaScript、Layout 和 Paint 的耗时

如果 TTFB 很低但 FCP 很晚，说明页面已经收到响应，问题更可能发生在资源加载或主线程执行阶段。

3. 使用 Network 判断加载问题

重点查看：

• HTML 的 TTFB

• 请求瀑布图

• JS、CSS和图片的体积

• 资源下载耗时

• 是否命中缓存

• 是否启用压缩

• 是否存在串行请求或阻塞资源

如果主 JS 文件体积过大、下载时间明显，就继续分析构建产物，判断是否存在不必要的首屏依赖。

4. 使用 Performance 判断主线程问题

重点查看：

• Main Thread 火焰图

• Scripting、Rendering、Painting 的时间分布

• Long Task

• Call Tree

• Bottom-Up

• FCP、LCP标记及具体 LCP Element

Call Tree 用于自顶向下查看调用关系，Bottom-Up 用于按照函数自身耗时聚合热点。

5. 根据证据选择优化手段

不同问题对应不同方案：

• 初始模块过多：代码分包、路由懒加载、延迟加载非首屏模块。

• 同步计算耗时：优化算法、任务切片或使用 Web Worker。

• 大量 DOM 挂载：分页、列表虚拟化、减少响应式数据开销。

• 服务端响应慢：优化接口、缓存或数据查询。

• 静态资源过大：压缩、缓存、CDN或调整资源格式。

不能在没有证据时直接认定代码分包或图片压缩一定有效。

6. 验证优化效果

在相同设备、网络、CPU和缓存条件下，分别记录优化前后的指标并多次测试。

部署后还要通过真实用户监控观察 FCP、LCP 等指标的分位数，确认大多数真实用户获得改善，而不是只有开发人员自己的电脑变快。

递进追问与补答

追问一：根据性能数据判断主要瓶颈

追问：

进一步得到以下数据：

HTML TTFB：120ms
主 JS 文件：压缩后 1.8MB，下载耗时 400ms
JS 下载完成后：主线程出现一个持续 2.2 秒的 Long Task
FCP：2.9s
LCP：3.1s
图片加载均发生在 FCP 之后

请回答：

1. 当前最可能的主要瓶颈是什么？

2. 会继续在 Performance 的哪些区域查找证据？

3. 代码分包和图片压缩，哪个更可能优先有效？为什么？

我的补答：

1. FCP 是2.9秒，图片不是主要瓶颈，主要问题是持续2.2秒的 Long Task，它导致 FCP 出现时间变长。

2. 在 Performance 中找到这个 Long Task 的调用树，自下而上分析任务的时间分布。

3. 优先考虑代码分包，将长任务拆解为多个小任务，优化 FCP。

**补答评分：**72 / 100

补答点评：

主要瓶颈判断正确，也知道继续分析调用树，但存在三个问题：

1. 给定数据中 LCP 是3.1秒，不是2.9秒。

2. 图片发生在 FCP 之后，只能说明它不是 FCP 的直接瓶颈，仍需要确认具体 LCP Element。

3. 代码分包不等于长任务拆分。

代码分包用于减少或延迟初始模块；任务切片用于拆分必须执行的同步计算。如果 Long Task 来自低效算法、海量 DOM 或第三方脚本，单纯进行代码分包未必有效。

更准确的表达是：

TTFB 只有120ms，服务端不是主要瓶颈。JS 下载后出现了持续2.2秒的 Long Task，而 FCP 在2.9秒，因此首要怀疑主线程被 JavaScript 初始化或渲染阻塞。下一步应在 Main Thread 火焰图中选中该任务，结合 Call Tree、Bottom-Up 和源码映射定位具体耗时函数，再根据根因选择代码分包、延迟初始化、任务切片或渲染优化。

追问二：5万条数据和5万行 DOM 如何优化

追问：

进一步分析发现2.2秒 Long Task 由两部分组成：

1.4s：对接口返回的 5 万条数据进行转换和排序
0.6s：一次性创建并挂载 5 万行表格 DOM

这两个部分应该分别如何优化？哪些工作适合放入 Web Worker，哪些问题应该通过 Vue 渲染策略解决？

我的补答：

1. 将5万条数据的转换和排序放入 Web Worker 子线程单独处理，完成后返回主线程。Web Worker 适合处理这类不需要操作 DOM 的任务。

2. 对5万行 DOM 使用 Vue 渲染策略，例如列表虚拟化或者骨架屏。

补答评分： 78 / 100

补答点评：

核心方向正确：

• 数据转换和排序属于 CPU 密集型任务，不依赖 DOM，适合放入 Web Worker。

• 列表虚拟化能够减少实际创建和挂载的 DOM 节点。

但 Web Worker 并不是无成本的：

• 主线程与 Worker 之间传递大量对象通常需要结构化克隆。

• 会增加数据复制、通信和内存成本。

• 筛选条件快速变化时，需要取消旧任务或忽略过期结果。

• Worker 只是避免阻塞主线程，不一定减少总计算时间。

骨架屏也不能解决5万个 DOM 节点的问题：

• 列表虚拟化和分页会实际减少 DOM 数量。

• 骨架屏只改善等待过程中的视觉反馈。

• 如果骨架屏结束后仍一次性挂载5万行，页面依然会产生 Long Task。

更完整的方案应该先判断是否需要把5万条数据全部发送到前端。如果后端能够分页、筛选和排序，通常应优先减少传输和前端处理的数据量；确实需要客户端计算时，再考虑 Web Worker。

最终总结

这道题的核心不是背诵代码分包、图片压缩、Web Worker 等优化手段，而是建立证据驱动的性能排查流程：

用户现象
-> 复现条件
-> 性能指标
-> Network 和 Performance 证据
-> 确认具体瓶颈
-> 选择对应优化方案
-> 同条件复测
-> 线上真实用户验证

本轮回答的主要进步是：

• 从笼统使用 DevTools，进步到能够根据 TTFB、FCP 和 Long Task 判断主线程阻塞。

• 能继续通过调用树定位耗时函数。

• 能针对 CPU 计算和海量 DOM，分别选择 Web Worker 与列表虚拟化。

仍需继续巩固：

• 代码分包、任务切片与算法优化的区别。

• Web Worker 的通信、复制、内存和取消成本。

• 骨架屏与实际渲染优化的职责边界。

• 服务端分页与客户端计算之间的工程权衡。