acongm

摘要（Auto）

  • 生成时间：2025-12-20
  • 简历中出现的项目标题（提取）：大疆用户中心重构 / 大疆售后 RMS 系统重构 / 跨平台公告插件系统 / 大疆 DevOps 平台维护 / XDR 系统 - 魔方大屏 + 报表
  • 面试大纲关键词（提取 Top10）：1）大疆用户中心重构：性能优化 + HTTP 原理 + Webpack 架构 / 性能指标与方法论 / 简历可落地点（结合你的“优化四板斧”） / HTTP 常考点（从“为什么变快”倒推） / Webpack 架构（工程化面试常考） / 按优化顺序，把方案“串起来”（排查 → 定位 → 选择 → 验证） / 0. 排查与基线（先把问题“量化”） / 1. 先保“可见”——骨架屏预渲染（直接拉低 LCP） / 2. 再减“阻塞”——关键渲染路径（CRP）梳理：CSS/字体/首图优先级 / 3. 再降“下载与解析成本”——更小的包体与更少的无效代码

建议追问（Auto）

  • 你为什么在该项目/场景里选择这个方案？替代方案为何不选？
  • 最大一次事故/踩坑是什么？如何定位与回滚？
  • 如果重做：架构/边界/工程化会怎么调整？

关联卡片

在我项目中的角色与使用场景

项目前端负责人。目标是统一 PC/移动端代码并进行性能攻坚，降低维护成本并提升登录转化。

原理简述

我会用“关键渲染路径（CRP）+ 资源优先级 + 传输层 + 包体积”把“为什么变快”讲清楚：

  • Context：
    • 用户中心属于高频访问入口，首屏体感和转化强相关；同时存在 PC/移动多端共存导致的维护成本问题。
  • Problem（典型瓶颈拆解）：
    • 首屏关键资源被阻塞（CSS/字体/首图优先级不合理）。
    • 首屏 bundle 过大，解析/执行占用主线程，影响 LCP/INP。
    • 骨架/占位策略不一致导致 CLS（页面跳动）。
  • Solution（按“优化四板斧”组织，面试很好讲）：
    • 先量化：RUM 上报（LCP/INP/CLS）、关键路由分布、弱网/低端机回归矩阵。
    • 先保可见：骨架屏/占位与渐进渲染，把 LCP 拉下来。
    • 再减阻塞：CRP 梳理（关键 CSS、字体策略、首图 preload）。
    • 再降成本：路由级拆包、依赖瘦身、减少无效渲染与长任务。
    • 再做治理：性能预算 + CI 门禁 + 上线后趋势监控与告警。
  • Outcome：
    • 不硬报数字，用“指标口径 + 验证方式”说明（例如 LCP p75、INP p75 的下降趋势）。

对比表格

决策点方案 A方案 B方案 C我怎么选（口径）
构建体系Webpack 存量优化Vite 全量迁移双构建并行存量项目优先“先稳后快”：旁路验证，逐模块迁移
骨架屏纯前端渲染服务端直出预生成静态骨架首屏关键页面可用“预生成/直出”降低 LCP，保证尺寸一致避免 CLS
资源优先级默认加载preload 关键资源prefetch 下一跳关键资源 preload（首图/关键 chunk/字体），prefetch 用于路由热度

模拟问答

<<<<<<< Current (Your changes)

  • [ ] Q1：为什么骨架屏能显著改善 LCP？如何避免 CLS？
    • LCP 为什么会变好：骨架屏把“最大内容区域”更早绘制出来，减少“等 JS 执行/接口返回才出内容”的空窗期。
    • 关键实现点（避免翻车）：
      • 尺寸一致：骨架与真实内容共享同一布局（同宽高/同栅格），避免切换时产生 Layout Shift。
      • CSS 优先：骨架所需关键 CSS 尽量内联或优先加载，避免“骨架也被 CSS 阻塞”。
      • 切换策略：不要“闪一下骨架就消失”，弱网/低端机可延迟切换，避免抖动。
    • 验证口径：LCP p75 下降 + CLS 保持稳定；用 Performance 里的 Layout Shift 事件定位抖动源。
  • [ ] Q2：你的“优化四板斧”分别对应浏览器链路哪一段？怎么保证每一刀都有证据？
    • 量化：RUM/Web Vitals（真实用户）+ Lighthouse（实验室）对齐口径（p50/p75/p95、设备/网络矩阵）。
    • 定位：Network 看关键资源 waterfall；Performance 看 Long Task、主线程阻塞点；必要时看框架 Profiler。
    • 选择：先保可见（骨架/占位）→ 再减阻塞（CRP：CSS/字体/首图）→ 再降成本（包体/执行）。
    • 验证：每次改动绑定假设（例如“首屏 JS -200KB → LCP p75 -300ms”），上线灰度对比趋势。
  • [ ] Q3：如果重做一次，你会怎么设计性能预算与回归门禁？
    • 预算维度：入口/关键路由 chunk 体积上限、首屏关键资源（css/font/hero）上限、长任务阈值。
    • 门禁落地：CI 比对产物体积（或 stats.json）、Lighthouse 关键指标阈值；超阈值阻断或需要审批。
    • 守护策略：上线后 RUM 趋势告警（p75/p95），异常触发开关降级与回滚。
  • [ ] Q4：HTTP/1.1 vs HTTP/2 vs HTTP/3，对首屏变快分别影响在哪里？
    • HTTP/1.1：多连接并发、队头阻塞明显；域名拆分有时能提并发但副作用大（DNS/握手/缓存分散）。
    • HTTP/2：多路复用、头部压缩（HPACK），整体更适合“少连接多请求”的现代站点；一般不推荐再做 domain sharding。
    • HTTP/3：基于 QUIC（UDP），减少传输层队头阻塞；在弱网/丢包环境可能更稳。
    • 验证口径：对比关键资源总下载耗时、连接数、协议版本、以及瀑布图阻塞链是否缩短（不是只看“协议升级了”）。
  • [ ] Q5：TLS 1.3 的收益点是什么？你怎么在线上确认“确实变快了”？
    • 收益点：握手往返更少（RTT 更少）、会话复用更友好；配合 HTTP/2 复用收益更明显。
    • 线上确认：
      • Network 面板确认协商协议/握手耗时变化（结合不同网络环境）。
      • 看 TTFB 与首屏关键资源的连接建立耗时分布（p75/p95），避免被缓存命中“假快”干扰。
  • [ ] Q6：缓存体系你怎么设计（强缓存/协商缓存/CDN/哈希策略/SW）？最大的坑是什么？
    • 强缓存：cache-control: max-age, immutable 用于带 hash 的静态资源。
    • 协商缓存：HTML/配置类资源用 ETag/Last-Modified 控制更新。
    • CDN：按路径与 query 设计缓存键；注意按用户/权限隔离的资源不要误缓存。
    • 哈希策略：业务 chunk 用 contenthash；runtime 单独抽离避免全量失效。
    • Service Worker：适合离线/弱网兜底，但最大坑是“更新策略”——必须有版本切换与强制刷新方案，否则会卡旧资源。
  • [ ] Q7：CRP 里最常见的阻塞是什么？你具体怎么处理（CSS/字体/首图）？
    • CSS：关键 CSS 提取/内联；非关键拆分延迟加载。
    • 字体：子集化/压缩 + 合理 font-display（swap/optional），必要时 preload；避免 FOIT/FOUT 带来的体验问题。
    • 首图：用 preload/fetchpriority="high" 提升优先级，且保证尺寸合适（避免传大图缩小）。
  • [ ] Q8：WebP/AVIF 怎么接入？怎么做兼容兜底与性能验证？
    • 接入：优先 <picture>（avif/webp/jpg fallback）或按能力探测下发。
    • 兜底：旧环境回退 jpg/png；同时确保预留宽高，避免 CLS。
    • 验证：对比同一首图资源体积/下载耗时、LCP 候选资源完成时间与解码开销（Performance）。
  • [ ] Q9：core-js 精简怎么做？常见风险是什么？
    • 做法：基于 browserslist + useBuiltIns: usage/按需引入，避免全量 polyfill。

    • 风险：目标浏览器误配置导致线上缺 polyfill；需要“兼容性回归矩阵 + 监控错误”兜底。

  • [ ] 为什么骨架屏能显著改善 LCP？如何避免 CLS？
  • [ ] 你的“优化四板斧”分别对应浏览器链路的哪一段？如何验证每一刀的收益？
  • [ ] 如果重做一次，你会怎么设计性能预算与回归门禁？
  • [ ] 从“HTTP/协议/缓存”角度，哪些点是你优化后真正在首屏链路里生效的？
    • 可复述要点：
      • 协议：HTTP/2 复用减少连接开销，但要注意“域名拆分”在 H2 下多数没收益。
      • 缓存：强缓存（cache-control）+ 协商缓存（etag/last-modified）+ 版本 hash 命名提升命中率。
      • CDN：静态资源走 CDN，关注回源率与缓存失效策略（按 hash 文件名可长缓存）。
      • Service Worker（如有）：能做离线与更细粒度缓存，但更新策略要谨慎（避免“缓存住 bug”）。
  • [ ] TLS 1.3 / 0-RTT 你会怎么讲？如何证明线上确实有收益？
    • 可复述要点：
      • TLS 1.3 减少握手轮次，弱网/高 RTT 下收益更明显；配合 HTTP/2 复用能放大整体收益。
      • 证明方式：抓真实用户网络数据（RUM）+ 服务器日志（协议协商、握手耗时），对比 TTFB/连接建立时间分布。
  • [ ] 图片优化（WebP/AVIF/懒加载）怎么落地？如何兼容兜底？如何避免 CLS 与解码开销？
    • 可复述要点： - 格式：优先 WebP/AVIF，旧环境回退 jpg/png（<picture> 或服务端按 Accept 协商）。 - 兜底：按 UA/能力探测，失败回退；同时做好缓存键区分（避免不同格式互相污染缓存）。 - CLS：固定宽高/占位；懒加载要配合占位与骨架；首图设置更高优先级。 - 解码：控制首图尺寸与压缩，避免“传大图缩小显示”。

      Incoming (Background Agent changes)

补充可直接回答的要点（给你“可背诵”的版本）：

  • 为什么骨架屏改善 LCP？
    • LCP 关注“最大内容元素是否渲染完成”。骨架屏让最大元素更早出现（即便是占位），用户感知更早“有内容”。
    • 关键：骨架要与真实内容同尺寸/同布局，否则会带来 CLS。
  • 四板斧对应链路：
    • 量化：RUM/埋点（真实用户数据）
    • 可见：渲染策略（骨架/占位/渐进）
    • 阻塞：CRP（CSS/字体/首图/关键 JS）
    • 成本：包体/执行/无效渲染（拆包、依赖瘦身、memo/虚拟化）
  • 预算与门禁：
    • 预算（体积/关键资源/长任务阈值）写进 CI；
    • 上线后看趋势（p75/p95），异常告警 + 可回滚开关。

手写代码区

关键资源优先级（HTML 注入示例）：

<!-- 首图/关键字体/关键 chunk：preload -->
<link rel="preload" as="image" href="/assets/hero.webp" fetchpriority="high" />
<link
  rel="preload"
  as="font"
  href="/assets/Inter.woff2"
  type="font/woff2"
  crossorigin
/>
1
2
3
4
5
6
7
8
9

骨架屏切换关键逻辑（伪代码：避免 CLS 的关键是“占位尺寸一致”）：

type ViewState = 'skeleton' | 'real'

function shouldShowSkeleton(ttfbMs: number, deviceScore: number) {
  // 弱网/低端机更倾向展示 skeleton，提升感知速度
  return ttfbMs > 300 || deviceScore < 50
}
1
2
3
4
5
6

我的补充（Manual）

（不会被脚本覆盖：你真实线上观测、踩坑与回滚方案）

复盘与反思（Learnings）

  • 如果重做会怎么改？

面试官追问（面试官视角）

  • [ ] 为什么选这个方案？替代方案为什么不选？
  • [!] 最大一次事故/踩坑是什么？如何定位与回滚？
  • [ ] 如果重做会怎么改？
  • [ ] HTTP/1.1、HTTP/2、HTTP/3 的核心差异你怎么用“首屏优化”串起来讲？
  • [ ] 字体（font-display/子集化/预加载）怎么做？如何避免 FOIT/FOUT 与重排？
  • [ ] 你如何设计“回归矩阵”（机型/网络/路径）？为什么用 p75/p95 而不是平均值？
上次更新:
(adsbygoogle = window.adsbygoogle || []).push({});