面试官：在项目中你是如何做前端优化？

1. 前端优化方案
2. 确认哪些页面需要优化
• 建立监控体系
• 确定采集指标
• RUM 指标
• Navigation Timing
• JS Error
• 请求异常
• 根据监控信息分析页面
3. 针对性优化
• 资源优化
• 使用 Brotli 进行纯文本压缩
• 使用响应式图像和 WebP
• 图像是否经过适当优化？
• 网络字体是否经过优化？
• 构建优化
• 你正在使用 tree-shaking、scope hoisting 和 code-splitting 吗？
• 能否将 JavaScript 抽离到 Web Worker？
• 能否将频繁执行的功能抽离到 WebAssembly?
• 你有在 JavaScript 中使用 module/nomodule 模式吗？
• 识别并删除未使用的 CSS / JS
• 修剪 JavaScript 包大小
• 使用针对目标 JavaScript 引擎的优化。
• 客户端渲染还是服务器端渲染?
• 正确设置 HTTP 缓存报文头
• 传输优化
• 是否对 JavaScript 库进行了异步加载？
• 使用 IntersectionObserver 和图片懒加载
• 渐进加载图片
• 你发送了关键 CSS 吗？
• 尝试重新组合你的 CSS 规则
• 预热连接用于加速传输
• 优化渲染性能
• 你是否了解如何避免回流和重绘?
• 网络优化
• 启用 OCSP stapling 了吗？
• 是否针对 HTTP 协议做了正确的优化？
• 减小请求头的大小
• 总结
• 优化工具
• 速成方案

说到前端优化，这是一个很大的范围。可能平时更多的文章是基于某一点去深入的讲解。所以趁机整理一套前端优化的基础大纲，一方面给让自己沉淀下这些知识，另一方面也方便后续优化时有个清单可以去对照着优化。

前端优化方案

先来一道面试必考题：「聊一聊你怎么做前端优化？」 那么一个相对完善的前端优化方案应该是怎么样的呢？

在过去的经验中，我认为：首先需要知道哪些页面需要优化，需要怎么样的优化，然后才能针对性的优化。所以我会将前端优化分为以下几个步骤：

• 确认哪些页面需要优化
  • 建立监控体系
  • 确定监控指标
  • 根据监控信息分析页面
• 针对性优化
  • 资源优化
  • 构建优化
  • 传输优化
  • 网络优化

确认哪些页面需要优化

建立监控体系

第一步我们需要建立一套前端的性能监控体系。前端性能监控目前主要有两种方案：

1. 第三方提供的成熟服务：例如 阿里云 ARMS、听云、监控宝等
2. 自主搭建

这里就不赘述各类第三方平台提供的服务了，主要讲明下自主搭建前端性能监控平台大概的实现思路。

确定采集指标

在前端监控方面，一般我们关注两个方向，性能和稳定。所以我们需要采集的指标大概有一下 4 个指标。

• RUM (Real User Monitoring) 指标：包括 FP, TTI, FCP, FMP, FID, MPFID。
• Navigation Timing：包括 DNS, TCP, DOM 解析等阶段的指标。
• JS Error：解析后可以细分为运行时异常、以及静态资源异常。
• 请求异常：采集 ajax 请求异常。

那么接下来我们来逐个分析各个指标如何采集。

RUM 指标

核心 Web 指标是指适用于所有网页的 Web 指标子集，每位网站开发者都应该去测量这些指标，并且这些指标还将显示在所有 Google 工具中。每项核心 Web 指标代表用户体验的一个不同方面，能够进行实际测量，并且反映出以用户为中心的关键结果的真实体验。

核心 Web 指标的构成指标会随着时间的推移而发展 。当前的指标构成侧重于用户体验的三个方面：加载性能、交互性、视觉稳定性。

主要包含包括以下指标（及各指标相应的阈值）：

这里大概给两条公式看下 HTTP/3 在结合 HTTPS 下跟 HTTP/2 的对比，给大家一个比较直观的感受，具体细节就不再简述了。毕竟本篇的主题不在这，如果有兴趣的话后面可以再详细讲。

HTTP/2 下：HTTPS 通信时间总和 = TCP 连接时间 + TLS 连接时间 + HTTP 交易时间 = 1.5 RTT + 1.5 RTT + 1RTT = 4 RTT

HTTP/3 下：首次链接时，QUIC 采用 TLS1.3，需要 1RTT，一次 HTTP 数据请求，共 2RTT。重连时直接使用 Session ID，不需要再次进行 TLS 验证，所以只需要 1RTT

OK，大概了解的 HTTP 协议的版本特点后，我们来看在目前主流 HTTP2 + HTTPS 的时代下，哪些优化策略已经过时了甚至是反优化呢

1. 减少请求数：HTTP/1.1 因为存在「队头阻塞」，所以我们通常会采用合并资源，捆绑文件（雪碧图等）等方式来减少请求数。但在 HTTP/2 中我们更需要注重网站的缓存调优，传输轻量、细粒度的资源，方便独立缓存和并行传输。
2. 多域名存储：HTTP/1.1 因为浏览器有最大连接数限制，所以我们会将资源分发到不同的域名下存放以此来增大最大连接数。但在 HTTP/2 中一个域只有一个链接，所以我们不需要去分多个域名存储，多域名存储甚至还会造成额外的 TLS 消耗。

减小请求头的大小

减小请求头的大小，常见的情况是 Cookie 。例如我们的主站中（如：www.test.com ） 存储了很多的 Cookie，我们的 CDN 域名（cdn.test.com）与我们主域一样，此时我们去请求时会附带上 .test.com域下的 Cookie。而且这些 Cookie 对于 CDN 毫无用处，会增大我们请求的包大小。所以我们可以将 CDN 域名与主域区分开，例如：淘宝（https://www.taobao.com）的 CDN 域名为 https://img.alicdn.com。

总结

优化工具

上面我们长篇大论的简述了许多前端优化的点，这里再推荐 PageSpeed Insights 和 WebPageTest 这两个工具。

1. PageSpeed Insights 可以帮助我们查看网站的各项 RUM 数据，同时会提供网站中的优化不足点，同时提供优化建议等。
2. WebPageTest 免费提供了全球多个地点进行网站速度测试。还可以依据测试结果提供丰富的诊断信息，包括资源加载瀑布图，页面速度优化检查和改进建议，会给每一项内容一个最终的评级。

速成方案

这个清单很庞大，如果要完成所有的优化可能需要很长时间。所以，如果你只有很有限的时间来进行优化，你会怎么做呢？让我们把它浓缩成15 个比较容易实现的点。

1. 根据实际经验制定合适的目标。一个比较合理的目标是：可视区域渲染 < 1s，页面渲染 < 3s，弱网 3G 的可操作时间 < 5s，重复访问的可交互时间(TTI) < 2s。
2. 为首屏准备关键 CSS，并将其内联在页面。对于 CSS / JS，关键文件大小控制在最大为压缩后 170KB 内。
3. 抽离、优化、延迟加载尽可能多的脚本，选轻量级替代方案（如用 DayJs 代替 MomentJs），并限制第三方脚本的影响。
4. 仅向具有 <script type="module"> 和 module/nomodule 模式的旧版本浏览器提供旧版本代码。
5. 尝试重新组合 CSS 规则。
6. 添加资源提示(resource hints)以提升页面加载速度，例如 dns-prefetch、preconnect、prefetch、preload、prerender 等。
7. 设置 Web 字体子集并异步加载，并利用 CSS 中的 font-display 实现快速的首次呈现。
8. 使用mozjpeg、 guetzli、 pingo 和 SVGOMG优化图像，并考虑使用图像 CDN 为 WebP 服务。
9. 检查 HTTP 缓存头和安全头是否设置正确。
10. 在服务器上启用 Brotli 压缩。（如果不行，那么请启用 Gzip 压缩。）
11. 只要服务器运行在 Linux 内核版本 4.9+上，就启用 TCP BBR 拥塞。
12. 如果可能，启用 OCSP stapling。
13. 如果 HTTP/2 可用，则启用 HPACK 压缩。如果激进一点可以尝试启用 HTTP/3。
14. 在 Service worker 中缓存字体、样式、JavaScript 和图像等资源。
15. 尝试使用渐进式 hydration 和流服务器渲染你的单页应用。