前端高频面试题-精选篇-性能优化专题模块
# 前端性能优化篇
# 一、前言
30 秒速记
- 性能优化先拆链路：
DNS解析 →TCP/TLS连接 →HTTP传输 → 浏览器渲染 → 主线程交互 - 指标要对应用户体验：
LCP看主内容呈现，INP看交互响应，CLS看布局稳定 - 定位顺序是“现象 → 指标 →
trace证据 → 瓶颈”，不能凭经验直接上优化清单 - 实验室工具便于复现，但上线后还要用
RUM按设备、网络、地域和页面分位数验证 - 性能与成本、正确性、可维护性相互制约，必须设基线、预算和回归门禁
前端性能优化要沿着页面加载链路定位，从 DNS、TCP、HTTP 一直看到浏览器解析和渲染。 网络阶段可以减少解析与连接成本，并通过压缩、合并资源和 CDN 缩短请求时间。浏览器阶段更关注资源加载、缓存、服务端渲染以及回流、重绘和不必要的 DOM 操作。实际处理时要先确认慢在哪一段，因为有些问题需要服务端配合，前端单独调整并不能解决。
# 知识体系： 从一道面试题说起
在展开性能优化的话题之前，我想先抛出一个老生常谈的面试问题：
从输入 URL 到页面加载完成，发生了什么？
- 这个问题非常重要，因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识，只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作，就是围绕这个过程来做文章。
- 我们现在站在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作（如下图所示）。
我们将这个过程切分为如下的过程片段：
DNS解析TCP连接HTTP请求抛出- 服务端处理请求，
HTTP响应返回 - 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户
大家谨记，我们任何一个用户端的产品，都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡，从而打磨出用户满意的速度。
# 从原理到实践：各个击破
- 我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。
具体来说，DNS 解析花时间，能不能尽量减少解析次数或者把解析前置？能——浏览器 DNS 缓存和 DNS prefetch。TCP 每次的三次握手都急死人，有没有解决方案？有——长连接、预连接、接入 SPDY 协议。如果说这两个过程的优化往往需要我们和团队的服务端工程师协作完成，前端单方面可以做的努力有限，那么 HTTP 请求呢？——在减少请求次数和减小请求体积方面，我们应该是专家！再者，服务器越远，一次请求就越慢，那部署时就把静态资源放在离我们更近的 CDN 上是不是就能更快一些？
以上提到的都是网络层面的性能优化。再往下走就是浏览器端的性能优化——这部分涉及资源加载优化、服务端渲染、浏览器缓存机制的利用、DOM 树的构建、网页排版和渲染过程、回流与重绘的考量、DOM 操作的合理规避等等——这正是前端工程师可以真正一展拳脚的地方。学习这些知识，不仅可以帮助我们从根本上提升页面性能，更能够大大加深个人对浏览器底层原理、运行机制的理解，一举两得！
我们整个的知识图谱，用思维导图展示如下：
面试官追问
追问 1商品页首屏有 30 个静态资源请求，负责人只要求压缩 JavaScript；为什么这不能代表已经覆盖完整性能链路？
压缩只处理 HTTP 请求体积，链路中还包含 DNS 解析、TCP 连接、服务器距离、资源加载以及浏览器渲染等过程。若主要耗时落在解析、建连或排版渲染，继续压缩代码的边际收益就会受限。
追问 2活动页引用三个不同域名的字体、图片和脚本，瀑布图里 DNS 与建连等待明显；前端和服务端团队应分别推进什么？
前端可评估 DNS prefetch 与预连接，并减少不必要的域名和请求；连接复用、长连接等通常需要服务端协作。优化前应先确认等待确实来自解析和建连，否则前置连接也会占用客户端资源。
追问 3一个 500 个请求的管理页面部署到远端机房后变慢，架构师主张只上 CDN，前端负责人主张先合并请求；两种方案分别击中什么成本？
CDN 主要缩短静态资源与用户之间的距离，减少请求次数则直接降低 HTTP 往返与调度成本。两者并不互斥，但若大量请求并非适合放到 CDN 的静态资源，仅调整部署位置无法消除请求数量带来的负担。
追问 4线上监控显示网络资源很快，页面仍在加载后明显抖动，长列表区域反复重新排版；排查方向为什么要从网络切到浏览器端？
网络阶段已经不是主要嫌疑，应检查 DOM 树构建、网页排版与渲染，以及不合理 DOM 操作引发的回流和重绘。继续追加预连接或缓存不会解决渲染抖动，还可能掩盖真正需要修改的页面更新逻辑。
追问 5首页团队在服务端渲染与纯浏览器渲染之间争论，但当前瓶颈尚未定位；你会如何避免把技术选型当成性能结论？
先按 DNS、TCP、HTTP、服务器距离、资源加载和浏览器渲染拆分耗时，再判断服务端渲染对应的阶段是否真是瓶颈。服务端渲染只是浏览器端优化图谱中的一种手段，若主要成本来自资源体积或频繁回流，换渲染模式未必命中问题。
# 二、网络篇 1：webpack 性能调优与 Gzip 原理
30 秒速记
- 先分清两个目标：构建性能关心开发和发布速度，产物性能关心用户下载、解析和执行成本
- 构建提速的主线是缩小
loader处理范围、命中持久化缓存、减少重复解析和合理并行 - 产物减量靠
Tree Shaking、code splitting、懒加载和依赖分析；Tree Shaking依赖静态ESM与正确的sideEffects声明 Gzip/Brotli优化传输字节，不会降低浏览器解析和执行过多JavaScript的主线程成本DllPlugin、CommonsChunkPlugin、HappyPack主要是旧版webpack方案；现代webpack 5应优先评估文件系统缓存和内建拆包
这类优化要分清构建速度和产物体积：前者影响开发发布效率，后者直接影响用户下载成本。 构建侧可以限制 loader 范围、开启缓存，并避免第三方依赖反复处理；产物侧则通过依赖分析、Tree Shaking 和按需加载删除或延后无用代码。Gzip 利用文本中的重复内容降低传输体积，文件越大、重复越多，通常越值得启用。它仍有压缩和解压成本，对极小文件或重复度低的内容不一定划算。
从现在开始，我们进入网络层面的性能优化世界。
大家可以从第一节的示意图中看出，我们从输入 URL 到显示页面这个过程中，涉及到网络层面的，有三个主要过程：
DNS解析TCP连接HTTP请求/响应
对于 DNS 解析和 TCP 连接两个步骤，我们前端可以做的努力非常有限。相比之下，HTTP 连接这一层面的优化才是我们网络优化的核心。因此我们开门见山，抓主要矛盾，直接从 HTTP 开始讲起。
HTTP 优化有两个大的方向：
- 减少请求次数
- 减少单次请求所花费的时间
这两个优化点直直地指向了我们日常开发中非常常见的操作——资源的压缩与合并。没错，这就是我们每天用构建工具在做的事情。而时下最主流的构建工具无疑是 webpack，所以我们这节的主要任务就是围绕业界霸主 webpack 来做文章。
# webpack 的性能瓶颈
相信每个用过 webpack 的同学都对“打包”和“压缩”这样的事情烂熟于心。这些老生常谈的特性，我更推荐大家去阅读文档。而关于 webpack 的详细操作，则推荐大家读读这本 关于 webpack 的掘金小册，这里我们把注意力放在 webpack 的性能优化上。
webpack 的优化瓶颈，主要是两个方面：
webpack的构建过程太花时间webpack打包的结果体积太大
# webpack 优化方案
← 2 面试指南
