1. 面试官到底想从“性能优化”里问出什么1.1 性能优化在面试中的真实定位铜九铁十秋招和跳槽季一起挤过来前端岗位的面试题翻来覆去就那么几大类框架原理、工程化、手写代码、计算机基础剩下的就是性能优化。性能优化这玩意儿在简历上几乎人手一条“负责项目性能优化首屏加载时间降低X%”但面试官心里清楚大部分人只是配了个cdn、开了个gzip连自己项目里最大的性能瓶颈在哪都没测过。所以面试官问性能优化其实想验证三件事第一你手里有没有一套完整的方法论而不是背了一堆零散的知识点第二你做的优化有没有数据支撑有没有对比前后变化第三遇到真实的线上问题时你有没有系统性的排查思路。换句话说性能优化面试题表面上考知识点实际上考的是你有没有“把事做成闭环”的能力。这篇文章我把前端性能优化面试中最常被追问的知识点全部串了一遍从指标采集到加载链路从构建优化到运行时渲染从内存泄漏到白屏排查每一块都尽量说清“是什么、为什么、怎么落地、有什么坑”。适合正在准备秋招的同学也适合想系统梳理自己性能优化知识体系的前端从业者。1.2 先过一遍必背的指标概念面试聊性能优化必然绕不开指标。连指标都说不清楚后面的优化手段就是空中楼阁。常见的性能指标分两类一类是加载类指标一类是交互类指标。加载类指标最基础的是FPFirst Paint首次绘制、FCPFirst Contentful Paint首次内容绘制和LCPLargest Contentful Paint最大内容绘制。FP只代表页面开始画了东西可能是个背景色FCP代表第一个有内容的绘制比如一段文字、一张图片LCP则代表页面主体内容加载完成通常是首屏最大的图片、标题块或视频。面试官如果追问哪个指标最关键直接答LCP因为它是用户感知页面“可用”的关键节点。交互类指标以前常问FIDFirst Input Delay首次输入延迟现在逐渐被INPInteraction to Next Paint交互到下一次绘制的延迟取代。INP统计用户整个访问周期内所有交互的延迟取最差的那次更能反映真实体验。另外CLSCumulative 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 reldns-prefetch href//cdn.example.com还有一个和它长得很像但作用不同的属性叫preconnect它比dns-prefetch更进一步会在后台提前完成DNS解析、TCP握手和TLS协商。如果是跨域的接口请求直接上preconnect效果比dns-prefetch更明显link relpreconnect hrefhttps://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-age3600资源在3600秒内直接本地取用不发请求public/private表示缓存可以被任何中间节点缓存还是只能被浏览器本地缓存no-cache不是不缓存而是每次使用前必须去服务器验证一下资源是否过期no-store这才是真正不缓存每次都要完整地下载资源注意no-cache和no-store的区别这是面试官最喜欢设的坑。no-cache是不用缓存虽然字面上看着像“不要缓存”实际意思是“缓存可以用但必须每次确认有效性”。no-store才是真正的“禁止缓存”。协商缓存是两个字段一队上场的Last-Modified配合If-Modified-SinceETag配合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-age604800, immutable; }immutable这个指令值得单独说一句它告诉浏览器这个资源在过期时间内永远不会变刷新页面时也不用重新请求适合带哈希指纹的静态资源比如app.abc123.js这种文件名里带内容哈希的。2.3 资源优先级与关键渲染路径面试问完缓存大概率会追问资源加载的优先级。HTML解析过程中浏览器会给每个资源分配一个加载优先级但默认策略不总是最优的前端可以主动干预。preload用于预加载当前页面马上要用到的关键资源比如首屏的主JavaScript文件、关键的字体文件写法是link relpreload hrefmain.js asscript要注意preload加载的资源浏览器会很快执行如果写了preload但实际没用到反而会浪费带宽。所以只对确定要用的资源用preload。prefetch是预加载“下一个页面可能用到的资源”优先级很低在浏览器空闲的时候才去加载。典型场景是用户停留在落地页时把详情页可能用到的数据接口或组件代码提前拉下来。不过有个坑prefetch的资源如果后续页面已经更新了版本就会白白下载没用的东西控制好粒度很重要。除了资源加载还有一条关键渲染路径Critical Rendering Path的优化思路。核心是尽量减少首次渲染所需的资源数量和体积。常见做法是内联首屏关键CSSCritical 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默认压缩JavaScriptCSS压缩需要额外配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基于ESBuildWebpack基于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。 前端性能优化面试全攻略：从指标采集到白屏排查
1. 面试官到底想从“性能优化”里问出什么1.1 性能优化在面试中的真实定位铜九铁十秋招和跳槽季一起挤过来前端岗位的面试题翻来覆去就那么几大类框架原理、工程化、手写代码、计算机基础剩下的就是性能优化。性能优化这玩意儿在简历上几乎人手一条“负责项目性能优化首屏加载时间降低X%”但面试官心里清楚大部分人只是配了个cdn、开了个gzip连自己项目里最大的性能瓶颈在哪都没测过。所以面试官问性能优化其实想验证三件事第一你手里有没有一套完整的方法论而不是背了一堆零散的知识点第二你做的优化有没有数据支撑有没有对比前后变化第三遇到真实的线上问题时你有没有系统性的排查思路。换句话说性能优化面试题表面上考知识点实际上考的是你有没有“把事做成闭环”的能力。这篇文章我把前端性能优化面试中最常被追问的知识点全部串了一遍从指标采集到加载链路从构建优化到运行时渲染从内存泄漏到白屏排查每一块都尽量说清“是什么、为什么、怎么落地、有什么坑”。适合正在准备秋招的同学也适合想系统梳理自己性能优化知识体系的前端从业者。1.2 先过一遍必背的指标概念面试聊性能优化必然绕不开指标。连指标都说不清楚后面的优化手段就是空中楼阁。常见的性能指标分两类一类是加载类指标一类是交互类指标。加载类指标最基础的是FPFirst Paint首次绘制、FCPFirst Contentful Paint首次内容绘制和LCPLargest Contentful Paint最大内容绘制。FP只代表页面开始画了东西可能是个背景色FCP代表第一个有内容的绘制比如一段文字、一张图片LCP则代表页面主体内容加载完成通常是首屏最大的图片、标题块或视频。面试官如果追问哪个指标最关键直接答LCP因为它是用户感知页面“可用”的关键节点。交互类指标以前常问FIDFirst Input Delay首次输入延迟现在逐渐被INPInteraction to Next Paint交互到下一次绘制的延迟取代。INP统计用户整个访问周期内所有交互的延迟取最差的那次更能反映真实体验。另外CLSCumulative 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 reldns-prefetch href//cdn.example.com还有一个和它长得很像但作用不同的属性叫preconnect它比dns-prefetch更进一步会在后台提前完成DNS解析、TCP握手和TLS协商。如果是跨域的接口请求直接上preconnect效果比dns-prefetch更明显link relpreconnect hrefhttps://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-age3600资源在3600秒内直接本地取用不发请求public/private表示缓存可以被任何中间节点缓存还是只能被浏览器本地缓存no-cache不是不缓存而是每次使用前必须去服务器验证一下资源是否过期no-store这才是真正不缓存每次都要完整地下载资源注意no-cache和no-store的区别这是面试官最喜欢设的坑。no-cache是不用缓存虽然字面上看着像“不要缓存”实际意思是“缓存可以用但必须每次确认有效性”。no-store才是真正的“禁止缓存”。协商缓存是两个字段一队上场的Last-Modified配合If-Modified-SinceETag配合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-age604800, immutable; }immutable这个指令值得单独说一句它告诉浏览器这个资源在过期时间内永远不会变刷新页面时也不用重新请求适合带哈希指纹的静态资源比如app.abc123.js这种文件名里带内容哈希的。2.3 资源优先级与关键渲染路径面试问完缓存大概率会追问资源加载的优先级。HTML解析过程中浏览器会给每个资源分配一个加载优先级但默认策略不总是最优的前端可以主动干预。preload用于预加载当前页面马上要用到的关键资源比如首屏的主JavaScript文件、关键的字体文件写法是link relpreload hrefmain.js asscript要注意preload加载的资源浏览器会很快执行如果写了preload但实际没用到反而会浪费带宽。所以只对确定要用的资源用preload。prefetch是预加载“下一个页面可能用到的资源”优先级很低在浏览器空闲的时候才去加载。典型场景是用户停留在落地页时把详情页可能用到的数据接口或组件代码提前拉下来。不过有个坑prefetch的资源如果后续页面已经更新了版本就会白白下载没用的东西控制好粒度很重要。除了资源加载还有一条关键渲染路径Critical Rendering Path的优化思路。核心是尽量减少首次渲染所需的资源数量和体积。常见做法是内联首屏关键CSSCritical 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默认压缩JavaScriptCSS压缩需要额外配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基于ESBuildWebpack基于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。