--- theme: cyanosis --- 开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第11天，[点击查看活动详情](https://juejin.cn/post/7167294154827890702 "https://juejin.cn/post/7167294154827890702") # 前言 > **更好的体验才会俘获用户的芳心** 性能优化一直是Web端的”热度之王“，不论是日常工作还是面试，都是重中之重；小生不才，将我工作所做、书中所得呈现在各位看官面前，供各位看官品味个中滋味。 # 一、why？ ## 1.性能是留住用户的关键 - Pinterest 将感知等待时间减少了 40%，这将搜索引擎流量和注册量增加了 15% 。 - COOK 将页面平均加载时间减少了 850 毫秒，从而将转化次数提高了 7%，将跳出率降低了 7%，并将每个会话的页面增加了 10% 。 - BBC 发现他们的网站加载时间每增加一秒，他们就会失去 10% 的用户。 - DoubleClick by Google 发现，如果网页加载时间超过 3 秒，则会有 53％的用户放弃移动网站的访问。 ## 2.性能意味着提高转化率留住用户对于提高转化率至关重要。慢速网站对收入有负面影响，而快速网站显示可以提高转化率。 - 对于 Mobify而言，主页加载速度每提高 100 毫秒，基于会话的转化率就会增加 1.11%，平均年收入增加近 380,000 美元。此外，结账页面加载速度每提高 100 毫秒，基于会话的转化率就会增加 1.55%，从而使年均收入增加近 530,000 美元。 - 当 AutoAnything 将页面加载时间减少一半时，他们的销售额增长了 12% 到 13%。 - 零售商 Furniture Village 审核了他们的网站速度，并制定了解决他们发现的问题的计划，导致页面加载时间降低了 20%，转化率提高了 10%。 ## 3.性能关乎用户体验当网站开始加载时，用户需要等待一定的时间出现内容。在此之前，没有用户体验可言。这种缺乏体验在快速连接上是短暂的。然而，在较慢的连接上，用户被迫等待。随着页面资源慢慢载入，用户可能会遇到更多问题。 ![非常慢的页面加载连接（顶部）与较快的页面加载连接（底部）比较](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e4a4bd50ea2a4832a0882d0f0896cb4c~tplv-k3u1fbpfcp-zoom-1.image) ### 著名2-5-8原则 - 当用户在2秒之内得到响应时，就会觉得系统的响应很快 - 当用户在2~5秒之间得到响应时，就会觉得系统的响应速度还可以 - 当用户在5~8秒以内得到响应时，就会觉得系统的响应速度很慢，但是还可以接受 - 而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟糕透了，或认为系统已经失去响应，而选择离开这个Web站点，或发起第二次请求。 ## 4.影响性能的因素从web服务本身看，一是客户端，二是服务端 - 客户端对于客户端，用户使用不同的浏览器、不同的版本，可能对性能有不同程度的影响。抛开IE不谈，绝大多数情况下现代浏览器一般网页的性能差距不大。而用户网络方面，相较于10年前的3G网络或者4M宽带，到现在4/5G或者百M甚至千M宽带的普及，好了太多了。随着网络技术的发展，10年后可能我们现在做的所有网络层面的优化都将失去意义，但现阶段，我们还是需要为客户节省点儿流量。 - 服务端我们就是服务方，也就是乙方。硬件层面，我们的服务也要受网卡、带宽及至运营商的限制。所在服务器的CPU、内存、磁盘、操作系统以及我们程序的开发语言、框架、软件选择，任何一个环节，都可能对服务性能产生影响。当然，这些多数是运营团队的职责。我们要做的，就是把自己力所能及的一摊子做到最好。 # 二、性能指标不断优化用户体验是所有网站取得长远成功的关键。无论您是一名企业家、营销人员，还是开发者，Web 指标都能帮助您量化网站的体验指数，并发掘改进的机会。 | 指标 | 解释 | |:--------:| :-------------| | FP 白屏（First Paint Time ） | 从页面开始加载到浏览器中检测到渲染（任何渲染）时被触发（例如背景改变，样式应用等） | | FCP 首屏（first contentful paint ） | 从页面开始加载到页面内容的任何部分呈现在屏幕上的时间。（关注的焦点是内容，这个度量可以知道用户什么时候收到有用的信息（文本，图像等）） | | FMP 首次有效绘制（First Meaningful Paint ） | 表示页面的“主要内容”，开始出现在屏幕上的时间点，这项指标因页面逻辑而异，因此上不存在任何规范。（只是记录了加载体验的最开始。如果页面显示的是启动图片或者 loading 动画，这个时刻对用用户而言没有意义） | | LCP（Largest Contentful Paint ） | LCP 指标代表的是视窗最大可见图片或者文本块的渲染时间。（可以帮助我们捕获更多的首次渲染之后的加载性能，但这项指标过于复杂，而且很难解释，也经常出错，没办法确定主要内容什么时候加载完。） | | 长任务（Long Task） | 当一个任务执行时间超过 50ms 时消耗到的任务（50ms 阈值是从 RAIL 模型总结出来的结论，这个是 google 研究用户感知得出的结论，类似用户的感知/耐心的阈值，超过这个阈值的任务，用户会感知到页面的卡顿） | | TTI （Time To Internative） | 从页面开始到它的主要子资源加载到能够快速地响应用户输入的时间。（没有耗时长任务） | | 首次输入延时 FID （first Input Delay） | 从用户第一次与页面交互到浏览器实际能够开始处理事件的时间。（点击，输入，按键） | | 总阻塞时间 TBT（total blocking time ） | 衡量从 FCP 到 TTI 之间主线程被阻塞时长的总和。| | DCL （DOMContentLoaded） | 当 HTML 文档被完全加载和解析完成之后，DOMContentLoaded 事件被触发，无需等待样式，图像和子框架的完成加载。 | | L（onLoaded） | 当依赖的资源，全部加载完毕之后才会触发 | | CLS(Cumulative Layout Shift) | 是所有布局偏移分数的汇总，凡是在页面完整生命周期内预料之外的布局偏移都包括。布局偏移发生在任意时间，当一个可见元素改变了它的位置，从一个渲染帧到下一个 | 上面介绍了 11 种性能指标，我们没必要搞懂每一个指标的定义 ## 1.核心 Web 指标核心 Web 指标的构成指标会随着时间的推移而发展。当前针对 2020 年的指标构成侧重于用户体验的三个方面——加载性能、交互性和视觉稳定性——并包括以下指标（及各指标相应的阈值）： ![关键性能指标](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/31903af6f8c94b0bb238fd805992fa27~tplv-k3u1fbpfcp-zoom-1.image) - [Largest Contentful Paint (LCP)](https://web.dev/lcp/) ：最大内容绘制，测量加载性能。为了提供良好的用户体验，LCP 应在页面首次开始加载后的2.5 秒内发生。 - [First Input Delay (FID)](https://web.dev/fid/) ：首次输入延迟，测量交互性。为了提供良好的用户体验，页面的 FID 应为100 毫秒或更短。 - [Cumulative Layout Shift (CLS)](https://web.dev/cls/) ：累积布局偏移，测量视觉稳定性。为了提供良好的用户体验，页面的 CLS 应保持在 0.1. 或更少。 ## 2.查看指标 ### （1）web-vitals 通过使用web-vitals库，测量每项指标就像调用单个函数一样简单： ```c ``` ### （5）优化渲染性能使用 **CSS** 的 **will-change** 通知浏览器哪些元素和属性将会改变。 ``` will-change: auto will-change: scroll-position will-change: contents will-change: transform will-change: opacity will-change: left, top will-change: unset will-change: initial will-change: inherit ``` **CSS** 大部分样式是通过 **CPU** 来计算的，但 **CSS** 中也有一些 **3D** 的样式和动画的样式，计算这些样式会有很多重复且大量的计算任务，可以交给 **GPU** 来跑。浏览器在处理下面的 **CSS** 的时候，会使用 **GPU** 渲染： - **transform** - **opacity** - **filter** - **will-change** 这里要注意的是 **GPU** 硬件加速是需要新建图层的，而把该元素移动到新图层是个耗时操作，界面可能会闪一下，所以最好提前做。**will-change** 就是提前告诉浏览器在一开始就把元素放到新的图层，方便后面用 **GPU** 渲染的时候，不需要做图层的新建。 ### （5）避免回流和重绘说道回流和重绘，我们先来回顾下浏览器的渲染流程： - **构建 DOM 树** - **HMTL** 词法语法分析，转成对应的 **AST** 树。 - **样式计算** - 格式化样式属性，例如：rem -> px、white -> #FFFFFF 等。 - 计算每个节点样式属性：根据 **CSS** 选择器与 **DOM** 树共同构建 **render** 树。 - **生成布局树** - 这里去除一些 **dispy:none** 等隐藏样式的元素，因为它们不在 **render** 树中。 - **建立图层树** - 主要分为「显式合成」和「隐式合成」。 - 当重绘时就只需要**重绘当前图层**。 - **生成绘制列表** - 将图层树转换成绘制的**指令列表**。 - **生成图块和位图** - 绘制列表交付给**合成线程**，进行图层分块。 - 渲染进程中专门维护了一个**栅格化线程池**，专门负责把图块交由 **GPU** 渲染。 - **GPU** 渲染后将位图信息传递给合成线程，合成线程将位图信息在显示器显示。 - **显示器显示内容** ![显示器显示内容](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/26a8679842634057bfdf09d4461c2a43~tplv-k3u1fbpfcp-zoom-1.image) 其中第四步**建立图层树**很重要，我们再着重的讲一下。浏览器从 **DOM** 树画质到屏幕图形上，需要做**树结构到层结构**的转化。这里介绍4个点： - **渲染对象（RenderObject）** 一个 **DOM** 节点对应了一个渲染对象，渲染对象维持着 **DOM** 树的树形结构。渲染对象知道怎么去绘制 **DOM** 节点的内容，它通过向一个绘图上下文（GraphicsContext）发出必要的绘制指令来绘制 **DOM** 节点。 - **渲染层（RenderLayer）** 浏览器渲染时第一个构建的**层模型**，位于同一个层级坐标空间的渲染对象都会被归并到同一个**渲染层**中，所以根据层叠上下文，不同层级坐标空间的的渲染对象将会形成多个渲染层，以此来体现它们之间的**层叠关系**。所以，对于满足形成层叠上下文条件的渲染对象，浏览器会自动为其创建新的渲染层。通常以下几种常见情况会让浏览器为其创建新的渲染层： - **document 元素** - **position: relative | fixed | sticky | absolute** - **opacity < 1** - **will-change | fliter | mask | transform != none | overflow != visible** - **图形层（GraphicsLayer）** 图形层是一个负责生成最终准备呈现出来的**内容图形**的层模型，它拥有一个**图形上下文**（GraphicsContext），图形上下文会负责输出该层的位图。存储在共享内存中的位图将作为纹理（可以把它想象成一个从主存储器移动到图像存储器的位图图像）上传到 **GPU**，最后由 **GPU** 将多个位图进行合成，然后绘制到屏幕上，此时，我们的页面也就展现到了屏幕上。所以**图形层**是一个重要的**渲染载体和工具**，但它并不直接处理**渲染层**，而是处理**合成层**。 - **合成层（CompositingLayer）** **满足某些特殊条件的渲染层**，会被浏览器自动提升为合成层。合成层拥有**单独**的图形层，而其他不是合成层的渲染层，则会和**第一个拥有图形层的父层共用一个**。那么一个渲染层满足哪些特殊条件时，才能被提升为合成层呢？这里也列举一些常见情况： - **3D transforms** - **video、canvas、iframe** - **opacity 动画转换** - **position: fixed** - **will-change** - **animation** 或 **transition** 设置了**opacity**、**transform**、**fliter**、**backdropfilter** 上面提到满足一些**特殊条件**的渲染层最终会被浏览器提升了合成层，称为**显式合成**。除此之外，浏览器在合成阶段还存在一种**隐式合成**。下面我们通过举例来看下： - 假设，我们有两个 **absolute** 定位的 **div** 在屏幕上交叠了，根据 **z-index** 的关系，其中一个 **div** 就会”盖在“了另外一个上边。 ![css层级](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5edde5e48a6948b89cbd36dfe321d2fb~tplv-k3u1fbpfcp-zoom-1.image) - 这时候，如果我们给 **z-index: 3** 设置 **transform: translateZ(0)** ，让浏览器将其提升为合成层。提升后 **z-index: 3** 这个合成层就会在 **document** 上方，那么按理来说 **z-index: 3** 就会在 **z-index: 5** 上面，我们设置的 **z-index** 就会出现**交叠关系错乱**的情况。 ![css层级](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/46602888bf77416ea8b2c9b4ccbaaa2c~tplv-k3u1fbpfcp-zoom-1.image) - 为了纠正这种错误的交叠顺序，浏览器必须让原本应该“盖在”上边的**渲染层**也同时提升为合成层。这称为**隐式合成**。渲染层提升为合成层之后，会给我们带来不少好处： - 合成层的位图，会交由 **GPU** 合成，比 **CPU** 处理要快得多； - 当需要重绘时，只需要**重绘本身**，不会影响到其他的层； - 元素提升为合成层后，**transform** 和 **opacity** 才不会触发重绘，如果不是合成层，则其依然会触发重绘。当然了，任何东西滥用都是会有副作用，例如： - 绘制的图层必须传输到 **GPU**，这些层的数量和大小达到一定量级后，可能会导致传输非常慢，进而导致一些低端和中端设备上出现闪烁。 - **隐式合成**容易产生过量的合成层，每个合成层都占用额外的内存，形成层爆炸。占用 **GPU** 和大量的**内存资源**，严重损耗页面性能。而内存是**移动设备**上的宝贵资源，过多使用内存可能会导致浏览器崩溃，让性能优化**适得其反**。 OK，大概知道了**浏览器的渲染原理**后，我们来看下如何在实际中去**减少回流和重绘**： - 始终在**图像上**设置宽度和高度属性：浏览器会在默认情况下会分配框并保留空间，后续图片资源加载完成后不需要回流。 - **避免多次修改**：例如我们需要修改一个 **DOM** 的 **height/width/margin** 三个属性，这时候我们可以通过 **cssText** 去修改，而不是通过 **dom.style.height** 去修改。 - **批量修改 DOM**：将 **DOM** 隐藏或者克隆出来修改后再替换，不过现在浏览器会用队列来存储多次修改，进行优化。这个是适用范围已经不是那么广了。 - **脱离文档流**：对于一些类似动画之类的频繁变更的 **DOM** 可以使用绝对定位将其脱离文档流，避免父元素频繁回流。 ### （6）尝试重新组合你的 CSS 规则根据[CSS and Network Performance](https://link.juejin.cn/?target=https://csswizardry.com/2018/11/css-and-network-performance/)的研究，按照**媒体查询**条件把 **CSS** 文件进行拆分可能对我们的页面性能有一定提升。这样，浏览器会使用高优先级检索关键CSS，使用**低优先级**处理其他的所有内容。 ``` // 我们把所有的css放在一个文件中 ``` 我们把所有的css放在一个文件中，浏览器会这样处理他： ![所有的css放在一个文件中，浏览器会这样处理他](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1003807af4ea42b18cfe41e6f100b60c~tplv-k3u1fbpfcp-zoom-1.image) ___ ``` // 当我们将其拆分成按 media 查询的时候 ```` 当我们将其拆分成按 media 查询的时候，浏览器会这样： ![将其拆分成按 media 查询的时候，浏览器会这样](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6e4362e51148423aab6b5bc1ed44985c~tplv-k3u1fbpfcp-zoom-1.image) 避免在 **CSS** 文件中使用 **@import**，因为它的工作原理，会影响浏览器的**并行下载**。不过目前我们更多使用的是 **scss**、**less**他们会将 **@import** 的文件直接包含在 **CSS** 中，并不会产生额外的 **HTTP** 请求。另外，不要将 < link rel="stylesheet"> 放在 **async** 代码段之前。如果 **JavaScript** 脚本不依赖于样式，可以考虑将异步脚本置于样式之上。如果存在依赖，可以将 **JavaScript** 分成两部分，将它们分别放到 **CSS** 的两边来加载。动态样式也可能会有很高的代价，虽然因为 **React** 的性能很好，所以通常只会发生在大量组合组件并行渲染时才会出现这种情况。根据 [The unseen performance costs of modern CSS-in-JS libraries in React apps](https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/) 的研究，在 **production** 模式开启时，通过 **CSS-in-JS** 创建的组件可能会比常规的 **React** 组件多花一倍的渲染时间。所以在应用 **CSS-in-JS** 时，可以采用以下方案来提升你的程序性能： - **不要过度的组合嵌套样式组件**：这可以让 **React** 需要管理的组件**更少**，可以更快的完成渲染工作 - **优先使用“静态”组件**：一些 **CSS-in-JS** 库会在你的 **CSS** 没有**依赖主题**或 **props** 的情况下优化其执行。你的标签模板越是「静态」，你的 **CSS-in-JS** 运行时就越有可能执行得更快。 - **避免无效的React重新渲染**：确保只在需要的时候才渲染，这样可以避免 **React** 和 **CSS-in-JS** 库的运行时工作。 - **零运行时的 CSS-in-JS 库是否能适用于你的项目**：有时我们会选择在 **JS** 中编写 **CSS**，因为它确实提供了一些很好的**开发者体验**，同时我们又不需要访问额外的**JS API**。如果你的应用程序不需要对主题的支持，也不需要使用大量复杂的 **CSS props**，那么零运行时的 **CSS-in-JS** 库可能是一个很好的选择。使用零运行时的库，你能从你的 **bundle** 文件中减少 **12KB**，因为大多数 **CSS-in-JS** 库的大小在 **10KB-15KB** 之间，而零运行时的库（如 linaria）**小于1KB**。 ## 4.网络优化 ### （1）资源放 CDN **CDN（Content Delivery Network）是指内容分发网络**，也称为内容传送网络。由于**CDN**是为加快网络访问速度而被优化的**网络覆盖层**，因此被形象地称为"网络加速器"。你可以简单理解，你人在**北京**，访问的就是北京的**服务器节点**，人在**成都**，访问的就是成都的**服务器节点**。 **CDN**最适合部署**静态资源**，最大限度地**减少**了互联网因为**地域、运营商的差异而带来的网络损耗**。它还有**额外的优点**，你自己的服务可能得考虑下同时**十万个用户访问**会不会崩，用它就不用担心了，不用考虑**负载均衡**，不用考虑**高可用**，专业的人干专业的事。 ![资源放 CDN](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ab19fa19daff4c8c8fc764a3196cf678~tplv-k3u1fbpfcp-zoom-1.image) ### （2）HTTP缓存再试想这样一个场景，假设你的网页万年不变，那是不是**用户**除首次外，接下来的每一次对你**服务器**的访问都是浪费呢？针对这种情况，相信你也很容易想出**解决方案**，也就是我们下一个关键词——**HTTP缓存**。 **HTTP** 缓存分为以下两种，两者都是通过 **HTTP 响应头**控制缓存。 #### 强制缓存再次请求时无需再向服务器发送请求 ``` client server GET /a.ab389z.js -------> <------- 200 OK (再也不会发请求) ``` 与之相关的 Response Headers 有以下两个： - Expires 这个头部很严格：使用绝对时间，且有固定的格式。 Expires: Mon, 25 Oct 2021 20:11:12 GMT - Cache-Control，具有强大的缓存控制能力。常用的有以下两个: - no-cache，每次请求需要校验服务器资源的新鲜度。 - max-age=31536000，浏览器在一年内都不需要向服务器请求资源。 #### 协商缓存再次请求时，需要向服务器校验新鲜度，如果资源是新鲜的，返回 304，从浏览器获取资源 ``` client server GET /a.js -----------> <----------- 200 OK GET /a.js -----------> <----------- 304 Not Modified ``` 与之相关的 Request/Response Headers 有以两个： - Last-Modified/If-Modified-Since，匹配 Response Header 的 Last-Modified 与 Request 的 If-Modified-Since 是否一致。 - Etag/If-None-Match，匹配 Response Header 的 Etag 与 Request 的 If-None-Match 是否一致。 ### （3）ServiceWorker 现代浏览器除了**强缓存**和**协商缓存**外，还额外提供了一些**API**可以让你订制控制缓存。我们熟知的浏览器的存储有哪些呢？最早的**Cookie**，到后面的**LocalStorage**、**SessionStorage**，再到浏览器的数据库**IndexedDB**。直接用它们可以实现对缓存的部分控制，但你没办法拦截网络的加载，比如页面都还没加载，你的代码都没工作，怎么拦截这个JS或图片说**不再加载**了？而**ServiceWorker**（简称sw），就是应运而生的一个高级缓存控制器。一句话描述的话，它就是**浏览器提供的代理**。网页的所有**网络请求**，都经它"中转"，这角色像不像**曹公公**？ ![曹公公插图](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ccadd823c6e14406a647eecd30fd2400~tplv-k3u1fbpfcp-zoom-1.image) 它是基于**web worker**的，可以访问**cache**和**indexedDB**。 sw 是基于 **HTTPS** 的，因为**Service Worker**中涉及到请求拦截，所以必须使用**HTTPS**协议来保障安全。如果是本地调试的话，**localhost**是可以的。一般来说，它可以有效提升用户的**弱网体验**，移动端网页用的多些。使用上也简单，只是维护起来并不容易，一般需要**框架**或**第三方库**来管理。 ```c // html if ('serviceWorker' in navigator) { window.addEventListener('load', function () { navigator.serviceWorker.register('./serviceWorker.js', { scope: './demo.html' }) .then(function (registration) { console.log('ServiceWorker registration successful with scope: ', registration.scope); }) .catch(function (err) { console.log('ServiceWorker registration failed: ', err); }); }); } ``` ```c // serviceWorker.js /* 监听安装事件，install 事件一般是被用来设置你的浏览器的离线缓存逻辑 */ this.addEventListener('install', function (event) { /* 通过这个方法可以防止缓存未完成，就关闭serviceWorker */ event.waitUntil( /* 创建一个名叫V1的缓存版本 */ caches.open('v1').then(function (cache) { /* 指定要缓存的内容，地址为相对于跟域名的访问路径 */ return cache.addAll([ './demo.html', './demo.js', './demo.css', './demo2.js', '/images/demo.jpg', ]); }) ); }); /* 注册fetch事件，拦截全站的请求 */ this.addEventListener('fetch', function (event) { event.respondWith( caches.match(event.request).then(function (response) { return response || fetch(event.request); }) ); }); ``` - 页面刷新一次后，在浏览器的**Application**里能看到**Service Workers**多了一条： ![Service Workers](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/283e898dc7ce4c2c9218f6419a1b0258~tplv-k3u1fbpfcp-zoom-1.image) - 而网络里**Size**多了个标志： ![Service Workers](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/178207297f1d4dbe939c695722b3a1f8~tplv-k3u1fbpfcp-zoom-1.image) - 而**Timing**里也多了： ![Timing](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/66b75ecd45934ceb947b693f2f1d1d9c~tplv-k3u1fbpfcp-zoom-1.image) > 注意：如果你只是做测试，**sw**开启后最好到**Application**里把它注销掉，否则说不定会影响你的开发（如果你注册的端口号和网页刚好与现在的一样了）。 ### （4）启用 OCSP stapling 在服务器上启用 **OCSP stapling** 功能，可实现由全站加速预先缓存在线证书验证结果并下发给客户端，无需浏览器直接向 **CA站点** 查询证书状态，从而减少用户验证时间。 ### （5）HTTP协议优化随着 **HTTPS** 及 **HTTP/2** 的流行，很多 **HTTP/1.1** 时代的优化策略已经不奏效了，甚至还有反优化的作用。这里我们顺带把各个版本的 **HTTP** 协议做一下简单的分析： - HTTP/1.0 - 浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个**TCP**连接（**TCP连接的新建成本很高，因为需要客户端和服务器三次握手**），服务器完成请求处理后立即断开**TCP**连接，服务器不跟踪每个客户也不记录过去的请求。 - HTTP/1.1 - **管道化（Pipelining）**：提出管道化方案解决连接延迟，服务端可设置 **Keep-Alive** 来让连接延迟关闭时间，但因为浏览器自身的 **Max-Connection** 最大连接限制，同一个域名下的请求连接限制（同域下谷歌浏览器是一次限制最多6个连接），只能通过多开域名来实现，这也就是我们的静态资源选择放到 **CDN** 上或其它域名下，来提高资源加载速度。管道化方案需要前后端支持，但绝大部分的**HTTP代理器**对管道化的支持并不友好。 - **只支持GET/HEAD**：管道化只支持 **GET / HEAD**方式传送数据，不支持 **POST** 等其它方式传输。 - **头部信息冗余**：**HTTP** 是无状态的，客户端/服务端只能通过 **HEAD** 的数据维护获取状态信息，这样就造成每次连接请求时都会携带大量冗余的头部信息，头部信息包括 **COOKIE** 信息等。 - **超文本协议**：**HTTP/1.X** 是超文本协议传输。超文本协议传输，发送请求时会找出数据的**开头和结尾帧**的位置，并去除多余空格，选择最优方式传输。如果使用了 **HTTPS**，那么还会对数据进行**加密处理**，一定程度上会造成**传输速度**上的损耗。 - **队头阻塞**: 管道化通过延迟连接关闭的方案，虽然可同时发起对**服务端**的多个请求，但服务端的 **response** 依旧遵循 **FIFO**（先进先出)规则依次返回。举个例子客户端发送了1、2、3、4四个请求，如果1没返回给客户端，那么2，3，4也不会返回。这就是所谓的「队头阻塞」。**高并发高延迟**的场景下阻塞明显。 - HTTP/2.0 - **多路复用**：一个域只要一个 **TCP** 连接，实现真正的并发请求，降低延时，提高了带宽的利用率。 - **头部压缩**：客户端/服务端进行渐进更新维护，采用 **HPACK** 压缩，节省了报文头占用流量。 1.相同的头部信息不会通过请求发送，延用之前请求携带的头部信息。 2.新增/修改的头部信息会被加入到 **HEAD** 中，两端渐进更新。 - **请求优先级**：每个流都有自己的优先级别，客户端可指定优先级。并可以做流量控制。 - **服务端推送**：例如我们加载 **index.html**, 我们可能还需要**index.js**, **index.css**等文件。传统的请求只有当拿到**index.html**，解析**html**中对**index.js/index.css**的引入才会再请求资源加载，但是通过服务端数据，可以提前将资源推送给客户端，这样客户端要用到的时候直接调用即可，不用再发送请求。 - **二进制协议**：采用**二进制协议**，区别与**HTTP/1.X**的超文本协议。客户（服务）端发送（接收）数据时，会将**数据打散乱序**发送，接收数据时接收一端再通过 **streamID** 标识来将数据合并。二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。 > 这里再补充一下 **HTTP2** 相对于 **HTTP1.1** 并不全是优点：因为 **HTTP2** 将多个 **HTTP** 流放在同一个 **TCP** 连接中，遵循同一个流量状态控制。只要第一个 **HTTP** 流遇到阻塞，那么后面的 **HTTP** 流压根没办法发出去，这就是「行头阻塞」。 - HTTP/3.0 采用 **QUIC** 协议，基于 **UDP** 协议，避免了 **TCP** 协议的一些缺点，采用 **TLS1.3** 将 **HTTPS** 所需的 **RTT** 降至最少为0。 - TCP 协议的不足 - **TCP** 可能会间歇性地挂起数据传输：如果一个序列号较低的**数据段**还没有接收到，即使其他序列号较高的段已经接收到，TCP 的接收机滑动窗口也不会继续处理。这将导致TCP 流瞬间挂起，在更糟糕的情况下，即使所有的段中有一个没有收到，也会导致关闭连接。这个问题被称为 **TCP** 流的行头阻塞（HoL）。 ![TCP间歇性地挂起数据传输](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/db929119a62548b4b2cb73dd8884b7e7~tplv-k3u1fbpfcp-zoom-1.image) - **TCP 不支持流级复**：虽然 **TCP** 确实允许在**应用层**之间建立多个逻辑连接，但它不允许在一个 **TCP** 流中复用数据包。使用 **HTTP/2** 时，浏览器只能与服务器打开一个 **TCP** 连接，并使用同一个连接来请求多个对象，如 **CSS**、**JavaScript** 等文件。在接收这些对象的同时，**TCP** 会将所有对象序列化在同一个流中。因此，它不知道 **TCP**段的对象级分区。 - **TCP 会产生冗余通信**：**TCP** 连接握手会有冗余的消息交换序列，即使是与已知主机建立的连接也是如此。 ![TCP 会产生冗余通信](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/22c4a2c54c3a4bdea0b4ca708c0e8f27~tplv-k3u1fbpfcp-zoom-1.image) - QUIC 协议的优势 - **选择UDP作为底层传输层协议**：在 **TCP** 之上建立新的传输机制，将继承 **TCP** 的上述所有缺点。因此，**UDP** 是一个明智的选择。此外，**QUIC** 是在用户层构建的，所以不需要每次协议升级时进行内核修改。 - **流复用和流控**：**QUIC** 引入了连接上的多路流复用的概念。 **QUIC** 通过设计实现了单独的、针对每个流的流控，解决了整个连接的行头阻塞问题。 - **灵活的拥塞控制机制**：**TCP** 的拥塞控制机制是刚性的。该协议每次检测到拥塞时，都会将拥塞窗口大小减少一半。相比之下，**QUIC** 的拥塞控制设计得更加灵活，可以更有效地利用可用的网络带宽，从而获得更好的**吞吐量**。 - **更好的错误处理能力**：**QUIC** 使用增强的丢失**恢复机制**和**转发纠错**功能，以更好地处理错误数据包。该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音，因为这些网络用户在传输过程中经常出现**高错误率**。 - **更快的握手**：**QUIC** 使用相同的 **TLS** 模块进行安全连接。然而，与 **TCP** 不同的是，**QUIC** 的握手机制经过优化，避免了每次两个已知的对等者之间**建立通信时**的冗余协议交换。 ![QUIC 协议的优势](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b28050c16cec4d2eab38d4ea645f52f8~tplv-k3u1fbpfcp-zoom-1.image) > 这里大概给两条公式看下 **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** 的时代下，哪些优化策略已经过时了甚至是反优化呢？ **减少请求数**：**HTTP/1.1** 因为存在「队头阻塞」，所以我们通常会采用合并资源，捆绑文件（雪碧图等）等方式来减少请求数。但在 **HTTP/2** 中我们更需要注重网站的缓存调优，传输轻量、细粒度的资源，方便独立缓存和并行传输。 **多域名存储**：**HTTP/1.1** 因为浏览器有最大连接数限制，所以我们会将资源分发到不同的域名下存放以此来增大最大连接数。但在 **HTTP/2** 中一个域只有一个链接，所以我们不需要去分多个域名存储，多域名存储甚至还会造成额外的 **TLS** 消耗。 ### （6）减小请求头的大小减小**请求头**的大小，常见的情况是 **Cookie** 。例如我们的主站中（如：www.test.com ）存储了很多的 **Cookie**，我们的 **CDN** 域名（cdn.test.com）与我们主域一样，此时我们去请求时会附带上 **.test.com**域下的 **Cookie**。而且这些 **Cookie** 对于 **CDN** 毫无用处，会增大我们请求的包大小。所以我们可以将 **CDN** 域名与主域区分开，例如：淘宝（https://www.taobao.com）的 **CDN** 域名为 https://img.alicdn.com。 # 总结 > 感谢屏幕前的你看到了这里！我从“为什么要进行性能优化” => “查看性能指标” => “罗列 Web 优化的一些方法”三个方面完成了本篇文章，随着**Web3.0**时代的到来，性能优化已经成为我们开发过程中的**重中之重**。有了这些**优化的点**，相信你在**写代码**或者**优化老项目时**都能游刃有余，能提前考虑到其中的一些坑，并且规避。注意：“鞋合不合适只有脚知道”，我们在对项目进行优化之前，一定要问自己或者团队一个问题 —— 是否合适 # 相关资料 [为什么速度很重要？](https://web.dev/vitals/#core-web-vitals) [最全的前端性能定位总结](https://juejin.cn/post/7052918009555320839) [web性能优化](https://wiki.uino.com/d/6234531d0dc1b7f991482139.html) [CSR、SSR、NSR、ESR傻傻分不清楚，一文帮你理清前端渲染方案！](https://juejin.cn/post/6844904178519834638) [什么是强缓存和协商缓存](https://juejin.cn/post/7131237076065845256) [你会怎么做前端优化？](https://juejin.cn/post/7028028584463695879) > 水平有限，还不能写到尽善尽美，希望大家多多交流，跟春野一同进步！！！