性能公共素材

使用说明

• 性能相关的短讲法、量化、取舍和治理闭环统一维护在本页。
• 如果要改核心口径，优先改本页，避免多份问答漂移。

性能指标一句话定性

如果面试官问性能指标，我不会背一串缩写，而会按“加载速度、交互响应、页面稳定性”三类来讲，再对应说我是怎么优化的。

性能指标 30 秒

我一般会先讲 Web Vitals 这一套：TTFB 看后端和网络首包速度，FCP 看首次内容出现，LCP 看首屏核心内容加载，INP 看交互响应，CLS 看页面稳定性。解决思路也按指标拆：TTFB 偏后端和缓存，FCP/LCP 偏资源体积、懒加载和渲染链路，INP 偏主线程阻塞和长任务拆分，CLS 偏图片尺寸预留、骨架屏和异步内容插入方式。这样回答会比只背指标更完整。

性能指标 1 分钟

我会先把性能指标分三类。第一类是加载速度，比如 TTFB、FCP、LCP；第二类是交互体验，比如 INP；第三类是稳定性，比如 CLS。这样讲比单纯背概念更像真实项目里的分析方式。

具体来说，TTFB 主要反映服务端响应和缓存命中；FCP 表示页面第一次有内容；LCP 更关注首屏最重要内容什么时候出来；INP 看用户操作后页面多久有真实反馈；CLS 看页面有没有明显抖动。

如果讲解决思路，我会按问题来源说。加载慢就看资源体积、接口耗时、缓存和关键路径资源；交互卡就看主线程长任务、重复渲染、重计算；页面抖就看图片和广告位是否预留尺寸、异步内容插入方式是否稳定。也就是说，我不会把性能优化讲成一个大口号，而会讲成指标和治理动作之间的一一对应。

性能指标 2 到 3 分钟

如果面试官问“有哪些性能指标，是怎么解决的”，我一般不会从 API 开始讲，而会先讲一套分析框架。对我来说，前端性能指标可以分成三组：第一组是加载性能，第二组是交互性能，第三组是视觉稳定性。这样讲比较接近真实排查路径。

加载性能里，我最常讲的是 TTFB、FCP 和 LCP。TTFB 代表首字节时间，偏服务端响应、网络链路和缓存命中；FCP 代表第一次内容绘制，说明用户什么时候看到页面开始有东西；LCP 更关键，它看的是首屏最重要内容什么时候真正出来，通常比 FCP 更接近用户体感。

如果这几个指标差，我会先拆原因。比如 TTFB 高，我会优先看服务端接口耗时、CDN、缓存策略、SSR 或网关链路；如果 FCP/LCP 高，我会看首屏资源是不是太大，JS 包是不是过重，关键图片是不是没有压缩，字体是不是阻塞渲染，首屏组件是不是做了太多同步计算。对应动作一般包括代码拆包、懒加载、资源压缩、图片格式优化、缓存、预加载关键资源，以及减少首屏不必要的同步工作。

第二组是交互性能，我一般会重点讲 INP。以前很多人会讲 FID，但现在更建议讲 INP，因为它更能反映一次完整交互从输入到页面响应的真实体验。如果 INP 差，通常说明主线程太忙，比如长任务太多、React 重渲染太频繁、一次输入触发了太重的计算，或者事件回调里做了太多同步逻辑。这个时候我会从减少长任务、拆分计算、延迟非关键逻辑、避免不必要渲染、虚拟列表和 memo 化这些方向去优化。

第三组是视觉稳定性，也就是 CLS。这个指标经常被忽略，但用户体感很明显。比如图片没预留尺寸、广告位后插入、骨架屏和真实内容高度差很多、异步模块把页面撑开，这些都会导致页面抖动。如果 CLS 高，我一般会先做尺寸预留、固定容器占位、优化异步内容插入策略，并让骨架屏尽量接近最终布局。

如果让我再收一下，我会说性能指标不是背概念，而是看你能不能把指标和优化动作对应起来。比如 TTFB 对服务端和缓存，LCP 对首屏资源和渲染链路，INP 对主线程阻塞，CLS 对布局稳定性。真正有经验的回答，不是知道多少缩写，而是知道每个指标差的时候应该先查哪里。

性能优化 5 分钟逐字稿

如果面试官让我系统讲前端性能优化，我一般不会上来就背一堆技巧，比如 memo、懒加载或者虚拟列表。我会先讲一个框架：前端性能问题我通常分成三类看，第一类是加载性能，第二类是交互性能，第三类是页面稳定性。这样讲的好处是，后面每个指标和动作都能对得上。

加载性能这块，我一般重点看 TTFB、FCP 和 LCP。TTFB 更偏服务端和缓存，FCP 说明页面什么时候第一次开始有内容，LCP 更接近用户对首屏速度的真实体感。如果这些指标差，我第一反应不会是直接改组件，而是先看首屏资源、包体积、图片和字体、缓存命中，以及是不是把太多非首屏逻辑同步打进来了。对应的动作通常是代码拆包、懒加载、资源压缩、图片格式优化、缓存和预加载关键资源。

第二类是交互性能，我一般会重点讲 INP。因为对用户来说，页面能不能点得动、输得动，比首屏快一点还是慢一点更容易感知。如果 INP 差，我会优先怀疑主线程是不是有长任务，比如一次输入触发了太重的排序、过滤、格式化，或者一次状态更新带出了大面积重渲染。React 场景里，我会先看状态边界是不是太大，再看是不是有不必要的重复渲染，最后才考虑 memo、useMemo、useCallback 这些局部优化。我的原则一直是先缩小更新范围，再谈缓存。

第三类是页面稳定性，也就是 CLS。这个指标经常容易被忽略，但用户体感很强。最常见的问题就是图片、广告位、异步模块没有预留尺寸，或者骨架屏和真实内容差异太大，导致页面后续一直往下顶。这个问题的解决思路也比较明确，就是尺寸预留、固定占位、优化异步内容插入方式，让骨架屏更接近最终布局。

如果再往工程化一点讲，我不会把性能优化理解成一次性改代码，而会把它看成一个闭环。先用 Web Vitals 和性能监控把问题采上来，再结合浏览器 Performance、React Profiler 和录屏去定位，然后做有优先级的优化，最后再把监控、告警和防回归补齐。因为性能最怕的不是这次慢，而是过几周又慢回去。

所以如果让我用一句话总结，我会说前端性能优化不是某个 API 或某个 hook 的技巧题，而是一套“指标拆解、瓶颈定位、优化动作和持续治理”的完整方法。这样回答，面试官通常会觉得你不是只会背术语，而是真的做过性能治理。

串联链路一句话

我不会把性能指标、监控 SDK 和 Web Vitals 拆成三个孤立题，而会把它们串成一条链：先定义看什么，再决定怎么采，最后再看怎么把数据变成优化动作。

串联链路 30 秒

如果要把这三个题串起来讲，我会这样回答：Web Vitals 解决的是“看哪些指标”，监控 SDK 解决的是“怎么稳定采集和上报”，而性能分析真正要解决的是“数据回来之后怎么定位和优化”。也就是说，指标是目标，SDK 是载体，优化是结果，这三件事本来就是一条链。

串联链路 1 分钟

我一般会先讲 Web Vitals 这一层，因为它定义了核心性能语言，比如 TTFB、FCP、LCP、INP、CLS。这些指标分别对应加载速度、交互响应和页面稳定性。

接下来我会讲监控 SDK，因为指标光知道没用，关键是怎么稳定地采出来。SDK 层要解决的是采集、校准、上下文补充和上报链路，比如用 PerformanceObserver 监听指标，用 buffered: true 避免漏采，再通过 transport 做批量、重试和 sendBeacon 兜底。

最后我会讲性能优化，因为数据不是为了采而采，而是为了定位问题。比如 LCP 高，我会优先查首屏资源和渲染链路；INP 高，我会查主线程长任务；CLS 高，我会查布局预留和异步内容插入。这样回答能把指标、SDK 和优化串成一个完整闭环。

串联链路 2 到 3 分钟

如果面试官把性能指标、监控 SDK 和 Web Vitals 放在一起问，我会把它理解成一个完整的性能治理闭环，而不是三道独立题。因为真实项目里，这三件事本来就是连着的。

第一层是指标定义，也就是到底看什么。我一般会先用 Web Vitals 作为主轴，因为它跟用户体验更贴近。比如 TTFB 对应首包速度，FCP 对应第一次有内容，LCP 对应首屏核心内容，INP 对应交互响应，CLS 对应页面稳定性。这样你就有了一套统一语言去描述体验问题。

第二层是采集和校准，也就是监控 SDK 解决的问题。光知道指标还不够，关键是你能不能稳定地采出来，而且采出来的数据得可信。比如 PerformanceObserver 怎么监听，SDK 初始化晚了怎么用 buffered: true 补采，CLS 怎么过滤 hadRecentInput，后台页、prerender、bfcache 这些场景怎么修正时间基准。这一层如果做不好，后面的优化方向就会被脏数据带偏。

第三层是上报和上下文。SDK 不能只把一个数字发出去，还要带环境信息、页面路径、版本号、设备信息，有条件的话还要补归因信息。比如 LCP 最好能知道是图片慢、接口慢还是渲染慢；CLS 最好能知道最大位移来源。这样数据回来之后才不是只看仪表盘，而是真的能往定位走。

第四层才是优化动作，也就是数据怎么落到工程决策。比如 TTFB 高，我会先查服务端接口、缓存、CDN；LCP 高，我会查首屏资源、图片、字体和 JS 包；INP 高，我会查主线程长任务、重复渲染和同步阻塞；CLS 高，我会查尺寸预留、占位和异步内容插入方式。这样每个指标都能对应到一类明确动作。

所以我一般会把这类题总结成一句话：Web Vitals 定义目标，监控 SDK 承担采集和上报，性能治理负责把数据变成优化动作。面试官如果想看的是系统性思维，这样讲会比把三道题拆开答更完整。

量化结果一句话

我不会只说“页面变快了”，而会讲清楚基线是什么、指标怎么变、用户体验和业务结果有什么变化。

量化结果 30 秒

如果面试官问性能优化结果怎么量化，我一般会分三层说。第一层是技术指标，比如 LCP、INP、CLS、接口耗时、包体积；第二层是用户体验，比如首屏更快、输入不卡、页面不抖；第三层是业务结果，比如跳出率下降、转化提升、工单减少或者用户反馈改善。这样回答比单纯说“优化了 30%”更完整。

量化结果 1 分钟

我一般不会只给一个绝对数字，而会先讲基线和口径。比如优化前 LCP 的 p75 是多少，优化后降到多少；或者输入场景里 INP 从多少降到多少。因为性能结果如果没有基线，其实很难说明问题。

然后我会补一层用户体感，比如首屏核心内容更早出现、筛选操作不再明显卡顿、列表滚动更顺。最后如果有业务侧数据，我会再补一层，比如页面停留、跳出率、转化链路、用户投诉或客服反馈的变化。

也就是说，我会把性能结果讲成“指标变化 + 体感变化 + 业务影响”三层，而不是只丢一个百分比。

量化结果 2 到 3 分钟

如果面试官问性能优化结果怎么量化，我一般会先说一个原则：性能结果不能只讲“优化了多少”，要讲“基线是什么、口径是什么、结果影响了什么”。因为没有这三层，数字很容易变成没有上下文的口号。

第一层是技术指标，我通常会优先讲 p75 这类更贴近真实用户体验的指标，而不是只讲平均值。比如首屏体验我会看 LCP、FCP，交互体验我会看 INP，稳定性我会看 CLS，必要时再补接口耗时、资源体积、渲染耗时或者错误率。这样能说明我不是只会背一个指标，而是知道该看哪一层。

第二层是用户体感。我通常会把指标翻译成人能听懂的话。比如 LCP 下降，不只是数字变小了，而是用户更早看到首屏核心内容；INP 下降，不只是毫秒数变了，而是筛选、输入、切换这类操作不再有明显迟滞；CLS 下降，不只是布局稳定性提升，而是页面看起来不再乱跳。面试里这一步很重要，因为很多面试官更关心你是不是能把技术结果翻译成体验结果。

第三层是业务影响。如果项目里有业务数据，我会补得更完整，比如页面停留时间、漏斗转化、跳出率、客服工单、用户投诉是否改善；如果没有直接业务指标，我也不会硬编，而会诚实地说至少能确认两类结果：一类是监控指标确实下降，另一类是线上主观反馈和问题工单减少。

另外我会特别注意不要只报最漂亮的那个数字，而是说明这个数字是在什么场景、什么设备、什么分位数下看的。比如我会说“优化前 p75 的 LCP 大概在 4 秒左右，优化后降到 2.8 秒附近”，这会比只说“优化了 30%”更可信。

所以如果让我总结，我会说性能优化结果最稳的讲法就是三层：先讲指标变化，再讲用户体感，再讲业务影响。能把这三层串起来，面试官会更容易相信你是真的做过性能治理，而不是只会背几个术语。

取舍一句话

性能优化不是看到哪里慢就全改，而是先看收益最大的是哪一层，再决定优先动资源、状态边界、渲染量还是交互链路。

取舍 30 秒

如果面试官问性能优化怎么取舍，我一般会先看三件事：问题影响范围有多大、优化收益有多直接、改动风险有多高。比如首屏卡得很明显，我会优先动首屏资源和关键渲染路径；长列表卡，我会优先上虚拟列表；如果只是某个局部计算慢，我才会考虑 memo 或缓存。我的原则是先做收益大、验证快、风险可控的动作，而不是一上来就大改架构。

取舍 1 分钟

我做性能优化时一般会先排优先级，而不是把所有手段都上一遍。最常用的判断框架有三个维度：第一，影响范围，是不是核心页面、核心链路、主要用户群都会受影响；第二，收益大小，优化之后是不是能明显改善首屏、交互或稳定性；第三，改动成本和风险，会不会牵一发而动全身。

比如首屏问题，我通常优先做代码拆包、懒加载、图片压缩、缓存和关键资源优化，因为收益直接、验证也快；交互卡顿我会先拆长任务、减渲染量；长列表问题优先虚拟列表，因为它能直接减少渲染数量。反过来，如果某个方案改动很大、收益又不确定，我一般不会把它当第一选择。

所以我的取舍思路通常是：先做最影响体感、最容易验证、最不容易带来副作用的优化，再考虑更深层的结构调整。

取舍 2 到 3 分钟

如果面试官问性能优化怎么取舍，我一般会强调一点：性能优化不是技术动作堆砌，而是一个典型的工程取舍问题。因为你几乎永远不可能把所有问题一次性都优化到极致，所以关键不是“会多少招”，而是知道先动哪里最值。

我通常会从四个维度判断。第一是用户体感，哪个问题最容易被用户直接感知，比如首屏白得久、输入有明显迟滞、页面一直抖，这类优先级一定高。第二是影响范围，是不是核心页面、核心路径，还是某个边缘场景。第三是收益确定性，也就是你做完之后是不是大概率能看到明显改进。第四是改动风险，特别是会不会引入新的复杂度和维护成本。

比如首屏慢，如果已经能确认是包体积和关键资源问题，那我通常优先做拆包、懒加载、资源压缩和缓存，因为这些动作的收益比较确定，而且验证也快。再比如长列表卡，如果问题已经很明显，那虚拟列表通常比在单个 cell 上做很多细碎优化更划算，因为它直接减少渲染数量。

反过来，有些优化虽然听起来高级，但未必值得优先做。比如到处加 memo、useMemo，如果真正问题是状态边界太大，那这些动作很可能收益很有限，还会增加代码复杂度。所以我一般会先收缩更新范围，再决定需不需要加缓存。我的原则一直是：先做结构上能减少工作量的动作，再做局部技巧优化。

另外一个很重要的取舍点，是止血和长期治理要分开。比如线上已经明显卡了，那我可能先上一个收益快的方案，比如减少首屏渲染量、降级某些重逻辑、先用虚拟列表止血；等问题被控制住，再去做更底层的状态边界治理、组件拆分或者监控补齐。这样既能保护线上体验，也不会把团队拖进一次过大的改造里。

所以如果让我总结，我会说性能优化最核心的取舍原则就是三句：优先优化用户最有体感的问题，优先做收益最大且验证最快的动作，优先做能从根上减少工作量的优化，而不是一上来就堆技巧。

防回归一句话

性能优化如果只做一次，不做监控和防回归，很容易过几周又回到原点，所以我会把它当成一个持续治理闭环。

防回归 30 秒

如果面试官问性能怎么做监控和防回归，我一般会讲三件事。第一，先把关键指标接进监控，比如 LCP、INP、CLS、接口耗时和错误率；第二，按页面和核心链路做阈值告警，不让问题只能靠用户反馈；第三，把这次优化沉淀成发布后校验和长期看板，避免同类问题反复出现。

防回归 1 分钟

我一般会把性能治理分成三个环节：采集、告警、防回归。采集层面先明确核心指标，比如 LCP 看首屏、INP 看交互、CLS 看稳定性，必要时补 TTFB、接口耗时和资源体积。

告警层面我不会只盯全站平均值，而会更关注核心页面、核心路径和 p75 这种更接近用户体感的口径。这样一旦某次发版把核心页面性能拉差，能更快发现。

防回归层面我会做两件事：一是把关键指标放进发布后观察清单，二是把这次优化抽成团队规则，比如首屏资源不要再无脑进主包、图片必须预留尺寸、重列表必须优先考虑虚拟化。这样性能才不会变成一次性的救火。

防回归 2 到 3 分钟

如果面试官问性能监控、告警和防回归怎么做，我一般会把它理解成性能治理的后半段。因为优化动作本身只是开始，真正难的是怎么保证问题后面不反复出现。

第一步是监控。我会先把关键指标接进统一监控链路里，而不是等用户说慢才知道慢。最常用的一般就是 LCP、INP、CLS、TTFB，再加接口耗时、资源大小、错误率这些辅助指标。这里我会特别强调口径，通常不会只看平均值，而更关心 p75、核心页面和核心路径的数据。因为性能问题很多时候不是全站普遍差，而是集中在少数关键场景。

第二步是告警。我的经验是，告警不能太泛，否则很快就没人看了。所以我更倾向于给核心页面和关键指标设阈值，比如某个主链路页面的 LCP 连续一段时间超过阈值，或者某次发版后 INP 明显抬升。这种告警最好还能带上版本、页面路径和设备维度，方便快速定位。

第三步是防回归。这里我通常会做三类事情。第一类是发布后观察，也就是每次重要发版之后重点盯核心页面和指标变化，不等用户反馈。第二类是规则沉淀，比如主包体积预算、图片尺寸预留、长列表虚拟化、重计算延后执行，这些最好变成团队共识。第三类是经验回流，把这次问题的根因和判断方式写下来，让下次排查路径更短。

如果团队工程化能力更强一点，我还会继续往前做，比如把包体积、关键页面 Lighthouse 或 Web Vitals 校验接进 CI，至少在合并前先把明显风险暴露出来。虽然这不能完全替代线上监控，但能把一部分回归提前拦下来。

所以如果让我总结，我会说性能治理真正闭环是“采集 - 告警 - 观察 - 防回归”。能把这四步讲清楚，面试官会更容易相信你做过的是持续治理，而不是一次性优化。