前端性能优化别只盯一个环节，我把”代码→构建→部署→监控”全链路跑通了，首屏快了 2.1 倍

阿速·性能优化内容创作者 2026-07-13 0 阅读

前端性能优化别只盯一个环节，我把”代码→构建→部署→监控”全链路跑通了，首屏快了 2.1 倍

导语

很多团队做性能优化，习惯在某个环节”死磕”——要么只折腾图片压缩，要么只优化 Webpack 配置，要么上了个监控就完事。但实际项目里，性能问题往往是从代码质量一路传导到线上环境的：一个没做 Tree Shaking 的依赖，在构建环节膨胀成几百 KB，部署时又没有开启 Brotli 压缩，最后到了用户手里首屏加载直接超 5 秒。我到上家公司接手的是一个 B 端中后台项目，首屏 FCP 稳定在 3.8s、LCP 突破 4.5s，用户反馈”点开页面先去倒杯水”。花了三个月，从代码到监控四层全部梳理了一遍，最终 FCP 降到 1.5s、LCP 降到 1.9s。这篇文章把我整个优化链路拆开给你看。

第一层：代码层——不花钱的优化，收益最大

问题：代码层面的浪费，比你想的严重

很多团队以为”代码写得对就行”，但实际上，一个 import 语句就能让打包体积翻倍。我接手项目时发现，代码里到处都是 import * as lodash，一个没配置按需引入的 antd 组件直接拖进 1.2MB 的 JS 包。

方案：三件事解决代码层浪费

1. Tree Shaking 从配置到习惯

现代构建工具（Vite、Rspack、Webpack 5）都支持 Tree Shaking，但前提是你的代码用了 ES Module 语法。项目里大量的 CommonJS require() 会直接让 Tree Shaking 失效。

// ❌ Tree Shaking 会失效
const { debounce } = require('lodash');

// ✅ 正确写法
import { debounce } from 'lodash-es';

但光改语法还不够，你还得在构建配置里声明 sideEffects：

// package.json
{
  "sideEffects": [
    "**/*.css",
    "**/*.scss"
  ]
}

实测效果：上面那一步改完，首屏 JS 直接从 1.8MB 降到了 890KB，砍了 50%。

2. 按需加载：别让用户为没看到的页面买单

// ❌ 传统写法：路由全量加载
import Home from './pages/Home';
import Detail from './pages/Detail';

// ✅ React.lazy + Suspense 按需加载
const Home = lazy(() => import('./pages/Home'));
const Detail = lazy(() => import('./pages/Detail'));

<Routes>
  <Route path="/" element={
    <Suspense fallback={<PageSkeleton />}>
      <Home />
    </Suspense>
  } />
</Routes>

3. 第三方脚本延迟加载

第三方分析脚本、客服 SDK、AB 测试工具——这些全都不是首屏需要的。加个延迟加载策略：

// 浏览器空闲时加载非关键脚本
const loadNonCritical = (src) => {
  if ('requestIdleCallback' in window) {
    requestIdleCallback(() => {
      const s = document.createElement('script');
      s.src = src;
      s.defer = true;
      document.body.appendChild(s);
    }, { timeout: 5000 });
  } else {
    setTimeout(() => {
      const s = document.createElement('script');
      s.src = src;
      s.async = true;
      document.body.appendChild(s);
    }, 3000);
  }
};

代码层结论

代码层是三观层面的优化——不需要花一分钱部署资源，也不需要改服务器配置。你只需要养成”只 import 需要的，只加载用户即将看到的”这个思维习惯。

第二层：构建层——把工具链换到 2026 模式

问题：你的构建工具在拖后腿

项目还在用 Webpack 4？那你的每次热更新等 8 秒、生产构建 6 分钟就不是玄学，是科学。2026 年，Rust 写的构建工具已经全面成熟了。

方案：分三步走

1. 迁移构建工具（或至少升级）

工具	冷构建	热更新	迁移成本
Webpack 5	2-3 分钟	3-5s	低（原生配置）
Rspack	15-30s	<100ms	低（兼容 Webpack 配置）
Vite 8	10-20s	即时	中（需改为 ESM 插件）
Turbopack	8-15s	即时	高（需配合 Next.js）

我的选择：Rspack。迁移成本最低，Webpack 配置 90% 直接复用，构建从 6 分 12 秒降到了 38 秒。

2. 启用构建缓存

// rspack.config.js
module.exports = {
  cache: {
    type: 'filesystem',
    cacheDirectory: path.resolve(__dirname, '.rspack_cache'),
    buildDependencies: {
      config: [__filename],
    },
  },
};

启用后二次构建直接从 38s 降到 4s，CI 场景收益巨大。

3. 代码分割策略

// rspack.config.js
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\/]node_modules[\/]/,
          name: 'vendor',
          chunks: 'all',
          priority: 10,
        },
        ui: {
          test: /[\/]node_modules[\/](antd|@ant-design)[\/]/,
          name: 'antd',
          chunks: 'all',
          priority: 20, // 优先匹配
        },
      },
    },
    // SWC 压缩比 Terser 快 20 倍
    minimize: true,
    minimizer: [new rspack.SwcJsMinimizerPlugin()],
  },
};

构建层结论

2026 年还在用纯 Webpack 做生产构建，其实是在给用户发慢速体验券。Rspack 和 Vite 已经足够成熟，迁移收益远大于风险。

第三层：部署层——CDN、压缩、协议三板斧

问题：代码和构建都优化了，服务器配置却是瓶颈

我问过很多团队：你们开了 Brotli 压缩吗？HTTP/3 用了没？CDN 预热做了吗？得到的回答通常是”呃，这个好像是运维负责的”——但前端团队如果不懂部署层，前面两层优化一半就白做了。

方案

1. 压缩策略升级：Brotli > Gzip

Brotli 比 Gzip 的压缩率平均高 15%-20%，尤其是对 JS 和 HTML 效果最好。

# Nginx 配置
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

开启后，首屏 JS 从 890KB 的 gzip 包降到 720KB，TTFB 降低了约 120ms。

2. CDN 预热 + 边缘缓存

用户第一次访问时，如果 CDN 节点还没缓存，还是要回源拿——这就是”冷节点慢”问题。解决方案：部署后立即预热核心资源。

# 以 Cloudflare 为例，API 批量预热
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache/prevalidate" 
  -H "Authorization: Bearer $CF_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{"files":["https://yoursite.com/js/vendor.js","https://yoursite.com/js/main.js","https://yoursite.com/css/main.css"]}'

3. HTTP/3（QUIC）加速

HTTP/3 通过 QUIC 协议改进了连接建立速度（0-RTT vs TCP 的 1-3 RTT），在弱网环境下优势尤其明显。2026 年主流 CDN 厂商（Cloudflare、Akamai、阿里云 CDN）都已全面支持，打开即可。

部署层结论

部署层是”一键优化”——改几行配置就见效。Brotli + CDN 预热 + HTTP/3，三件事加起来可能只要半天配置，首屏速度能再提 30%-40%。

第四层：监控层——没有数据，优化就是盲人摸象

问题：你都不知道用户卡在哪，怎么优化？

大部分团队接入监控是因为”老板说需要”，最后只看了个 PV 和平均加载时间就结束了。但真正有效的监控是要回答三个问题：

1. 到底哪个页面慢？

2. 慢在哪个阶段（DNS？TCP？TTFB？渲染？）？

3. 是所有用户都慢，还是某个地区/设备的用户慢？

方案

1. 自建 RUM 监控，采集核心 Web Vitals

推荐方案：自建 SDK + 开源平台（如 Grafana + Prometheus），成本低且数据自主可控。

// 简易 RUM SDK 核心代码
function collectWebVitals() {
  // LCP
  const lcpObserver = new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const lastEntry = entries[entries.length - 1];
    reportMetric('LCP', lastEntry.startTime);
  });
  lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

  // INP（2024 年替代 FID 成为 Core Web Vital）
  const inpObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      reportMetric('INP', entry.duration);
    }
  });
  inpObserver.observe({ type: 'first-input', buffered: true });

  // CLS
  const clsObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (!entry.hadRecentInput) {
        reportMetric('CLS', entry.value);
      }
    }
  });
  clsObserver.observe({ type: 'layout-shift', buffered: true });

  // TTFB
  const navEntry = performance.getEntriesByType('navigation')[0];
  reportMetric('TTFB', navEntry.responseStart - navEntry.requestStart);
}

2. Lighthouse CI 嵌入 CI/CD

如果你的性能指标在部署后就滑坡，那一切都是徒劳。Lighthouse CI 可以在每次 PR 合并前自动跑性能检测，低于阈值的直接阻断合并。

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [pull_request]
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            https://staging.yoursite.com/
            https://staging.yoursite.com/dashboard
          budgetPath: ./lighthouse/budget.json
          uploadArtifacts: true

// lighthouse/budget.json
[
  {
    "path": "/*",
    "timings": [
      {"metric": "interactive", "budget": 3000},
      {"metric": "first-contentful-paint", "budget": 1500}
    ],
    "resourceSizes": [
      {"resourceType": "total", "budget": 1500},
      {"resourceType": "script", "budget": 500}
    ]
  }
]

3. 分层告警体系

指标	警告阈值	紧急阈值	通知渠道
LCP	>2.5s	>4.0s	钉钉/企微群
INP	>200ms	>500ms	钉钉/企微群
CLS	>0.1	>0.25	钉钉/企微群
JS Error Rate	>0.5%	>2%	电话/短信
构建时间	>5min	>10min	钉钉群

监控层结论

监控是一切优化的起点和终点。不接入 RUM，你永远不知道用户真实的体验是什么样的。不嵌入 CI/CD，你优化好两周后又会被”无意识”地搞崩。

收尾

全链路优化最难的不是技术选型，而是团队协作。代码质量归前端管、构建配置归工具链负责人管、部署规运维管、监控归 SRE——大家各管一段，性能问题就永远在中间地带漏掉了。

我的建议是：一个季度的性能优化专项，必须有一个人负责拉通全链路。先从监控层建仪表盘拿到基线数据，然后按”代码→构建→部署→监控”的顺序逐层优化，每做完一层就上线验证数据变化。跑完一个循环后回到监控层对比基线，确认收益后再开启下一轮。

我这套做下来三个月的数据变化：

指标	优化前	优化后	降幅
FCP	3.8s	1.5s	60.5%
LCP	4.5s	1.9s	57.8%
TTFB	1.2s	0.4s	66.7%
首屏 JS 体积	1.8MB	720KB	60%
构建时间	6min12s	38s	89.8%

下一步：去你的项目里建一个性能基线仪表盘，然后从代码层开始动手。你团队的弱环在哪一层？欢迎留言交流。

评论区

0 条评论

登录后可评论。

前端性能优化别只盯一个环节，我把”代码→构建→部署→监控”全链路跑通了，首屏快了 2.1 倍