对一个产品来说，用户体验是最重要的。当页面加载时间过长、交互操作不流畅时，会给用户带来很糟糕的体验，最坏的情况下会导致用户流失。因此，在各种技术优化方案中，性能优化出现的频率最高、优先级也常常更高。
对于前端应用来说，页面加载耗时、渲染耗时、网络耗时、脚本执行耗时等指标会影响用户的等待时长，而 CPU 占用、内存占用、本地缓存占用等可能会导致页面卡顿甚至卡死。因此，性能优化可以从常见耗时和资源占用两个维度来解决。
在浏览器页面加载过程中，可以分为以下阶段：
根据这个过程，可以从 4 个方面进行耗时优化：网络请求优化、首屏加载优化、渲染过程优化、计算/逻辑运行提速。
我们分别来看看。
1. 网络请求优化。
网络请求优化的目标在于减少网络资源的请求和加载耗时，可以参考以下优化方案：
在请求资源返回后，浏览器会进行解析和加载，这个过程会影响页面的可见时间，通过对首屏加载的优化，可有效地提升用户体验。
2. 首屏加载优化。
顾名思义，首屏加载优化核心点在于：**将页面内容尽快展示给用户，减少页面白屏时间。**因此，首屏加载优化的方案主要包括两方面：首屏加载耗时优化以及使用页面过渡效果。
其中，性能和渲染耗时优化属于技术优化手段，可以通过以下方式进行：
相比性能和渲染耗时优化，使用页面过渡效果可能更倾向于产品策略。很多时候产品策略的调整，给用户带来的体验优化效果不低于技术手段优化，因此我们也需要重视。常见的方案包括使用骨架屏进行预渲染，以及使用过渡动画让用户感知到页面正在顺利加载，从而避免用户对于白屏页面或是静止页面产生烦躁和困惑。
除了首屏渲染以外，用户在浏览器页面过程中，也会触发页面的二次运算和渲染，此时需要进行渲染过程的优化。
3. 渲染过程优化。
渲染过程的优化，主要在于减少用户的操作等待时间，避免出现卡顿的情况，比如：
除此之外，渲染过程同样可以使用页面过渡动画的方式（比如加载中），给予用户及时的反馈，来提升用户的体验。
对于运算逻辑复杂、计算量较大的业务逻辑，我们还需要进行计算/逻辑运行的提速。
4. 计算/逻辑运行提速。
计算/逻辑运行速度优化的方式主要包括：
在前端性能优化实践中，网络请求优化和首屏加载优化方案使用频率最高，因为不管项目规模如何、各个模块和逻辑是否复杂，这两个方向的耗时优化方案都是比较通用的。
相比之下，对于页面内容较多、交互逻辑/运算逻辑复杂的项目，才需要针对性地进行渲染过程优化和计算/逻辑运行提速。
我们继续看看资源占用和卡顿的问题。
提到性能优化，大多数我们都在针对页面加载耗时进行优化，对资源占用的优化会更少，因为资源占用常常会直接受到用户设备性能和适应场景的影响，大多数情况下优化效果会比耗时优化局限。
资源占用常见的优化方式包括：
对于页面耗时和资源占用的性能优化分析，可以使用 Chrome 开发者工具进行针对性的分析和优化，这些内容在前文已经介绍过了，这里就不再详细讲解。
那么，是不是知道了常见的性能优化方案，就可以直接在项目中使用呢？
性能优化通常需要投入不少的人力和成本来完成，因此更多时候我们可以将其当作是一个项目的方式来进行管理。从项目管理的角度来讲，我们的性能优化工作会拆解为以下部分内容：
性能优化的第一步，就是要确定优化的目标和预期。在给出具体的数据之前，我们首先需要对一些性能数据进行定义。比如：
要选择合适有效的指标进行定义，比如由于前端框架的出现，Page Load 耗时（window.onload事件触发的时间）已经难以作为页面可见时间的关键点，因此可以使用框架提供的生命周期，或者是使用 Largest Contentful Paint (LCP，关键内容加载的时间点)更为合适。
对需要关注的性能数据进行定义完成后，可以对它们进行目标和预期的确定，一般来说有两种方式：
根据确定的目标和预期，我们就可以选择合适的优化方案。为什么不能将上面全部的技术方案都做一遍呢？主要原因有两个：
一是性价比，可能部分技术优化需要投入大量的人力，但是优化效果可能不明显，比如切换到 HTTP/2 和 HTTP/3；
二是不适用，比如有些业务并不具备差异化服务。 举个例子，小明的预期目标是客户端内打开应用 TTI 耗时减少 30%，因此他可以选择的优化方案包括：
对首页数据进行分片/分屏加载；
首屏仅加载需要的资源，通过异步加载方式加载剩余资源；
使用服务端直出渲染（SSR）；
使用 Tree-shaking 移除代码中无用的部分；
配合客户端进行资源预请求和预加载，比如使用预热 Web 容器；
配合客户端将资源和数据进行离线，可用于下一次页面的快速渲染。 其中，5、6 需要客户端小伙伴进行支持，那么小明则可以根据对方可以投入人力进行配合，来确定这两个优化点是否在本次方案中。
为了达成目标，对合适的技术优化点进行罗列之后，需要对每个优化点进行简单的调研，确定它们的优化效果。比如针对首页数据进行分屏加载，可以通过简单的模拟测试，对比完整数据的 TTI 耗时，与首屏数据的 TTI 耗时，预估该技术点的优化效果如何。
最后，根据每个优化点的优化效果以及相应的工作量评估，以预期为目标，选择性价比最优的技术方案。
在技术方案确定后，则需要对工作内容进行排期，并按计划执行。优化完成后，还需要结合目标和预期，对优化效果进行复盘，同时还可以提出未来优化的规划。
手百前端团队根据 QA 专项测试和用户反馈发现问题，定义指标、客户端和前端上报，用天幕平台监控预警，分析优化并评估。
阿里云 ARMS 性能监控方案通过页面打开速度监控 Web 场景。
美团用 Hybrid 开发模式，通过 EnhanceHybrid、SSR 和离线化技术优化。
| 公司 | 核心技术 | 特点 |
|---|---|---|
| 百度 | CloudHybrid + WebView 预创建 | 依托 Native，重性能方案 |
| 阿里云 | ARMS（Apdex）+ 低风险 SSR | 标准化、指标采集前沿 |
| 美团 | EnhanceHybrid + SSR + 离线化 | 低成本、务实解决 Hybrid 性能 |
性能优化本质是解决业务问题：手百属于超级 App，借助 Native 能力做重性能方案值得；阿里云提供标准化服务，指标采集和 SSR 实现较前沿；美团立足 Hybrid 用 EnhanceHybrid 低成本务实解决问题。
选择方案需结合业务场景：内容型/强交互用 RN/Flutter，追求发版效率与多端覆盖用 H5/小程序，超级 App 内嵌页用增强 Hybrid 方案。