如果你看到这篇文章,大概率是遇上了差不多的场景:页面一打开,白屏两三秒,用户等得着急,自己也跟着焦虑。我前两年接手过一个管理后台项目,首屏加载时间稳定在3秒开外,模块切换还经常卡顿,后来花了两周时间把首屏压到了800毫秒以内,核心过程其实就是几个常规手段的组合拳,没有银弹,但每一步都有章可循。这篇内容就围绕首屏加载到底慢在哪、怎么量、怎么改、怎么守住这条线来写,适合正在做前端性能优化的同学,也适合准备性能优化相关面试题的朋友参考。1. 先把首屏加载这件事拆清楚1.1 首屏加载到底在优化什么指标很多人一谈首屏优化就甩出一堆减少请求压缩体积的结论,但真到动手时,连观测对象都没定清楚。首屏优化的第一步不是优化,而是把指标量化。业内常用的几个核心指标包括:FCP(First Contentful Paint,首次内容绘制)、LCP(Largest Contentful Paint,最大内容绘制)、TTI(Time to Interactive,可交互时间)、FID(First Input Delay,首次输入延迟)。这几个指标对应的是不同阶段的体验问题。FCP关注的是白屏结束、第一个可见内容出现的时间;LCP关注的是页面最大元素(通常是首屏主图、标题栏、核心内容块)渲染出来的时间;TTI关注的是用户能正常点击操作的时间。举个实际例子,一个后台列表页如果接口在2秒后返回,表格骨架屏早就渲染出来了,但表格数据到2秒才出现,那么FCP可能是500毫秒,而LCP就是2秒——用户感知的是页面半天不出数据,优化方向就该对准数据请求链路,而不是静态资源体积。1.2 为什么首屏速度决定产品口碑首屏加载时间直接影响用户的耐心阈值。移动端用户普遍期望页面在3秒内加载完成,超过3秒,流失率会明显上升。这不是玄学,各大平台的性能分析数据都指向这个规律。对一个内容型或有交易属性的产品来说,首屏慢一天,对应的就是转化率的持续折损。我自己更关注的是另一个维度:性能问题会累积口碑。用户不会因为你某个版本优化了200毫秒而夸你,但会因为持续的白屏和卡顿而投诉你。性能指标是产品体验的基础水位,水位低了,其他功能做得再好都容易被掩盖。这也是为什么现在前端团队都会把性能指标纳入CI检查,而不是等上线后靠用户反馈发现问题。1.3 动手前先完成性能基线测量没有基线数据就不要做优化,这是铁律。我每次接手性能优化任务,第一件事就是花半天时间把当前项目的各项指标完整测一遍,并记录下来。用到的工具主要有三类:浏览器DevTools的Performance面板:可以录制页面加载全过程,查看主线程的耗时分布、网络请求时间线、渲染阻塞情况,适合定位具体瓶颈。LightHouse:给出综合评分、核心性能指标数值,以及一堆优化建议,适合做宏观判断和优化前后的对比。Web Vitals库或PerformanceObserver API:在代码环境里直接采集RUM(Real User Monitoring)数据,了解真实用户场景下的性能分布。我通常的做法是:先用LightHouse跑一轮,记录FCP、LCP、TTI、TBT(Total Blocking Time)等数值;再打开Network面板,刷新几次,看首屏资源的数量、体积、加载瀑布图,重点关注那些耗时异常高的请求;最后用Performance面板录制一次完整的加载流程,找到主线程上的长任务(Long Task),为后续优化提供方向。注意:测量时环境要尽量统一,建议用无痕窗口、禁用浏览器缓存、用网路模拟(比如DevTools里的Fast 3G或Slow 4G)来测,这样数据才具备可对比性。本地开发环境因为走了dev server,数据参考意义不大,一般用线上预览环境或打包后的静态文件来测。2. 构建阶段的优化:在源头控制体积2.1 路由级代码分割与组件懒加载首屏加载最直观的问题往往是首屏请求的JS体积过大。一个单页应用如果把所有路由页面的代码都打包进一个bundle,哪怕只想看一个登录页,用户也得下载整个应用的全部代码。解决思路就是把一次性加载所有代码改成只加载当前页面需要的代码。React下用React.lazy结合Suspense,Vue下用defineAsyncComponent,都是经典做法。以Vue 3为例:import { defineAsyncComponent } from vue const UserDashboard defineAsyncComponent(() import(/views/dashboard/index.vue))这样配置后,UserDashboard组件只会在路由命中时才通过网络加载对应的chunk,而不在首屏bundle内。需要注意的是,懒加载组件的粒度不要拆得过细。一个折中的原则是:以路由页面为基本单位做懒加载,是对收益和复杂度最平衡的方案;如果把页面内的单个子组件也全部拆出去,请求数暴增,加载速度反而可能变慢。2.2 第三方依赖的体积控制第三方库往往是打包体积的大头。一个典型例子是日期处理库:Moment.js体积接近70KB(gzip后约20KB左右),而Day.js只有2KB左右,API设计却非常接近。如果项目里只是做简单的日期格式化、加减运算,换成Day.js几乎零成本。另一个常见的体积陷阱是Lodash——如果只用到debounce、throttle、cloneDeep这几个函数,完全可以用对应的独立包lodash/debounce、lodash/cloneDeep,或者直接手写,没必要把整个Lodash引入主包。我还见过更隐蔽的问题:组件库按需加载没配好。以Element Plus为例:import { ElButton, ElTable } from element-plus配合unplugin-vue-components和unplugin-auto-import这两个Vite插件,组件和API都能实现按需自动导入,最终打包体积能明显缩小。很多项目的构建体积问题并不是代码多,而是把用不上的组件、工具函数一起打包了。2.3 Tree Shaking与sideEffects的正确配置Tree Shaking依赖ES Module的静态结构,打包器在生产环境构建时把没有被引用的导出剔除掉。但要真正生效,有一个经常被忽略的配置项:sideEffects。如果package.json里没有这个字段或配置错误,打包器可能保留那些看起来没用但可能有副作用的模块。一个典型的场景:项目里引入了某个CSS重置库或全局样式文件,如果配置了sideEffects: false,打包器可能把CSS文件一并摇掉。正确做法是:{ sideEffects: [**/*.css, **/*.scss, **/*.vue] }这样告诉打包器:除了CSS、SCSS、Vue组件这类文件,其他的纯ES模块都可以放心摇树。实际排查时,我习惯在构建完成后查看打包分析报告(webpack-bundle-analyzer或rollup-plugin-visualizer),能直观看到每个chunk的体积占比,快速定位谁占了大头。2.4 图片资源的压缩与格式选择首屏上的图片对LCP影响很大。很多项目里的图片是设计稿直接导出的PNG,一张几MB的落地页banner图能让LCP直接飙到2秒以上。常规处理方式有几步:压缩:用sharp或在线工具(如TinyPNG)s把PNG/JPG压缩一遍,肉眼几乎无差异的情况下体积能减少50%以上。换格式:首屏的装饰性大图,优先考虑WebP。同等画质下,WebP比JPEG体积小30%左右。现在现代浏览器对WebP的兼容性已经完全够用,如果你还需要兼容老浏览器,可以用picture标签多提供一版兼容格式,让浏览器自行选择。响应式尺寸:不要在移动端加载一张1920px宽的大图。用srcset配合sizes属性,让不同屏幕宽度加载不同分辨率的图片:img srcbanner-800.png srcsetbanner-800.png 800w, banner-1600.png 1600w sizes(max-width: 768px) 100vw, 1600px altbanner /关键图片预加载:如果首屏的LCP元素是一张图片,考虑用link relpreload asimage href...提前加载它,而不是等CSS解析完才发起图片请求。从构建源头控制,相当于在发车之前就减重,后面网络层的优化才能事半功倍。3. 网络传输层的优化:让资源在最少时间内到达3.1 HTTP缓存策略的合理配置构建阶段把包变小了,接下来就要保证用户第二次访问时不再重复下载这些静态资源。HTTP缓存的首选方案是强缓存 文件名哈希组合。带哈希值的静态资源(如app.a1b2c3.js)适合设置长时间Cache-Control: max-age31536000, immutable,因为只要文件名没变,内容一定没变,浏览器直接用本地缓存即可,不会再发请求。而入口HTML文件则适合设置no-cache或max-age0,保证用户每次访问时都去服务器拿最新的HTML,再根据HTML里引用的新哈希文件名去拉新资源。实际操作中,还遇到过缓存配置反了的情况:静态资源配置了很短的缓存时间,结果每次访问都要重新下载;HTML反而被配置了很长时间,导致用户永远拿到旧的HTML,新发布的功能一直不生效,最后只能靠强制刷新解决。这种问题表面上看是用户浏览器缓存了,根上还是配置不规范。3.2 CDN与边缘加速静态资源部署到CDN,是网络层优化里性价比最高的一步。CDN的本质是让资源从离用户最近的边缘节点返回,减少网络链路时间。国内常用的CDN服务商各有不同,但配置思路大同小异:把构建产物同步到CDN的源站,开启CDN加速域名,静态资源地址统一指向CDN域名。有一个细节值得注意:CDN和主站域名要区分开,原因有二。第一,避免CDN域名携带主站的Cookie,减少无意义的Cookie头传输体积;第二,并行下载时,不同域名可以让浏览器突破同一域名下的连接数限制。如果项目里有静态资源跨域需求,记得给CDN域名配置正确的CORS头,否则字体文件、Canvas图片等可能加载失败。3.3 Preload、Prefetch、Preconnect的使用时机这三个Link标签是网络层优化容易被忽略的利器,但用错地方反而适得其反。link relpreload asscript hrefxxx.js:告诉浏览器这个资源是当前页面必需的,应该尽早下载。适合首屏关键资源,比如入口JS、关键CSS、LCP图片。注意不要一股脑preload所有资源,否则浏览器在解析初期就被塞满了下载任务,反而延误真正关键的请求。link relprefetch hrefyyy.js:预取的是未来可能用到的资源,比如用户下一步可能点开的路由页chunk,在浏览器空闲时提前获取。适合非首屏但在页面流转中会用到的资源。link relpreconnect hrefhttps://api.example.com:提前建立源站的连接,包括DNS解析、TCP握手、TLS握手,等真正发出API请求时,可以省去这几百毫秒的握手时间。适合首屏即有请求的后端API域名、CDN域名、字体文件域名等。我用过一个原则:当前页面要用的资源用preload,下一步可能要跳转的资源用prefetch,确定要发起跨域请求的第三方源用preconnect。优先级从高到低排列,避免滥用。3.4 Service Worker缓存与离线兜底Service Worker是另一个层面的缓存能力,它像一个代理层,在浏览器和网络之间拦截请求。首屏优化的场景里,Service Worker主要做两件事:静态资源预缓存:页面首次访问时,安装Service Worker并预缓存当前版本的静态资源列表。之后用户再次访问时,资源直接从Service Worker的Cache Storage返回,几乎零延迟。这与HTTP缓存策略互补——HTTP缓存是浏览器层面的,SW缓存是应用层面的,可控性更高。运行时缓存:对某些请求(如字体、图片)在第一次成功后放入缓存,后续请求直接命中。接入Service Worker也同样有复杂度上的代价:缓存策略要设计合理,否则更新发布后用户可能一直命中旧缓存,怎么刷新都没用。我的建议是,静态资源用缓存优先策略,并配合版本号管理;API请求用网络优先,失败回退缓存策略。发布新版本时,通过更新sw.js的内容触发Service Worker更新,并在控制权交接时主动清理旧缓存。4. 运行时渲染优化:让用户尽快看到内容和可交互4.1 骨架屏与加载占位体验网络和构建层面的优化缩短的是资源到达的时间,但即使资源到了,数据接口如果慢,页面该空还是空。骨架屏解决的是等待期间用户看到什么的问题。用一个与最终内容结构近似的灰色占位块,让用户感觉页面正在加载而不是白屏。骨架屏可以选择在服务端渲染时直接输出HTML(把骨架图带在HTML里),也可以在前端挂载时渲染。前者成本高一些,但首屏效果最好;后者简单,对既有项目侵入小。以Vue 3为例,最简单的方式是在Suspense的fallback插槽里放骨架屏:template Suspense DashboardPanel / template #fallback DashboardSkeleton / /template /Suspense /template骨架屏的粒度要尽量贴近真实内容结构,宽度高度模拟最终形态,而不是一个统一的灰色方块。这样用户等待时的焦虑感能被明显缓解。注意骨架屏本身不要引入额外的大依赖,如果项目里有现成的类似组件库就复用,没有的话,一个简单的CSS动画占位块完全够用,不要为了骨架屏引入一个重型插件。4.2 关键CSS内联与样式加载优化CSS是渲染阻塞资源。浏览器默认情况下,遇到外部CSS文件会先下载并解析完才能渲染页面,CSS文件越大,首屏被阻塞的时间越长。常规的优化手段是把首屏真正需要的核心CSS内联到HTML里,其余CSS异步加载。Vite内置的vite-plugin-critical或Webpack的html-critical-webpack-plugin都能实现这个逻辑:分析首屏DOM结构,提取出关键CSS规则,内联到HTML的style标签,其余样式以异步方式加载。我在一个门户型项目里用过这个方案,FCP大概能快300~400毫秒,效果非常直观。内联CSS的做法也有风险:如果内联的CSS体积过大(超过几十KB),反而拖慢HTML本身的解析时间。所以内联策略通常只针对首屏的上面一屏内容,往下滚动区域的内容样式还是应该放在外链CSS里。4.3 减少主线程长任务,优化JS执行时机即使所有资源都快速加载完成,如果JS执行时阻塞了主线程,页面依然无法交互。这个过程里最典型的问题就是首屏JS执行时间过长。从Performance面板里能清楚看到一个个红色的Long Task(超过50ms的任务),这些任务阻塞了渲染。常见改善手段有几类:把非关键的JS推迟执行:用defer属性加载非关键脚本,让它们在DOM解析完成后执行;或者用setTimeout、requestIdleCallback把非必要的初始化任务调度到空闲时段。注意requestIdleCallback的兼容性,现在Safari也支持了,但使用前还是建议做一下降级判断。拆分长任务:如果一个同步函数耗时超过200ms,考虑分成多个小任务,用setTimeout或MessageChannel配合requestIdleCallback来分片处理,避免一次性阻塞主线程。Web Worker处理纯计算任务:比如大文件上传时的文件哈希计算、复杂数据处理逻辑、大数据表格的格式化等,这些不依赖DOM的计算任务可以全部丢到Worker线程。前端热词里经常提到的前端使用worker上传大文件,实际上就是这个逻辑的典型应用。worker把计算从主线程剥离后,页面的流畅度提升非常明显。我在优化一个数字大屏项目时,把ECharts图表的初始化逻辑做了延迟调度:首屏先渲染核心业务指标图,其他的图表等主线程空闲后再逐个初始化。这样一来LCP不变的情况下,TTI快了将近500ms。4.4 图片懒加载与资源时序控制首屏以外的图片,特别是长列表场景里的图片,应该统一使用懒加载。原生loadinglazy属性已经足够解决大部分场景:img srcexample.png loadinglazy altexample /不过loadinglazy有一个需要注意的点:它只对滚动视口附近的图片做延迟加载,对首屏位置的图片不会生效。如果首屏本身有大量图片,懒加载帮不了忙,还是要配合构建阶段的图片压缩和预加载策略。另外,在列表虚拟滚动的场景里,懒加载属性通常已经不够用,更合理的方案是配合IntersectionObserver,在元素真正进入视口时才设置src,组件内自己做图片资源的调度。5. 性能监控与长期守住基线5.1 用错误的形式上线性能监控:Web Vitals性能优化不是一次性的项目,改完上线就完事了。代码持续迭代的过程中,一个不经意的依赖引入就可能让体积反弹。所以上线后必须建立监控机制,用真实用户数据来评估优化效果。推荐的监控组合是web-vitals库采集指标 定时上报到监控平台。以web-vitals为例:import { onLCP, onINP, onCLS } from web-vitals onLCP((metric) { // 上报指标值、页面路径、设备信息等 fetch(/api/metrics, { method: POST, body: JSON.stringify(metric) }) })上报的数据最好包含:指标名、指标值、页面路由、设备类型、浏览器版本、网络类型等维度,这样后续分析时能区分是慢在网络还是慢在设备还是慢在特定页面。5.2 在CI阶段设置性能回归门槛比线上监控更前置的手段是在CI流程里加入性能预算。我用过的方式是Lighthouse CI:在项目的CI配置里引入lighthouse-ci,每次拉取代码后对构建产物跑一轮Lighthouse。在配置里设置阈值,比如LCP不大于1.5秒、TBT不大于100ms、CLS不大于0.05。一旦某个PR让指标超过阈值,CI直接标记失败,让开发同学在合并前就意识到性能问题。这样做的价值在于,把性能从事后补救变成了事前拦截。就算优化做不到完美,至少能阻止性能继续劣化。5.3 常见问题排查速查表我整理了最近几年在性能优化实战里踩过和见别人踩过的坑,整理成表格,方便大家对照排查:问题现象可能原因排查手段解决方向首屏FCP很慢,资源体积不大关键CSS被外链阻塞LightHouse看render-blocking资源内联关键CSS,异步加载其余样式LCP一直上不去,但FCP还行首屏最大元素渲染太晚Performance面板看LCP元素出现在时间轴的哪个阶段给LCP元素加preload,减少该元素渲染路径上的阻塞白屏时间正常,但用户点击没反应主线程长任务过多Performance看Long Task分布拆分长任务、Worker处理计算、延迟初始化非核心组件新版本发布后,老用户一直看不到更新HTML缓存配置过长Network面板看HTML请求的状态码HTML设no-cache,静态资源用哈希文件名长缓存首屏请求数奇多,资源一个接一个组件粒度过细、懒加载滥用Network面板看请求瀑布图合并chunk,合理设置路由懒加载粒度页面加载时大图片撑满整个请求带宽首屏图片未优化格式和尺寸Network看图片请求体积WebP格式、srcset响应式、压缩图片使用VxeTable等重型表格组件首屏卡数据量大、组件初始化开销高Performance录制数据分页/虚拟滚动、延迟初始化表格、按需引入组件5.4 优化上线后的效果复盘思路每次上线优化方案后,要形成一个复盘习惯。我在项目里通常的做法是:上线前先在预发环境测一组基线数据,上线后观察一到两周的RUM数据,两者对比。这一步的意义不只是给团队一个我们做到了的正反馈,更重要的是可以验证当初的优化手段是否真的在真实场景中生效。曾有一次,我把图片全面切换成WebP以后,测试环境的LCP从1.6秒降到了1.1秒,但线上RUM数据几乎没有变化。后来排查发现,是公司内部代理层把新格式的图片请求拦截了,部分用户还是走了JPEG回退。如果没有线上的RUM对比,这次优化就是白忙一场还自以为成功。所以,优化效果的判断题,必须以线上真实数据为结论,不能只依赖本地复测。另一个值得复盘的角度是成本与收益。首屏优化也不是所有手段都无脑上。有些项目本身首屏是登录页,基本没有复杂逻辑,那骨架屏、Service Worker这些方案投入产出比就很低。优化要有取舍,把力气用在用户真正感知最强烈的地方,比堆砌手段更重要。根据我个人的实际操作经验,做性能优化最忌一次到位的心态。前端工程是持续演进的,依赖会升级,业务会变更,用户的设备和网络环境也在变化,性能水位线需要持续关注。与其花一个季度做一次轰轰烈烈的大重构,不如建立小步快跑的机制:每次迭代都带一点性能意识,每个PR都跑一下预算检查,时间长了,团队的整体工程质量自然会提升。最后再分享一个小技巧:如果还没想好从哪个指标开始优化,就从LCP入手。大部分用户对首屏最直观的感知就是最大屏内容多久出来,它和FCP、TTI、CLS的关联度都很高,优化LCP往往能带动整体体验的改善。抓住一个核心指标建立信心,再逐步拓展到其他维度,这个思路比一头扎进浩如烟海的性能清单里要高效得多。