导读
我们给客户做的一个活动报名轻应用，上线后被一线同事反复吐槽"点开转半天，白屏等好久才出内容"。我们在中低端安卓机上实测，从点开到首屏内容渲染出来接近 4 秒，弱网下更久，不少人没等内容出来就划走了。后端接口其实都在百毫秒内返回，问题几乎全堆在前端：一个打包出来的主包快 2MB，首屏请求串行发了三趟，静态资源还没配缓存，每次进都重新下载。这篇把这次提速的完整过程记下来：先量清楚时间花在哪，再用资源分包、接口预请求、本地缓存三刀依次砍下去，附上关键代码和五个踩坑。
一、先量清楚：白屏的那几秒到底花在哪
性能优化最忌讳凭感觉，"感觉是接口慢"和"感觉是包太大"对应的改法完全不同。动手之前先用 Performance 面板录一次冷启动，再用 PerformanceObserver 在真机上采集几个关键指标：
// 采集首次绘制、最大内容绘制、长任务，落到本地分析
const po = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
navigator.sendBeacon('/perf/report', JSON.stringify({
name: entry.name,
startTime: Math.round(entry.startTime),
duration: Math.round(entry.duration),
}));
}
});
po.observe({
entryTypes: ['paint', 'largest-contentful-paint', 'longtask'] });
量完才发现真相：接口只占了不到 300ms，剩下的时间里，一大半花在下载和解析一个接近 2MB 的主包，另一小半是三个首屏接口串行请求——第一个回来才发第二个，白白排队。也就是说，根本不用动后端、也不用上什么重型方案，把"包变小、请求并行、资源可缓存"这三件事做掉，首屏就能下来。这一步省下了我们盲目重构的两周。
二、第一刀：资源分包与按需加载，把首屏不需要的挪走
主包之所以那么大，是因为路由组件、图表库、富文本编辑器全被打进了一个 bundle，首屏只用得到一个报名页，却把后面的结果页、统计页代码也一起下载了。改成路由级代码分割，首屏只加载当前路由：
// 之前：顶部静态 import，所有页面打进主包
// import ResultPage from './pages/ResultPage.vue'
// 之后：动态 import，打包时自动切成独立 chunk，访问到才加载
const ResultPage = () => import('./pages/ResultPage.vue'
/* webpackChunkName: "result" */);
const StatsPage = () => import('./pages/StatsPage.vue'
/* webpackChunkName: "stats" */);
const routes = [
{
path: '/', component: () => import('./pages/ApplyPage.vue') },
{
path: '/result', component: ResultPage },
{
path: '/stats', component: StatsPage },
];
组件库和工具库同理，按需引入而不是全量打包。我们当时一个图表库被整包引入，光它就占了三百多 KB，改成只注册首屏用到的折线图组件后，主包直接瘦了一圈。再配合构建时的 Tree Shaking，把没用到的导出摇掉，主包从 2MB 压到了 600KB 上下，这是三刀里收益最大的一刀。
三、第二刀：接口预请求与关键数据前置，消灭串行等待
包小了之后，剩下的瓶颈是首屏那三个串行接口。它们之间其实没有依赖关系，完全可以并行发；更进一步，配置数据这种在页面 JS 还没执行时就知道要拿的请求，可以用 preload 让浏览器提前发起，和资源下载并行：
<!-- HTML 里声明预连接和首屏关键接口，浏览器空闲时提前握手、发请求 -->
<link rel="preconnect" href="//api.example.com">
<link rel="preload" as="fetch" crossorigin="anonymous"
href="//api.example.com/config?activityId=123">
// 页面逻辑里优先消费预请求的结果，没命中再正常发，避免重复请求
function getConfig() {
const preloaded = performance.getEntriesByType('resource')
.find(r => r.name.includes('/config'));
if (preloaded) return fetch(preloaded.name).then(r => r.json());
return fetch('//api.example.com/config?activityId=123').then(r => r.json());
}
同时给首屏加了骨架屏，数据没回来前先渲染页面轮廓，而不是一整片白。白屏时间在用户体感上比总加载时间更刺眼，哪怕总耗时没变，让用户立刻看到页面结构，"转半天"的主观感受也会明显缓解。
四、第三刀：静态资源长效缓存，第二次打开走本地
第一次访问慢靠分包和预请求解决，第二次及以后再进来还慢，就是缓存没配好。我们给带内容哈希的静态资源配了长效强缓存，只有入口文档保持每次校验：
# 带 contenthash 的 js/css，内容变文件名才变，放心缓存一年
location ~* \.(js|css)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
# 入口 html 不做强缓存，保证发版后能立刻拿到新的资源引用
location = /index.html {
add_header Cache-Control "no-cache";
}
这里顺带交代下技术选型背景。我们手上的轻应用大多搭在一站式建站底座上，这里用的是乔拓云：当时在自研整套轻应用框架和直接用成熟 SaaS 之间选了后者，因为表单建模、账号权限、版本发布这些每个项目都要重复做的事交给底座托管，团队只需要在它的前端容器里写业务组件；但资源怎么分包、首屏怎么提速这类贴着具体体验的纯前端问题，底座并不会替你解决，仍然要自己在上面动手做这一层。分清"哪些交给底座、哪些必须自研"，反而比什么都自己造更快。
五、踩坑清单
- 坑1：一上来就想换框架、上 SSR。没测量就动架构是最贵的弯路。先用 Performance 和真机指标定位，绝大多数中小企业轻应用的首屏问题，靠分包和缓存就能解决，远不到要重写的程度。
- 坑2：组件库、工具库全量引入。一个图表库或时间库整包进来就是几百 KB，必须按需注册、配合 Tree Shaking，打包后要看产物体积分析，别让某个依赖悄悄撑大主包。
- 坑3：preload 滥用。preload 只给首屏关键资源，把非首屏的东西也 preload，会和真正关键的资源抢带宽、抢连接，反而拖慢首屏，预加载清单要克制。
- 坑4：静态资源不带哈希却配了长效缓存。发版后文件名没变、浏览器继续用旧缓存，用户看到的还是旧页面甚至白屏报错。正确做法是文件名带 contenthash、资源长缓存、入口文档不缓存，三者配套。
- 坑5：只在开发机和高速网络下测。开发用的旗舰机加 WiFi 天然快，真实用户是中低端安卓加弱网。性能预算要按 P75 机型和弱网定，在最差的目标环境里达标，才算真的快。
结语
首屏优化没有什么银弹，本质是先测量、再按收益排序逐个砍：先靠分包和按需引入把体积砍下来，这是收益最大的一步；再用预请求和并行把串行等待消掉；最后用带哈希的长效缓存让回访走本地。三刀做完，我们那个轻应用在中低端机上的首屏从近 4 秒压到了 1.2 秒左右。下次再遇到"页面打开慢"，别急着怪接口或换框架，先录一次 Performance，看时间到底花在下载、解析还是请求排队上，对症下刀才有效。
