最近在辅导简历和模拟面试时反复遇到一类问题候选人一聊到首屏优化第一反应就是“拆包”。问怎么拆能说上几句 SplitChunks、manualChunks再问拆完之后首屏到底变快了多少、瓶颈在哪个环节、线上指标有没有验证很多人就答不上来了。这个现象挺有代表性的。倒不是“拆包”不重要而是它只是首屏优化链路里的一环。2026 年前后端面试里面试官更想看到的是你对资源加载、渲染架构、可观测性的整体理解以及遇到真实性能问题时能不能“从点到面”做系统分析。本文就围绕这条主线展开既可以当作面试准备素材也可以直接当作项目性能优化的落地参考。1. 别再迷信“拆包”了首屏优化到底在考什么1.1 为什么“无脑拆包”会被淘汰“无脑拆包”指的是这么一类做法不管项目多大、不管用户访问场景先把 node_modules 里的第三方库全部拆成独立 chunk再按路由拆一遍以为 chunk 数量越多、首屏加载的代码越少性能就一定越好。问题在于拆包解决的是“代码体积与缓存利用率”的问题而不是“首屏渲染快慢”的全部问题。盲目拆包会带来几个副作用请求数量爆炸一个页面加载几十个 JS chunkHTTP/1.1 下并发有限HTTP/2 虽然支持多路复用但每个请求仍有头开销、解析开销和数量限制浏览器并发连接数通常 6 个左右HTTP/2 多路复用也存在“队头阻塞”的公平性问题。缓存命中率下降如果把频繁变动的业务代码和稳定的第三方库混在一起拆或者拆得太碎会导致线上发布后大量 chunk 失效用户需要重新下载。忽略真实瓶颈有些页面首屏慢根本原因不是 JS 体积大而是图片没优化、接口串行依赖、字体加载阻塞渲染、主线程被长任务占用。拆包拆得再彻底这些瓶颈依然存在。所以现在的面试题和工程实践都不再把“拆包”当独立考点而是把它放到“资源加载策略”这个更大的框架里看。1.2 首屏优化三层模型我比较推荐候选人建立这样一个分析框架面试答题也好项目落地也好都按这个顺序走层次关注点典型手段资源加载请求数量、体积、优先级、网络链路代码分割、preload/prefetch、HTTP 缓存、CDN、图片压缩、关键 CSS 内联渲染架构页面由谁渲染、何时渲染、如何激活交互CSR、SSR、SSG、ISR、流式渲染、hydration 优化可观测性真实用户指标、错误归因、持续回归RUM、Core Web Vitals、Performance API、Source Map、告警这三层是层层递进的关系。资源加载负责“更快地把关键资源送到浏览器”渲染架构负责“更快地把首屏内容画出来并能够交互”可观测性负责“证明优化有效、发现问题、防止回退”。本文后面每一部分都会围绕这三层展开。2. 没有度量就没有优化先掌握性能指标与采集方式2.1 核心指标到底看哪些首屏优化之前必须先把“首屏”量化。不同项目关心的指标不完全一样但下面这几类是目前前端性能领域最常提到的指标全称 / 含义关注点建议阈值FPFirst Paint首次绘制页面第一次发生视觉变化尽量 1.8sFCPFirst Contentful Paint首次内容绘制首次绘制出文本或图片等实际内容良好 1.8sLCPLargest Contentful Paint最大内容绘制首屏内最大可见元素的渲染时间良好 2.5sINPInteraction to Next Paint交互到下一次绘制的延迟用户交互后的响应速度替代 FID良好 200msTTITime to Interactive可交互时间页面完全可交互移动端尽量 3.8sTBTTotal Blocking Time总阻塞时间从 FCP 到 TTI 之间主线程阻塞的总时长良好 200ms这里需要注意LCP 不是“页面加载完成时间”而是“首屏最大的那块内容出现的时间”。电商页面的主图、新闻页的首屏标题、后台系统的表格头部都可能是 LCP 元素。优化 LCP 的关键是让 LCP 元素对应的资源尽早下载并尽快渲染这比整体 bundle 小不少更重要。INP 是近两年 Google 推动替代 FID 的指标它衡量的是用户点击、按键等交互后页面到下一次绘制的延迟。这个指标和“拆包”就很有关系如果拆包后首屏需要执行的 JS 仍然很长主线程被长任务占用用户交互就会明显卡顿INP 就会变差。这也是为什么不能只看“加载快不快”还要看“交互顺不顺”。2.2 用 PerformanceObserver 采集真实指标面试时能说出指标含义是基础能现场写出采集代码是加分项。真实项目里我们一般用web-vitals库来采集 Core Web Vitals但了解底层 API 也很有必要。// 文件路径src/utils/performance-collect.js // 采集 FCP、LCP、INP 等指标并通过 PerformanceObserver 实现 function observePerformance() { // 1. 采集 FCP首次内容绘制 const paintObserver new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.name first-contentful-paint) { console.log(FCP:, entry.startTime); // 在这里将数据上报到后端或分析平台 } } }); paintObserver.observe({ type: paint, buffered: true }); // 2. 采集 LCP最大内容绘制 const lcpObserver new PerformanceObserver((list) { const entries list.getEntries(); const lastEntry entries[entries.length - 1]; console.log(LCP:, lastEntry.startTime); }); lcpObserver.observe({ type: largest-contentful-paint, buffered: true }); // 3. 采集 INP交互到下一次绘制 const inpObserver new PerformanceObserver((list) { const entries list.getEntries(); const lastEntry entries[entries.length - 1]; console.log(INP:, lastEntry.startTime); }); inpObserver.observe({ type: event, buffered: true, durationThreshold: 16 }); } // 页面加载后开始采集 window.addEventListener(load, () { // 给浏览器一点时间确保 paint/lcp 等条目已生成 setTimeout(observePerformance, 1000); });代码说明buffered: true表示观察器建立后会把之前已经产生的性能条目补发给回调避免因为脚本放在页面底部而漏掉早期指标。LCP 条目是动态更新的浏览器可能在加载过程中多次触发largest-contentful-paint所以取entries的最后一个。INP 的durationThreshold: 16是为了过滤掉低于 16ms 的点击事件因为 16ms 大约是 60fps 下的一帧时长低于这个值通常不会产生明显卡顿。2.3 用 Performance 面板和 Lighthouse 快速定位除了代码采集日常排查建议配合浏览器工具。Chrome DevTools 的 Performance 面板可以录制一段加载过程重点看以下几块Network Timing每个请求的 DNS、TCP、TLS、TTFB、Content Download 耗时。Main Thread 火焰图找到占用主线程时间最长的 Task判断是脚本执行、样式计算还是布局绘制。渲染流水线通过 Frame 面板查看是否存在掉帧。Lighthouse 则可以快速给出一份可量化的报告但它属于“实验室数据”不能完全代表真实用户网络和设备。最佳的度量组合是实验室数据Lighthouse用于开发和 CI 回归。真实用户监控RUM用于线上持续观测。3. 资源加载从“少加载”到“聪明地加载”3.1 关键请求链路拆解页面首屏渲染依赖的请求通常包括这几类HTML 文档决定浏览器能否尽快解析出 DOM 结构。CSS 样式阻塞渲染必须等样式表下载并解析完成浏览器才会做首次绘制。JavaScript 脚本默认情况下同步脚本会阻塞 HTML 解析。图片影响 LCP 元素的出现时间。字体使用font-display: swap不当会导致文字不可见或布局偏移。这几类资源不是孤立存在的它们共同组成了“关键请求链”。比如HTML - CSS - JS - 接口 - 首屏渲染。优化链路的目标是让每一跳都尽可能短同时把非关键资源的加载往后放。3.2 preload、prefetch、preconnect 的正确用法很多项目优化资源加载只想着合并请求、压缩体积却忽略了浏览器预加载和预连接的能力。这几条link标签虽然简单但在面试和实战中都是高频考点。!-- 预连接提前建立与第三方域的 TCP/TLS 连接 -- link relpreconnect hrefhttps://api.example.com crossorigin / !-- 预加载当前页面即将使用的关键资源可以提高优先级 -- link relpreload asstyle href/styles/main.css / link relpreload asfont typefont/woff2 href/fonts/main.woff2 crossorigin / !-- 预获取下一个导航可能使用的资源在空闲时下载 -- link relprefetch href/route/login.js /使用建议preconnect适用于接口域名、CDN 域名、字体仓库域名等可以省去 DNS 查询和 TCP 握手时间。如果域名和当前页面同源不需要加。preload用来提高关键资源优先级。注意不要过度使用否则会把所有资源的优先级都提上去反而拖慢真正的关键资源。prefetch一般用于“用户下一步很可能访问”的路由资源触发条件是浏览器空闲不能在首屏关键资源没加载完时抢先占用带宽。preload字体会有一个常见的坑字体文件需要加crossorigin属性否则字体请求可能被浏览器拦截。3.3 关键 CSS 内联与压缩渲染阻塞是 CSS 的天然属性浏览器只有拿到完整 CSS 才能开始绘制。为了尽快完成首次渲染我们可以把首屏关键 CSSCritical CSS提取出来内联到 HTML 的head中。非关键 CSS 通过mediaprint或动态加载策略延迟加载。!-- 内联关键 CSS 示例 -- style /* 这里放首屏区块所需的关键样式 */ .header { display: flex; align-items: center; } .product-card { max-width: 1200px; margin: 0 auto; } /style !-- 非关键样式延迟加载 -- link relstylesheet href/styles/non-critical.css mediaprint onloadthis.mediaall /mediaprint的策略是浏览器认为这是打印样式不会阻塞渲染等它下载完成后再通过onload把media改成all让样式生效。这个方案不需要额外 JS 库兼容性也不错。当然关键 CSS 的提取本身需要工具支持。Vite 官网提到 2026 年版本对 CSS inlining 有了较强的推荐路径社区常用方案有vite-plugin-critical后端渲染框架内置的 Critical CSS 能力由 CI 构建时生成关键 CSS真实的实践经验是不要对每个页面都做 Critical CSS 提取优先针对首屏文案、首屏图片区域、顶部导航这些“用户最先看到的区块”做内联收益最大。3.4 图片与字体首屏最大元凶之一很多项目首屏慢不是 JS 太大而是图片没有优化。首页轮播图每张 1MB加载三张就是 3MB不管拆包拆得多细都救不回来。图片优化的常见思路使用 WebP/AVIF 格式配合picture标签按设备分辨率选择。开启 CDN 图片压缩和处理能力例如按质量参数动态输出。给 LCP 图片设置fetchpriorityhigh其他图片默认loadinglazy。占位图使用低分辨率模糊图或骨架屏避免大图阻塞布局稳定。!-- LCP 图片高优先级加载 -- img srchttps://cdn.example.com/product-main.webp alt商品主图 width800 height800 fetchpriorityhigh / !-- 非首屏图片懒加载 -- img loadinglazy decodingasync srchttps://cdn.example.com/product-detail-1.webp alt商品详情图 /字体方面font-display: swap能避免文字不可见的问题但可能带来 FOIT/FOUT 或 CLS布局偏移。推荐组合字体文件使用woff2格式并用unicode-range拆分。对非常用的字体延迟加载。为字体设置预留的size-adjust或与设计系统配合减少 swap 带来的布局偏移。4. 拆包的正确姿势按路由、按依赖、按变化频率4.1 拆包的本质是什么拆包的本质有三个目标按需加载用户访问哪个路由就只加载那个路由的代码。缓存复用第三方库和业务代码分开打包利用浏览器缓存减少重复下载。并行加载把互相独立的模块拆成多个 chunk利用 HTTP/2 多路复用并发下载。理解这三个目标再去设计拆分策略就不会“无脑拆”。4.2 不推荐的拆法先说不推荐的两种每个组件都做成懒加载。结果是首屏路由内部出现大量动态组件每个都需要单独请求模块初始化耗时被放大了。把所有第三方库按包名拆成一个一个 chunk。如果项目里有 80 个依赖就会产生 80 多个 chunk请求数量爆炸而且部分库之间存在公共依赖拆得不合理反而下载重复代码。4.3 Webpack SplitChunks 配置示例Webpack 5 中optimization.splitChunks是拆包的核心配置。下面是一个相对稳妥的配置思路// 文件路径webpack.config.js module.exports { optimization: { splitChunks: { chunks: all, // 单独抽离 node_modules 中的稳定依赖 cacheGroups: { // 框架与核心运行时 vendorReact: { test: /[\\/]node_modules[\\/](react|react-dom|react-router-dom)[\\/]/, name: vendor-react, priority: 20, }, // 状态管理、工具库等体积较大的第三方依赖 vendorLib: { test: /[\\/]node_modules[\\/](axios|lodash|dayjs|echarts)[\\/]/, name: vendor-lib, priority: 10, }, // 其余第三方依赖 vendorOther: { test: /[\\/]node_modules[\\/]/, name: vendor-other, priority: 0, }, }, }, }, };配置说明chunks: all表示同步和异步模块都能参与拆包。cacheGroups是核心通过priority决定模块优先进入哪个组。React 相关的依赖优先命中vendorReact不会被打进vendorLib。把echarts之类体积大、更新频率低的库单独拆出配合 CDN 长效缓存可以显著减少用户重复下载。不要把axios和业务代码合在同一个 chunk 里否则业务代码每次发布axios也会跟着失效。4.4 Vite manualChunks 配置示例Vite 底层用的是 Rollup拆包配置在build.rollupOptions.output.manualChunks中// 文件路径vite.config.js import { defineConfig } from vite; import react from vitejs/plugin-react; export default defineConfig({ plugins: [react()], build: { rollupOptions: { output: { manualChunks(id) { // 按包名拆出独立 chunk if (id.includes(node_modules)) { if (id.includes(react) || id.includes(react-dom)) { return vendor-react; } if (id.includes(echarts) || id.includes(lodash)) { return vendor-lib; } return vendor-other; } }, }, }, }, });manualChunks接收一个函数参数id是模块的绝对路径。通过判断路径中是否包含特定包名把模块分到不同 chunk。这里想强调一个点不要为了配置而配置。如果你的项目用的框架包、工具库加起来才 100 多 KB拆成三四个 chunk 可能比拆成十个更有意义。合理的拆包粒度应该是“请求数量和体积之间的平衡点”。4.5 拆包与 HTTP 缓存策略配合拆包后最重要的一步是配合长效缓存。常规做法vendor-react、vendor-lib这类稳定 chunk 使用Cache-Control: max-age31536000, immutable。业务代码 chunk 文件名的 hash 会随内容变化使用Cache-Control: no-cache配合ETag或Last-Modified做协商缓存。不稳定的公共模块可以单独拆成一个chunk-vendors但避免频繁变动导致公共部分反复失效。文件命名时要使用contenthash而不是hash。contenthash是内容级别哈希而hash是构建级别哈希。用错了会导致未修改的 chunk 也被更新。output: { filename: js/[name].[contenthash:8].js, chunkFilename: js/[name].[contenthash:8].js, }5. 渲染架构决定首屏体验的“上层设计”5.1 CSR、SSR、SSG、ISR 怎么选资源加载优化的是“把资源送到浏览器”但页面内容是客户端渲染还是服务端渲染直接决定了用户等待的体验逻辑。渲染模式首屏 HTMLJS 依赖适用场景典型问题CSR空壳 HTML依赖 JS 渲染后台系统、交互复杂应用首屏白屏时间长SEO 差SSR服务端返回完整 HTMLhydration 后交互门户首页、电商、内容站服务端压力大TTFB 可能变长SSG构建期生成静态 HTML可离线、可缓存博客、文档站内容更新需要重新构建ISR静态页 定时增量更新既能缓存又有更新电商活动页、动态内容较多的页面配置复杂实时性有限首屏优化的关键在于不要把“HTML 出来了”当成“页面好了”。CSR 下HTML 只是空壳真正的首屏内容要等 JS 执行完才能出现。SSR 则把渲染工作前置到服务端用户拿到 HTML 时已经能看到内容但脚本 hydration 完成之前页面上的交互事件还没有绑定。5.2 流式渲染与 Hydration 优化流式 SSR 是近几年比较值得关注的趋势。它不像传统 SSR 那样等整个页面渲染完再一起返回而是分块输出 HTML。比如先输出header和首屏商品列表再输出footer和剩余内容。用户能提前看到关键区域TFFBTime to First Byte之后的首屏体感会明显改善。现在主流 React 框架通过 Suspense 和renderToPipeableStream实现流式渲染。Next.js 的 App Router 也已经把流式渲染作为默认能力之一。Vue 生态则通过vue/server-renderer的pipeToNodeWritable支持类似能力。对已有 CSR 项目来说如果要迁移到 SSR建议按“首屏页面”而不是“全站”来做。先挑 1-2 个对首屏体验和 SEO 高要求的页面做 SSR其他页面保持 CSR。// 文件路径app/product/page.tsxNext.js App Router 示例 // 这个组件可以配合流式渲染实现首屏关键区先返回 export default async function ProductPage() { // 服务端获取商品信息 const product await getProduct(); return ( main h1{product.title}/h1 img src{product.image} alt{product.title} fetchpriorityhigh / {/* 详情部分用 Suspense 包裹往下延迟输出 */} Suspense fallback{div加载中.../div} ProductDetail / /Suspense /main ); }hydration 最常见的优化是延迟 hydration等关键用户交互区域先水合非关键区域空闲时再水合。部分 hydration只对动态交互组件做客户端接管静态内容不水合。减少水合成本组件树拆分、事件委托、避免在 hydrate 阶段执行过多定时器。5.3 边缘渲染带来的新选择CDN 从“静态缓存层”演进成“边缘计算平台”后前端渲染又多了一个选项把 SSR 逻辑分发到离用户更近的边缘节点执行。这样可以同时获得静态 CDN 的响应速度和 SSR 的动态渲染能力降低 TTFB。这类能力在 Next.jsMiddleware、Edge Runtime、Nuxt/Jamstack 平台中都很常见。面试如果想给自己加分可以多说一句你理解渲染架构优化的本质是把渲染位置放在“离用户足够近且计算成本可控”的地方而不是机械地争论 SSR 还是 CSR。6. 完整实战一个电商列表页的首屏优化这一节用一个接近真实场景的案例把前面讲到的点串起来。假设我们维护一个移动端 H5 电商列表页技术栈是 React Vite最近接到线上反馈“页面打开很慢”。6.1 基线数据与问题判断优化前先拿到线上数据指标优化前实测中位数目标FCP2.8s 1.8sLCP4.5s 2.5sJS 总体积1.2MB首屏 JS 400KB关键请求数36 个 15 个接口串行次数3 次1 次通过 Performance 面板和 Network 面板分析主要问题集中在所有页面代码都被打进同一个 bundle首屏路由也要加载 1.2MB JS。首页头图和列表图片没有做压缩和优先级控制。接口请求存在串行依赖先请求用户信息再请求商品列表拿到列表后还要请求优惠信息。页面先用 JS 渲染路由级代码没有做懒加载。6.2 优化流程第一步先跑通“可观测性”。在项目里接入 RUM 采集 FCP、LCP、INP确保后续每一次优化都能用数据验证。// 文件路径src/main.jsx import { onCLS, onFCP, onINP, onLCP, onTTFB } from web-vitals; function sendToAnalytics(metric) { // 这里替换成你的数据上报接口 navigator.sendBeacon(/api/performance, JSON.stringify(metric)); } onCLS(sendToAnalytics); onFCP(sendToAnalytics); onINP(sendToAnalytics); onLCP(sendToAnalytics); onTTFB(sendToAnalytics);第二步做资源加载优化路由级懒加载const ProductList lazy(() import(./pages/ProductList))。图片走 CDN统一转 WebP设置fetchpriorityhigh给首屏头图其他图懒加载。关键 CSS 内联到 HTML。对接口域名做preconnect。第三步做拆包与缓存策略。使用 Vite 的manualChunks把 React、工具库单独拆出配合 CDN 长效缓存。第四步做渲染层优化。如果项目允许优先用 SSR/SSG 方案。这里以 Next.js 为例改造列表页为服务端渲染减少客户端 JS 执行时间。// 文件路径app/products/page.tsxNext.js App Router 示例 import { getProductList } from /server/api; import ProductCard from ./ProductCard; export default async function ProductsPage() { const products await getProductList(); return ( div classNameproduct-list {products.map((item) ( ProductCard key{item.id} product{item} / ))} /div ); }第五步接口请求并行化。用Promise.all并行请求接口或者让服务端 BFF 层合并接口减少浏览器端串行等待。// 优化前串行请求 const userInfo await fetchUserInfo(); const productList await fetchProductList(userInfo.regionId); const couponInfo await fetchCouponInfo(productList.amount); // 优化后并行请求如接口之间无依赖 const [userInfo, productList, couponInfo] await Promise.all([ fetchUserInfo(), fetchProductList(), fetchCouponInfo(), ]);6.3 优化结果与复盘优化后中位数数据表现指标优化前优化后提升FCP2.8s1.4s50%LCP4.5s1.9s57%首屏 JS1.2MB380KB68%关键请求数36 个12 个67%这次实战的关键结论是拆包只解决了 1.2MB - 380KB 这一项而真正的体验提升来自图片优化、预连接、渲染架构和接口并行化的合力。7. 可观测性让首屏优化持续生效而不是“一次性表演”7.1 可观测性的核心组件很多团队做性能优化上线后就没有然后了。下一次版本迭代可能引入新的重组件性能又悄悄劣化。可观测性要解决的就是“持续”的问题。一个相对完整的可观测体系包含上报告警、速度监控、错误监控、会话回放等模块。下面这个是适合中小型前端团队的可行架构可以用表格看模块数据来源作用性能监控web-vitals Performance API RUM SDK采集 FCP、LCP、INP、TTFB 等指标资源监控Resource Timing / Performance ResourceTiming查看每个资源的加载耗时与成功率错误监控window.onerror unhandledrejection Source Map定位 JS 运行时错误告警指标阈值 错误率阈值性能回归时及时通知日志查询结构化日志存入后端按用户、地区、版本回溯问题7.2 资源级性能数据的采集除了页面级指标有时候还需要定位“具体是哪个资源慢”。这时候可以用PerformanceObserver观察resource类型// 文件路径src/utils/resource-monitor.js const observer new PerformanceObserver((list) { const entries list.getEntries().filter((entry) { // 只关注同域 API 和关键图片资源 return entry.initiatorType fetch || entry.initiatorType img; }); const slowResources entries .filter((entry) entry.duration 500) .map((entry) ({ name: entry.name, duration: entry.duration, initiatorType: entry.initiatorType, transferSize: entry.transferSize, domContentLoadedTime: entry.responseEnd - entry.requestStart, })); if (slowResources.length 0) { // 上报慢资源 console.warn(Slow resources:, slowResources); } }); observer.observe({ type: resource, buffered: true });在面试里提到这种“不仅能监控页面级指标还能定位到资源级耗时”的思路会比只说“接了 web-vitals”要更有竞争力。7.3 建立性能回归防线可观测性不只服务于线上也应该接入 CI。常见做法是在 CI 中使用 Lighthouse CI 跑性能审计设置性能分数门槛低于阈值就阻止合并。在测试环境用 Puppeteer 模拟弱网环境采集核心指标。上线后对比新旧版本同一指标的分布确认没有性能回归。有一个容易忽视的细节指标要按“分位数”和“分布”观察不能只盯平均值。用户设备的差异很大平均值容易被极端值拉高建议观察 P50、P75、P95 分位数的变化。8. 常见问题与排查思路整理一些实际项目中高频出现的问题按“现象 - 原因 - 解决思路”列出来方便面试前快速复习和团队内部排错问题现象常见原因解决思路拆包后 chunk 数量暴涨页面更慢了拆包粒度过细请求过多统一给 chunk 设置最小体积限制合并小 chunk业务代码更新后第三方库缓存也失效第三方库和业务代码被打在同一 chunk调整 SplitChunks / manualChunks把 node_modules 单独拆出首屏图出现很晚LCP 持续偏慢图片未设置 fetchpriority仍被当成普通图片排队给 LCP 图片加 fetchpriorityhigh切换 WebP 格式字体文件导致空白文字或布局跳动未设置 font-display或字体体积过大使用 font-display: swap压缩 woff2合理拆分 unicode-range首屏接口 TTFB 很高DNS/连接未预建接口跨域多跳或服务端响应慢对接口域名做 preconnectBFF 聚合接口优化后端缓存SSR 页面内容出来了但按钮点击没反应hydration 未完成或部分元素未水合检查 hydration 时机优先水合关键交互区上线后性能数据波动大只观察平均值没有做分位数和分组统计按 P50/P75/P95 观察按页面/机型/网络分组对比部署后首屏 JS 资源 404文件名 hash 变更但 HTML 未更新确认 HTML 不使用强缓存js 使用 contenthash回退到协商缓存策略这套表格看起来简单但每一条在真实项目里都踩过坑。面试时如果能围绕其中两三条展开讲“我遇到过的真实场景”比背概念有说服力得多。9. 面试答题框架与工程建议9.1 面试题怎么答由点到面的系统博弈如果你是准备面试遇到“如何做首屏优化”这种题不要一上来就背拆包配置。可以按照下面的思路组织回答第一步先确认目标的场景。是 C 端 H5、中后台还是 SSR 站点不同场景的优化重点不一样。第二步先谈度量。我说的首屏先用 FCP、LCP、INP、TTFB 等指标定义清楚。优化前一定先采集数据没有数据就是拍脑袋。第三步分层展开资源加载层包括代码分割、关键 CSS、图片字体、HTTP 缓存、CDN、preload/preconnect。渲染架构层提到 CSR / SSR / SSG 的选择以及 hydration、流式渲染对首屏体验的影响。可观测性层强调 RUM、CI 性能门槛、版本对比保证优化可持续。第四步给出一个“系统博弈”的结论首屏优化不是一把梭拆包而是资源加载、渲染架构、可观测性之间的平衡。比如拆包可以减少首屏 JS但拆得太碎会带来请求开销SSR 能提前渲染内容但会增加服务端压力和 TTFBpreload 能提升关键资源优先级但用多了会让所有资源都变成高优先级。这样的回答方式既展示了知识广度也展示了你作为工程师的系统判断力。9.2 团队落地建议如果你是在真实项目里做性能优化下面几条工程建议值得参考从页面维度做治理不要遍地开花第一个月只盯 Top 3 流量最高的页面。建设性能看板先有数据再定目标。建议以“P75 分位数”作为主要观察指标。制定优化清单把可执行的事项拆成清单例如“首屏图片全部转 WebP”“LCP 图片加 fetchpriority”“关键路由懒加载”“第三方库定期审查”等。控制依赖膨胀每次引入新依赖前评估体积与必要性。一个dayjs就能解决的事情不要为了“沉淀能力”引入一整套工具库。发布动作要有回滚预案SSR、边缘渲染这类架构级改造默认要支持开关和灰度。10. 结语与学习路线首屏优化这件事从表面看是“页面加载快不快”背后却是对 HTTP、浏览器渲染机制、构建工具、服务端渲染、监控体系的综合理解。2026 年前端面试的题目越来越不满足于“你会配置 SplitChunks”而是希望看到一个候选人能不能诊断出真实性能瓶颈能不能在资源加载、渲染架构、可观测性之间做出合理取舍。如果你想系统进阶下一步可以从这几个方向入手深入浏览器工作流程理解关键渲染路径、样式计算、布局、绘制、合成之间关系。熟悉 Performance API 的全部类型能自己写一个 RUM SDK。找一个中大型项目尝试用 Next.js 或同类框架做局部 SSR / 流式渲染改造记录前后数据变化。把 Lighthouse CI 接入你的项目 CI把性能回归变成一个自动化检查项。如果本文对你有帮助可以先收藏备用。动手去改一版真实页面的资源加载策略并自己采集一组前后对比数据会比再看十篇文章都管用。