用户点进网站就关掉？JS 首屏加载优化的真实战场

做过前端的兄弟都有过这种经历：用户满怀期待点开链接，屏幕却是一片惨白的等待动画。哪怕后端接口响应再快，如果浏览器还在解析巨大的 JS 文件，体验就是零。很多时候我们忙着修 Bug，却忘了首屏加载才是留住用户的“生死线”。今天不谈理论堆砌，聊聊在实际项目中怎么把 JS 加载时间压下来。

别让脚本卡住渲染主线程

浏览器解析 HTML 遇到 <script> 标签默认是同步阻塞的。这意味着文档解析暂停，直到脚本下载执行完毕才继续。很多项目默认把所有业务代码塞在一个 bundle 里，结果就是主线程被长期占用。核心原则是：非关键 JS 绝对不要在 DOM 构建初期执行。

最直接的改动往往最有效。检查 <script> 标签，如果是逻辑无关紧要的统计代码或第三方插件，加上 defer 属性。它会让脚本异步下载，等 HTML 解析完成后按顺序执行，完全不打断页面结构呈现。对于不需要保持执行顺序的工具库，async 更合适，但要注意依赖问题。如果用了 ES6 Module 语法（<script type="module">），默认就是异步延迟执行，这点常被忽略，利用这个特性可以减少手动配置。

按需加载，打破单体包诅咒

随着业务膨胀，一个 vendor.js 几兆起步是常态。浏览器必须下载完才能执行，这是物理瓶颈。解决思路很简单：拆包。

在路由层面做切割是最立竿见影的。Vue 或 React 项目里，每个路由视图对应一个独立模块。使用 动态 import (import('./View')) 代替静态引入，打包工具会自动将其分割成独立的 chunk 文件。用户只有点击导航进入详情页时，才会触发对应的 JS 下载。这比一上来就把所有路由代码都拉下来要聪明得多。

有些开发为了图方便，会把公共组件抽离出来作为全局依赖，但这可能导致首页多了几十 KB 不必要的代码。建议定期分析打包体积报告，找出那些低频使用但被强制引用的库，把它们也放进动态加载队列里。

慎用资源提示，精准投喂

<link rel="preload"> 是个好东西，但不是万能药。有些团队喜欢给首页所有资源都加 preload，结果浪费了宝贵的带宽优先级。浏览器对高优先级的处理是有上限的，过量反而拖累真正关键的请求。

只针对当前首屏强依赖的资源做提示。比如首屏轮播图的图片、决定布局的关键 CSS，或者是首屏立即执行的初始化 JS。确保这些资源能在网络空闲时立刻抢占优先级。注意，不要预加载用户在深层页面才用到的字体或非可视区域图片，那是浪费。

监控才是优化的终点

优化动作做完不代表结束。本地跑分高不代表线上用户流畅。关注 Chrome DevTools 中的 LCP（最大内容绘制）指标，它比单纯的 FP（首次绘制）更能反映用户体验。

如果上线后发现某个地区 LCP 突然飙升，可能是该地区的 CDN 节点 JS 资源分发出了问题。建立真实的 RUM（实时用户监控）机制，收集不同设备、不同网络下的首屏耗时，用数据驱动下一轮的优化决策。有时候压缩代码带来的提升不如换一个更近的 CDN 节点明显，数据不会骗人。

性能优化是一场没有终点的马拉松，不是改一次配置文件就能一劳永逸。少写一点没用的代码，多拆几个小包，比任何花哨的技巧都管用。下次上线前，不妨打开 Network 面板看看，你的首屏到底在等什么。