下面是GPT总结的web性能优化，我整理了一下，方便自己阅读。
以下内容分为三部分：一是分析思路与流程，二是常用工具推荐，三是Chrome DevTools 中几个常用且好用的功能示例。
一、分析思路与流程
明确性能目标与衡量指标
明确“性能”：
页面首次可交互（First Contentful Paint）
首屏渲染时间（Time to First Byte、First Paint、First Meaningful Paint）
可交互时间（Time to Interactive）
整体加载完成时间（Load Event End）
结合业务需求，确定用户体验最关心的关键指标（KPI），如：
首屏加载时间 < 2s
首个输入延迟（FID）< 100ms
累计布局偏移（CLS）< 0.1
基于这些指标，才能有的放矢地去定位瓶颈。
收集初步的性能数据（基线测量）
通过 Lighthouse、WebPageTest、Chrome DevTools 自带的 Performance 面板等工具，先跑一次完整的测速，把得出的各项指标（TTFB、FCP、LCP、TTI、Total Blocking Time、Overall Load Time、资源大小统计等）记录下来，作为后续优化前后的对比基线。
也可以接入 RUM（Real User Monitoring）系统，比如 Google Analytics、Sentry Performance、New Relic Browser，收集真实用户在不同网络环境（4G、3G、宽带）下的加载情况。
深入分析各项耗时明细
网络请求分析：查看资源请求的数量、按域名分组大小、缓存命中率、是否存在多余的第三方脚本；关注阻塞（Blocking）、排队（Queuing）和传输（Transfer）时长。
JavaScript 执行分析：分析脚本解析与编译、函数执行、长任务（Long Tasks）。如有大量主线程阻塞、长任务会阻塞渲染或用户交互，需要考虑拆分 Webpack bundle、采用 Code Splitting、懒加载。
渲染与布局：查看是否存在强制同步布局（Forced Reflow）、频繁的 DOM 操作导致布局抖动，是否存在大面积的 repaint。
资源加载优先级：评估关键 CSS/JS 是否合理 inline 或预加载，图片是否做了懒加载、尺寸压缩，以及字体加载策略（font-display）是否合理。
定位瓶颈并分类优化方案
网络层面
合并或拆分请求：将多个小静态资源合并为一个包（或反之，拆分较大的包为按需加载）；
启用 HTTP/2 或 HTTP/3，减小握手与队头阻塞（Head-of-line Blocking）；
核查缓存策略（Cache-Control、ETag），确保静态资源在客户端可复用；
开启 Gzip 或 Brotli 压缩；
确认 CDN 覆盖与节点就近分发。
代码包体积
使用 Tree Shaking、代码分割（Code Splitting）、按需加载（dynamic import）；
删除不必要的 polyfill、第三方库里不使用的功能；
压缩混淆 JS/CSS（Terser、CSSNano）。
图片与多媒体资源
图片压缩（WebP、AVIF），使用合适的分辨率；
图片懒加载（Intersection Observer API）；
Sprite 图合并静态小图标，尽量减少 HTTP 请求。
也不一定。如果启用 HTTP/2 或 HTTP/3，并行能力增强，合并请求反而会降低性能。
渲染与交互
减少无意义的 DOM 操作，避免频繁读写 DOM；
避免同步布局、强制回流，合理使用 requestAnimationFrame；
使用虚拟列表（Virtual List）处理长列表。
第三方脚本
定期审查埋点 / 监控 / 广告 / 社交插件，移除或延迟加载冗余脚本；
将不影响首屏渲染的第三方脚本标记为 async 或 defer，或放在页面底部。
验证和迭代
每做一步优化，都要重新收集 Performance 指标，与基线做对比；
借助 Lighthouse、CI/CD 中的自动化检测工具（如 GitHub Action + Lighthouse CI）持续监控；
对比真实用户数据（RUM），避免“合成测试指标很好，但真用户网络环境下反而没提升”的情况。
二、常用工具推荐
浏览器级工具
Chrome DevTools：自带 Network、Performance、Coverage、Lighthouse、Web Vitals、Audits、Memory 等面板，适合本地快速定位瓶颈。
自动化测试与报告
Lighthouse CLI / Lighthouse CI：既可以在本地命令行执行 Lighthouse 审计，也可以集成到持续集成流水线里，对比性能得分、查看详细报告。
WebPageTest：支持多地节点、多种网络模拟（3G、DSL、快网），可以生成瀑布流（Waterfall）、Video Capture、Filmstrip、Speed Index 等数据。
PageSpeed Insights：Google 官方工具，结合 Lighthouse 分析，同时给出移动端与桌面端的评分与优化建议。
真实用户监控（RUM）
Google Analytics：可以打开 Site Speed 报表，查看真实用户的加载时间分布；也可接入自定义埋点上报 FCP、LCP 等 Web Vitals。
New Relic Browser / Datadog Browser RUM / Sentry Performance：能够在生产环境监控用户体验，分析不同地域、设备、网络下的性能表现。
打包分析
Webpack Bundle Analyzer / Source-map-explorer / Rollup-plugin-visualizer：可视化打包体积，找出哪个模块体积最大，进一步做按需加载或删除不必要依赖。
Bundlephobia：在线查看某个 npm 包的体积、下载统计、Tree Shaking 后体积等。
其他辅助工具
Pingdom、GTmetrix：在线性能检测与报告，相对 WebPageTest 严谨度稍低，但上手更快。
BrowserMob Proxy / Fiddler / Charles：抓包工具，用于调试 HTTP/HTTPS 请求，查看请求头、响应头、Cookie、重定向链路。
HEAP Profiler / CPU Profiler（Chrome DevTools）：用于深度分析 JS 运行时性能、内存泄漏、调用栈等。
三、Chrome DevTools 中几个好用的功能
下面着重介绍几个在实际排查网络与渲染性能时经常会用到的面板与要点。
1. Network 面板（网络面板）
Waterfall 瀑布流
每个资源的请求时序：DNS 查询、TCP 建立、SSL 握手、请求发送（Request Sent）、等待服务器响应（Waiting / TTFB）、内容下载（Content Download）、以及结束时间。
从瀑布流上可以直观看出是否有“队头阻塞”（Head-of-line Blocking）、哪个请求是阻塞渲染的关键请求。
按域名与资源类型分组
在 Headers 栏目里可查看所有请求的域名、请求方法（GET/POST）、状态码、内容大小等；
在 Sizes 栏目里可快速看哪个资源占用流量最多；
在 Initiator 栏目可以看到是哪个脚本或哪个 HTML 标签发起的请求。
过滤和筛选
可以通过“JS/CSS/Img/Media/Font/Doc/XHR”等标签快速过滤；
也可以在 Filter 输入框里根据 URL 关键字或正则筛选感兴趣的请求；
Disable Cache（禁用缓存）
在开发测试时勾选“Disable cache”可以确保所有请求都走网络而非本地缓存，方便复现首次加载时的网络开销。
Throttling（模拟网络环境）
可在 “No throttling” 下拉里选择“Fast 3G、Slow 3G、Offline” 等，以模拟移动网络环境下的加载速度。
Capture Screenshots
勾选左上角的相机图标后，在加载过程中会自动截取页面渲染快照；配合 Performance 面板的 Filmstrip 视图，可以定位哪个资源加载完成对应的视觉变化。
2. Performance 面板（性能面板，又叫 Timeline）
录制整个页面加载与交互过程
点击“Record”（录制），然后刷新页面或执行某个操作，工具会捕获加载期间的网络请求、脚本执行、布局（Layout）、绘制（Paint）、合成（Composite）、垃圾回收（GC）等各阶段耗时。
关键时间线（Timings）
Top-down 视图里会标注 CIF（DOMContentLoaded）、Load、First Paint、First Contentful Paint、Largest Contentful Paint、Time to Interactive 等时间点（有时需要开启 Web Vitals 支持）。
查看长任务（Long Tasks）
在 Flame Chart 上可以看到哪些 JavaScript 执行占用了主线程超过 50ms，会被标注为长任务；根据 Call Tree（调用树）可以追溯是哪段代码导致的。
帧率与交互流畅度
通过 FPS（Frames Per Second）视图监测渲染帧率，帧率过低可能是由于过多重绘重排（Reflow/Repaint）或频繁执行 JS 造成。
CPU / Memory 节点
可以在录制时分别打开 CPU Profiler 或 Memory Profiler，定位内存泄露或高 CPU 占用的调用栈。
3. Lighthouse 面板（审计）
一键跑性能审计
在 DevTools 的右侧或菜单中切换到“Lighthouse”面板，选择“Mobile”或“Desktop”，然后点击“Generate report”（生成报告）。
审计会根据最新的 Lighthouse 规则给出性能分数（0–100），并列出可优化项（例如：减少首次内容绘制时间、启用文本压缩、图片元素所占空间建议、使用合并脚本等）。
可视化建议与详情
对每一项得分，Lighthouse 都会给出“为什么重要”、“如何优化”的详细说明，以及与同行业网站的对比。非常适合做一次性健康检查。
4. Coverage 面板（覆盖率检测）
Detect Unused CSS/JS（检测未使用代码）
打开 DevTools 后，按 Ctrl+Shift+P（Windows）或 ⌘+Shift+P（Mac），输入 “Coverage: Show Coverage” 并回车，打开 Coverage 面板。
点击左上角小圆点开始录制，再次刷新页面。工具会扫描页面加载过程中哪些 CSS/JS 代码块被实际使用、哪些未用。
根据未使用百分比，可以考虑移除或拆分那些冗余很高的模块。
5. Web Vitals / Core Web Vitals
实时查看 LCP、FID、CLS
在最新版本的 Chrome DevTools 的 Performance 面板中，如果勾选了 “Capture Web Vitals”，录制时就会在时间轴上标注 LCP、FID、CLS 等关键指标。
也可以通过控制台命令 performance.getEntriesByType('paint') 查看 First Paint (FP) 与 First Contentful Paint (FCP) 时间。
6. Audit for Networking/Blocking
Disable JavaScript / CSS
在 Network 面板中右键某个脚本或样式文件，选择 “Block request URL”，即可临时屏蔽该资源，然后观察页面表现，便于在无需改代码的情况下判断某个库/样式对首屏渲染的阻塞程度。
Request Blocking
DevTools 的 “Network” 面板中有一个 “Block” 选项卡，可以自定义匹配规则（如正则）屏蔽特定域名、文件类型的请求，测试若该请求不加载，对页面加载有何影响。
7. 其他辅助功能
Inspect Mode 与 Layout Shift Region
在 Elements 面板中，右上角有一个 “Inspect element” 按钮，可以直接选中页面元素，在右侧看到对应的 CSS 规则、盒模型（Box Model）信息、继承链等，便于优化样式。
Performance Monitor
在 DevTools 菜单里勾选 “Performance Monitor”，可在顶部显示 CPU 利用率、DOM Nodes 数量、JS Heap、Layout 队列长度等实时数据，对发现性能瓶颈有辅助意义。
Application 面板
查看 Cache Storage、Service Worker、Local Storage、IndexedDB、Cookie 等。若项目启用了 PWA，可以查看离线缓存策略是否生效、Service Worker 是否出现异常。
四、小结
抓大放小，有的放矢：首先要量化几个关键性能指标（如 FCP、LCP、TTI），明确“哪里卡”，分析“为什么卡”；
数据驱动优化：借助 Lighthouse、Chrome DevTools、WebPageTest 等工具形成初始报告，从网络、资源、渲染、脚本执行等角度分别剖析；
细化手段：从减少请求数、减小请求体积、合理缓存策略、异步加载、懒加载、拆包降维、优化渲染路径等多方面入手；
迭代与监控：每一次优化都要验证指标变化，并结合 RUM 监控真实用户体验，避免 “合成指标” 与 “真实指标” 脱节。
掌握并灵活运用以上思路和工具，相信你在分析和优化 Web 应用资源加载性能时，会更加高效、有的放矢。