前端性能实战：基于 Vite 与 Chrome DevTools 的首屏加载优化方案

首屏优化这件事，很多团队都知道重要，但真正做起来时常常会陷入一种“改了不少，收益却不明显”的状态。原因通常不是工具不够，而是没有形成一条完整链路：先测量，再定位，再优化，再验证。

这篇文章我会从一个中级前端工程师常见的实战场景出发，带你用 Vite 做构建侧优化，用 Chrome DevTools 做定位与验证，目标是把首屏加载优化这件事做成一套可重复执行的方法，而不是一次性的玄学调参。

背景与问题

在现代前端项目里，首屏慢通常不只是一种问题，而是多个因素叠加：

JavaScript 包太大，主线程解析和执行时间长
首屏不需要的依赖被提前打进主包
图片、字体、第三方脚本阻塞关键渲染路径
CSS 体积大，或者样式加载顺序不合理
接口请求串行，导致页面内容迟迟出不来
缓存策略和压缩策略没配置好
本地开发感觉很快，但线上弱网下体验明显变差

如果只盯着“打包体积”，你会漏掉很多真正影响用户感知的因素。用户不关心你的 bundle.js 是 300KB 还是 500KB，他们只关心：

页面多久能看到东西
多久能开始点击
点击后会不会卡

所以首屏优化一定要围绕几个关键指标来做。

核心原理

首屏优化到底在优化什么

从用户视角看，首屏体验大致经历了这几个阶段：

浏览器拿到 HTML
解析 HTML / CSS，构建页面结构
下载并执行关键 JS
请求首屏接口
渲染首屏内容
页面进入可交互状态

这对应到性能指标，通常重点关注：

FCP（First Contentful Paint）：首次内容绘制
LCP（Largest Contentful Paint）：最大内容绘制
TBT（Total Blocking Time）：主线程阻塞时间
INP（Interaction to Next Paint）：交互响应表现
CLS（Cumulative Layout Shift）：布局抖动

其中首屏优化最常盯的，一般是：

尽快让用户“看见内容” → FCP / LCP
尽快让用户“能操作” → TBT / INP

一个常见误区

很多人会说：“我用了 Vite，已经很快了。”

这句话只对了一半。Vite 提升的是开发阶段体验，以及生产构建的合理性基础，但它不会自动帮你解决：

不合理的依赖引入
过度集中打包
第三方 SDK 阻塞
图片和字体资源过重
接口瀑布流
渲染时机不合理

也就是说，Vite 是很好的起点，但不是终点。

一条可执行的优化链路

我通常会按这个顺序做：

flowchart TD
    A[建立基线数据] --> B[Chrome DevTools 录制性能]
    B --> C[识别瓶颈: 网络/主线程/资源]
    C --> D[在 Vite 与代码层做优化]
    D --> E[重新构建并复测]
    E --> F[比较指标变化]
    F --> G[沉淀为团队规范]

首屏慢的典型来源

flowchart LR
    A[首屏慢] --> B[网络慢]
    A --> C[资源大]
    A --> D[主线程忙]
    A --> E[渲染阻塞]
    A --> F[接口返回慢]

    B --> B1[弱网/高延迟]
    C --> C1[大图片]
    C --> C2[大依赖包]
    D --> D1[JS 执行过多]
    D --> D2[同步计算重]
    E --> E1[CSS 阻塞]
    E --> E2[字体阻塞]
    F --> F1[串行请求]

前置知识

阅读本文前，建议你至少熟悉：

ES Module 和动态导入 import()
Vue / React 任意一种组件化思路
Vite 基本配置方式
Chrome DevTools 的 Network、Performance、Coverage 面板

如果这些你都接触过，那接下来就可以直接上手。

环境准备

本文示例基于以下环境：

Node.js 18+
Vite 5+
Chrome 最新版
任意前端框架都行，下面我用 React + Vite 做示例，思路迁移到 Vue 也一样

初始化项目：

npm create vite@latest vite-first-screen-demo -- --template react
cd vite-first-screen-demo
npm install
npm run dev

再补几个分析和压缩常用依赖：

npm install -D rollup-plugin-visualizer vite-plugin-compression

实战代码（可运行）

这一节我会按“先制造问题，再逐步优化”的方式演示，这样你更容易理解每一步是在解决什么。

第一步：先构造一个典型的首屏问题

假设首页有这些问题：

首屏直接引入重量级图表库
大图不做懒加载
请求串行
第三方统计脚本同步注入

一个不太理想的首页写法

src/App.jsx

import { useEffect, useState } from 'react'
import * as echarts from 'echarts'
import './App.css'

function App() {
  const [user, setUser] = useState(null)
  const [stats, setStats] = useState(null)

  useEffect(() => {
    async function load() {
      const userRes = await fetch('/api/user')
      const userData = await userRes.json()
      setUser(userData)

      const statsRes = await fetch('/api/stats')
      const statsData = await statsRes.json()
      setStats(statsData)

      const chartDom = document.getElementById('chart')
      const chart = echarts.init(chartDom)
      chart.setOption({
        xAxis: { type: 'category', data: ['Mon', 'Tue', 'Wed'] },
        yAxis: { type: 'value' },
        series: [{ data: [120, 200, 150], type: 'line' }],
      })
    }

    load()
  }, [])

  return (
    <div className="page">
      <h1>首屏优化演示</h1>
      <img
        src="https://picsum.photos/1200/500"
        alt="banner"
        className="hero"
      />
      <div className="card">
        <h2>用户信息</h2>
        <pre>{JSON.stringify(user, null, 2)}</pre>
      </div>
      <div className="card">
        <h2>统计信息</h2>
        <pre>{JSON.stringify(stats, null, 2)}</pre>
      </div>
      <div id="chart" style={{ width: '600px', height: '300px' }} />
    </div>
  )
}

export default App

这段代码的问题非常典型：

echarts 首屏同步引入
/api/user 和 /api/stats 串行请求
大图直接加载，且没有尺寸优化
图表在首屏立即初始化，即使用户可能还没滚动到那里

很多线上项目的“首屏慢”，本质上就是这种写法积累出来的。

第二步：用 Chrome DevTools 建立性能基线

在优化之前，不要急着改代码。先录数据。

1. Network 面板看资源瀑布

重点观察：

首屏 JS 是否过大
图片是否过大
是否有阻塞脚本
接口是否串行
是否命中缓存
是否开启 gzip / brotli

建议开启：

Disable cache
Slow 4G
CPU 4x slowdown（在 Performance 中模拟）

2. Performance 面板看主线程

录制后重点关注：

Main 线程是否有长任务（Long Task）
Scripting 时间是否过多
LCP 出现在什么时候
哪个资源拖慢了渲染

3. Coverage 面板看“加载了但没用多少”

Coverage 很适合抓这种问题：

首屏加载了一个大库，但实际只用了很少一部分
CSS 加载很多，但首屏真正用到的很少

第三步：用动态导入拆掉非首屏依赖

图表通常不是首屏核心内容。它经常体积大、初始化也重，所以优先延迟加载。

优化后的拆分方式

src/components/LazyChart.jsx

import { useEffect, useRef } from 'react'

export default function LazyChart() {
  const chartRef = useRef(null)

  useEffect(() => {
    let chartInstance = null

    async function initChart() {
      const echarts = await import('echarts')
      if (!chartRef.current) return

      chartInstance = echarts.init(chartRef.current)
      chartInstance.setOption({
        xAxis: { type: 'category', data: ['Mon', 'Tue', 'Wed'] },
        yAxis: { type: 'value' },
        series: [{ data: [120, 200, 150], type: 'line' }],
      })
    }

    const observer = new IntersectionObserver(
      (entries) => {
        if (entries[0].isIntersecting) {
          initChart()
          observer.disconnect()
        }
      },
      { threshold: 0.2 }
    )

    if (chartRef.current) {
      observer.observe(chartRef.current)
    }

    return () => {
      observer.disconnect()
      if (chartInstance) {
        chartInstance.dispose()
      }
    }
  }, [])

  return <div ref={chartRef} style={{ width: '600px', height: '300px' }} />
}

src/App.jsx

import { useEffect, useState } from 'react'
import LazyChart from './components/LazyChart'
import './App.css'

function App() {
  const [user, setUser] = useState(null)
  const [stats, setStats] = useState(null)

  useEffect(() => {
    async function load() {
      const [userRes, statsRes] = await Promise.all([
        fetch('/api/user'),
        fetch('/api/stats'),
      ])

      const [userData, statsData] = await Promise.all([
        userRes.json(),
        statsRes.json(),
      ])

      setUser(userData)
      setStats(statsData)
    }

    load()
  }, [])

  return (
    <div className="page">
      <h1>首屏优化演示</h1>
      <img
        src="https://picsum.photos/800/320"
        alt="banner"
        className="hero"
        loading="eager"
        fetchPriority="high"
      />
      <div className="card">
        <h2>用户信息</h2>
        <pre>{JSON.stringify(user, null, 2)}</pre>
      </div>
      <div className="card">
        <h2>统计信息</h2>
        <pre>{JSON.stringify(stats, null, 2)}</pre>
      </div>
      <LazyChart />
    </div>
  )
}

export default App

这里具体优化了什么

echarts 从主包移出，避免阻塞首屏
图表真正进入可视区才加载
两个接口改成并行请求
Banner 图尺寸下降，减少首屏传输成本
通过 fetchPriority="high" 提示浏览器优先抓取首屏关键图

这一招在业务系统里非常实用，尤其是首页带报表、地图、富文本编辑器时，收益通常立竿见影。

第四步：配置 Vite 构建策略

光在代码里拆分还不够，构建层也要配合。

`vite.config.js` 示例

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { visualizer } from 'rollup-plugin-visualizer'
import viteCompression from 'vite-plugin-compression'

export default defineConfig({
  plugins: [
    react(),
    visualizer({
      open: true,
      gzipSize: true,
      brotliSize: true,
      filename: 'dist/stats.html',
    }),
    viteCompression({
      algorithm: 'brotliCompress',
      ext: '.br',
    }),
  ],
  build: {
    sourcemap: false,
    cssCodeSplit: true,
    chunkSizeWarningLimit: 800,
    rollupOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules')) {
            if (id.includes('echarts')) {
              return 'echarts'
            }
            if (id.includes('react')) {
              return 'react-vendor'
            }
            return 'vendor'
          }
        },
      },
    },
  },
})

这份配置的作用

visualizer：分析打包产物，定位谁最大
viteCompression：生成 brotli 压缩文件
cssCodeSplit：让 CSS 按需拆分
manualChunks：控制大依赖拆包，避免全塞进一个 vendor 文件

为什么要谨慎使用 `manualChunks`

我踩过一个坑：拆得太碎，结果请求数量暴增，在弱网环境下反而变慢。

所以这里有个边界：

大而重、非首屏、低频使用 的依赖，适合单独拆
高度耦合、几乎每页都用 的依赖，不要过度切碎

第五步：优化 HTML 入口与关键资源优先级

首屏性能很大程度上是“浏览器早知道什么最重要”。

`index.html` 示例

<!doctype html>
<html lang="zh-CN">
  <head>
    <meta charset="UTF-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />
    <title>Vite 首屏优化演示</title>

    <link
      rel="preconnect"
      href="https://picsum.photos"
      crossorigin
    />

    <link
      rel="preload"
      as="image"
      href="https://picsum.photos/800/320"
    />
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>

什么时候用 `preload`、`prefetch`、`preconnect`

preload：明确告诉浏览器“这个资源首屏很快就要用”
prefetch：给后续导航页面做准备，不适合首屏关键资源
preconnect：提前建立连接，适合关键第三方域名

一个常见错误是把很多资源都 preload。这样会稀释优先级，甚至挤占真正关键资源的带宽。

第六步：避免第三方脚本阻塞首屏

很多项目的真实性能黑洞不是你自己的代码，而是第三方：

埋点
A/B 实验
地图 SDK
在线客服
广告脚本

不推荐的写法

<script src="https://example.com/sdk.js"></script>

这会阻塞解析。

更稳妥的写法

<script async src="https://example.com/sdk.js"></script>

或者在业务真正需要时再注入：

export function loadThirdPartyScript(src) {
  return new Promise((resolve, reject) => {
    const script = document.createElement('script')
    script.src = src
    script.async = true
    script.onload = resolve
    script.onerror = reject
    document.body.appendChild(script)
  })
}

在组件中按需调用：

import { useEffect } from 'react'
import { loadThirdPartyScript } from './utils/loadScript'

export default function AnalyticsLoader() {
  useEffect(() => {
    requestIdleCallback?.(() => {
      loadThirdPartyScript('https://example.com/sdk.js').catch(console.error)
    })
  }, [])

  return null
}

这类脚本如果不影响首屏核心流程，尽量放到：

页面空闲时
用户操作后
二屏甚至更后面

第七步：图片与字体优化

很多页面的 LCP 其实是图片，而不是文字块。

图片优化建议

优先使用 AVIF / WebP
提供合理尺寸，不要把 2000px 的图缩成 400px 展示
首屏大图设置明确宽高，减少 CLS
非首屏图片用 loading="lazy"

示例：

<img
  src="/images/banner.webp"
  alt="banner"
  width="800"
  height="320"
  loading="eager"
  fetchPriority="high"
/>

字体优化建议

如果你使用自定义字体：

首屏尽量少用超大字体文件
配置 font-display: swap
字体按字重拆分，不要一股脑全上

示例：

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom-font.woff2') format('woff2');
  font-display: swap;
}

body {
  font-family: 'CustomFont', system-ui, sans-serif;
}

用 DevTools 验证优化效果

做完优化后，别凭感觉判断，要回到工具里验证。

一次完整验证流程

sequenceDiagram
    participant Dev as 开发者
    participant DT as Chrome DevTools
    participant App as 页面应用
    participant Net as 网络资源

    Dev->>DT: 开启 Slow 4G / Disable Cache
    Dev->>App: 刷新并录制 Performance
    App->>Net: 请求 HTML/CSS/JS/图片/API
    Net-->>App: 返回资源
    App-->>DT: 上报渲染与主线程时间线
    Dev->>DT: 对比 FCP/LCP/TBT/请求瀑布
    Dev->>App: 修改代码与 Vite 配置后再次复测

重点看哪些现象

1. Network

JS 主包是否明显下降
图表库是否被独立拆出
首屏图片是否更小
接口是否并行发出

2. Performance

长任务是否减少
主线程空闲时间是否增加
LCP 是否提前
页面是否更早进入可交互状态

3. Lighthouse

可以作为辅助，但不要完全依赖分数。真实业务中，更重要的是：

弱网下的实际感知
真实用户监控数据（RUM）
核心路径是否稳定

常见坑与排查

这一节我尽量写得接地气一点，都是项目里很容易遇到的问题。

坑 1：拆包后体积是小了，但请求反而更多了

现象：

主包变小
但首屏请求数量明显上升
在弱网环境下速度不升反降

原因：

manualChunks 拆得过细
动态导入触发了太多并发小请求

排查方式：

看 Network 瀑布是否出现大量碎片 chunk
看首屏关键 chunk 是否依赖链太长

建议：

不要按“每个包一个 chunk”机械拆分
以“使用场景”而不是“包名”组织 chunk

坑 2：懒加载之后页面白块时间变长

现象：

首屏主包变小了
但某些模块滚动到时才加载，用户看到明显空白

原因：

延迟加载过头了
没有提供骨架屏或占位内容

建议：

对非首屏模块使用懒加载没问题
但要配合 Skeleton、占位高度、加载态

示例：

import { Suspense, lazy } from 'react'

const ChartPanel = lazy(() => import('./components/ChartPanel'))

export default function Dashboard() {
  return (
    <Suspense fallback={<div style={{ height: 300 }}>图表加载中...</div>}>
      <ChartPanel />
    </Suspense>
  )
}

坑 3：图片优化了，但 LCP 没明显改善

原因通常有三个：

LCP 元素根本不是图片，而是大标题或大卡片
图片虽然变小了，但请求开始时间太晚
主线程太忙，图片到了也来不及渲染

排查方式：

在 Performance 或 Lighthouse 中确认 LCP 元素是谁
看这个资源是“下载慢”还是“渲染晚”

坑 4：开发环境快，生产环境慢

这是很多人第一次上线 Vite 项目会遇到的反差。

原因：

本地没有真实网络延迟
本地资源没有 CDN / 缓存差异
线上接入了第三方脚本、监控、埋点
线上 sourcemap、压缩、缓存策略不合理

建议：

用 production build 本地预览测试：npm run build && npm run preview
模拟弱网和中端机 CPU
对线上资源头做检查

坑 5：接口并行后，后端扛不住或者数据顺序出问题

前端把请求并行化很常见，但也不是永远正确。

边界条件：

如果接口有强依赖关系，就不能强行并行
如果接口会触发昂贵计算，并行可能把后端压爆
如果数据一致性依赖先后顺序，就要保留串行

建议：

真正独立的接口再并行
能聚合就让后端提供聚合接口
性能优化不能牺牲业务正确性

安全/性能最佳实践

这一节把一些实战中最值得长期坚持的原则收拢一下。

1. 以关键渲染路径为中心做优化

优先保证：

首屏 HTML 尽快到达
首屏 CSS 尽快可用
首屏必要 JS 最小化
首屏接口并行化
首屏核心图片优先下载

不要一开始就想“把全站性能都拉满”，先救最关键的那一屏。

2. 资源优化要和缓存策略一起看

构建再漂亮，如果缓存策略没配好，收益也会打折。

推荐思路：

带 hash 的静态资源使用长缓存
HTML 使用协商缓存或短缓存
CDN 开启 gzip / brotli
为静态资源配置合理 Cache-Control

3. 控制第三方脚本权限与时机

从安全角度看，第三方脚本不只是性能风险，也是供应链风险。

建议：

只引入必要的第三方 SDK
固定可信域名来源
避免在首屏同步执行不必要脚本
对关键资源启用 CSP、SRI（若适用）

示例 CSP 思路：

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'self'; script-src 'self' https://trusted.example.com;"
/>

当然，CSP 在复杂业务里需要按实际资源域名细化，不要直接照抄。

4. 建立性能预算

这是非常有用、但最容易被忽略的一点。

例如你可以约定：

首屏主 JS < 200KB gzip
单张首屏图片 < 150KB
LCP < 2.5s
TBT < 200ms

一旦超标，就在 CI 或构建分析中报警。这样性能才不会在迭代中慢慢回退。

5. 用真实用户数据闭环

实验室数据很重要，但线上真实数据更重要。

建议至少采集：

LCP
INP
CLS
首屏接口耗时
静态资源加载失败率

如果只在本地 DevTools 看一次，就说“优化完成”，那基本很难持续有效。

逐步验证清单

如果你准备在自己的项目里照着做，可以按下面这个清单执行。

Step 1：基线测量

打开 DevTools Network，模拟 Slow 4G
打开 Performance，录制首页加载
记录 FCP / LCP / TBT
找出首屏最大 JS、最大图片、最长任务

Step 2：代码层优化

非首屏大依赖改为 import()
接口从串行改为合理并行
图片改小并补充宽高
非关键第三方脚本延后执行

Step 3：构建层优化

启用打包分析
检查 vendor 是否过大
合理配置 manualChunks
启用 brotli / gzip

Step 4：回归验证

再次录制 Performance
对比 LCP 是否提前
对比主线程长任务是否减少
确认没有引入新的白屏、闪动、功能异常

一套更实用的落地思路

如果你问我，真正在线上项目里最值得优先做的是哪几件事，我会按收益排序给出一个实战版优先级：

找出首屏不必要的大依赖并延迟加载
把串行接口改成并行或聚合接口
优化首屏 LCP 图片
延后第三方脚本
检查主线程长任务
最后再做更细的 chunk 调优

原因很简单：前四项通常最容易见效，而且不会陷入过度工程化。

总结

首屏优化不是某一个技巧，而是一条完整的方法链：

用 Chrome DevTools 找到真正瓶颈
用 Vite 做合理拆包和构建优化
用代码层手段控制加载时机、资源优先级和请求方式
最后再回到指标验证收益

如果要把本文压缩成几个最实用的结论，就是这几条：

先测量，不要凭感觉优化
大依赖优先做动态导入，尤其是图表、编辑器、地图
接口能并行就并行，但别破坏业务依赖
LCP 图片要小、早、明确优先级
第三方脚本能晚一点，就别抢首屏
拆包不是越碎越好，要看弱网下真实表现

最后给一个边界提醒：如果你的首屏核心瓶颈来自后端接口慢、SSR 缺失、CDN 布局不合理，那么仅靠 Vite 和前端代码优化，收益会有限。这时候就要把优化范围扩展到服务端渲染、缓存体系和接口聚合层。

但对于绝大多数中后台、营销页、数据看板类项目来说，本文这套方法已经足够把首屏体验拉上一个明显台阶。关键不是“知道这些技巧”，而是你能不能把它们按顺序做一遍，并且每一步都用数据验证。

《前端性能实战：基于 Vite 与 Chrome DevTools 的首屏加载优化方案》

前端性能实战：基于 Vite 与 Chrome DevTools 的首屏加载优化方案

背景与问题

核心原理

首屏优化到底在优化什么

一个常见误区

一条可执行的优化链路

首屏慢的典型来源

前置知识

环境准备

实战代码（可运行）

第一步：先构造一个典型的首屏问题

一个不太理想的首页写法

第二步：用 Chrome DevTools 建立性能基线

1. Network 面板看资源瀑布

2. Performance 面板看主线程

3. Coverage 面板看“加载了但没用多少”

第三步：用动态导入拆掉非首屏依赖

优化后的拆分方式

这里具体优化了什么

第四步：配置 Vite 构建策略

vite.config.js 示例

这份配置的作用

为什么要谨慎使用 manualChunks

第五步：优化 HTML 入口与关键资源优先级

index.html 示例

什么时候用 preload、prefetch、preconnect

第六步：避免第三方脚本阻塞首屏

不推荐的写法

更稳妥的写法

第七步：图片与字体优化

图片优化建议

字体优化建议

用 DevTools 验证优化效果

一次完整验证流程

重点看哪些现象

1. Network

2. Performance

3. Lighthouse

常见坑与排查

坑 1：拆包后体积是小了，但请求反而更多了

坑 2：懒加载之后页面白块时间变长

坑 3：图片优化了，但 LCP 没明显改善

坑 4：开发环境快，生产环境慢

坑 5：接口并行后，后端扛不住或者数据顺序出问题

安全/性能最佳实践

1. 以关键渲染路径为中心做优化

2. 资源优化要和缓存策略一起看

3. 控制第三方脚本权限与时机

4. 建立性能预算

5. 用真实用户数据闭环

逐步验证清单

Step 1：基线测量

Step 2：代码层优化

Step 3：构建层优化

Step 4：回归验证

一套更实用的落地思路

总结

`vite.config.js` 示例

为什么要谨慎使用 `manualChunks`

`index.html` 示例

什么时候用 `preload`、`prefetch`、`preconnect`