大疆用户中心重构（2022.02-2022.09）- 面试技术大纲

技术栈：Vue3 + TypeScript + Vite + Pinia（简历）
目标：性能优化 + HTTP 原理 +（工程化可类比到 Webpack 架构）

---

性能优化：指标体系与定位方法

• 指标体系：LCP / FCP / TTI / CLS / INP、首屏/白屏时间、资源体积、接口耗时、缓存命中率
• 定位手段：Performance / Network 面板、Lighthouse、Web Vitals 上报、Long Task 分析
• 优化策略：关键渲染路径优化、渐进式渲染（骨架屏 / 占位 / 分片渲染）

简历可落地点（结合“优化四板斧”）

• 骨架屏预渲染：怎么做（预生成/服务端直出/静态骨架）、一致性（闪烁/布局偏移）、对 LCP 的影响评估
• 更小的代码体积：core-js 精简、字体子集化/压缩、CSS 打包策略（提取/合并/按需）
• 更快的加载与渲染：资源优先级（preload/prefetch）、合理加载顺序、gzip/br、首屏关键资源最小化
• 传输层优化：TLS 1.3 的收益点（握手/复用/延迟），以及真实线上观测方法
• 图片优化：WebP/AVIF 接入、兼容兜底策略、图片尺寸与懒加载、占位与解码开销

HTTP 常考点（从“为什么变快”倒推）

• HTTP/1.1 vs HTTP/2 vs HTTP/3：队头阻塞、并发模型、HPACK/QPACK、0-RTT
• TLS：握手流程、证书链、会话复用、OCSP Stapling、连接复用与域名拆分的取舍
• 缓存体系：强缓存/协商缓存、CDN 缓存、版本号/哈希策略、Service Worker 缓存与更新

Webpack 架构（工程化面试常考，可用于“构建工具理解”话题）

• 构建流程：entry → module graph → loader → plugin → chunks → assets
• 产物与优化：splitChunks、runtimeChunk、tree-shaking（sideEffects）、scope hoisting
• 构建性能：持久化缓存、并行压缩、sourceMap 策略、bundle 分析与预算（budgets）
• 现代替代：Webpack vs Vite（依赖预构建/ESM dev server）什么时候选谁、迁移风险点

按优化顺序，把方案“串起来”（排查 → 定位 → 选择 → 验证）

面试复述主线：我先把目标收敛到 LCP/首屏（简历：LCP 2.3s → 1.4s，首屏 < 1.5s），然后沿着浏览器关键链路 网络 → 解析 → 渲染 → 资源加载 分段拆解瓶颈，做到“每一刀都有证据、每一刀都有回归验证”。

0. 排查与基线（先把问题“量化”）

• 先定指标：以 LCP/首屏为主，辅以 FCP/CLS/INP 与关键接口耗时、缓存命中率，建立对比基线（同机型/同网络/同账号/同页面路径）。
• 再抓证据：
  • Network：看首屏关键资源（HTML/CSS/JS/字体/首图）耗时、阻塞关系、是否命中缓存、压缩比、协议版本。
  • Performance：看长任务（Long Task）、主线程忙点、是否存在明显的解析/执行阻塞。
  • Lighthouse/Web Vitals：把“体感慢”对齐到可度量指标（LCP/TTFB/资源体积/阻塞时长）。

1. 先保“可见”——骨架屏预渲染（直接拉低 LCP）

• 为什么先做这个：首屏慢最影响转化；骨架屏让“关键内容更早可见”，对 LCP 的改善最直接。
• 怎么做（可讲实现）：骨架结构尽量接近最终布局，避免布局抖动；必要时对骨架做预生成/内联关键 CSS，减少等待 JS 执行才出内容。
• 提升对比：LCP 2.3s → 1.4s；同时重点解释如何控制 CLS（骨架与真实内容尺寸一致、占位策略）。

2. 再减“阻塞”——关键渲染路径（CRP）梳理：CSS/字体/首图优先级

• 浏览器原理串联：HTML 解析生成 DOM；CSS 会影响 render tree，关键 CSS 阻塞首屏渲染；字体可能触发 FOIT/FOUT；首图通常成为 LCP 候选。
• 为什么这么做：如果首屏被 CSS/字体/首图阻塞，再快的接口也救不了 LCP。
• 典型落地动作：
  • 关键 CSS 优先（提取/内联/拆分），非关键样式延后加载。
  • 字体压缩/子集化，配合合理的 font-display，减少阻塞与重排。
  • 首图优先级提升（preload/合理格式），非首屏图片懒加载。
• 验证方式：对比首屏关键资源 waterfall：阻塞链缩短、首屏 render 更早发生；CLS 保持可控。

3. 再降“下载与解析成本”——更小的包体与更少的无效代码

• 为什么选择精简体积：JS 体积不仅影响下载，还会影响 parse/compile/execute（主线程占用），在中低端机更明显。
• 对应动作：精简 core-js、优化打包 CSS、字体压缩，做到“只给首屏必须的”。
• 验证方式：对比 bundle 体积、首屏 chunk 数量、主线程长任务占比是否下降。

4. 再优化“传输层”——gzip + TLS 1.3（让关键资源更快到达）

• 浏览器原理串联：首屏每个关键请求都要经历连接建立/握手/传输；在弱网下握手与 RTT 很敏感。
• 为什么选 TLS 1.3：减少握手开销、提升连接建立效率（配合 HTTP/2 复用更明显）；属于“全站收益”的优化点。
• 为什么选 gzip：对文本资源（HTML/CSS/JS/JSON）压缩收益明显，直接减少传输字节数。
• 验证方式：看响应头 content-encoding、压缩比、TTFB/下载耗时变化；对比首屏关键资源总下载字节与耗时。

5. 最后补“图片格式”——WebP（兼顾体积与视觉）

• 为什么放在后面：它主要改善的是“图片传输体积”，通常要在关键链路梳理完后做收尾提速；同时需要考虑兼容兜底。
• 怎么做（可讲兜底）：按 UA/能力探测选择 WebP，旧环境回退 png/jpg；结合响应式图片与尺寸裁剪避免“传大图缩小显示”。
• 验证方式：对比同一首图资源体积与下载耗时，确认 LCP 候选资源更快完成。

6. 回归与守护（防止“优化回退”）

• 回归矩阵：不同端（PC/移动）、不同网络（4G/弱网）、不同页面路径对比；重点盯 LCP/CLS/错误率。
• 长期治理：性能预算（bundle/首屏资源上限）、上线前 Lighthouse/关键指标门禁、线上 Web Vitals 监控告警。