# 抛出"问题" 我们先来阐述阐述问题,今儿在写一个有关于新手指引的公用组件，类似于这样的形式: ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ddf69db9e47a49fc95197f2a36ea23c5~tplv-k3u1fbpfcp-watermark.image?) 我相信大家首先想到的思路就是在`useEffect`中通过`getBoundingClientRect()`获得对应传入元素(`id`)的位置，然后通过定位增加一个类似的弹窗效果。当我天真的以为这样就可以实现它的时，我碰到了一个"无从下手"解决的问题。 > `useEffect`中获取`getBoundingClientRect()`的值是随机的？随机的？？？作为一个基本的程序员，随机的代码执行结果，这我怎么能够接受呢！我们来看看简化后的代码: ## "问题"代码 ```ts // 代码已经是很简化的版本了仅仅保留了核心的内容 import React, { useEffect } from 'react' import './_index.scss' const GuideBeta = () => { useEffect(() => { console.log(document.getElementById('step1')) console.log(document.getElementById('step1')?.getBoundingClientRect()) }, []) return (

第一个指引

第二个指引

) } export { GuideBeta } ``` 上面代码其实很简单，渲染两个`id`为`step1`和`step2`的元素，然后在`useEffect()`之中去打印获取`id`为`step1`的元素。差不多页面渲染出来就是这个样子: ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e5717be04aeb464fb0251cd4c2b3c6f3~tplv-k3u1fbpfcp-watermark.image?) ## 输出结果这个是正常的输出结果: ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9fa2588f96c444e9b5ab5bfb518a8d21~tplv-k3u1fbpfcp-watermark.image?) 当时当我们尝试多刷新几次页面来看看打印结果: ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e6b9ce054d654bfd861a58375bd1c0b4~tplv-k3u1fbpfcp-watermark.image?) 也许你会奇怪是不是我代码写的有问题，这里先卖个小关子**两次不同的打印结果，产生的原因和业务代码没有任何关系**。要搞清楚这个问题，我们需要从一些基础的理论知识来层层递进。 > 血与泪的教训，我`checked`了我的代码整整一早上... # 浏览器加载机制关于浏览器加载机制其实我相信大家已经老生常谈了，这里我结合上边两次不同打印的原理来稍微聊聊对应的机制: **`js`执行浏览器会被`js`引擎"霸占"，从而导致渲染进程无法执行阻塞`DomTree`的渲染的，那么`Css`呢？`css`加载是否会阻塞`Dom Tree`的渲染呢？** 让我们带着这个问题来谈谈`css`是否会阻塞`Dom Tree`的构建。 ## `css`加载是否会阻塞`Dom Tree`的渲染和解析 ### 验证`css`加载和`Dom Tree`的关系我们尝试先来看看这端代码: ```html Document

大大的标题

``` 代码其实很简单，就是在`js`脚本中定时器中获取`h1`标签。之后引入了`bootstrap`样式库。 > 注意：我们需要将浏览器中"网络"限制为`SLOW 3G`进行测试。 ![Filmage-2021-10-11_193844.gif](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/06ccb4465e114ad4b4d087ceca04de15~tplv-k3u1fbpfcp-watermark.image?) 通过上边的表现，我们可以看到当页面加载中。`js`脚本中的`setTimeout`已经成功的在控制台打印出来了`h1`标签对应的元素。也就是说 **`css`还未加载完成，我们就已经可以获取到对应的`Dom`**, 所以 **`css`加载并不会阻塞`Dom Tree`的构建。** 但是同时注意到，当`css`文件加载完成后页面才会渲染出来蓝色的`大大的标题`，也就是说**当`css`文件加载完成后，页面才会进行渲染。** 此时我们可以得知`css`的加载是会阻塞`Render Tree`的渲染的，你可以暂时理解成`Render Tree`为`Dom Tree`，之后我们会在后边详细讲解。 ### `css`对于`Dom Tree`结论我们来谈谈关于`css`加载的结论: 1. `css`加载并不会阻塞`Dom Tree`的构建，因为`css`还未加载完时我们已经可以获取到对应的`h1`标签了。 2. `css`加载会阻塞`Dom Tree`的渲染，只有当`css`加载完成后页面才会渲染出蓝色的`大大的标题`。 ## `css`加载对于`js`的影响那么`css`加载对于`js`的是否有影响呢？废话不多说我们来看代码: ### `css`加载对于`js`验证 ```html Document

大大的标题

``` 我们先来看看这段代码执行结果，同样是在`SLOW 3G`情况下: ![Filmage-2021-10-11_201815.gif](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a40e59e3c90d46c38011012ef9c220b8~tplv-k3u1fbpfcp-watermark.image?) 我们可以看到两次脚本相差`2550ms`，正好是`css`代码加载完毕之后才开始执行了后边的`script`脚本。 ### `css`加载对于`js`的结论同样我们得知,**位于`css`代码之前的`js`代码加载执行是毫无疑问的，但位于`css`加载之后的代码，`css`代码的加载是会阻塞后续`js`代码的执行的**。 ## `css`加载结论我们稍微来总结一下目前关于`css`加载的结论: 1. `css`代码加载并不会阻塞`Dom Tree`的构建。 2. `css`代码加载是会阻塞`Dom Tree`在浏览器上的渲染。 3. `css`代码加载是会阻塞后续`js`代码的执行。 ## 造成`css`加载的原理上边我们已经总结过了`css`加载对于`Dom Tree`、`js`、`Render Tree`(`Dom Tree`在浏览器上的渲染)部分的表现和总结，现在我们来看看造成这一切的原因: ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5621a16d35854e3d95de7e79c28395f4~tplv-k3u1fbpfcp-watermark.image?) 一次浏览器的渲染流程大概就是如此，关于`layout`->`paint`->`composite`**关键渲染帧**涉及到一些重塑和回流的知识这部分内容之后我会详细为大家介绍。 **我们先来关注下`HTML`和`Css`的加载其实他们是并行加载，这也就印证了我们上边提到的`css`加载并不会影响`Dom Tree`的构建。** 但是我们可以看到，当`cssom`和`dom tree`家在完成后会合并成为一个`Render Tree`，浏览器会根据`Render Tree`的元素和布局进行渲染，这也就是我们上边说到的**等到`css`文件加载成功后浏览器才会渲染出内容**。同时浏览器的渲染引擎和`js`的解释引擎他们是互斥的，也就是说`css`加载和`dom`加载都会和`js`执行加载互斥的。(当然排除`scirpt`标签上的`defer`和`async`)属性。相关浏览器加载原理部分大概就提到这里，我相信结合实际出发去读原理才会让人印象深刻。结合上两个`Demo`实例我相信大家已经能很好的拿原理思路来佐证我们的结论。接下来让我们回归文章开头的问题，来一探究竟: ## 回到问题本身针对为什么我们在`useEffect`中获取到的`Dom`元素是正常的，但是打印`getBoundingClientRect()`的值却可能会出现两种结果呢？看到这里我相信你已经能大概猜出来结果，没错！他和我们的业务代码没有一毛钱关系，完全取决于`css`文件的加载！！(真的是坑惨我了😭) ### 偶发正常情况分析我们先来看看当值打印正常时候的`net work`控制面板: ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1e572f7ad4874169a96f53efab6110f5~tplv-k3u1fbpfcp-watermark.image?) ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c5a44a30ce69479e92ea86b6915be03e~tplv-k3u1fbpfcp-watermark.image?) + `console.js`是我们`react`代码，包含对应业务逻辑。 + `console.css`是我们业务的`css`代码，包含对应的元素位置定义。我们可以看到，我们的`css`代码是远远早与`js`代码加载完成的，也就是说在`js`代码执行之前页面其实就已经正常渲染了(`cssom`和`domTree`合成正确的`render Tree`)，所以此时我们通过`useEffect`执行完毕拿到的就是正确的位置`getBoundingClientRect()`。 ### 偶发非正常情况分析我们来看看偶发非正常`getBoundingClientRect`打印的结果: ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ff5b3f5037534753a6ccfa9803d539c9~tplv-k3u1fbpfcp-watermark.image?) 要解释清楚这个问题，我们首先来看看`html`中`js`文件和`css`文件的顺序: ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1a579a99fa24fc79049f87442e76a8e~tplv-k3u1fbpfcp-watermark.image?) 这是`html`中的`head`标签中加载两个脚本的顺序，`js`文件引用了`defer`属性。 > 所谓`defer`意思是说`js`的加载会异步执行并不会阻塞后续加载，按照加载顺序在文档完成解析后，`DomContentLoaded`事件前依次执行对应加载完成的`js`脚本。[有关`defer`详细信息你可以在这里看到](https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/script) > 所谓的`DomContentLoaded`事件，当初始的 **HTML** 文档被完全加载和解析完成之后，**`DOMContentLoaded`** 事件被触发，而无需等待样式表、图像和子框架的完全加载。你可以理解成为当`Dom Tree`构建完成后就会触发`DomContentLoaded`事件。此时也就是说我们的`script`脚本会异步加载等待`Dom Tree`解析完毕后,`DOMContentLoaded`事件调用前进行执行。此时我们来看看对应的网络请求结果: ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/738530166c9f4e35ba7795a096bc7557~tplv-k3u1fbpfcp-watermark.image?) 是我们的`js`加载快于`css`加载`13ms`完成。当`js`加载完成后`css`还在请求`download`中，此时由于`dom Tree`已经构建完毕符合我们`js`的执行时机,所以此时`js`优先于`css`执行完成。当我们执行`js`时页面上并不存在任何样式，此时我们通过`getBoundingClientRect`获取的值自然是不正确的（其实获取的就是不存在样式时候的位置值）。 > 由于`defer`脚本已经完成，所以在`css`加载过程中其实线程是空虚的，所以此时`js`引擎会执行加载完成的`defer`脚本进行执行。造成`js`提前与`css`执行完毕。 ### 解决方法其实解决方式存在很多种，最简单直白的方式就是利用`window.onload`事件。 > The **`load`** event is fired when the whole page has loaded, including all dependent resources such as stylesheets and images. This is in contrast to [`DOMContentLoaded`](https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event "DOMContentLoaded"), which is fired as soon as the page DOM has been loaded, without waiting for resources to finish loading. 当然你也可以有自己的方式，清楚了问题的本质后有很多种方法都可以实现。 ## 总结我们来稍微阶段性总结一下: 1. `css`的加载是会阻塞后续`js`的执行的，后续`js`会等待`css`加载完成后才会执行。 2. `css`的加载并不会阻塞`Dom Tree`的构建。 3. `css`的加载是会阻塞页面渲染的，因为页面渲染的`Render Tree`是需要`css om`和`dom tree`进行合并从而渲染页面的。 **Tips:** 关于第二点，`css`的加载并不会阻塞`Dom Tree`的构建，但是如果在`css`文件之后存在`js`脚本，`js`是会阻塞`dom tree`的构建的，因为`css`加载阻塞了`js`执行，所以间接的阻塞了`dom tree`的构建。同时在不同浏览器下可能会有不同的解释机制，这里绝大多数情况下是针对于`chrome`进行的解释。文章中由于业务引发的"血案"就到此为止了，我们已经阐述了对应发生的机制以及`why to do`。当然浏览器执行机制我相信文章的讲述还是比较片面，如果有兴趣我们可以在评论区互相交流。