前端首屏性能优化有哪些关键手段？｜阿里巴巴前端面经解析

60 秒回答模板

我会先把首屏性能拆成可度量的几个阶段：浏览器拿到 HTML、下载并解析关键资源、渲染出第一批内容、加载最大可见内容、页面变得可交互，以及用户后续输入是否卡顿。对应指标上，FCP 看首次内容绘制，LCP 更接近用户感知的首屏主体完成时间，TTI 偏实验室环境下衡量可交互时间，INP 关注真实用户交互延迟。优化上我会从减少关键路径资源开始，包括压缩 HTML、CSS、JS，移除无用代码，按路由和组件做代码分割；渲染策略上根据业务选择 SSR、SSG 或 CSR，内容型页面更适合 SSR/SSG，强交互后台可接受 CSR 但要控制首包和接口等待；资源层面使用 CDN、强缓存、协商缓存、预加载关键资源、懒加载非首屏资源；图片使用合适尺寸、现代格式和响应式加载，字体控制字重和子集化；接口层面减少串行请求、做聚合和缓存；最后必须用 Lighthouse、Performance、Web Vitals 和真实用户监控验证，避免只做骨架屏这种感知补丁而没有真实缩短 LCP 和交互阻塞。

考点 先定义首屏指标

主线 压缩关键渲染路径

易错点 只背压缩、缓存、懒加载三个词，没有说明 FCP、LCP…

深入解析

先定义首屏指标

回答这类题不能只罗列压缩、缓存、懒加载，而要先说明优化对象。FCP 是首次内容绘制，表示用户第一次看到文本、图片、背景等内容；LCP 是最大内容绘制，通常更贴近首屏主体内容是否真正出来；TTI 是页面达到稳定可交互状态的实验室指标，受长任务和主线程阻塞影响；INP 关注用户输入到页面响应的延迟，能反映真实交互卡顿。面试时要强调不同指标解决的问题不同，不能把首屏优化简单等同于白屏时间。

压缩关键渲染路径

关键渲染路径包括 HTML 解析、CSSOM 构建、JavaScript 下载和执行、布局绘制等环节。CSS 通常会阻塞渲染，首屏必需样式应尽量小，非关键样式可以延后加载；JavaScript 会阻塞解析和占用主线程，首屏脚本应拆小、延迟或异步加载。还要减少重定向、DNS 查询和 TLS 握手成本，控制首字节时间。核心思想是让浏览器尽快拿到必要内容和必要样式，而不是一开始就加载完整业务包。

控制资源体积与执行成本

资源体积优化不只是开启 gzip 或 brotli，还包括依赖治理、Tree Shaking、移除重复包、减少 polyfill、按需引入组件库和图标库。代码分割要按路由、业务模块和低频能力拆分，首屏只加载当前路径必要代码，其余能力在用户需要时再加载。同时要关注 JavaScript 执行成本，包小但初始化逻辑重也会拖慢 TTI 和 INP，因此需要减少同步计算、拆分长任务、推迟非关键初始化，必要时使用 Web Worker 承担耗时计算。

选择合适渲染策略

SSR、SSG、CSR 的取舍要结合业务场景。SSR 能让服务端返回带内容的 HTML，有利于降低白屏和改善内容型页面的 FCP、LCP，但会增加服务端压力和水合成本；SSG 适合内容稳定、可提前生成的页面，配合 CDN 可以获得很好的首屏速度；CSR 开发灵活、交互强，但首屏依赖 JavaScript 包和接口返回，容易出现空容器等待。好的回答要说明没有绝对最优，关键是用页面类型、数据实时性、访问量和交互复杂度来决策。

缓存与 CDN 加速

网络层优化要区分静态资源和动态数据。静态资源应使用内容哈希文件名，配合长时间强缓存和 CDN 分发，让用户就近获取资源；HTML 通常缓存时间较短，避免发布后拿到过期入口；接口可根据业务使用服务端缓存、边缘缓存、浏览器缓存或本地缓存。还可以对关键域名做预连接，对关键 CSS、字体、首屏图做预加载，但预加载要克制，滥用会抢占带宽，反而影响真正关键资源。

图片字体与媒体优化

图片经常是 LCP 的主要来源，优化时要控制尺寸、压缩质量、使用 WebP 或 AVIF 等现代格式，并根据设备宽度返回合适分辨率，避免移动端下载桌面大图。首屏关键图不应懒加载，非首屏图片才适合懒加载。字体方面要减少字重和字体文件数量，做中文子集化，设置合理的字体显示策略，避免长时间不可见文本或频繁布局偏移。媒体资源要避免自动加载大文件，优先加载封面和必要元数据。

数据接口与业务流程

很多首屏慢并不是静态资源慢，而是接口串行、字段过多、网关转发复杂或服务端聚合不足。优化时要梳理首屏真正需要的数据，减少非必要字段，把串行请求改为并行或后端聚合，给慢接口设置缓存和降级策略。对于用户身份、配置、推荐等依赖链较长的数据，要避免一个接口阻塞整页渲染。首屏优先展示稳定核心内容，低优先级模块可以延后请求，但延后必须有边界，不能造成页面一直跳动。

感知优化与监控闭环

骨架屏、占位、渐进渲染能改善等待感，但它们不等于真实性能优化。如果骨架屏之后主体内容仍然很晚出现，LCP 没有改善，用户只是看到了更早的占位。面试中要强调最终要用数据验证，包括实验室工具定位长任务、资源瀑布和布局抖动，也要接入真实用户监控统计 FCP、LCP、INP、错误率、接口耗时和不同网络设备下的分布。优化后应对比发布前后指标，而不是只凭主观感觉判断有效。

易错点

只背压缩、缓存、懒加载三个词，没有说明 FCP、LCP、TTI、INP 的指标口径和差异。
把骨架屏当成真正性能优化，忽略主体内容仍然很晚渲染、交互仍然卡顿的问题。
一概认为 SSR 一定比 CSR 快，没有结合水合成本、服务端压力、数据实时性和页面类型分析。
滥用预加载和懒加载，导致关键资源被延后发现，或者非关键资源抢占首屏带宽。
只关注资源下载体积，不关注 JavaScript 执行时间、长任务和主线程阻塞对交互指标的影响。
优化后没有监控和对比数据，只凭本地体验判断效果，无法证明线上用户真的变快。

面试官追问

FCP 和 LCP 有什么区别，为什么更关注 LCP？

FCP 只表示页面第一次绘制出内容，可能只是一个标题、背景色或加载文案，并不代表用户真正需要的主体内容可见。LCP 衡量视口内最大内容元素完成渲染的时间，通常更接近用户对首屏完成的感知，所以优化首屏时不能只追求很早的 FCP，还要确保主体内容尽快出现。

骨架屏算不算首屏性能优化？

骨架屏属于感知优化，可以减少用户面对空白页的焦虑，但它本身不一定缩短资源下载、接口返回或主线程执行时间。如果骨架屏之后真实内容仍然很晚出现，LCP 和可交互时间并不会改善。面试中应把骨架屏作为辅助方案，核心仍是减少关键资源和数据等待。

什么时候应该用 SSR 或 SSG 优化首屏？

当页面以内容展示为主、首屏信息明确、搜索收录或分享体验重要时，SSR 和 SSG 更有优势。SSG 适合内容变化不频繁的页面，能配合 CDN 快速返回；SSR 适合需要请求实时数据但仍希望首屏有内容的页面。若应用交互复杂且个性化强，则要评估水合成本和服务端压力。

懒加载会不会影响 LCP？

会，关键要看资源是否属于首屏主体。非首屏图片、低频组件和弹窗逻辑适合懒加载，可以减少首包体积；但如果把首屏大图或主体内容也懒加载，浏览器会更晚发现并下载它们，反而拉长 LCP。因此懒加载要基于资源优先级，而不是机械套用。

如何定位首屏慢的真正原因？

可以先用性能面板看资源瀑布、主线程长任务、LCP 元素和接口耗时，再结合真实用户监控看不同网络、设备和地区的分布。如果主要时间花在下载，就优化体积、缓存和 CDN；如果花在执行，就拆包和减少长任务；如果花在数据，就优化接口链路和缓存策略。