背景 & 痛点

痛点：移动端首屏 LCP 常常超过 3 秒。导致使用者打开页面即离开，转化率直线下降。

sotool 是一个 PDF 工具箱。首页包含 10+ 个工具入口、FAQ、对比表格、推荐位等，首屏 HTML 超过 30 KB。

Vite 打包后：

• index.html 加载 app.js
• app.js 引入了 vuevue-routerpdf-libhtml2pdf.jsmammothxlsx 等库
• 首页虽然不直接用到 pdf-lib但它仍被打进了 vendor chunk 中
• 痛点：大量不必要的代码在首屏同步下载，网络竞争激烈。

说到调整一，手动 Chunk 拆分

痛点：LCP 高的根本原因是一次性请求了几百 KB 的 Vendor 包。

Vite 默认把所有第三方库打进一个 chunk，导致首页加载了大量无关代码。我们通过 manualChunks 把库按功能拆分：

// vite.config.ts
export default defineConfig({
再看build。{
rollupOptions: {
至于output，{
manualChunks: {
从vendor来看，'pdf-lib':,'pdfjs-dist':,mammoth:,xlsx:,'html2pdf-jspdf':
}
}
}
}
});

效果：

• 首页只加载 vendor chunk

Pitfall：

• C​​hunk 拆得太细会产生过多 HTTP 请求。移动端 HTTP/2 多路复用并不总是生效，建议控制在 5–7 个 chunk 为佳。
• CSP 或缓存策略需要同步更新，否则可能出现缓存失效导致的闪退。其实，

从调整二来看。modulePreload 过滤

Pain point：Spa 页面会在 ` ` 中自动生成 ``，把所有 chunk 都预加载，包括不需要的 PDF 库，加剧网络竞争。

// vite.config.ts
export default defineConfig({
// …modulePreload: {
resolveDependencies {
// 首页不 preload 大型 PDF 工具 chunk
if (
) ||
hostId.endsWith
) {
return deps.filter(
dep =>!老实说，dep.includes &&!dep.includes
);}
return deps;}
}
})，说起来，

• `preload` 请求从原来的 12 条降至 4 条。网络争抢明显减轻，
• LCP 提高约 0.4 秒。

调整三这方面。路由懒加载

Pain point：Spa 中每个工具页面都被一次性打进主包，即使使用者只访问首页，也要下载全部工具代码。

// router/index.ts
{
path这方面，'/merge',name: 'Merge'。component: => import
},{
从path来看，'/compress',name: 'Compress',component: => import
},//…其余路由同理

router.beforeEach => { store.commit;next，});router.afterEach => { setTimeout => store.commit,300);})，
• C​SS/JS 分割必须保持公共依赖在 vendor 中，否则每次懒加载都会重复下载相同代码。

至于调整四。字体加载调整

Pain point：`@fontsource` 引入的多个变量字体包总计近 600 KB，使得首屏文字渲染被阻塞。

// main.ts
import '@fontsource-variable/plus-jakarta-sans';import '@fontsource-variable/jetbrains-mono';import '@fontsource/instrument-serif';import '@fontsource/instrument-serif-italic.css';

S​olution：使用 `font-display: swap` 并监控字体就绪状态。

@font-face {
font-family: 'PlusJakartaSans';src: url format;font-display: swap;}
@font-face {
font-family: 'JetBrainsMono';src: url format;font-display: swap;老实说，}
@font-face {
font-family: 'InstrumentSerif';src: url format;font-display: swap;}

Pitfall：切换期间可能出现文字闪烁。怎么说呢，我们利用 `document.fonts.ready` 移除全局 `font-loading` 类。以保证首次渲染使用程序字体，而非空白占位。

document.fonts.ready.n => {
document.documentElement.classList.remove;})，

从调整五来看，首屏内容直出

Pain point：Spa 首屏 HTML 完全为空。 需要等 JS 下载并执行完毕后才能渲染内容，这直接拖慢 LCP，也不利于 SEO。

S​olution：在建立完成后使用 Playwright 脚本对关键页面进行预渲染。把渲染好的 HTML 写入静态文件中，让服务器直接返回已填充内容的页面。

// scripts/prerender.mjs
import { chromium } from 'playwright';import fs from 'fs';import path from 'path';说起来，=> {
const browser = await chromium.launch;const page = await browser.newPage;const urls =;for {
await page.goto;说起来，const html = await page.content;const outPath = path.resolve;fs.mkdirSync,{ recursive:true });fs.writeFileSync;console.log，按理说，}
await browser.close;})，

E​ffect：

• LCP 从原来的 ~3 秒下降到 ~0.2 秒。
• S​EO 收录提高，因为搜索引擎能够直接读取页面正文。话说回来，
• C​onstraint：每增加一个预渲染页面都会让 CI/CD 建立时间增加约 3 秒。需要权衡维护成本与收益，对于小型工具站这种方式已经足够；若项目规模更大，可考虑 Nuxt SSR 等方案。话说回来，

调整前后对比 📊

& 行动教程

• **手动 Chunk 拆分 + modulePreload 筛选** 是性价比最高的两招——改动少、收益大；说起来，建议先落地实现，
• **字体 `font-display : swap`** 属于细节，却能立刻把阻塞式渲染时间压到毫秒级；
• **预渲染** 能让 LCP 降至亚秒级。同时提高 SEO，但维护成本最高；小站可自行脚本实现，大站推荐 SSR 框架如 Nuxt；
• **路由懒加载** 与 **loading 状态** 的配合可以把点击延迟控制在感知不到的范围内；
• 如果你正为 SPA 首屏慢而焦虑，请先检查以下几个 “痛点”：① 首屏 JS 包体积是否超过 100KB；② 是否有大量未使用的第三方库进入 Vendor 包；③ 是否所有 Chunk 都被 `` 强制提前下载；④ 字体是否阻塞渲染，⑤ 是否缺乏任何形式的 SSR/预渲染。其实，针对这些问题逐项排查，就能快速收获数百毫秒甚至数秒的性能提高。说起来，
• 更多细节和源码请查看仓库 👉 https://github.com/yourname/sotool-optimize。