2026年了前端面试里“你怎么做首屏优化”的答法已经变了。以前面试官听你说“拆包、路由懒加载、gzip、CDN”就会点头现在这么回答大概率只能拿到及格分。原因是首屏优化的重心在变当工程化基础设施已经普及拆包和压缩这类操作早被脚手架默认配置掉了面试官真正想确认的是你有没有能力在资源加载、渲染架构、可观测性三个层面做系统博弈。这个判断不是拍脑袋。你看现在各厂前端面试题的高频词PerformanceObserver、渲染架构、流式渲染、hydration、Web Vitals、INP、TTI、可观测性这些词混在一起已经不是“认识一个工具”能应付的了。它们指向同一个事实首屏优化正在从“构建配置题”变成“系统设计题”。这篇文章我分四块讲清这件事为什么“无脑拆包”只能及格资源加载、渲染架构、可观测性各自考什么三者如何在真实项目里博弈以及一个从零落地的优化方案包含代码、指标采集、验证与排错。建议收藏备用。1. 这篇文章真正要解决的问题1.1 别再无脑拆包了面试里的常见误区拆包本身没有错路由懒加载也确实是优化首屏的有效手段之一。问题在于很多人把“执行某个优化动作”等同于“做首屏优化”。这两件事的差距就是初级工程师和资深工程师的分水岭。面试必考题你的项目首屏加载很慢怎么排查低分答法是这样的先拆包把第三方库单独抽出来打成 vendor。路由懒加载组件按需加载。静态资源上 CDN配 gzip。如果只答到这里面试官连环追问一来就露馅了怎么知道首屏缓慢慢在资源加载还是页面渲染拆包之后首屏真的变好了吗如果页面是纯 CSRFCP 是快了但 LCP、INP、TTI 有没有变化中间某一个环节卡住你靠什么定位这时候你会发现前面配置背得再熟也没有用因为根本没有打通“问题发现 - 定位 - 优化 - 验证”的完整链路。1.2 2026 年首屏优化考的是什么现在首屏优化是一个系统工程核心是三件事资源加载层怎么更高效地把关键资源从服务器运到浏览器。包括网络请求、缓存策略、资源优先级、CDN、HTTP 版本。渲染架构层浏览器拿到资源之后用什么架构快速绘制出用户可见的内容。包括 CSR、SSR、流式渲染、并发渲染、hydration 策略。可观测性层优化动作如何被验证、被监控、被回归。没有数据优化只是玄学。这三层不是串行关系而是互相制约的博弈关系。把资源加载做到极致但渲染架构不匹配首屏依然上不去渲染架构选了 SSR 但没做流式渲染和 hydration 优化TTI 反而受损可观测性做不好优化和回退全靠猜。2. 基础概念先把关键术语拉齐2.1 首屏优化到底在看哪些指标做性能优化和面试之前先把指标口径统一。首屏阶段最核心的指标是这几项指标全称含义关注点FPFirst Paint首次绘制白屏结束的时间FCPFirst Contentful Paint首次内容绘制用户看到第一个文字/图片的时间LCPLargest Contentful Paint最大内容绘制页面主要内容出现的时间INPInteraction to Next Paint交互到下一次绘制的延迟用户交互后界面响应速度TTITime to Interactive可交互时间页面真正能响应用户操作的时间TBTTotal Blocking Time主线程阻塞总时长长任务对交互的影响过去大家讲首屏说得多的是 FCP但 2026 年的面试趋势会更关注 LCP 和 INP。LCP 代表用户感知的“页面有没有打开”INP 代表“能不能马上用”。一个页面如果 FCP 做得很快但首屏的大图迟迟不出现LCP 会很难看如果页面渲染出来了但点击按钮半天没反应INP 会报警。2.2 拆包是什么为什么它只是手段之一拆包Code Splitting本质是改变资源的体积分配把下载从“一次性全量”变成“按需分段”。它解决的是“某个 JS 包太大导致解析与执行时间过长”的问题影响的是传输体积和脚本执行时间。但拆包不解决下面这些问题服务器响应慢TTFB 高。关键 CSS 没有内联或被延迟加载。渲染架构选错CSR 在低端机上白屏时间长。图片超大且没有预加载LCP 上不去。优化完没有监控下次重构直接把性能搞退化。所以拆包是“资源加载层”里的一个子手段。认识到这一点后面讲系统博弈才立得住。2.3 资源加载、渲染架构、可观测性分别指什么这是理解 2026 年面试题的底层框架也是本文后续所有内容的骨架。资源加载从 HTTP 请求发起到浏览器拿到 JS/CSS/图片的关键链路优化。涉及协商缓存、CDN、preload/preconnect、HTTP/2/3、压缩、DNS 预解析、请求优先级等。一句话总结让关键资源更快到达浏览器。渲染架构页面用客户端渲染还是服务端渲染是否流式渲染是否并发渲染hydration 怎么做不同框架下服务端能力差异边缘运行时如何选型。一句话总结让浏览器拿到资源后更快画出内容。可观测性知道真实用户在什么条件下页面有多慢慢在哪个阶段优化后有没有提升。涉及 RUM真实用户监控、PerformanceObserver、错误监控、日志链路、归因分析。一句话总结让每一次优化都有数据可依。层级核心问题常用手段资源加载资源多久能到浏览器拆包、压缩、CDN、缓存、preload、HTTP 优化渲染架构浏览器多久能画出页面SSR、流式渲染、岛屿架构、部分 hydration可观测性怎么证明快/慢、如何归因Web Vitals、PerformanceObserver、RUM、告警3. 面试的第一道大题资源加载3.1 资源加载优化真正要解决的问题资源加载要回答的问题不是“把所有包都拆开”而是“在正确的时间、用正确的优先级、尽可能少地传输关键资源”。判断一个人是真懂还是背配置可以用下面这几个小问题首屏需要的关键 JS/CSS 是否被最优先加载非关键资源是否被延迟或变成异步静态资源是否充分利用了浏览器缓存给 CDN 的资源有没有配置合理的 Cache-Control在弱网环境下资源加载策略是否依然可靠真正做过性能优化的人对这些问题的回答不会只停留在“用 preload ”或“上 CDN”而是会给出前置条件、验证方式和回退方案。3.2 面试题首屏白屏时间太长你在网络层面怎么优化一个比较规范的排查链路是这样的打开 DevTools Network 面板先看每个请求的耗时找出体积最大的脚本和图片。打开 Performance 面板分析关键渲染路径看哪个阶段阻塞最久。用 WebPageTest 或 Lighthouse 对页面做一次扫描获取 FCP、LCP、TTI 的基线数据。根据资源类型分头处理大体积 JS代码拆包、按需加载、减少 polyfill。大图片转 WebP/AVIF、响应式图片、关键图片 preload。CSS内联首屏关键 CSS非关键 CSS 异步加载。请求链路开 CDN、配协商缓存、开启 HTTP/2。优化后再跑一次相同工具对比指标变化确认没有副作用。如果面试只答到“拆包、CDN、压缩”就停了说明缺少排查链路意识。3.3 关键代码基于 PerformanceObserver 采集资源加载指标资源加载阶段最容易出现“凭感觉优化”的问题。有经验的工程师会先把资源的真实加载耗时采集上来再看哪类资源是瓶颈。下面是一个用 PerformanceObserver 采集脚本和样式表加载耗时的最小示例。// file: performance-resource-observer.js const observer new PerformanceObserver((list) { const entries list.getEntries(); for (const entry of entries) { if (entry.initiatorType ! script entry.initiatorType ! css) { continue; } const metric { name: entry.name, initiatorType: entry.initiatorType, duration: entry.duration, transferSize: entry.transferSize, decodedBodySize: entry.decodedBodySize, renderTime: entry.renderTime || null, }; // 通过 sendBeacon 上报避免影响页面卸载 navigator.sendBeacon(/api/perf/resource, JSON.stringify(metric)); } }); observer.observe({ type: resource, buffered: true });注意事项buffered: true表示可以获取页面加载早期已经发生的资源条目。上报建议用navigator.sendBeacon不要在性能埋点里使用 fetch否则会引入网路噪音甚至可能因为页面卸载导致请求中断。采集周期不要太长建议在页面 load 之后延迟几秒再停止采集避免把懒加载资源全部计入首屏统计。3.4 资源加载层容易踩的坑很多人一听到优化就开干结果踩了一堆坑。下面这几个非常典型拆包拆太细导致请求碎片化。拆出几十个小 chunkHTTP/2 开启后多路复用能缓解连接数问题但每一个小文件都有请求头开销和文件查找性能损耗。只拆 vendor 不分业务 chunk。把所有第三方库合到一个 vendor 里确实减少了请求数量但用户访问一个页面也要把整个 vendor 下载并解析完搬到手机弱网场景更明显。图片全部懒加载反而伤了 LCP。首屏主视觉图如果加了loadinglazy浏览器可能推迟加载它最后 LCP 直接变红。首屏关键图片不该懒加载。preload 滥用导致带宽争抢。把十几个资源全部 preload等于主动抢占了关键资源的带宽可能让 LCP 更慢。4. 面试的第二道大题渲染架构4.1 为什么资源加载优化到极限后瓶颈会转移到渲染架构当一个项目的 JS 总包体已经压到不能更小了还有没有首屏空间有答案在渲染架构上。传统 CSR 的应用在浏览器端要做三件事下载 JS、解析执行 JS、生成 DOM 绘制页面。在低端 Android 设备上JS 解析执行时间可能超过 1 秒。这意味着 FCP 被 JS 执行硬生生拖慢任凭你怎么压缩体积都会有天花板。这时候要破局只能换架构。4.2 面试题CSR 项目首屏太慢从架构上你会怎么优化低分答法“上 SSR。”高分答法先判断业务场景再选择具体架构方案。正确思路是这样的先看页面是什么类型。如果是复杂强交互后台全量 SSR 收益有限反而增加了服务器成本和复杂度。如果内容型页面占比高SSR 或 SSG 可以有效提升 FCP 和 LCP。如果决定上 SSR不能只做传统 SSR还要考虑流式渲染、异步组件加载和 hydration 开销。React 18/19 可以用renderToPipeableStream做流式渲染Vue 也有类似的服务端渲染方案。4.3 一个核心示例React 流式渲染传统 SSR 会把整个组件树渲染完成后再一次性返回 HTML 字符串导致 TTFB 很高。流式渲染的思路是让服务器一边渲染一边把已经完成的 HTML 片段推给浏览器。用户可能几毫秒内先看到页面的 header然后再陆续看到正文。// file: server/index.tsx import express from express; import { renderToPipeableStream } from react-dom/server; import App from ../src/App; const app express(); app.get(/, (req, res) { res.setHeader(Content-Type, text/html); const { pipe } renderToPipeableStream(App /, { bootstrapScripts: [/static/client.js], onShellReady() { res.write(!DOCTYPE html html head title流式渲染示例/title /head body div idroot); pipe(res); res.write(/div /body /html); res.end(); }, onError(err) { console.error(err); }, }); }); app.listen(3000);这段代码的价值在于onShellReady一旦触发就表示应用外壳已经准备好服务器就可以开始向浏览器推送 HTML而不是等整棵组件树都渲染完。用户可以更快看到内容对应的是 FCP 和 LCP 的改善。4.4 hydration 的代价与并发渲染SSR 只是服务端返回了 HTML 字符串浏览器要让它“活”起来还得执行 JS、绑定事件这个阶段叫 hydration。hydration 也有代价。服务端返回 HTML 后浏览器还要下载并执行客户端 JS如果 hydration 过程中有大量组件需要绑定事件TTI 和 INP 就会变差。甚至会出现“页面已经能看到了但点击按钮没有反应”的现象这对应 INP 指标的劣化。所以面试回答渲染架构时提到下面几个概念会明显加分部分 hydration只对需要交互的组件做 hydration其余组件保持静态 HTML。岛屿架构在静态页面上嵌入多个可交互的“岛屿”组件分别 hydration减少整体激活成本。减少 hydration 范围某些低交互组件不需要客户端事件绑定可以跳过。从材料看很多团队并不会全量上 SSR而是选择“静态页面 局部交互岛屿”的混合架构配合边缘运行时做部署成本和性能都不错。5. 面试的第三道大题可观测性5.1 没有数据优化只是玄学面试里问可观测性并不要求每个人都去搭一套监控平台。面试官想看的是你有没有“用数据驱动性能优化”的意识以及能不能说出从数据到结论的完整链路。真正的性能优化流程应该是先采集现状指标。定位瓶颈在加载、渲染还是交互。做对应优化。优化后再采集数据对比验证。设置告警防止性能退化。如果只优化不埋点下次业务迭代直接把性能搞坏你根本不知道。5.2 面试题怎么在真实用户环境采集性能指标市面上有 web-vitals 这个库封装了 Web Vitals 指标采集使用很方便。下面是真实项目的采集示例。// file: collect-vitals.js import { onFCP, onLCP, onINP, onCLS } from web-vitals; // 采样 10%避免把全量用户数据打给后端 const sampleRate 0.1; if (Math.random() sampleRate) { return; } function report(metric) { const body JSON.stringify({ metricName: metric.name, value: metric.value, rating: metric.rating, navigationType: metric.navigationType, userAgent: navigator.userAgent, pagePath: location.pathname, sessionId: getSessionId(), }); if (navigator.sendBeacon) { navigator.sendBeacon(/api/vitals, body); } else { fetch(/api/vitals, { method: POST, body, keepalive: true, }); } } onFCP(report); onLCP(report); onINP(report); onCLS(report); function getSessionId() { let id sessionStorage.getItem(session_id); if (!id) { id ${Date.now()}-${Math.random().toString(16).slice(2)}; sessionStorage.setItem(session_id, id); } return id; }关键点采样上报。全量上报会在高流量页面造成大量无效请求。带上sessionId和pagePath方便按会话和页面维度归因。用sendBeacon避免页面卸载时请求丢失。记录ratinggood/needs-improvement/poor后续可以直接统计通过率。5.3 从指标倒推问题指标不是用来展示的是用来定位的。下面这张表是性能排查的常用思路。指标异常可能原因优先检查TTFB 高服务器处理慢、CDN 未命中后端日志、缓存命中率FCP 正常但 LCP 高首屏大图加载慢、图片未 preload资源加载瀑布图TTI 很高hydration 过重、脚本执行阻塞主线程长任务分布INP 差事件处理函数执行慢、渲染频繁被阻塞长任务与事件处理回调CLS 波动图片未占位、字体加载抖动布局变化详情这套从指标到原因的映射面试官一定会喜欢因为这说明你没有停留在“定义指标”层面而是能真正用指标指导优化。6. 资源加载、渲染架构、可观测性的系统博弈6.1 三层优化不是串行关系前面分别讲了三个层级现在回到核心判断首屏优化是这三层之间的系统博弈。举几个真实场景场景一SSR 上得过度TTI 变差了。团队为提升 FCP 全量上 SSR结果服务端渲染返回的 HTML 很大浏览器解析完 HTML 还要再下载执行一套完整客户端 JS主线程被大量长任务占满。FCP 变好了TTI 和 INP 反而崩了。这其实是资源加载与渲染架构之间的博弈服务端 HTML 增加了传输体积客户端 hydration 增加了主线程压力。场景二资源加载优化做到了极致但弱网用户的首屏还是慢。团队把 JS 拆得很细、压缩比例也调到了极限但用户的设备是老手机JS 执行时间仍然很长。拆包只是让 JS 下载更快并没有减少 JS 的执行总量。这时候非改渲染架构不可比如把重交互页面改成服务端渲染或增加预渲染。场景三优化上线了一周数据看不出来有没有效果。团队做了很多优化动作但没有在可观测性上建立基线。上线后不知道哪些指标变好了哪些变差了甚至连 regress 了都不知道。这时候不是优化做得不够而是可观测性建设拖了后腿。6.2 真正的资深工程师会用数据做取舍面试官在追问“你会怎么做首屏优化”时不仅想听技术选型还想听你做决策的方法。好的回答一定会包含数据驱动和取舍判断。举个例子如果业务方要求首屏再快 200ms而当前资源加载层已经没有明显水分作为前端工程师你该怎么回应不会答的人继续压 JS继续拆包拆到不能再拆。会答的人先去采集数据定位这 200ms 发生在哪一阶段然后判断如果 TTFB 高那是后端和网络层的问题需要和后端协作设置缓存策略。如果 LCP 元素加载慢那是资源加载层的问题可以 preload 关键图片。如果 TTI 高可能是 hydration 太大需要做部分 hydration 或减少客户端组件激活范围。如果以上都不明显可能就是性能预算已经到极限应该向产品说明情况避免无意义的内耗。所以真正的系统博弈不只是技术方案之间的取舍也是和产品、和后端、和运维团队数据对齐。7. 从零落地一个首屏优化方案这一章我以一个典型中后台前端项目为例走一遍从建立基线到优化上线的完整流程。技术栈不限关键是链路完整。7.1 环境准备与前提说明前端框架React 或 Vue 均可示例使用 React。构建工具Vite。部署环境支持静态资源服务并能配置 CDN 和缓存策略。目标浏览器Chrome 最新两个版本为主。版本细节请以实际项目为准本文重点演示通用思路。7.2 步骤一先埋点收集现状不要着急优化没有基线数据之前任何优化都是盲目的。第一个动作是在入口文件注册 Web Vitals 采集至少运行一天收集线上用户的数据分布。// file: src/index.jsx import React from react; import ReactDOM from react-dom/client; import App from ./App; import { initVitalsReport } from ./telemetry/vitals; // 初始化性能上报 initVitalsReport(); const root ReactDOM.createRoot(document.getElementById(root)); root.render(App /);收集到的数据至少要覆盖 FCP、LCP、TTI、INP、CLS 五项并按页面路径和用户设备维度拆分。没有后端存储能力的话可以先输出到控制台在测试环境用模拟数据跑通流程。7.3 步骤二分析构建产物调整资源加载策略然后对构建产物做体积分析找出哪些 chunk 是首屏路径上的瓶颈。npm run buildVite 默认会输出构建报告也可以用rollup-plugin-visualizer看到依赖体积分布。核心动作把超过 200KB 的依赖单独拆出。按路由切分业务代码确保首屏只加载当前页面需要的 JS。对首屏关键图片做 preload。对非关键脚本使用async或defer加载。一个典型的 Vite 分包配置示例// file: vite.config.js import { defineConfig } from vite; import react from vitejs/plugin-react; import { visualizer } from rollup-plugin-visualizer; export default defineConfig({ plugins: [react(), visualizer({ open: true })], build: { rollupOptions: { output: { manualChunks: { react: [react, react-dom], router: [react-router-dom], utils: [lodash-es, dayjs], }, }, }, }, });注意这个分包结果是业务调研后的结果不是无脑拆分。react单独拆是因为几乎每个页面都会用到utils拆是因为体积占比可观但更新频率低适合长缓存。7.4 步骤三评估当前渲染架构决定是否 SSR 化资源加载优化做完之后如果首屏还是慢就要评估渲染架构。优先检查页面是内容型文章、商品详情还是强交互型控制台。服务器有没有能力跑 Node 服务。团队是否能接受 SSR 引入的运维复杂度。对内容型静态页面先考虑预渲染不一定要上完整 SSR。Vite 生态下可以用vite-plugin-prerender之类的插件对路由做预渲染。// file: vite.config.js import { defineConfig } from vite; import { vitePrerender } from vite-plugin-prerender; export default defineConfig({ plugins: [ vitePrerender({ staticDir: dist, routes: [/, /about, /blog/2026-frontend-performance], }), ], });预渲染的收益是构建时生成完整 HTML用户拿到手就是有内容的页面FCP 和 LCP 天然比 CSR 快而且不需要额外服务器成本。缺点是内容需要静态化不适合高度个性化页面。7.5 步骤四上线可观测性与告警这一步很多人忽略。优化上线不是终点可观测性才是闭环。建议至少做到Web Vitals 指标按采样采集存到日志服务。设置阈值告警LCP 4s 的比例超过 15% 时告警。监控优化前后同一个分位的指标变化例如 P75、P90。一个简单的告警判定函数// file: telemetry/threshold-alert.js const THRESHOLDS { LCP: { poor: 4000, needsImprovement: 2500 }, INP: { poor: 500, needsImprovement: 200 }, CLS: { poor: 0.25, needsImprovement: 0.1 }, }; export function evaluateMetric(name, value) { const config THRESHOLDS[name]; if (!config) { return unknown; } if (value config.poor) { return poor; } if (value config.needsImprovement) { return needs-improvement; } return good; }这里的阈值来自 Web Vitals 的通用建议生产环境可以按业务调整。7.6 步骤五效果验证与性能报告优化完不能直接说“应该快了”要验证。验证手段用 Lighthouse 对优化前和优化后的构建产物分别打分。用 WebPageTest 模拟 4G 网络和低端设备。在 DevTools Performance 面板录制一段首屏加载查看主线程长任务分布。收集线上 RUM 数据对比优化前后同一分位的 LCP、TTI、INP。一份合格的性能报告应该包含基线数据、优化动作清单、优化后数据、结论和后续建议。8. 常见问题与排查方法下面这张表覆盖了首屏优化最常见的故障场景按排查顺序整理。问题现象可能原因排查方式解决方案TTFB 很高服务器处理慢、CDN 未生效查看网络瀑布图和后端日志开启 CDN、配置边缘缓存FCP 慢但 LCP 正常关键 CSS 未被尽早加载看 CSS 是否被 JS 异步注入内联关键 CSS降低 CSS 阻塞FCP 正常但 LCP 很高首屏大图加载慢看 LCP 元素的加载瀑布图给图片加 preload压缩为 WebP页面出现时间早但点击没反应hydration 太重看主线程长任务和 JS 执行时长做部分 hydration减小激活范围INP 差事件处理回调阻塞主线程用 PerformanceObserver 查长任务拆解长任务、避免同步高开销逻辑优化后反而变慢CDN 缓存策略错误检查缓存命中率配置合理 Cache-Control上报请求太多没有采样或埋点项太多查看服务端日志增加采样率、合并上报字段排错第一原则是先看数据再猜原因。不要一上来就改代码。9. 最佳实践与工程师能力进阶9.1 分层建立性能基线每个项目应该有专属的性能基线FCP、LCP、TTI、INP、CLS 各是多少P50 和 P90 分位分别是多少不同设备档位差多少。基线数据建议放在项目的 README 或性能面板中让团队每次版本发布都能拿新数据做对比。9.2 优化必须可回滚性能优化和业务代码一样可能出现副作用。上线前确认能回滚的开关比如用配置开关切换新的渲染模式用灰度流量观察数据确认无性能退化再全量放开。9.3 关注新标准和工具链变化2026 年前端性能优化的演进方向有几个INP 全面替换 FID。INP 衡量的是用户所有交互中体验最差的延迟比 FID 只关注首次输入更严格。BFCache 的利用。浏览器后退前进时可以直接从缓存恢复页面对性能体验提升巨大。边缘渲染。把渲染逻辑推近用户减少网络传输距离。AI 辅助性能分析。部分性能监控平台已经可以自动分析长任务和资源瀑布图帮助定位瓶颈。9.4 进阶学习路径如果你想把首屏优化真正吃透建议按照下面的顺序学习打包原理Webpack/Rollup 的代码分割和 tree-shaking 原理。浏览器渲染机制关键渲染路径、HTML/CSS/JS 执行顺序。服务端渲染React 流式渲染、Vue SSR、边缘渲染。性能监控体系Web Vitals、PerformanceObserver、Sentry 等工具落地。工程化实践性能预算、CI 性能检查、灰度兜底。这个路径从一个“会用工具的前端”逐渐变成一个“能从数据发现瓶颈、从架构解决瓶颈、从体系防止回归”的前端工程师。面试里再遇到“你怎么做首屏优化”时不要再张口就是拆分和压缩。先谈谈你会如何采集指标、定位瓶颈再谈资源加载、渲染架构、可观测性的具体选型。这套打法的信息密度和工程判断力远高于单纯背一个拆包配置。最后提醒一句任何优化动作上线前先确认自己有撤回方案。首屏优化没有银弹只有拿数据说话的系统博弈。