前端性能优化在面试里经常被问，但很多回答听起来像清单：图片懒加载、代码分包、缓存、压缩、减少请求。这些点都对，可如果没有场景，面试官很难判断你是不是真的优化过页面。
更有说服力的回答要从用户感知开始。页面是首屏慢，还是点击后卡顿？是白屏时间长，还是列表滚动掉帧？是某个机型慢，还是所有用户都慢？不同问题对应的定位和优化完全不同。
先描述症状，而不是直接报方案
比如你可以这样开场：这个页面的问题不是所有接口都慢，而是用户进入页面后前两秒看不到核心内容，低端机列表滚动时会卡顿。我们先把问题拆成加载阶段和交互阶段：加载阶段看资源体积、接口耗时、渲染阻塞；交互阶段看组件重复渲染、长任务和列表节点数量。
这个开场比“我做了懒加载”更像项目经历，因为它先定义了问题。
首屏优化要讲关键路径
首屏慢通常涉及资源、接口和渲染。面试里可以按关键路径讲：浏览器拿到页面后，需要加载哪些脚本、哪些样式、哪些接口返回后才能展示核心内容。优化不是把所有东西都延后，而是让用户最先看到最重要的内容。
常见做法包括：路由级代码拆分，让用户只加载当前页面需要的脚本；首屏图片按尺寸压缩并使用合适格式；非核心模块延后加载；接口并行请求；骨架屏或占位减少空白等待；服务端给静态资源设置缓存。每个做法最好对应一个具体瓶颈，而不是一口气全说。
卡顿要讲渲染和数据量
交互卡顿常常不是网络问题，而是浏览器主线程被占满。比如一次性渲染几千条列表、输入框每次输入都触发复杂计算、弹窗打开时重新渲染整棵组件树、图表数据量太大。回答时可以讲如何定位：通过浏览器性能面板看长任务，通过组件调试工具看重复渲染，通过日志或埋点看特定页面和机型。
优化也要具体。长列表可以用虚拟列表，只渲染视口附近的元素；高频输入可以做防抖，也就是等用户短暂停止输入后再触发请求；昂贵计算可以缓存结果；图表可以抽样或分页；不必要的状态提升要收回来，避免一个小状态变化导致大面积渲染。
性能指标要翻译成人话
如果面试里提到指标，最好解释它们对应的用户感受。首屏关键内容出现时间，反映用户多久能看到主要信息；最大内容渲染时间，反映核心区域什么时候加载出来；交互延迟，反映用户点击后页面有没有反应；长任务数量，反映页面是否容易卡顿。
不要为了显得专业堆缩写。面试官更关心你能不能把指标、问题和优化动作串起来。比如“首屏核心内容从三秒多降到两秒以内”比单纯报一串英文指标更容易理解。
一段更完整的面试表达
可以这样说：我负责的后台列表页在数据量变大后首屏慢、筛选卡。定位时先看网络，发现首屏接口和资源加载都有影响；再看渲染，发现表格一次性渲染大量行，筛选时整页重复渲染。优化上，我把非首屏模块拆出去，图片和图标资源做了压缩，列表改成分页加虚拟滚动，筛选输入做了防抖，并把复杂统计从前端同步计算改成后端返回。上线后看首屏核心内容出现时间、接口耗时、长任务数量和用户筛选操作耗时。
这类回答能体现前端工程能力：不是背优化技巧，而是能从用户感知出发，把页面问题定位到资源、接口、渲染和交互链路上。
性能优化要有验证闭环
前端性能题不要只报优化清单。图片懒加载、代码分包、缓存都只是手段，面试官更想听你怎么发现瓶颈、怎么选择方案、怎么证明有效。
首屏慢：定位方向是资源体积和关键路径，优化动作是分包、压缩、预加载关键资源，验证指标是首屏时间和资源瀑布。滚动卡顿：定位方向是长列表和重渲染，优化动作是虚拟列表、减少同步计算，验证指标是帧率和长任务。
- 输入延迟：定位方向是主线程被占用，优化动作是防抖、拆任务、worker，验证指标是交互响应时间。
- 接口慢导致空白：定位方向是加载状态和缓存，优化动作是骨架屏、缓存、并行请求，验证指标是用户等待感和错误率。
面试里最好讲一个前后对比：优化前用户看到什么，定位证据是什么，改完指标和体验怎么变化。没有验证的优化，很难让人信服。