1. 面试官到底想从“性能优化”里问出什么
1.1 性能优化在面试中的真实定位
铜九铁十，秋招和跳槽季一起挤过来，前端岗位的面试题翻来覆去就那么几大类：框架原理、工程化、手写代码、计算机基础，剩下的就是性能优化。性能优化这玩意儿在简历上几乎人手一条“负责项目性能优化，首屏加载时间降低X%”，但面试官心里清楚，大部分人只是配了个cdn、开了个gzip，连自己项目里最大的性能瓶颈在哪都没测过。
所以面试官问性能优化，其实想验证三件事：第一，你手里有没有一套完整的方法论，而不是背了一堆零散的知识点；第二，你做的优化有没有数据支撑，有没有对比前后变化；第三，遇到真实的线上问题时，你有没有系统性的排查思路。换句话说，性能优化面试题表面上考知识点，实际上考的是你有没有“把事做成闭环”的能力。
这篇文章我把前端性能优化面试中最常被追问的知识点全部串了一遍，从指标采集到加载链路，从构建优化到运行时渲染，从内存泄漏到白屏排查，每一块都尽量说清“是什么、为什么、怎么落地、有什么坑”。适合正在准备秋招的同学，也适合想系统梳理自己性能优化知识体系的前端从业者。
1.2 先过一遍必背的指标概念
面试聊性能优化，必然绕不开指标。连指标都说不清楚，后面的优化手段就是空中楼阁。常见的性能指标分两类：一类是加载类指标，一类是交互类指标。
加载类指标最基础的是FP（First Paint，首次绘制）、FCP（First Contentful Paint，首次内容绘制）和LCP（Largest Contentful Paint，最大内容绘制）。FP只代表页面开始画了东西，可能是个背景色；FCP代表第一个有内容的绘制，比如一段文字、一张图片；LCP则代表页面主体内容加载完成，通常是首屏最大的图片、标题块或视频。面试官如果追问哪个指标最关键，直接答LCP，因为它是用户感知页面“可用”的关键节点。
交互类指标以前常问FID（First Input Delay，首次输入延迟），现在逐渐被INP（Interaction to Next Paint，交互到下一次绘制的延迟）取代。INP统计用户整个访问周期内所有交互的延迟，取最差的那次，更能反映真实体验。另外CLS（Cumulative Layout Shift，累计布局偏移）也要记住，它衡量页面元素的稳定性，数值应该小于0.1，大于0.25就属于体验很差了，常见诱因是图片没有声明宽高比、动态插入内容、字体加载导致文字跳动。
还有个容易忽略的点：性能指标要结合用户的真实设备来评估。开发机上秒开的页面，低端Android手机上可能白屏好几秒。所以面试的时候提一嘴“我用Performance面板在低端机模拟场景下采集指标”，会显得你是真跑过线上环境的。
2. 资源加载链路优化，从输入URL到页面可交互
2.1 DNS、TCP、HTTP这三层怎么省时间
用户输入一个网址到页面展示，中间要经历DNS解析、TCP建连、HTTP请求、服务端处理、响应返回、浏览器解析渲染这么一条长链路。前端能动手的环节比想象中多，面试时从这条链路展开讲，会显得思路很完整。
DNS解析这块，最常见的优化手段是dns-prefetch。在<head>里提前告诉浏览器，这个域名后面可能会用到，可以提前解析。比如页面要请求cdn.example.com上的静态资源，就在HTML头部写一行：
<link rel="dns-prefetch" href="//cdn.example.com">还有一个和它长得很像但作用不同的属性叫preconnect，它比dns-prefetch更进一步，会在后台提前完成DNS解析、TCP握手和TLS协商。如果是跨域的接口请求，直接上preconnect，效果比dns-prefetch更明显：
<link rel="preconnect" href="https://api.example.com" crossorigin>注意后面的crossorigin，如果接口请求是跨域的，不写这个属性，浏览器只会做DNS解析和TCP握手，不会预连接TLS。这个小细节面试的时候说出来，多半能让面试官眼睛亮一下。
HTTP请求层最核心的优化是减少请求次数和减小传输体积。减少请求次数靠的是HTTP缓存、雪碧图（现在已经很少用了）、内联小文件；减小体积靠的是gzip/Brotli压缩、图片压缩、开启HTTP/2多路复用。HTTP/2解决了HTTP/1.1队头阻塞的问题，同一个域名下多个请求可以并行传输，所以现代项目不需要像以前那样把几十个小图片合成一张雪碧图了。
但也要留意，HTTP/2虽然多路复用，TCP层面的队头阻塞依然存在。如果一个TCP连接丢了一个包，后续的数据都得等重传。所以HTTP/3（基于QUIC）才被推出来，彻底把队头阻塞问题从传输层解决掉了。面试如果聊到HTTP/2和HTTP/3区别，抓住“HTTP/1.1是应用层串行、HTTP/2解决了应用层队头阻塞、HTTP/3解决了TCP层队头阻塞”这条线去答，基本不用背什么概念。
2.2 HTTP缓存策略是面试重点中的重点
HTTP缓存是性能优化面试里出场率最高的考点，没有之一。面试官喜欢让你解释强缓存和协商缓存的区别，以及对应的Header字段。
强缓存的核心字段是Cache-Control和Expires。Cache-Control是比较现代的方案，里面有一堆指令，最常用的几个一定要能背出来：
max-age=3600：资源在3600秒内直接本地取用，不发请求public/private：表示缓存可以被任何中间节点缓存，还是只能被浏览器本地缓存no-cache：不是不缓存，而是每次使用前必须去服务器验证一下资源是否过期no-store：这才是真正不缓存，每次都要完整地下载资源
注意no-cache和no-store的区别，这是面试官最喜欢设的坑。no-cache是不用缓存，虽然字面上看着像“不要缓存”，实际意思是“缓存可以用，但必须每次确认有效性”。no-store才是真正的“禁止缓存”。
协商缓存是两个字段一队上场的：Last-Modified配合If-Modified-Since，ETag配合If-None-Match。浏览器第一次请求资源时，响应头里带着Last-Modified或ETag，下次请求时浏览器把值放进请求头发给服务器。服务器判断资源没变，返回304状态码，浏览器继续用本地缓存，响应体为空，省流量。
这里有个经验要分享：实际项目中，ETag通常比Last-Modified更精准。因为Last-Modified只有秒级精度，文件在一秒内修改过就可能判断失误。而ETag是根据文件内容生成的哈希值，内容变了才变。所以现代服务器配置里通常两个字段同时开，浏览器会优先使用ETag。
还有一个面试官常追问的问题：强缓存和协商缓存哪里配置？前端一般改不了服务端配置，但可以告诉面试官，CDN平台、Nginx、后端代码里都能配。Nginx的常见配置长这样：
location /static/ { expires 7d; add_header Cache-Control "public, max-age=604800, immutable"; }immutable这个指令值得单独说一句，它告诉浏览器这个资源在过期时间内永远不会变，刷新页面时也不用重新请求，适合带哈希指纹的静态资源，比如app.abc123.js这种文件名里带内容哈希的。
2.3 资源优先级与关键渲染路径
面试问完缓存，大概率会追问资源加载的优先级。HTML解析过程中，浏览器会给每个资源分配一个加载优先级，但默认策略不总是最优的，前端可以主动干预。
preload用于预加载当前页面马上要用到的关键资源，比如首屏的主JavaScript文件、关键的字体文件，写法是：
<link rel="preload" href="main.js" as="script">要注意，preload加载的资源浏览器会很快执行，如果写了preload但实际没用到，反而会浪费带宽。所以只对确定要用的资源用preload。
prefetch是预加载“下一个页面可能用到的资源”，优先级很低，在浏览器空闲的时候才去加载。典型场景是用户停留在落地页时，把详情页可能用到的数据接口或组件代码提前拉下来。不过有个坑：prefetch的资源如果后续页面已经更新了版本，就会白白下载没用的东西，控制好粒度很重要。
除了资源加载，还有一条关键渲染路径（Critical Rendering Path）的优化思路。核心是尽量减少首次渲染所需的资源数量和体积。常见做法是内联首屏关键CSS（Critical CSS），把首屏真正用到的样式直接以<style>嵌在HTML里，非关键CSS异步加载。JavaScript脚本最好加上defer或async属性，避免阻塞HTML解析。
这里补充一下defer和async的区别，也是高频面试题。async是下载完成之后立即执行，执行时可能还在解析文档，执行顺序不保证；defer是等文档解析完成之后再执行，多个defer脚本按顺序执行。现代项目里，模块化脚本用defer更稳妥，因为大多数脚本依赖DOM结构已解析完毕。
3. 构建与打包层面的优化手段
3.1 Webpack打包优化的几个抓手
问完浏览器加载链路的优化，面试官下一步往往转向构建工具，因为现代前端项目基本离不开Webpack或Vite。构建优化的切入点很多，但面试常问的核心就几个：Tree Shaking、代码压缩、CDN外置、持久化缓存。
Tree Shaking的本质是消除“没用到的代码”。它依赖ES Module的静态结构——import和export语句不能在运行时改变，这让构建工具可以偷偷删掉没有引用的导出。Webpack开启Tree Shaking的前提是mode: production直接默认开启，但有个前提：代码必须走ES Module语法，CommonJS的require动态语法是没法静态分析的，天然做不了Tree Shaking。有不少老项目用着babel-preset-env时把ES Module转成了CommonJS，导致Tree Shaking失效，这个坑面试可以主动提，会显得有经验。
代码压缩方面，Webpack 5内置了terser-webpack-plugin，默认压缩JavaScript，CSS压缩需要额外配css-minimizer-webpack-plugin。压缩能做的比想象中多：去掉注释、缩短变量名、删除死分支。一个常见的进阶操作是配合DefinePlugin或EnvironmentPlugin，在构建时把process.env.NODE_ENV替换成production，这样代码里的if (process.env.NODE_ENV === 'development')分支会在生产构建时被直接移除，这也是Tree Shaking的一种产出效果。
还有一点容易被忽略：第三方依赖的优化。moment这种老库自带全量语言包，构建时会把几十种语言全打进去，实际项目里只用一种。处理办法是webpack.IgnorePlugin忽略语言包目录，或者直接在resolve.alias里把moment替换成更轻量的day.js。这类问题在面试中属于“懂行”的加分项。
3.2 Vite为什么快，面试回答要说到点子上
现在越来越多的项目切换到Vite，面试官问“Vite为什么比Webpack快”的概率非常高。如果只答“Vite基于ESBuild，Webpack基于JavaScript”，这只能算勉强及格。真正的要点在开发模式和生产构建两个维度分开答。
开发模式下，Vite利用了浏览器原生ES Module支持，不对整个项目做预打包，只对源代码做按需转换。你改了一个组件文件，Vite只需重新请求并转换那个文件，几十毫秒内就能热更新。Webpack则需要从入口出发重新构建依赖图，项目一大，热更新可能要等好几秒甚至几十秒。这是两者开发体验差距的最大来源。
但注意，Vite生产构建用的不是ESBuild，而是Rollup。因为ESBuild打包速度快，但代码分割、Tree Shaking等高级功能还不够完善。Vite是两套工具组合：开发用ESBuild做预构建依赖，生产用Rollup做最终打包。这个细节说出去，面试官基本就知道你是真用过Vite而不是只看了两篇博客。
Vite预构建依赖这块还有一个常考的点：为什么Vite要把依赖预构建成ESM格式？因为有些第三方库是CommonJS模块，浏览器原生不支持，Vite会用ESBuild把它们预先转成ESM，并合并成单个文件，减少浏览器请求次数。面试答到这里，顺便说一句“这就是为什么node_modules里的依赖在启动时会先构建一次，改依赖要重启dev server”，就很扎实了。
3.3 代码分割，不只是把包拆小那么简单
代码分割（Code Splitting）是构建优化里含金量最高的一个概念。它的目的是让用户只加载当前页面需要的代码，而不是一次性下载整个应用。
最直白的做法是按路由拆块。在React Router或Vue Router里配置动态导入：
const UserPage = () => import('./pages/UserPage.vue')这样每个路由页面会生成独立的chunk，访问首页时不会加载用户管理页的代码。中大型项目里这一步收益非常明显，首屏包的体积能降一半以上。
另一种拆法是按第三方库拆分，利用Webpack的splitChunks配置。比如把react、react-dom、vue、vue-router这类体积大又长时间不变的基础库单独拆出来，合并成一个vendorschunk。这样用户第二次访问时，哪怕业务代码更新了，vendorschunk的文件名没变，就能命中缓存，不用重复下载几MB的框架代码。
这里要提醒一个不少人踩过的坑：拆得太细会导致HTTP请求数量暴涨，反而拖慢加载速度。每个文件都有自己的请求开销，尤其是HTTP/1.1的场景下，几十个小文件串行加载，体验比一个大文件还差。做代码分割的时候一定要看具体项目的体积分布，用webpack-bundle-analyzer直观查看每个chunk的大小，再决定拆分的粒度。一般原则是：业务代码按路由拆，基础库合并成一个不超过500KB左右的vendor chunk，再搭配CDN和HTTP/2使用。
4. 渲染与交互层的性能优化
4.1 从重排重绘讲到渲染帧预算
加载性能只是性能优化的一半，另一半是运行时渲染性能。面试从“页面加载出来了”继续追问，就是渲染层面的优化。
首先要分清重排（Reflow）和重绘（Repaint）。重排指元素几何属性变化，浏览器需要重新计算布局，影响范围可能是局部也可能是整个页面，代价很高；重绘指颜色、背景等视觉属性变化，浏览器只需要重新绘制像素，代价相对低。操作DOM导致重排是性能杀手，面试中常被问到的优化手段无外乎几类：
合并DOM操作，把多次修改合成一次。比如用document.createDocumentFragment()建一个文档片段，把需要变动的元素先加到片段里，再一次性挂载到真实DOM上。
使用requestAnimationFrame把布局变化集中到下一帧执行。还有个经典技巧：把读取DOM属性和写入DOM属性的操作分开。因为你在修改完DOM之后立刻读取它的offsetHeight、scrollTop之类的属性，浏览器还没应用更新呢，只能强制同步重排来给你一个准确的值。如果代码里出现了“修改-读取-修改-读取”的循环，性能直接崩盘。
还有一个容易被忽略的点是CSS属性选择器的性能。虽然现代浏览器优化得很好，但样式计算仍然是有成本的。尽量减少复杂的选择器、避免层级过深，同时用will-change属性来提示浏览器提前优化，但will-change不要滥用，每个元素都加会吃内存，反而更卡。
渲染帧预算这个知识点可以当压轴讲。浏览器的刷新率通常是60Hz，也就是每帧只有16.6毫秒。一帧之内要完成脚本执行、样式计算、布局、绘制、合成，如果脚本执行超过10毫秒，页面就会掉帧，产生卡顿感。面试答到这里，可以顺手引出长任务（Long Task）的概念：超过50毫秒的任务会被Performance面板标记为Long Task。有一次我在实际页面上检测到一个300毫秒的长任务，排查发现是某个图表库在初始化时同步解析了一大段JSON，后来改成懒加载加载图表数据，卡顿问题直接解决。这类真实案例很能说明你理解渲染性能的本质，而不是只会背概念。
4.2 长列表渲染与虚拟滚动实现思路
面试问到长列表，十有八九是考虚拟滚动。几百条数据直接渲染其实没啥问题，但上万条数据一次性渲染成DOM，页面基本就废了。虚拟滚动的核心思想是：只渲染用户可视区域内的那一小部分DOM节点，配合绝对定位和滚动事件动态更新渲染内容。
实现思路分两种。固定高度列表比较简单，计算出容器高度和每个元素高度，滚动时算出可视区域的起始索引startIndex，然后只渲染startIndex到endIndex之间的元素，再用一个transform: translateY()把整个渲染区域位移到正确的位置。高度一固定，数学公式非常直接：startIndex = Math.floor(scrollTop / itemHeight)。
动态高度列表就麻烦一点。如果每个列表项的高度不固定，比如评论区的内容长度不一，就得先渲染一次才能知道实际高度，然后把这些高度存到数组里。每次滚动时用一个二分查找定位当前scrollTop对应的是第几个元素。这样做在滚动过程中不需要重新测量高度，状态更新更精准。主流方案是react-window的VariableSizeList，后续也有FlashList这类原生性能更强的方案。
虚拟滚动还有个后端配合的思路叫“无限滚动分页”。前端滚动到接近底部时自动加载下一页数据，配合HTTP缓存或Service Worker缓存，体验可以做到非常顺畅。面试可以提一下这个组合方案，因为实际项目中很少单独靠虚拟滚动扛下所有，大多会和分页加载结合。
4.3 事件优化与JS执行效率
交互层性能，除了渲染帧，就是JavaScript本身的执行效率。这里的高频考点是防抖（Debounce）和节流（Throttle），面试官几乎必问，问的方式通常是“搜索框的实时搜索怎么实现”“滚动事件怎么优化”。
防抖和节流的区别必须准确描述：防抖是用户停止操作后才执行，适合搜索输入、窗口resize；节流是固定时间间隔内最多执行一次，适合滚动加载、鼠标移动事件。手写一个防抖函数，这是面试现场常提的代码题：
function debounce(fn, delay) { let timer = null; return function (...args) { clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; }注意这里要用clearTimeout取消上一个定时器，同时箭头函数不能这么写，因为要保留this指向。节流函数也顺手备一个：
function throttle(fn, interval) { let lastTime = 0; return function (...args) { const now = Date.now(); if (now - lastTime >= interval) { lastTime = now; fn.apply(this, args); } }; }除了防抖节流，还有几个提升JS执行效率的手段平时容易忽视。Web Worker可以开一个独立的线程跑耗时的计算任务，比如大量数据的排序、图片处理、JSON解析，这样不阻塞主线程。但要记住，Worker里不能直接操作DOM，跨线程通信用postMessage，数据量太大的时候传输本身也有开销。requestIdleCallback可以在浏览器空闲时间执行低优先级任务，比如上报日志、初始化非关键的组件。requestIdleCallback的兼容性一般，实际生产里更常见的是用setTimeout模拟在下一帧执行。
5. 常见问题与排查经验实录
5.1 面试高频追问：白屏排查链路
白屏问题在面试里也是高频场景题，面试官会给一堆现象，问你怎么排查。我总结一条白屏排查链，面试照着说基本不会卡壳。
第一步，打开DevTools的Network面板，看HTML请求本身有没有返回。如果HTML返回了但DOM没渲染出来，先看控制台有没有报错，脚本执行错误会直接中断渲染流程。第二步，检查JavaScript和CSS资源有没有加载失败，特别是CDN的跨域问题。Script标签加载外部脚本时，没有crossorigin属性可能拿不到详细的错误信息，排查起来很麻烦。第三步，看首屏依赖的数据接口是否返回异常。很多页面是等数据到了才渲染，接口挂了页面就空白，这种情况要在代码层面设置兜底状态。第四步，用Performance面板看LCP和FCP的指标，如果FCP时间很长，大概率是JavaScript阻塞了解析。第五步，真机测试。有时候白屏是低端设备内存不足，加载了过大的JavaScript文件导致卡死。
这个排查链虽然不深，但胜在完整，体现了“从网络到渲染”的系统性思维。面试时能按顺序说出来，比单说一句“看Network面板”强很多。
5.2 内存泄漏的判断与应对
内存泄漏问题面试官也爱问，因为网上项目代码里遗留问题很多。常见泄漏场景有三个：全局变量被意外持有、定时器或事件监听没有清理、闭包捕获了大量数据。
我在实际项目里踩过一个比较典型的坑：一个Swiper轮播组件在组件销毁时没有调用destroy()方法，导致定时器一直在跑，页面切来切去之后内存占用只涨不降。后来用Chrome DevTools的Memory面板做堆快照对比，才定位到问题。这里分享一个实操方法：在Memory面板里记录两次堆快照，中间操作一遍页面逻辑，然后对比两个快照中新增的对象，逐个检查泄漏源。排查定时器泄漏更简单的办法是window.setInterval不用原生的，而是包一层做统一管理，组件卸载时统一清除。
面试中说到内存泄漏，加上一句“我在组件卸载阶段统一清理定时器、事件监听和Web Worker”会很有说服力。再进阶一点，可以提WeakMap和WeakSet，用它们保存对对象的弱引用，一旦外部没有强引用了就能被垃圾回收。这也是ES6新增数据结构的一个隐藏用途。
5.3 我总结的几条避坑心得
铜九铁十面试，性能优化这块我建议各位还是亲手跑一遍自己的项目，把指标采集、优化操作、前后对比的完整过程走下来，比背十篇八股文都有用。这里把我实际做性能优化时总结的经验列几条，面试时能自然讲出来会加分。
第一个心得：任何优化都要先测量再动手。我见过很多人上来就开gzip、上CDN，结果页面最大的瓶颈是首屏有一张3MB的图片没压缩。用Lighthouse跑一遍，用Performance面板看一遍加载瀑布图，找到真正的大头再动刀。
第二个心得：图片优化是性价比最高的投入。现在团队项目里很多小伙伴还在直接放原图，一张相机拍的照片可能5MB。改成WebP格式、压缩到100KB左右，对视觉影响不大，但加载速度完全是两个世界。现代浏览器对<picture>标签的支持已经很成熟，可以按设备类型提供不同格式和尺寸的图。
第三个心得：别为了优化而优化。有个项目为了追求LCP指标，把首屏内容拆成了十几个异步组件，结果每个组件都要单独发请求，首屏反而变慢了。性能优化的目标是让用户体验变好，不是指标数字变得好看。每次动手前问自己一句：这个改动对用户的实际感知有帮助吗？
第四个心得：长期维护比一次性优化重要。性能优化不是上线前冲刺一下就完事了，需要持续监控。给项目接入一个性能监控平台，在用户真实环境里上报LCP、CLS、INP这些指标，一旦有波动就能及时发现。我自己习惯在每个项目的发布流程里带上性能回归测试，用Lighthouse的分数和几个核心指标做对比，低于阈值就阻断发布。这个习惯帮我拦住过两次因为合并了错误代码导致的性能回退。
面试前再唠叨一句：八股文背得再熟，不如自己动手把项目里的性能问题找出来几个、真正解决掉。面试官追问细节时，你脑子里有真实经历可以调用，那种底气是背题给不了的。祝大家铜九铁十都能拿到想要的offer。
