影响前端首屏性能的关键因素有哪些？｜字节跳动前端面经解析

60 秒回答模板

可以按关键渲染路径回答。第一是网络和服务端：DNS、TCP、TLS、TTFB、CDN、缓存命中会决定 HTML 多快回来。第二是资源加载：HTML、CSS、JS、字体、首屏图像的体积、优先级和阻塞关系会影响 FCP 与 LCP。第三是主线程执行：大型 JS bundle、框架初始化、水合、长任务、复杂样式和布局会延后可见内容。第四是数据依赖：如果首屏必须等多个接口串行返回，就会拖慢渲染。第五是运行环境：低端设备 CPU、网络波动、第三方脚本和广告统计会放大问题。优化上要做 SSR 或静态化、关键 CSS、代码分割、资源预加载、图像压缩、缓存、接口聚合和延后非关键脚本。

考点 起点速度

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

网络与 TTFB

首屏从用户导航开始，第一段时间消耗在 DNS 解析、连接建立、TLS 握手、请求排队和服务端生成 HTML 上。TTFB 过高会让后续所有前端优化都被推迟。CDN 就近分发、HTTP 缓存、服务端缓存、边缘渲染、减少重定向、启用 HTTP/2 或 HTTP/3、压缩传输和稳定后端接口，都会直接影响首屏起跑速度。

关键资源

浏览器拿到 HTML 后需要发现并加载关键 CSS、必要 JS、字体和首屏媒体资源。CSS 会阻塞渲染，过大的 CSS 文件会推迟首次内容出现；同步 JS 会阻塞 HTML 解析；首屏大图如果优先级低或体积大，会拖慢 LCP。优化要识别首屏必需资源，把非关键 CSS、非首屏组件、低优先级图像和第三方脚本延后。

主线程成本

即使资源下载很快，主线程也可能被 JavaScript 解析、编译、执行、框架初始化、虚拟 DOM diff、hydration、复杂样式计算和布局占满。移动设备上 CPU 更弱，桌面环境下看似正常的 bundle 在低端机上可能产生长任务。减少首屏 JS、拆分路由、避免重复依赖、降低组件初始化复杂度、减少同步布局读取，都是降低主线程压力的关键。

数据依赖

很多首屏慢来自数据等待：页面必须先请求配置，再请求用户信息，再请求列表，最后才渲染内容。串行接口、慢查询、过度个性化和客户端拼装都会拉长时间。可以通过服务端渲染携带首屏数据、接口聚合、并行请求、缓存公共数据、骨架屏和渐进渲染改善体验。真正关键的是区分首屏必须数据和可延后数据。

体验指标

首屏性能不能只看 load 事件。FCP 反映首次内容出现，LCP 反映最大主要内容完成，INP 反映交互响应，CLS 反映布局稳定性。一个页面可能很早显示骨架，但主要内容很晚才出现；也可能内容出现后因为字体或图像尺寸变化产生布局偏移。因此首屏优化要把可见、可读、可交互和稳定性一起考虑。

易错点

只从图像压缩解释首屏慢，忽略 TTFB、阻塞 CSS、JS 执行、接口和设备性能。
把 load 事件当作唯一首屏指标，没有区分 FCP、LCP、可交互和布局稳定性。
首屏核心资源也全部懒加载，导致 LCP 资源优先级被错误降低。
只做前端静态资源优化，不检查后端接口串行、缓存缺失和服务端渲染时机。

面试官追问

FCP 和 LCP 有什么区别？

FCP 关注页面第一次绘制出文本、图像或其他内容；LCP 关注视口内最大的主要内容元素何时完成渲染。FCP 早不代表用户看到了核心内容，LCP 更贴近首屏主体体验。

为什么首屏优化常说减少 JavaScript？

JavaScript 不只占网络体积，还需要解析、编译和执行，并可能阻塞 HTML 解析、样式计算和交互响应。移动设备上主线程预算有限，过多 JS 会明显延后可见和可交互时间。

骨架屏能提升首屏性能吗？

骨架屏主要改善感知等待和布局稳定性，不一定降低真实 LCP。如果骨架屏替代了主体内容但真实内容很晚出现，指标和用户体验仍然可能差。它应配合数据和资源优化使用。

首屏图像应该懒加载吗？

首屏核心图像通常不应该懒加载，而应压缩、使用合适格式、设置尺寸、提高加载优先级或预加载。懒加载更适合首屏之外的图像，避免和 LCP 资源抢优先级。