关于程序员:性能优化之关键渲染路径

不要再问“那怎么可能”，而是问“为什么不能”

大家好，我是 柒八九。

明天，咱们来谈谈，浏览器的 要害渲染门路 。针对浏览器的一些其余文章，咱们后面有介绍。别离从 浏览器架构 和最新的渲染引擎 介绍了对于页面渲染的相干概念。对应连贯如下。

页面是如何生成的(宏观角度)
Chromium 最新渲染引擎 –RenderingNG
RenderingNG 中要害数据结构及其角色

而明天的配角是 {要害渲染门路 | Critical Rendering Path}。它是影响页面在加载阶段的次要规范。

这里再啰嗦一点，通常一个页面有 三个阶段

加载阶段
- 是指从 发出请求到渲染出残缺页面 的过程
- 影响到这个阶段的次要因素有网络和 JavaScript 脚本
交互阶段
- 次要是从页面加载实现到 用户交互 的整个过程
- 影响到这个阶段的次要因素是 JavaScript 脚本
敞开阶段
- 次要是用户收回敞开指令后页面所做的一些 清理操作

好了，工夫不早了。开干。

要害渲染门路的各种指标

{要害资源 | Critical Resource}：所有可能 妨碍页面渲染 的资源

{要害门路长度 |Critical Path Length}：获取构建页面所需的所有要害资源所需的 RTT（Round Trip Time）

{关键字节 | Critical Bytes}：作为实现和构建页面的一部分而传输的 字节总数。

重温 HTTP 缓存

针对要害渲染门路进行各种优化解决

针对 React 利用做优化解决

DOM: 是 HTML 页面在解析后，基于对象的表现形式。

DOM是一个利用编程接口（API），通过创立示意文档的树, 以一种 独立于平台和语言 的形式拜访和批改一个页面的内容和构造。

在 HTML 文档中，Web 开发者能够应用 JS 来 CRUD DOM 构造，其次要的目标是动静扭转 HTML 文档的构造。

DOM 将整个 HTML 页面形象为一组分层节点

DOM 并非只能通过 JS 拜访, 像 {可伸缩矢量图 | SVG}、{数学标记语言 | MathML} 和 {同步多媒体集成语言 | SMIL} 都减少了该语言独有的 DOM 办法和接口。

一旦 HTML 被解析，就会建设一个 DOM 树。

上面的代码有三个区域：header、main和 footer。并且style.css 为内部文件。

<html>
  <head>
  <link rel="stylesheet" href="style.css">
  <title> 要害渲染门路示例 </title>
  <body>
    <header>
      <h1>...</h1>
      <p>...</p>
    </header>
    <main>
         <h1>...</h1>
         <p>...</p>
    </main>
    <footer>
         <small>...</small>
    </footer>
  </body> 
  </head>
</html>

当上述 HTML 代码被浏览器解析为 DOM 树 状构造时，其各个节点的关系如下。

每个浏览器都 须要一些工夫解析 HTML。并且，清晰的语义标记 有助于缩小浏览器解析 HTML 所需的工夫。(不残缺或者谬误的语义标记，还须要浏览器依据 上下文 去剖析和判断)

具体，浏览器是如何将 HTML 字符串信息，转换成可能被 JS 操作的 DOM 对象，不在此文的探讨范畴内。不过，咱们能够举一个很小的例子。在咱们 JS 算法探险之栈 (Stack) 中，有一个题就是 如何判断括号的正确性。

给定一个只包含 ‘(‘，’)’，'{‘，’}’，'[‘,’]’ 的字符串 s，判断字符串是否无效。无效字符串需满足：

左括号必须用雷同类型的右括号闭合。

左括号必须以正确的程序闭合。

示例：

输出：s = “()[]{}” 输入：true

输出：s = “(]” 输入：false

其实，下面的例子就是最简略的一种标签匹配。或者说的稳当点，它们的次要思维是统一的。

CSSOM也是一个基于对象的树。它 负责解决与 DOM 树相干的款式。

承接上文，咱们这里有和下面 HTML 配套的 CSS 款式。

header{
   background-color: white;
   color: black;
}
p{font-weight:400;}
h1{font-size:72px;}
small{text-align:left}

对于上述 CSS 申明，CSSOM 树 将显示如下。

因为，css的局部属性可能被继承，所以，在父级节点定义的属性，如果满足状况，子节点也是会有对应的属性信息，最初将对应的款式信息，渲染到页面上。

一般来说，CSS 被认为是一种 {阻断渲染 | Render-Blocking} 资源。

什么是 渲染阻断 ？渲染阻塞资源是一个组件，它将 不容许浏览器渲染整个 DOM 树，直到给定的资源被齐全加载。
CSS 是一种渲染阻断资源，因为在 CSS 齐全加载之前，你无奈渲染树。

起初，页面中所有 CSS 信息都被寄存在一个文件中 。当初，开发人员通过一些技术手段，可能将CSS 文件宰割开来，只在渲染的晚期阶段提供要害款式。

先将一个小知识点，其实，在后面的文章中，咱们曾经讲过了。这里，咱们再啰嗦一遍。

在 浏览器环境下，JS = ECMAScript + DOM + BOM。

JS 的 外围局部，即 ECMA-262 定义的语言，并不局限于 Web 浏览器。

Web 浏览器只是 ECMAScript 实现可能存在的一种 {宿主环境 | Host Environment}。而宿主环境提供 ECMAScript 的 基准实现 和与 环境本身交互必须的扩大。(比方 DOM 应用 ECMAScript 外围类型和语法，提供特定于环境的额定性能)。

像咱们比拟常见的 Web 浏览器、Node.js 和曾经被淘汰的 Adobe Flash都是 ECMA 的宿主环境。

ECMAScript 只是对实现 ECMA-262 标准的一门语言的称说，JS 实现了 ECMAScript，Adobe ActionScript 也实现 ECMAScript。

下面的内容只是做一个知识点的补充，咱们这篇文章中呈现的 JS 还是个别意义上的含意：即 javascript 文本信息。

JavaScript 是一种用来操作 DOM 的语言 。这些 操作破费工夫 ，并减少网站的整体 加载工夫。所有，

JavaScript 代码被称为 {解析器阻塞 | Parser Blocking} 资源。

什么是 解析器阻塞 ？当须要下载和执行 JavaScript 代码时，浏览器会 暂停执行和构建 DOM 树。当 JavaScript 代码被执行完后，DOM 树的构建才持续进行。

所以才有，JavaScript是一种低廉的资源 的说法。

上面是一段 HTML 代码的演示后果，显示了一些文字和图片。正如你所看到的，整个页面的显示只花了大概 40ms。即便有一张图片，页面显示的工夫也更短。这是因为在进行 第一次绘制 时，图像没有被当作要害资源。

记住，

{要害渲染门路 | Critical Rendering Path} 都是 对于 HTML、CSS 和Javascript的

当初，在这段代码中增加 css。正如下图所示，一个 额定的申请被触发 了。只管加载 html 文件的工夫缩小了，但解决和显示页面的总体工夫却减少了近 10 倍。为什么呢？

一般的 HTML 并不波及太多的 资源获取 和解析工作 。然而， 对于 CSS 文件，必须构建一个 CSSOM。HTML 的 DOM 和 CSS 的 CSSOM 都必须被构建。这无疑是一个耗时的过程。
JavaScript 很有可能会查问 CSSOM。这意味着，在执行任何 JavaScript 之前，CSS 文件必须被齐全下载和解析。

留神：domContentLoaded 在HTML DOM 被齐全解析和加载时被触发 。该事件不会期待image、子frame 甚至是样式表被齐全加载。惟一的指标是文档被加载 。能够在window 中增加事件，以查看 DOM 是否被解析和加载。

window.addEventListener('DOMContentLoaded', (event) => {console.log('DOM 被解析且加载胜利');
});

即便你抉择用 内联脚本取代内部文件 ，性能也不会有大的扭转。次要是因为须要构建CSSOM。如果你思考应用内部脚本，能够增加 async 属性。这将 解除对解析器的阻断。

{要害资源 | Critical Resource}：所有可能 妨碍页面渲染 的资源
{要害门路长度 |Critical Path Length}：获取构建页面所需的所有要害资源所需的 RTT（Round Trip Time）
- 当应用 TCP 协定传输一个文件时，因为 TCP 的个性，这个数据并不是一次传输到服务端的，而是须要拆分成一个个数据包来回屡次进行传输的
- RTT 就是这里的 往返时延
 - 它是网络中一个 重要的性能指标 示意从发送端发送数据开始，到发送端收到来自接收端的确认，总共经验的时延
- 通常 1 个 HTTP 的数据包在 14KB 左右
 - 首先是申请 HTML 资源，假如大小是 6KB，小于 14KB，所以 1 个 RTT 就能够解决
- 至于 JavaScript 和 CSS 文件
 - 因为渲染引擎有一个 预解析的线程 , 在接管到 HTML 数据之后, 预解析线程会 疾速扫描 HTML 数据中的要害资源, 一旦扫描到了，会立马发动申请
 - 能够认为 JavaScript 和 CSS 是 同时发动申请 的, 所以它们的 申请是重叠的 ，计算它们的 RTT 时, 只须要计算体积最大的那个数据 就能够了
{关键字节 | Critical Bytes}：作为实现和构建页面的一部分而传输的 字节总数。

在咱们的第一个例子中，如果是 一般的 HTML 脚本，下面各个指标的值如下

1 个要害资源(html)
1 个 RTT
192 字节的数据

在第二个例子中，一个 一般的 HTML 和内部 CSS 脚本，下面各个指标的值如下

2 个要害资源(html+css)
2 个 RTT
400 字节的数据

如果你心愿优化任何框架中的要害渲染门路，你须要在上述指标上下功夫并加以改进。

优化要害资源

将 JavaScript 和 CSS 改成内联的模式（性能晋升不是很大）

如果 JavaScript 代码没有 DOM 或者 CSSOM 的操作, 则能够改成 sync 或者 defer 属性

首屏内容能够优先加载，非首屏内容采纳 滚动加载

优化要害门路长度

压缩 CSS 和 JavaScript 资源

移除 HTML、CSS、JavaScript 文件中一些 正文内容

优化关键字节

通过缩小要害资源的个数和缩小要害资源的大小搭配来实现

应用 CDN 来缩小每次 RTT 时长

加载的要害是 “ 懒加载 ”。任何媒体资源、CSS、JavaScript、图像、甚至 HTML 都能够被懒加载。每次加载 无限的页面的内容，能够进步要害渲染门路。

不要在加载页面时加载这个整个页面的 CSS、JavaScript 和 HTML。
相同，能够为一个 button 增加一个事件监听，只有在用户点击按钮时才加载脚本。
应用 Webpack 来实现懒加载性能。

这里有一些利用纯 JavaScript 实现懒加载的技术。

比方，当初又一个 <img/>/<iframe/> 在这些状况下，咱们能够利用<img> 和<iframe>标签 附带的默认 loading 属性 。当浏览器看到这个标签时，它会 推延加载 iframe 和image。具体语法如下：

<img src="image.png" loading="lazy">
<iframe src="abc.html" loading="lazy"></iframe>

留神：loading=lazy的懒加载不应该用在非滚动视图上。

不能利用 loading=lazy 的浏览器中，你能够应用IntersectionObserver。这个 API 设置了一个根，并为每个元素的可见性配置了根的比率。当一个元素在视口中是可见的，它就会被加载。

IntersectionObserverEntry 对象提供指标元素的信息，一共有六个属性。
每个属性的含意如下。

time：可见性发生变化的工夫，是一个高精度工夫戳，单位为毫秒

target：被察看的指标元素，是一个 DOM 节点对象

rootBounds：根元素的矩形区域的信息，getBoundingClientRect()办法的返回值，如果没有根元素（即间接绝对于视口滚动），则返回 null

boundingClientRect：指标元素的矩形区域的信息

intersectionRect：指标元素与视口（或根元素）的穿插区域的信息

intersectionRatio：指标元素的可见比例，即 intersectionRect 占boundingClientRect的比例，齐全可见时为 1，齐全不可见时小于等于 0

咱们察看所有具备 .lazy 类的元素。
当具备 .lazy 类的元素在视口上时，相交率会降到零以下。如果相交率为零或低于零，阐明指标不在视口内。而且，不须要做什么。

var intersectionObserver = new IntersectionObserver(function(entries) {if (entries[0].intersectionRatio <= 0) return;

  //intersection ratio 在 0 上，阐明在视口上能看到
  console.log('进行加载解决');
});
// 针对指标 DOM 进行解决
intersectionObserver.observe(document.querySelector('.lazy));

留神：Async 和 Defer 是用于内部脚本的属性。

当应用 Async 时，将容许浏览器在下载 JavaScript 资源时做其余事件。一旦下载实现 ，下载的JavaScript 资源将被执行。

JavaScript 是 异步下载 的。
所有其余脚本的执行将被暂停。
DOM 渲染将同时产生。
DOM 渲染将只在脚本执行时暂停。
渲染阻塞的 JavaScript 问题能够应用 async 属性来解决。

如果一个资源不重要，甚至不要应用 async，齐全省略它

<p>... 执行脚本之前，能看到的内容...</p>

<script>
  document.addEventListener('DOMContentLoaded', () => alert("DOM 被构建实现!"));
</script>

<script async src=""></script>

<p>... 上述脚本执行完，能力看到此内容 ...</p>

当应用 Defer 时，JavaScript 资源将在 HTML 渲染时被下载。然而，执行不会在脚本被下载后立刻产生。相同，它会期待 HTML 文件被齐全渲染。

脚本的执行只产生在渲染实现之后。
Defer 能够使你的 JavaScript 资源相对不会阻断渲染

<p>... 执行脚本之前，能看到的内容...</p>

<script defer src=""></script>

<p>... 此内容不被 js 所阻塞，也就是说能立刻看到...</p>

当应用 Preload 时，它被用于 HTML 文件中没有的文件，但在渲染或解析 JavaScript 或 CSS 文件的时候。有了Preload，浏览器就会下载资源，在资源可用的时候就会执行。

应用Prelaod。浏览器会下载文件，即便它在你的页面上是不必要的。
太多的预载会使你的页面速度降落。
当有太多的预载文件时，应用预载的固有优先权将受到影响。
只有在首屏页面须要的文件才能够预载。
预载文件会在其余文件被渲染时才会被发现。例如，你在一个 CSS 文件内增加一个字体的援用。在 CSS 文件被解析之前，对字体的存在不会被晓得。如果该字体被提前下载，它将进步你的网站速度。
预加载只用于 <link> 标签。

<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">

原生 JS 领有很好的性能和可拜访性。对于一个特定的用例，你不须要全盘的依赖第三方脚本。尽管这些库往往能解决一堆问题，然而依附惨重的库来解决简略的问题会导致你的代码性能降落。

咱们的要求不是防止应用框架和编写 100% 的新代码。咱们的要求是应用辅助函数和小规模的插件。

如果资源在你的页面上被 重复应用 ，那么始终加载它们将是一种折磨。这相似于每次都在加载网站。缓存将有助于避免这种循环。在HTTP 响应头 中给内容提供过期信息, 只有在它们过期时才加载。

咱们之前在网络拾遗之 Http 缓存就介绍过，对于 http 缓存的知识点，我就间接拿来主义了。

最好最快 的申请就是 没有申请

浏览器对 动态资源 的缓存实质上是 HTTP 协定的缓存策略，其中又能够分为 强制缓存 和协商缓存。

两种缓存策略都会 将资源缓存到本地

强制缓存策略依据 过期工夫 决定应用本地缓存还是申请新资源：
协商缓存每次都会 发出请求 ，通过 服务器进行比照 后决定采纳本地缓存还是新资源。

具体采纳哪种缓存策略，由 HTTP 协定的首部（Headers）信息决定。

在网络通信之生成 HTTP 音讯中咱们介绍过，音讯头依照用处可分为 四大类
1. 通用头 ：实用于申请和响应的头字段
2. 申请头 ：用于示意申请音讯的附加信息的头字段
3. 响应头 ：用于示意响应音讯的附加信息的头字段
4. 实体头 ：用于 音讯体 的附加信息的头字段

咱们对 HTTP 缓存用到的字段进行一次简略的分类和汇总。

| 头字段 | 所属分组 |
| — | — |
| Expires | 实体头 |
| Cache-control | 通用头 |
| ETag | 实体头 |

ETag: 在 更新操作 中，有时候须要基于 上一次申请的响应数据 来发送下一次申请。在这种状况下，这个字段能够用来提供上次响应与下次申请之间的 关联信息。上次响应中，服务器会通过 Etag 向客户端发送一个惟一标识，在下次申请中客户端能够通过 If-Match、If-None-Match、If-Range 字段将这个标识告知服务器，这样服务器就晓得该申请和上次的响应是相干的。

这个字段的 性能和 Cookie 是雷同 的，但 Cookie 是网景（Netscape）公司自行开发的规格，而 Etag 是将其进行标准化后的规格

Expires和 Cache-control:max-age=x 是 强制缓存 策略的要害信息，两者均是 响应首部信息 (后端返给客户端) 的。

Expires 是 HTTP 1.0 退出的个性，通过指定一个 明确的工夫点 作为缓存资源的过期工夫，在此工夫点之前客户端将应用本地缓存的文件应答申请，而不会向服务器收回实体申请。

Expires 的长处:

能够在缓存过期工夫内缩小客户端的 HTTP 申请
节俭了客户端解决工夫和进步了 Web 利用的执行速度
缩小了 服务器负载 以及客户端网络资源的耗费

对应的语法

Expires: <http-date>

<http-date>是一个 HTTP- 日期工夫戳

Expires: Wed, 24 Oct 2022 14:00:00 GMT

上述信息指定对应资源的 缓存过期工夫 为 2022 年 8 月 24 日 14 点

Expires 一个 致命的缺点 是：它所指定的工夫点是以 服务器为准 的工夫，然而 客户端进行过期判断 时是将 本地的工夫与此工夫点比照。

如果客户端的工夫与服务器存在误差，比方服务器的工夫是 2022 年 8 月 23 日 13 点，而客户端的工夫是 2022 年 8 月 23 日 15 点，那么通过 Expires 管制的缓存资源将会生效，客户端将会发送实体申请获取对应资源。

针对这个问题，HTTP 1.1 新增了 Cache-control 首部信息以便 更精准 地管制缓存。

罕用的 Cache-control 信息有以下几种。

no-cache:
应用 ETag 响应头来告知客户端（浏览器、代理服务器）这个资源首先须要被查看是否在服务端批改过，在这之前不能被复用。这个 意味着 no-cache 将会和服务器进行一次通信，确保返回的资源没有批改过，如果没有批改过，才没有必要下载这个资源。反之，则须要从新下载。
no-store
在解决资源不能被缓存和复用的逻辑的时候与 no-cache相似。然而，他们之间有一个重要的区别。no-store 要求资源每次都被申请并且下载下来。当在解决隐衷信息（private information）的时候，这是一个重要的个性。
public & private
public示意此响应能够被浏览器以及两头缓存器 无限期缓存 ，此信息并 不罕用 ，惯例计划是应用 max-age 指定准确的缓存工夫
private 示意此响应能够被用户浏览器缓存，然而 不容许任何两头缓存器 对其进行缓存。例如，用户的浏览器能够缓存蕴含用户私人信息的 HTML 网页，但 CDN 却不能缓存。
max-age=<seconds>
指定从 申请的时刻 开始计算，此响应的缓存正本无效的最长工夫（单位：秒）例如，max-age=360 示意浏览器在接下来的 1 小时内应用此响应的本地缓存，不会发送实体申请到服务器
s-maxage=<seconds>
s-maxage 与 max-age相似，这里的 s 代表共享，这个指令个别仅用于 CDNs 或者其余 两头者 （intermediary caches）。这个指令会笼罩 max-age 和expires响应头。
no-transform
两头代理有时会扭转图片以及文件的格局，从而达到进步性能的成果。no-transform指令通知两头代理不要扭转资源的格局

max-age 指定的是缓存的 时间跨度，而非缓存生效的工夫点，不会受到客户端与服务器时间误差的影响。

与 Expires 相比，max-age 能够 更准确地管制缓存 ，并且比 Expires 有 更高的优先级

强制缓存策略下（Cache-control 未指定 no-cache和
no-store）的缓存判断流程

`Etag` 和 `If-None-Match`（协商缓存）

Etag 是 服务器 为资源分配的字符串模式 唯一性标识 ，作为 响应首部 信息返回给浏览器

浏览器 在 Cache-control 指定 no-cache 或者 max-age和 Expires 均过期之后，将 Etag 值通过 If-None-Match 作为 申请首部 信息发送给服务器。

服务器 接管到申请之后，比照所申请资源的 Etag 值是否扭转，如果未扭转将返回 304 Not Modified, 并且依据既定的缓存策略调配新的 Cache-control 信息; 如果资源产生了扭转，则会
返回最新的资源以及 重新分配 的 Etag值。

如果强制浏览器应用协商缓存策略，须要将 Cache-control 首部信息设置为 no-cache，这样便不会判断 max-age和 Expires 过期工夫，从而 每次资源申请都会通过服务器比照。

在纯 JavaScript 中，你能够自在地利用 service workers 来决定是否须要加载数据。例如，我有两个文件：style.css 和 script.js。我须要加载这些文件，我能够应用 service workers 来决定这些资源是否必须放弃最新，或者能够应用缓存。

在 Web 性能优化之 Worker 线程 (上) 咱们有介绍过对于 ServerWork 的具体介绍。如果感兴趣，能够去瞅瞅。

当用户 第一次启动单页应用程序时，装置将被执行。

self.addEventListener('install', function(event) {
  event.waitUntil(caches.open(cacheName).then(function(cache) {
      return cache.addAll(
        [
          'styles.css',
          'script.js'
        ]
      );
    })
  );
});

当用户执行一项操作时

document.querySelector('.lazy').addEventListener('click', function(event) {event.preventDefault();
  caches.open('lazy_posts’).then(function(cache) {fetch('/get-article’).then(function(response) {return response;}).then(function(urls) {cache.addAll(urls);
    });
  });
});

解决网络申请

self.addEventListener('fetch', function(event) {
  event.respondWith(caches.open('lazy_posts').then(function(cache) {return cache.match(event.request).then(function (response) {return response});
    })
  );
});

纸上得来终觉浅，绝知此事要躬行。情理，都懂，咱们来看看在理论开发中，如何做优化解决。咱们按 React 开发为例子。

优化被分成两个阶段。

1. 在应用程序被加载之前
1. 第二阶段是在利用加载后进行优化

让咱们建设一个简略的应用程序，有如下的构造。

Header
Sidebar
Footer

代码构造如下。

webpack-demo
|- package.json
|- package-lock.json
|- webpack.config.js
|- /dist
|- /src
 |- index.js
 |- Header.js
 |- Sidebar.js
 |- Footer.js
 |- loader.js
 |- route.js
|- /node_modules

在咱们的应用程序中，只有当用户登录时，才应该看到侧边栏。Webpack 是一个很好的工具，能够帮忙咱们进行 代码拆分 。如果咱们启用了代码拆分，咱们能够从App.js 或Route组件对 React进行 Lazy 加载解决。

咱们把代码按页面逻辑进行辨别。只有当应用程序须要时，才会加载这些逻辑片段。因而，代码的整体分量放弃较低。

例如，如果 Sidebar 组件只有在用户登录时才会被加载，咱们有几个办法来进步咱们的应用程序的性能。

首先，咱们能够在 路由层面 对代码进行懒加载解决。如上面代码所示，代码被分成了三个逻辑块。只有当用户抉择了一个特定的路由时，每个块才会被加载 。这意味着，咱们的 DOM 在初始绘制时不用将 Sidarbar 代码作为其 Critical Bytes 的一部分。

import { 
    Switch, 
    browserHistory, 
    BrowserRouter as Router, 
    Route
} from 'react-router-dom';
const Header = React.lazy(() => import('Header'));
const Footer = React.lazy(() => import('Footer'));
const Sidebar = React.lazy(() => import('Sidebar'));

const Routes = (props) => {
  return isServerAvailable ? (<Router history={browserHistory}>
         <Switch>
           <Route path="/" exact><Redirect to='/Header' /></Route>
           <Route path="/sidebar" exact component={props => <Sidebar {...props} />} />
           <Route path="/footer" exact component={props => <Footer {...props} />} />
        </Switch>
      </Router>
}

同样地，咱们也能够 从父级 App.js 中实现懒加载 。这利用了React 的条件渲染 机制。

const Header = React.lazy(() => import('Header'));
const Footer = React.lazy(() => import('Footer'));
const Sidebar = React.lazy(() => import('Sidebar'));

function App (props) {
  return(
    <React.Fragment>
       <Header user = {props.user} />
       {props.user ? <Sidebar user = {props.user /> : null}
       <Footer/>
    </React.Fragment>
  )
}

谈到条件渲染，React 容许咱们在点击按钮的状况下也能加载组件。

import _ from 'lodash';
function buildSidebar() {const element = document.createElement('div');
   const button = document.createElement('button');
   button.innerHTML = '登录';
   element.innerHTML = _.join(['加载 Sidebar', 'webpack'], ' ');
   element.appendChild(button);
   button.onclick = e => 
       import(/* webpackChunkName: "sidebar" */ './sidebar')
       .then(module => {
         const sidebar = module.default;
         sidebar()});

   return element;
 }

document.body.appendChild(buildSidebar());

在实践中，重要的是 把所有的路由或组件写在在叫做 Suspense 的组件中 ，以懒加载的形式加载。Suspense 的作用是在懒加载的组件被加载时，为应用程序提供一个 后备内容。后备内容能够是任何货色，比方一个<Loader/>，或者一条音讯，通知用户为什么页面还没有被画进去。

import React, {Suspense} from 'react';
import { 
    Switch, 
    browserHistory, 
    BrowserRouter as Router, 
    Route
} from 'react-router-dom';
import Loader from‘./loader.js’const Header = React.lazy(() => import('Header'));
const Footer = React.lazy(() => import('Footer'));
const Sidebar = React.lazy(() => import('Sidebar'));

const Routes = (props) => {
return isServerAvailable ? (<Router history={browserHistory}>
    <Suspense fallback={<Loader trigger={true} />}>
         <Switch>
           <Route path="/" exact><Redirect to='/Header' /></Route>
           <Route path="/sidebar" exact component={props => <Sidebar {...props} />} />
           <Route path="/footer" exact component={props => <Footer {...props} />} />
         </Switch>
    </Suspense>
</Router>
}

当初，应用程序曾经齐全加载，接下来就到了和谐阶段了。其中的所有的解决逻辑都是 React 为咱们代劳。其中最重要的一点就是 React-Fiber 机制。

如果想理解 React_Fiber，能够参考咱们之前的文章。

每当 React DOM 树 被批改时，它都会 迫使浏览器回流 。这将对你的应用程序的性能产生重大影响。 和谐被用来确保缩小从新流转的次数。同样地，React 应用状态治理来避免重现。例如，你有一个useState()hook。
如果应用的是类组件，利用 shouldComponentUpdate() 生命周期办法。shouldComponentUpdate()必须在 PureComponent 中实现。当你这样做时，state和 props 之间会产生 浅比照。因而，从新渲染的几率大大降低。

React.Memo接管组件，并将 props 记忆化。当一个组件须要从新渲染时，会进行 浅比照。因为性能起因，这种办法被宽泛应用。

function MyComponent(props) {
}
function areEqual(prevProps, nextProps) {
  // 比照 nextProps 和 prevProps，如果雷同，返回 false, 不会产生渲染
  // 如果不雷同，则进行渲染
}
export default React.memo(MyComponent, areEqual);

如果应用函数组件，请应用 useCallback() 和useMemo()。

分享是一种态度。

参考资料：

要害渲染门路
网络拾遗之 Http 缓存
React 官网

全文完，既然看到这里了，如果感觉不错，顺手点个赞和“在看”吧。

本文由 mdnice 多平台公布

关于程序员:性能优化之关键渲染路径

你能所学到的知识点

1. 加载阶段要害数据

<span style=”font-weight:800;color:#FFA500;font-size:18px”>{文档对象模型 | Document Object Model}</span>

CSSOM Tree

执行 JS

ECMAScript

示例演示

要害门路相干术语

缩小渲染器阻塞资源

懒加载

Async, Defer, Preload

应用 Async 解决脚本

应用 Defer 解决脚本

应用 Prelaod 解决内部资源

编写原生(Vanilla) JS，防止应用第三方脚本

<span style=”font-weight:800;color:#FFA500;font-size:18px”>{缓存 | Caching}</span> 和 <span style=”font-weight:800;color:#FFA500;font-size:18px”>{生效 | Expiring}</span> 内容

HTTP 缓存

Expires 和 Cache-control:max-age=x(强缓存)

`Etag` 和 `If-None-Match`（协商缓存）

JS 层面做缓存解决(ServerWorker)

React 利用中的优化解决

阶段一（加载前）

阶段二

应用正确的状态治理办法

利用 React.Memo

后记

Just My Socks（注册教程内含优惠码）

关于程序员:性能优化之关键渲染路径

你能所学到的知识点

1. 加载阶段要害数据

<span style=”font-weight:800;color:#FFA500;font-size:18px”>{文档对象模型 | Document Object Model}</span>

CSSOM Tree

执行 JS

ECMAScript

示例演示

要害门路相干术语

缩小渲染器阻塞资源

懒加载

Async, Defer, Preload

应用 Async 解决脚本

应用 Defer 解决脚本

应用 Prelaod 解决内部资源

编写原生(Vanilla) JS，防止应用第三方脚本

<span style=”font-weight:800;color:#FFA500;font-size:18px”>{缓存 | Caching}</span> 和 <span style=”font-weight:800;color:#FFA500;font-size:18px”>{生效 | Expiring}</span> 内容

HTTP 缓存

Expires 和 Cache-control:max-age=x(强缓存)

Etag 和 If-None-Match（协商缓存）

JS 层面做缓存解决(ServerWorker)

React 利用中的优化解决

阶段一（加载前）

阶段二

应用正确的状态治理办法

利用 React.Memo

后记

Just My Socks（注册教程 内含优惠码）

`Etag` 和 `If-None-Match`（协商缓存）

Just My Socks（注册教程内含优惠码）