# 前端性能优化篇
# 一、前言
⚡ 30 秒速记
- 骨架就是「输入
URL到页面展示」：DNS→TCP/TLS→HTTP请求响应 → 浏览器解析渲染 → 等待交互 - 网络层：
DNS缓存和dns-prefetch、长连接和preconnect、减少请求数和体积、CDN就近 - 浏览器层：资源加载顺序、缓存、
SSR、减少回流重绘和无意义的DOM操作 - 指标对齐体验：主内容慢看
LCP，点了没反应看INP，页面乱跳看CLS - 先定位慢在哪段再动手，
DNS和建连这两段大多要和服务端、运维一起改
性能优化的骨架就是「从输入 URL 到页面展示」这条链路，每一段都可能慢，先找到慢的那段再对症下药。 网络这头是 DNS 解析、建连、请求响应，能做的是预解析、预连接、减少请求和体积、上 CDN；浏览器这头是解析 HTML、加载资源、布局绘制，能做的是控制加载顺序、用好缓存、减少回流重绘。我自己排查一般先看 Network 瀑布图和 Performance 面板，确认是卡在网络还是卡在主线程，再决定改哪块，不然很容易压了半天 JS，结果瓶颈在接口。
# 知识体系： 从一道面试题说起
在展开性能优化的话题之前，我想先抛出一个老生常谈的面试问题：
从输入 URL 到页面加载完成，发生了什么？
- 这个问题非常重要，因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识，只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作，就是围绕这个过程来做文章。
- 我们现在站在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作（如下图所示）。
我们将这个过程切分为如下的过程片段：
DNS解析TCP连接HTTP请求抛出- 服务端处理请求，
HTTP响应返回 - 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户
大家谨记，我们任何一个用户端的产品，都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡，从而打磨出用户满意的速度。
# 从原理到实践：各个击破
- 我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。
具体来说，DNS 解析花时间，能不能尽量减少解析次数或者把解析前置？能——浏览器 DNS 缓存和 DNS prefetch。TCP 每次的三次握手都急死人，有没有解决方案？有——长连接、预连接、接入 SPDY 协议。如果说这两个过程的优化往往需要我们和团队的服务端工程师协作完成，前端单方面可以做的努力有限，那么 HTTP 请求呢？——在减少请求次数和减小请求体积方面，我们应该是专家！再者，服务器越远，一次请求就越慢，那部署时就把静态资源放在离我们更近的 CDN 上是不是就能更快一些？
