## 一、加载性能优化 ### 1、资源体积压缩 **代码分割（Code Splitting）** ``` // 路由级分割 const Home = lazy(() => import('./pages/Home')) // 组件级分割（条件渲染的重型组件） const HeavyChart = lazy(() => import('./components/HeavyChart')) ``` Webpack/Vite 会将每个 import() 打成独立 chunk，首屏只加载必要代码。 **Tree Shaking** Tree Shaking 依赖 ES Module 的静态结构。常见陷阱： ``` // 导入整个库 — 无法 tree shake import _ from 'lodash' // 按需导入 import debounce from 'lodash/debounce' // 或使用支持 ESM 的替代品 import { debounce } from 'lodash-es' ``` **压缩策略** | 算法 | 压缩率| 兼容性| 适用场景| |--------|--------|--------|--------| | Gzip | ~70%| 全量| 通用| | Brotli | ~80%| 现代浏览器| 生产推荐| Nginx 配置 Brotli： ``` brotli on; brotli_comp_level 6; brotli_types text/javascript application/json; ``` 详细配置见[如何在Nginx中配置Brotil与Gzip](https://zhemufanzhou.cn/posts/brotli-gzip-nginx) >在生产环境中，最推荐的方案是“前端预生成 + Nginx优先读取”的组合模式，这样可以兼顾性能和灵活性。对于Gzip在前端项目中的配置： vue.config.js ``` const CompressionPlugin = require('compression-webpack-plugin'); module.exports = { configureWebpack: { plugins: [ new CompressionPlugin({ test: /\.(js|css|html|svg)$/, // 需要压缩的文件类型 threshold: 10240, // 只有大于10KB的文件才压缩 minRatio: 0.8, // 只有压缩率低于0.8才生成 deleteOriginalAssets: false // 保留源文件，安全兜底 }) ] } }; ``` vite.config.js ``` import viteCompression from 'vite-plugin-compression'; export default defineConfig({ plugins: [ viteCompression({ algorithm: 'gzip', ext: '.gz', threshold: 10240, // 超过10KB才压缩 deleteOriginFile: false // 不删除源文件 }) ] }); ``` ### 2、资源加载策略 **使用场景判断** - preload → 当前页面"肯定会用到"且"默认优先级不够"的资源 - prefetch → 未来导航"可能会用到"的资源（浏览器空闲时加载）具体触发条件： | 资源类型| 用preload| 用prefetch| |--------|--------|--------| | 首屏 Hero 图| ✔（浏览器扫描 HTML 时发现太晚）| ✗| | 字体文件| ✔（CSS 解析后才发现，延迟 1-2 RTT）| ✗| | 首屏关键 JS chunk| ✔（异步 import 的 chunk 优先级低）| ✗| | 下一页路由 JS| ✗| ✔| | 搜索结果页资源| ✗| ✔（用户打开搜索框时触发）| | 当前页非关键图 | ✗| ✗（用 lazy loading）| **预加载（Preload / Prefetch）** ``` ``` 二者的本质差异：preload 是命令，prefetch 是建议。滥用 preload 会抢占带宽，适得其反。 **Resource Hints 进阶** ``` ``` **完整 HTML 配置** ``` ``` **使用JS动态注入prefetch（推荐）** 具体配置见文章[inject-resource-hints.js](https://zhemufanzhou.cn/posts/inject-resource-hintsjs) **HTTP/2 多路复用** HTTP/1.1 时代的"域名分片"（domain sharding）在 HTTP/2 下是反优化——HTTP/2 单连接多路复用，域名越多握手越多。升级 HTTP/2 后应合并资源域名。 Ubuntu系统中的Nginx配置HTTP/2： ``` # HTTP → HTTPS 重定向 server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$host$request_uri; } # HTTPS + HTTP/2 主站点 server { listen 443 ssl http2; # ← HTTP/2 就在这一行 listen [::]:443 ssl http2; server_name example.com www.example.com; # SSL 证书 ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; # TLS 配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; # OCSP Stapling ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 1.1.1.1 valid=300s; # 安全响应头 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; add_header X-Frame-Options DENY always; add_header X-Content-Type-Options nosniff always; # 静态文件根目录 root /var/www/example.com/dist; index index.html; # 缓存策略 location ~* \.html$ { add_header Cache-Control "no-cache, no-store, must-revalidate"; } location ~* \.(js|css|woff2|woff|ttf)$ { add_header Cache-Control "public, max-age=31536000, immutable"; gzip_static on; brotli_static on; } location ~* \.(png|jpg|jpeg|webp|avif|gif|svg|ico)$ { add_header Cache-Control "public, max-age=2592000"; gzip_static on; brotli_static on; } # SPA 路由支持 location / { try_files $uri $uri/ /index.html; } # API 反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } ``` **CentOS / AlmaLinux / RHEL 系统：** 配置在/etc/nginx/conf.d/example.com.conf；前提确保主配置文件/etc/nginx/nginx.conf中include了/etc/nginx/conf.d/*.conf >注意：如果是依赖sites-available中的配置文件生效，那么再单独配置这个文件就会产生冲突，一个域名对应一个 server 块，所有配置（SSL、HTTP/2、缓存、Brotli、location 等）全部写在一个文件里 ### 3、缓存策略原理图：请求流程：浏览器缓存 → 命中强缓存 → 直接返回（不发请求） ↓ 未命中发请求 → 命中协商缓存 → 304 Not Modified（传响应头，不传 body） ↓ 未命中 200 OK（完整响应） **强缓存 vs 协商缓存** 强缓存：Cache-Control: max-age=31536000, immutable → 命中时不发请求，直接用本地协商缓存：Cache-Control: no-cache + ETag/Last-Modified → 每次请求，但 304 时不传输 body 最佳实践：内容哈希 + 长期缓存 main.abc123.js → Cache-Control: max-age=31536000, immutable index.html → Cache-Control: no-cache >HTML 永远不缓存（或极短），JS/CSS 文件名含 hash 永久缓存。每次构建文件名变化，自动破缓存。 Vite 构建侧配置： ``` // vite.config.ts export default defineConfig({ build: { rollupOptions: { output: { // 产物文件名含 hash，配合长期缓存 entryFileNames: 'assets/[name].[hash].js', chunkFileNames: 'assets/[name].[hash].js', assetFileNames: 'assets/[name].[hash][extname]', // 手动拆包：第三方库单独 chunk，业务代码 hash 变化不影响 vendor 缓存 manualChunks: { vendor: ['react', 'react-dom'], antd: ['antd'], router: ['react-router-dom'], }, }, }, }, }) ``` Webpack 配置： ``` // webpack.config.js module.exports = { // ... 其他配置 output: { // 对应 Vite 的 entryFileNames / chunkFileNames filename: 'assets/[name].[contenthash:8].js', chunkFilename: 'assets/[name].[contenthash:8].js', // 对应 Vite 的 assetFileNames（图片、字体等静态资源） assetModuleFilename: 'assets/[name].[contenthash:8][ext]', // 清理 dist 目录 clean: true, }, optimization: { // 对应 Vite 的 manualChunks splitChunks: { chunks: 'all', cacheGroups: { // vendor: 对应 Vite 的 vendor: ['react', 'react-dom'] vendor: { test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/, name: 'vendor', chunks: 'all', priority: 10, }, // antd: 对应 Vite 的 antd: ['antd'] antd: { test: /[\\/]node_modules[\\/](antd|@ant-design)[\\/]/, name: 'antd', chunks: 'all', priority: 9, }, // router: 对应 Vite 的 router: ['react-router-dom'] router: { test: /[\\/]node_modules[\\/](react-router-dom|history)[\\/]/, name: 'router', chunks: 'all', priority: 8, }, // 默认：其他第三方库合并到 vendors defaultVendors: { test: /[\\/]node_modules[\\/]/, name: 'vendors', chunks: 'all', priority: 1, }, // 默认：业务代码公共模块 default: { minChunks: 2, priority: -20, reuseExistingChunk: true, }, }, }, // 保持 module id 稳定（hash 基于路径生成） moduleIds: 'deterministic', }, }; ``` Nginx 完整配置： ``` server { # ── 规则一：HTML 文件 — 永不强缓存 ── # HTML 是入口，必须保证能拿到最新版本 location ~* \.html$ { add_header Cache-Control "no-cache, no-store, must-revalidate"; add_header Pragma "no-cache"; add_header Expires "0"; } # ── 规则二：带 hash 的静态资源 — 永久缓存 ── # Vite/Webpack 构建产物：main.abc123.js，hash 变则文件名变 location ~* \.(js|css|woff2|woff|ttf)$ { add_header Cache-Control "public, max-age=31536000, immutable"; # immutable：告知浏览器文件内容绝对不变，省去条件请求 } # ── 规则三：图片 — 较长缓存 + 协商缓存兜底 ── location ~* \.(png|jpg|jpeg|webp|avif|gif|svg|ico)$ { add_header Cache-Control "public, max-age=2592000"; # 30 天 etag on; # 开启 ETag（内容 hash） # last_modified 默认开启 } # ── 规则四：Service Worker 文件 — 绝对不缓存 ── location = /sw.js { add_header Cache-Control "no-store"; } # ── 规则五：API 响应 — 由业务决定，通常不缓存 ── location /api/ { proxy_pass http://backend; add_header Cache-Control "no-store"; # 或者对 GET 只读接口做短期缓存 # add_header Cache-Control "public, max-age=60, s-maxage=300"; # s-maxage 只对 CDN/代理生效，用于区分浏览器缓存和 CDN 缓存时长 } } ``` 配置对照表 | Vite 配置| Webpack 配置| 说明| |--------|--------|--------| | entryFileNames: 'assets/[name].[hash].js'| output.filename: 'assets/[name].[contenthash:8].js'| 入口文件命名| | chunkFileNames: 'assets/[name].[hash].js'| output.chunkFilename: 'assets/[name].[contenthash:8].js'| 非入口 chunk 命名| | assetFileNames: 'assets/[name].[hash][extname]'| output.assetModuleFilename: 'assets/[name].[contenthash:8][ext]'| 静态资源命名 | | manualChunks: { vendor: ['react', 'react-dom'] } | splitChunks.cacheGroups.vendor| 手动拆包| 关键差异说明 **1、Hash 类型不同** ``` // Vite '[hash]' // 默认 8 位 // Webpack '[contenthash]' // 基于内容生成，缓存更精准 '[hash]' // 基于构建生成（不推荐） '[chunkhash]' // 基于 chunk 生成 ``` 推荐：Webpack 使用 [contenthash:8]（8 位长度，可自定义） **2、拆包粒度更细** Webpack 支持更精细的控制： ``` splitChunks: { chunks: 'all', // 所有类型的 chunk 都进行拆分 minSize: 20000, // 最小体积（字节） maxSize: 244000, // 最大体积（超过会尝试拆分） minChunks: 1, // 最少引用次数 maxAsyncRequests: 30, // 最大并行请求数 maxInitialRequests: 30, // 入口最大并行请求数 } ``` ### 为什么要拆 vendor chunk：不拆包时：业务代码一行改动 → main.js hash 变 → 浏览器重新下载包含 react 的整个 bundle 拆包后：业务代码改动 → main.abc.js hash 变（仅重下业务代码） react 未变 → vendor.xyz.js hash 不变（命中永久缓存） ## 二、渲染性能优化 ### 4. 关键渲染路径（CRP）浏览器渲染流程：Parse HTML → Build DOM → Build CSSOM → Render Tree → Layout → Paint → Composite CSS 阻塞渲染，JS 阻塞解析 ``` ... ``` **defer vs async：** defer：按顺序，DOM 解析完后执行，适合有依赖的脚本 async：无序，下载完立即执行，适合独立脚本（统计、广告） ``` function loadScript(src, { async = false, defer = false } = {}) { return new Promise((resolve, reject) => { const script = document.createElement('script') script.src = src if (async) script.async = true if (defer) script.defer = true script.onload = resolve script.onerror = reject document.body.appendChild(script) }) } // 统计脚本：async（不阻塞，顺序无关） loadScript('https://analytics.example.com/track.js', { async: true }) // 依赖 DOM 的脚本：defer（DOM 就绪后执行） loadScript('/lib/dom-dependent.js', { defer: true }) ``` **内联关键 CSS（Critical CSS）** 原理：无内联 CSS 时加载流程（2 RTT）：请求 HTML → 解析 → 请求 CSS → 解析 CSS → 渲染有内联关键 CSS（1 RTT）：请求 HTML → HTML 含关键 CSS → 立即渲染首屏 → 异步加载完整 CSS Vite 配置 npm install -D vite-plugin-critical ``` // vite.config.ts import { defineConfig } from 'vite' import critical from 'vite-plugin-critical' export default defineConfig({ plugins: [ critical({ criticalUrl: 'http://localhost:4173', // 预览服务地址 criticalBase: './dist', // 构建输出目录 criticalPages: [ { uri: '/', template: 'index' }, // 首页 { uri: '/product', template: 'product' }, // 商品页 ], criticalConfig: { inline: true, // 关键 CSS 内联到 ``` Webpack 配置 npm install -D beasties-webpack-plugin # 或 pnpm add -D beasties-webpack-plugin ``` // webpack.config.js const HtmlWebpackPlugin = require('html-webpack-plugin') const MiniCssExtractPlugin = require('mini-css-extract-plugin') const BeastiesWebpackPlugin = require('beasties-webpack-plugin') const isProduction = process.env.NODE_ENV === 'production' module.exports = { mode: 'production', plugins: [ new HtmlWebpackPlugin({ template: './public/index.html', scriptLoading: 'defer', }), // 必须：先将 CSS 提取为独立文件，beasties 才能处理 isProduction && new MiniCssExtractPlugin({ filename: 'assets/[name].[contenthash].css', }), // beasties 内联关键 CSS isProduction && new BeastiesWebpackPlugin({ // ── 核心选项 ── // 非关键 CSS 的加载策略（最重要的配置项） // 'body' → 移到 body 底部 // 'media' → media="print" 技巧异步加载，onload 切换为 all // 'swap' → 使用 rel="preload" + as="style" + onload // 'swap-high'→ 同 swap，但 preload 优先级更高 // 'js' → 用 JS 动态插入 // 'js-lazy' → 页面加载完成后再用 JS 插入（最懒） preload: 'swap', // 推荐，兼容性最好 // 从原始 CSS 文件中移除已内联的关键样式（避免重复） pruneSource: true, // 推荐开启，减小异步加载的 CSS 体积 // 添加

/* 首屏关键样式，工具自动提取 */

{visibleItems.map(item => )}

{value} } ``` **反模式：过度 memo 化** memo 本身有比较成本。对于渲染极快的简单组件，memo 的 props 比较反而比重渲染更慢。优化前应先 Profiler 测量。 ### Profiler 测量步骤（防止过度 memo 化） **步骤一：React DevTools Profiler** ``` 1. 打开 Chrome DevTools → 切换到 "⚛ Profiler" 标签 2. 点击 "Record"（圆形录制按钮） 3. 在页面上执行目标操作（如点击按钮、输入文字） 4. 停止录制 ``` 火焰图解读： ``` 每个色块 = 一次组件渲染色块宽度 = 渲染耗时灰色 = 未重渲染（memo 生效）黄色 = 渲染耗时长绿色/蓝色= 渲染耗时短点击色块可看到： - "Why did this render?" → 显示是哪个 prop/state 变化触发了渲染 ``` 实际截图分析案例： ``` 场景：点击"切换主题"按钮后优化前： App (12ms) ├─ Header (0.1ms) ← 不必要的重渲染 ├─ Sidebar (8ms) ← 不必要的重渲染（耗时！） └─ ThemeToggle (0.2ms) 优化后（加了 memo）： App (0.3ms) ├─ Header [灰色，跳过] ├─ Sidebar [灰色，跳过] └─ ThemeToggle (0.2ms) 结论：Sidebar 耗时 8ms，值得加 memo；Header 只有 0.1ms，加 memo 意义不大 ``` 步骤二：用代码测量（精准到微秒） ``` // 方式一：React Profiler 组件（精准测量单个组件树） import { Profiler } from 'react' function onRenderCallback( id, // 组件树的标识 phase, // "mount" | "update" | "nested-update" actualDuration, // 本次渲染耗时（ms） baseDuration, // 无 memo 时预估耗时 startTime, commitTime ) { if (actualDuration > 16) { // 超过一帧（16ms），记录告警 console.warn(`[Profiler] ${id} 渲染耗时 ${actualDuration.toFixed(2)}ms`) } } function App() { return ( ) } ``` 步骤三：判断是否值得 memo 化 ``` 决策依据（满足以下任一条件才加 memo）： 1. Profiler 显示该组件渲染耗时 > 1ms（经验阈值） 2. 该组件在父组件频繁渲染时被触发（如每次 input 变化） 3. 该组件含有昂贵的子树（深层嵌套或大量子组件）不需要 memo 的情况： 1. 组件渲染耗时 < 0.1ms（memo 的比较成本可能更高） 2. 组件的 props 本来就会变（memo 命中率低） 3. 组件本身就很少重渲染 ``` ### 11、状态位置优化（State Colocation） ``` // 状态提升过高，导致整棵树重渲染 function App() { const [inputValue, setInputValue] = useState('') return ( <> {/* inputValue 变化时也重渲染 */} ) } // 状态下移，影响范围最小化 function App() { return ( <> {/* 状态封装在此，不影响 HeavyList */} ) } ``` ### 12、Context 性能问题与解法 Context value 引用变化时，所有消费者全量重渲染。 ``` // 每次渲染都创建新 object，所有 Consumer 重渲染 // useMemo 稳定引用 const contextValue = useMemo(() => ({ theme, setTheme }), [theme]) // 更好：拆分为读/写两个 Context // 只关心 setTheme 的组件不会因 theme 变化重渲染 ``` ## 五、网络请求优化 ### 13 图片优化 ```

``` ### 六、度量与监控 ### 14、 Core Web Vitals Google 的核心性能指标，直接影响 SEO： | 指标| 全称| 优秀值| 度量内容| |--------|--------|--------|--------| | LCP| Largest Contentful Paint| < 2.5s| 最大内容元素渲染时间| | INP | Interaction to Next Paint| < 200ms| 交互响应延迟（2024 替代 FID）| | CLS| Cumulative Layout Shift| < 0.1| 视觉稳定性| **CLS 常见来源与修复：** ``` /* 图片/视频未设尺寸 → 加载时撑开布局 */ img { aspect-ratio: 16 / 9; width: 100%; } /* 预留空间 */ /* 字体闪烁（FOUT）→ font-display 控制 */ @font-face { font-display: optional; /* 超时则用系统字体，彻底避免 CLS */ } ``` ### 15、性能分析工具链开发阶段： Chrome DevTools Performance 面板 — 帧率、长任务、调用栈 React DevTools Profiler — 组件渲染耗时、原因 Lighthouse — 综合评分 + 优化建议生产监控： web-vitals 库 — 采集真实用户数据（RUM） Sentry Performance — 性能异常追踪 DataDog / Grafana — 自定义指标大盘在生产中采集 Core Web Vitals ``` import { onLCP, onINP, onCLS } from 'web-vitals' onLCP(({ value }) => sendToAnalytics('LCP', value)) onINP(({ value }) => sendToAnalytics('INP', value)) onCLS(({ value }) => sendToAnalytics('CLS', value)) ``` ### Lighthouse 和 DevTools 定位性能瓶颈 **Lighthouse 使用指南** 运行方式： # 方式一：命令行（推荐，排除插件干扰） npx lighthouse https://example.com \ --output html \ --output-path ./lighthouse-report.html \ --preset desktop \ # 或 mobile（默认） --throttling-method devtools # CPU/网络限速模拟 # 方式二：Chrome DevTools → Lighthouse 标签 # 方式三：CI 集成报告解读重点： Opportunities（机会）— 有明确优化方案的问题： ✗ Eliminate render-blocking resources → 有 JS/CSS 阻塞渲染 ✗ Properly size images → 图片尺寸过大 ✗ Remove unused JavaScript → bundle 中有未使用代码 ✗ Use efficient cache policy → 缓存配置不当 Diagnostics（诊断）— 需要进一步分析的数据： - Minimize main-thread work → 主线程工作时间明细 - Reduce JavaScript execution time → JS 解析/执行耗时 - Avoid long main-thread tasks → 超过 50ms 的长任务列表每条建议都有"estimated savings"（预估节省时间），优先处理收益最大的 LCP 归因分析（Lighthouse 告诉你 LCP 元素是谁）： Largest Contentful Paint element:

Load delay: 200ms ← 浏览器发现这个资源的延迟（应加 preload） Load time: 800ms ← 下载时间（应优化图片格式/大小） Render delay: 50ms ← 渲染延迟（通常可忽略） **Chrome DevTools Performance 面板精讲** 录制与分析步骤： 1. 打开 DevTools → Performance 标签 2. 勾选 "Web Vitals" 和 "Screenshots" 3. 按 Ctrl+Shift+E 模拟慢速网络（或手动选 "Slow 3G"） 4. 点击录制 → 执行操作 → 停止关键区域解读： ┌─────────────────────────────────────────────────────┐ │ FPS 图表（绿色 = 流畅；红色 = 掉帧） │ │ CPU 图表（越满越忙；纯红 = 主线程占满） │ │ NET 图表（资源加载瀑布） │ │ Web Vitals 时间线（LCP/CLS/INP 标注位置） │ ├─────────────────────────────────────────────────────┤ │ Main Thread 火焰图（最重要！） │ │ 红色三角 = Long Task（超过 50ms 的任务） │ │ 点击可看调用栈，找到具体函数 │ ├─────────────────────────────────────────────────────┤ │ Timings（DOMContentLoaded / Load / LCP 标记） │ │ Raster（GPU 光栅化） │ │ GPU（合成层操作） │ └─────────────────────────────────────────────────────┘ **定位 Long Task（长任务）：** Long Task > 50ms → 主线程被占用 → 用户操作无响应（INP 变差）分析步骤： 1. 在 Main 火焰图找到红色三角标注的任务 2. 展开调用栈，找到最耗时的函数 3. 点击具体函数 → Summary 面板显示： - Self time：函数本身耗时 - Total time：含子调用的总耗时 - Source：点击跳转源码常见长任务来源： - React 大树的同步渲染（升级到 React 18 并发模式） - JSON.parse() 解析大数据（用 Web Worker） - 复杂 CSS 动画导致的 Layout/Paint（改用 transform/opacity） Coverage 面板（找出未使用代码）： DevTools → Coverage 标签（Ctrl+Shift+P 搜索 "Coverage"）点击录制 → 操作页面 → 停止结果：文件名已使用未使用未使用率 main.js 40KB 160KB 80% ← 有 80% 的代码首屏未执行！ antd.css 5KB 195KB 97% ← 只用了 3% 的 Ant Design 样式行动： JS → 代码分割，按路由/功能懒加载 CSS → PurgeCSS 移除未使用样式，或切换到 CSS-in-JS/Tailwind **Memory 面板（定位内存泄漏）：** 1. 打开 Memory 标签 → 选 "Heap snapshot" 2. 操作页面（如：打开弹窗、关闭弹窗，循环 10 次） 3. 拍快照 → 对比前后内存内存泄漏常见来源：未清理的事件监听 window.addEventListener('resize', handler) // 组件卸载时清理 useEffect(() => { window.addEventListener('resize', handler) return () => window.removeEventListener('resize', handler) }, []) 未清理的定时器 useEffect(() => { const id = setInterval(tick, 1000) return () => clearInterval(id) // 清理 }, []) 闭包持有大对象引用导致无法 GC **Network 面板（分析请求瀑布）：** 关注指标： TTFB（Time to First Byte）> 600ms → 服务端慢，考虑 CDN 或 SSR 优化 Stalled（请求排队等待） → HTTP/1.1 并发限制，升级 HTTP/2 Content Download 时间长 → 资源体积大，开启压缩 Waterfall 呈阶梯状 → 串行依赖，考虑并行请求过滤技巧： - 按类型过滤：JS / CSS / Img / Fetch - 右键请求 → "Block request URL" → 测试资源加载失败的降级效果 - Initiator 列 → 查看是哪行代码触发了这个请求工具链总结：开发阶段 ├── React DevTools Profiler → 组件渲染耗时与原因 ├── Chrome Performance 面板 → 主线程长任务、帧率 ├── Coverage 面板 → 未使用代码（代码分割依据） └── Memory 面板 → 内存泄漏上线前 ├── Lighthouse CLI → 综合评分 + 具体建议（跑在 CI 里） └── WebPageTest → 真实多地区网络测速生产监控 ├── web-vitals 库 → 真实用户 Core Web Vitals 数据 ├── Sentry Performance → 性能异常追踪 └── Chrome UX Report → Google 真实用户体验数据（搜索影响） ## 总结：优化优先级矩阵 | 优先级| 措施| 收益| 成本| |--------|--------|--------|--------| | 必做| 代码分割 + 路由懒加载| 首屏减少 50%+ | 低| | 必做| 图片 WebP + lazy loading| 流量减少 30-50%| 低| | 必做| HTTP 缓存策略（hash + 长缓存）| 二次访问近零加载| 低| | 重要 | 虚拟列表（长列表场景） | 列表渲染从卡顿到流畅| 中| | 重要| Brotli 压缩 + HTTP/2| 传输体积再降 10-20% | 中| | 进阶| Critical CSS 内联| LCP 提升 0.3-0.8s| 高| | 进阶| Web Worker 卸载计算 | 消除主线程卡顿| 高| >性能优化的本质是在用户感知延迟与工程复杂度之间找平衡点。先用 Lighthouse 和 DevTools 定位真实瓶颈，再有针对性地优化——过早优化是万恶之源，这句话在前端同样成立。

Performance optimization前端实际项目场景的性能优化