点击关注公众号，”技术干货”及时达！
一、前言
在日常需求中，开发者只要能保证静态、动效、功能、埋点都正确实现，再把需求和接口文档认真理理就已经称得上信赖的好同事了。但对于性能优化，我们通常只是依赖零散的经验，如偶尔的图片压缩、点击的防抖节流这种散点式手段。「本文旨在把常见的前端性能优化的手段归类整理，画大图，供大家在自己的自测流程中参考。」
对于性能优化，并不是说有了这张大图，就不管开发什么项目都对着来一遍。优化是有场景与前提的，「「乱优化不如不优化」」。因此在优化前，有几点要注意：
01 | 依据数字而不是猜想
尽管有些开发者能凭直觉找出性能瓶颈，这并非理想做法。
正确的流程是首先进行性能分析，再根据结果的优先级进行优化。同时「警惕优化措施可能带来的新问题」，要用性能数据验证优化效果，而非依赖猜测。
02 | 个体数据不足信
有时候，你可能会发现某个著名网站加载异常缓慢，耗时许多秒。但仅凭单次体验就认定其“慢”是不科学的，性能评估也容易犯同样的错误。
因为个别请求的数据并不足以代表整体，响应时间会因用户环境和网络条件的不同而有所差异。「更客观的方法是分析统计数据」，包括平均响应时间、吞吐量（TP 值）和响应时间的分布情况等，以便全面评估性能表现。
03 | 不要过早优化和过度优化❝
“过早的优化是万恶之源” —— Knuth（计算机科学家）
❞
无需过分投入于微不足道的提升。我们应该将精力集中在最关键的性能瓶颈上，而不是偏离目标进行非关键优化。
通常，极致优化的代码可读性较差，结构也可能妥协，导致维护困难。过早优化可能将这些问题带入项目，增加后期的重构难度。最佳实践是，「将性能优化作为独立的阶段，在项目架构和功能基本稳定后再进行」。以确保优化工作既高效又有针对性。
04 | 保持良好的编码习惯
因为开发与优化是两个独立的阶段前端空格，所以遵循良好的编码规范有助于日后的代码重构
二、性能指标
既然是优化，肯定不能通过体感上的臆测，所以需要有明确的指标来判断页面的性能是好是坏。
这些指标可以根据业务和需求自定义，但常用指标有现成的，所以普遍做法还是使用行业内都认可的指标值。根据 10 规则，Web 前端性能指标主要有 5 个：
「性能指标」「权重」
Speed Index (速度指数)
10%
First Paint (FCP-首次内容绘制)
10%
Shift (CLS-累积布局偏移)
25%
Paint (LCP-最大内容绘制)
25%
Total Time (TBT-总阻塞时间)
30%
01 | Speed Index
「速度指数」（Speed Index）并不是一个具体的时间点，而是一个综合性指标，表示页面从加载开始到页面内容基本可见的过程中，用户感受到的加载速度。
形象点描述，你打开一个网页，内容开始一点点地加载显示。一开始，可能只有一部分内容，比如顶部的导航栏，之后是一些文本，然后是图片等。速度指数就是用来衡量这个 「“填充”过程的快慢」。
小于 3.4s 为优秀
02 | FCP
「首次内容绘制时间」（First Paint ），用来衡量从用户开始打开网页到浏览器渲染出第一块内容（如文本、图像、SVG等）的时间。
如上图，FCP发生在第二帧，页面从什么也没有，到有任意元素渲染出的时间。
❝
但其实描述不够准确，FCP 还包括一些额外的时间成本，比如：
上一个页面的所有卸载时间：如果用户从一个页面跳转到另一个页面，那么浏览器需要先卸载当前页面，这个卸载过程会花费一定的时间。
连接设置时间：浏览器与服务器建立连接所需的时间，包括DNS解析、TCP握手以及TLS协商（如果是HTTPS连接）。
重定向时间：如果请求的页面经历了一次或多次HTTP重定向，那么每次重定向都会额外增加时间。
❞
小于 1.8s 为优秀
03 | CLS
「累积布局偏移」（ Shift），衡量网页在加载过程中视觉稳定性的一个性能指标
CLS的计算方式如下
CLS评分是基于每个不期望的布局偏移事件发生的影响范围和移动距离。
对于每个偏移事件，计算其影响分数（ ）和移动分数（ ）。
两者相乘得到每次偏移的评分，所有偏移的评分累加起来即为页面的CLS评分。
小于 0.1 为优秀
04 | LCP
「最大内容绘制」（ Paint，简称LCP）记录了页面中最大元素（可能是一张图像或者一段文本）显示在屏幕上所需的时间。这个指标的意义在于，当这个最大元素加载完成后，用户通常会认为页面基本上已经加载完成，即使背后可能还有其他的内容和脚本在继续加载和执行。
LCP的计算方式如下
页面开始加载时，浏览器监测所有内容的显示。
每次有新内容显示时，浏览器会检查其大小，并判断是否是目前为止最大的元素。
在页面加载过程中，对最大元素的判断可能在不断更新。
当用户能与页面交互或页面停止加载新的视觉内容，最大的元素就认为确定了，这个时间点就是LCP。
举个例子，如果一个大广告横幅突然在页面中插入并推动其他内容向下移动，这将会产生一个较大的偏移评分，增加页面的CLS。
小于 2.5s 为优秀
05 | TBT
「总阻塞时间」（Total Time），越小越好。是一个用来衡量页面在加载过程中可交互性的性能指标。它反映了页面从开始加载到成为完全可交互的过程中，主线程被长任务（在主线程上运行超过 50ms 的任务）阻塞的总时长。
TBT的计算方式如下
在首次内容绘制（FCP）之后和完全可交互时间（TTI）之前，每个长任务的执行时间超过50毫秒的部分都会被计算为阻塞时间。
对所有这些长任务的超时部分进行累加，即得到总的阻塞时间。
上述时间轴包含 5 个任务，其中 3 个是长时间运行的任务，因为它们的时长超过 50 毫秒。下图显示了每个耗时较长的任务的阻塞时间：
在主线程上运行任务所花费的总时间为 560 毫秒，但其中只有 345 毫秒被认为是阻塞时间。
小于 200 为优秀
三、通用方法
了解优化的正确时机和关键指标后，下一步是掌握常用的前端性能优化策略。
这些策略是通用的，并不专门针对任何单一的性能指标。性能优化不只涉及技术层面的改进，还涉及用户的感知体验。如果把性能优化过程看作是一套标准操作流程（SOP），那么本节内容可以视为 SOP 的起点。
01 | 资源压缩
本质就是在不过分影响用户体验和功能完整性的前提下，让被请求的资源足够小。
a. 代码资源
是一个现代 应用程序的静态模块打包工具，这种类型的压缩主要针对文本文件和代码，目的是减小它们的体积，加快传输速度，并减少浏览器解析和执行的时间。
「压缩：」 通过使用如 这样的插件，移除 中的无用代码、注释、空格和换行符，以及对代码进行缩短变量名和函数名等操作以减少文件大小，提高加载速度。
「压缩CSS：」 可以利用 、gin 等插件来优化和最小化 CSS 代码。
「模块优化：」 可以进行 Tree 来剔除项目中未引用的模块。
b. 媒体资源
媒体资源压缩针对的是图像、音频和视频等，这类资源通常是网页内容中体积最大的部分前端空格，优化它们对于提升页面加载性能至关重要。但视觉效果和文件大小要做好 trade off ，不能一味追求压缩导致资源糊化。
「图像压缩：」 通过缩小尺寸、降低分辨率、改变图像格式（如使用 JPEG、PNG、WebP 等），以及利用工具如 对图像文件进行无损或有损压缩。
「视频压缩：」 调整视频的编码参数，如比特率、分辨率，或转换为更高效的视频格式（如H.264、H.265或VP9）来减少视频文件的大小。
「音频压缩：」 通过更改音频格式（如MP3、AAC等），减少比特率来降低音频文件的体积。
「字体压缩：」 全量字体包很大，所以具体需要哪些文案利用类似 font- 的工具裁剪后引入。
02 | 网络优化
网络传输怎么优化？本质就是减少请求、减少建立连接的时间、提高连接效率和稳定性。
a. 连接优化
「使用CDN」 「（内容分发网络）」
「DNS预解析」
「避免重定向」